AI 辅助沟通审阅

这项技能的产物是给人看的，所以判据也只能是人：不是「生成得更快」，而是对方少问了一轮。这一点决定了它和站里其他几条实践的分工——那些评的是模型的输出，这一条评的是一份要发出去的东西。

先分清是替你写，还是替你审

两种用法的代价完全不同。替你写：草稿来得快，但你要为「读起来很对、事实是错的」兜底。替你审：不产出内容，只指出问题——风险低得多，收益却经常更大，因为工程沟通里出问题的多半是遗漏，不是措辞。

默认从「替你审」开始。等你能稳定说清什么算一次好的审阅，再考虑让它替你写。

最好用的一招：让它先当读者

发出去之前，让模型以收件人的身份复述：它认为你要它做什么、期限是什么、有哪些前提你没写。复述不准的地方，就是真实读者也会误解的地方。

这比「帮我润色一下」有用得多，因为它测的是可理解性，不是文采——而润色恰恰是最容易的一步，也是最不缺的一步。

GitHub 那次复盘给了最硬的证据

他们把 Copilot 代码审查换到维护更好的共享 CLI 工具上，基准反而更差：审查成本更高、抓到的问题更少。真正翻转局面的是把「审查者实际怎么读一个 PR」写进指令，成本降约 20%、质量不变。

可迁移的那一点不是「指令比工具重要」，而是：审阅质量取决于你有没有把「一次好的审阅长什么样」写下来。写不出来，再强的工具也只是把模糊的要求执行得更快。

三种典型的失败

1. 润色盖住了缺口。 文字顺了，但「谁负责、什么时候、不做会怎样」依然没有。
2. 把不确定改成了确定。 模型倾向于抹平犹豫，而工程沟通里「我不确定 X」常常是最重要的一句。发出去前专门回看一遍被删掉的限定词。
3. 对外的东西没有人过。 这类属于必须事前授权的一档，交给《人在回路的审查》。

与相邻条目的分工

截图与图像怎么组织、怎么确认模型读对了，是《视觉输入的组织与核验》；把「什么算好」写成一句能判错的标准，是《模型与输出评估》；哪些沟通必须有人过目，是《人在回路的审查》；团队整体学得快不快，是《反馈闭环与团队学习》。这一条只管一件事：一份要给人看的东西，发出去之前怎么让它更难被误解。