先说一个核心判断：要让 Claude 生成的评审问题直接粘贴到目标平台——无论是飞书、钉钉还是 Confluence——关键在于事先吃透该平台的文本承载规则。这事儿看似只是小细节，但如果不做对，AI 输出的内容复制下来也毫无用处：格式混乱、换行丢失、符号被转义，最终只能手动重改。

以飞书为例。如果你打开一个飞书文档的评论区，试着输入「-」或「*」，它会自动识别并转为列表格式；但如果你想粘贴一个表格进去？抱歉，飞书原生不支持 Markdown 表格。换个平台，钉钉的评论区在输入栏里有个「插入代码块」的按钮，点击后才能用 ``` 包裹代码，否则你写好的缩进全被抹平。Confluence 呢？旧版空间默认走 Wiki 标记，新空间却可能是富文本编辑器，两种模式下的语法规则截然不同。

所以，在改写提示词之前，一定要做一步看似不起眼却至关重要的动作：打开你目标平台的实际需求文档页面，新建一条评论或批注，输入几个字，然后暂停查看实时预览效果。接着，从当前平台上复制一段你认可的结构清晰、格式规范的评审问题样本——比如飞书文档里 PM 写的真实提问：“① 用户退出登录后，本地缓存的 token 是否清除？② 未登录用户点击‘我的订单’，前端跳转逻辑是 401 还是重定向到登录页？”——把这当作参考模板保留下来。

按平台特性重构提示词结构

方法并不复杂，但每个平台的写法都需要量身定制。

飞书风格的核心是：序号 + 短句 + 问号结尾。不要把原始提示词写成“请列出 5 个关键风险点”这种模板化指令，要换成更具体的说法：“用阿拉伯数字编号，每条独立成行，每条以问号结尾，单条不超过 30 字，不加粗不加列表符号，不解释原因”。为什么？因为飞书评论区对纯文本兼容性最好，但一旦混入空行或冒号引导语，AI 就很容易生成带缩进或分段说明的冗余内容，粘贴后必须手动修正。

钉钉那边则需要适配评论区 + @功能。在提示词末尾追加一段话：“所有问题必须以‘@相关角色’开头，例如‘@后端 @测试’，每个问题后换行，禁止使用项目符号，禁止合并多角色到一个@里”。道理很简单：钉钉评论区不识别 Markdown，但支持 @ 触发提醒，漏掉这一个字符，问题基本等于没发出去。

Confluence 则要适配页面批注与宏。把原来的“给出评审建议”替换为：“输出为无序列表，每项以‘- ’起始，且每行开头插入 {color:#FF6B35}⚠️{color}，不使用标题、不空行、不加链接”。这里有一个坑需要注意：如果 Confluence 空间启用了新富文本编辑器，{color} 宏就会失效，这时需要改成 ⚠️，而且必须在粘贴之前先预览确认效果。

验证与微调

改成什么结构是一回事，能不能落地是另一回事。你需要完成完整的四步验证。

第一步：在平台对应的位置——比如飞书文档的评论框——把改写后的提示词粘贴进去，给 Claude 发送一次测试请求。

第二步：检查返回结果是否满足中间那三项硬指标：行数和预期编号一致；每行末尾都有问号；没有意外换行、没有多余空格、没有中文全角标点夹杂英文符号位置。

第三步：如果发现细节问题，比如“① 是否……？”变成了“①是否……？”（少了一个空格），那就需要在提示词中明确补上一条规则：“数字编号后必须跟一个半角空格”。

第四步：复制返回结果，直接粘贴到真实需求文档中，观察平台会不会自动格式化——飞书很可能把“1.”转成有序列表，钉钉可能把“- ”识别为列表项。如果自动格式化反而导致层级错乱，就不得不在提示词中禁用所有引导符号，改用纯数字加顿号。

这套流程走下来，不仅是修改提示词，更是把 AI 输出的文本与你实际使用的工具之间的差距给填补上。表面看是格式问题，底层却是工作流效率的问题。