这周关于 AI 代码评审最有用的一句话，跟工具无关，跟我们用来判定「这个改动安全了」的那个问题有关。Addy Osmani、Morgan Westlee Lunt、Qing Wang 在讲 Claude Code 团队如何做代码评审时提出：「有人读过这段代码吗」并不是我们真正关心的那件事的好替代品。Simon Willison 在 2026 年 10 月 16 日把这段话摘了出来。来源：https://simonwillison.net/2026/Oct/16/code-review/
关键事实
| 项目 | 内容 |
|---|---|
| 回答的问题 | AI 写的代码怎么评审？Claude Code 团队说「有人读过吗」问错了 |
| 简答 | Simon Willison 摘录的一段话里，Addy Osmani、Morgan Westlee Lunt、Qing Wang 提出：「有人读过这段代码吗」只是「这次改动可能出什么问题、该由哪道检查（自动或人工）来兜住」的不精确替代品。这个换问法把评审从事后闸门，变成了写代码时的拼写检查。 |
| 阅读时长 | ~4 分钟 |
| 最后更新 | 2026-10-17 |
原话
「我们认为『有人读过这段代码吗』，只是『这次改动可能出什么问题、该由哪道检查——自动的还是人工的——来兜住它』的一个不精确替代品。问出这个问题，也改变了评审发生的时点。以前评审是路的尽头一道闸门：写完代码、开 PR、等同事。现在评审是持续跑的，更像你打字时的拼写检查。大多数改动在被要求人看之前，已经被 Claude 至少审过并修过一遍。这拦住了大部分常规错误，把团队的注意力省下来给更高层的问题和真正的审查。」
这里其实有两个可以拆开的判断。第一，度量对象错了：diff 上有个签名，并不能说明这个 diff 安全。第二，时点因此改变：如果你需要的是一道特定的自动检查，那它可以持续跑，不必等到最后开个会。
为什么「有人读过」不再是有用的替代品
这个替代品在「读」是昂贵环节的年代是成立的。一个人必须把 diff 装进脑子里，读就是评审，他读懂了，大致就等于覆盖到了。
智能体以一种很具体的方式打破了这个前提：它们产出 diff 的速度超过任何人读的速度，而且这些 diff 通常很无聊。人快速扫四十个智能体生成的改动，测的其实是耐力。更糟的是，这种扫读没有针对性——重命名一个变量和改掉重试策略，花掉的是同样的注意力。
换上的问题更窄、也更可回答：就这次改动而言，可能的失败模式有哪些，每一类由哪道检查兜住？这个问题会立刻把改动分成三堆：测试能钉死的、需要人看一眼的、以及机械可验证所以两者都不需要的。
评审是拼写检查，不是闸门
第二个判断是操作层面的，也是最容易被低估的部分。评审前移不只是「早点审」，它改变的是评审的用途：
- 闸门的作用是拦住发布，天然产出是一个是/否，代价是延迟。
- 拼写检查的作用是边写边消噪，天然产出是一个更干净的 diff，单次代价接近于零。
如果大多数改动已经过了一遍 Claude，人的工作就从「找错别字」变成「这是不是对的改动、在不在对的位置、影响半径有多大」。这是资深注意力更好的用法，也恰好是智能体最弱的地方——它依赖 diff 里没有的上下文。
这套做法自己会长出的毛病
持续评审也有它的病理，作者的措辞其实已经暗示了：如果一切都「被 Claude 审过」，人的批准很容易变成仪式。签名回来了，只是前面多了个机器的名字。
三个习惯可以挡住它：
- 点名检查，而不是点名读者。 每个 PR 写清一两个真正值得担心的失败模式。如果一个都对不上，说明你还没想过这个改动。
- 高风险 diff 保留对抗性阅读。 鉴权、数据迁移、钱、删除、任何碰到构建或发布路径的改动——这里人还是要用以前的怀疑眼光读，并且说得出自己验证了什么。
- 记录到底验证了什么。 「已评审」不是证据。「在副本上跑了迁移、确认了回滚、核对了重试上限」才是。
放到 Windows 桌面智能体上是什么样
在本地跑智能体的人大多没有评审团队，只有自己。这个换问法仍然有用，因为它把模糊的愧疚感（「我该把这些都读一遍」）变成了一张清单：
- 按风险给 diff 分堆。 智能体只新增内容的文件风险低；碰启动项、安装包、凭据、计划任务的，一点都不低。
- 先跑无聊的检查。 构建、类型检查、冒烟跑一遍。这些是红的，读就是白读。
- 高风险的自己读，而且读出声。 用两句话解释这个改动；解释不出来，就是没审。
- 把证据留在改动旁边。 一小段「跑了什么、核对了什么」比一个点赞有用得多。
MOOGH 就是为这个循环做的：在本机跑、每一步动作可见、关键步骤仍由你批准——[下载 MOOGH]。
不太好接受的部分
如果问题真的是「这次改动该用哪道检查」，那么对很多改动，诚实的答案是：我们还没有那道检查。这段话不是在宣布评审问题解决了，而是在说「数了几双人眼」从来衡量的就不是安全性。认真对待它的团队，最后会写更多测试、写更明确的风险说明——前期更累，返工更少。
常见问题
这是在主张取消人工评审吗？ 不是。它主张把人工评审对准自动化答不了的问题，同时把能自动化的检查改成持续跑，而不是攒到最后。
一个人写代码也适用吗？ 适用，而且更容易。要省的「团队注意力」就是你自己的，纪律也一样：点名失败模式、跑检查、把高风险部分认真读完。
原文在哪？ Simon Willison 的摘录里链到了 Claude Code 团队那篇讲代码评审的文章；引文作者是 Addy Osmani、Morgan Westlee Lunt、Qing Wang。
相关阅读：