AI 写九成代码，人工审查如何分级

Claude 写了 Claude Code 约 90% 的代码，Anthropic 怎么审？这篇短文给出的答案是：先让自动检查提供证据，再按风险决定需要几个人批准。重点不是确认「有没有人读过」，而是弄清哪里可能出错、由哪道检查负责发现。

对正在用 AI 写代码的团队，值得借鉴的是审查流程怎么分工。但原文报告的效率和质量改善，是否由这套流程直接带来，还缺少足够证据。

人工审查之前，AI 要先证明代码能用

按原文描述，每个 PR 都先经过自动检查，再进入人工环节。Claude 需要用测试和截图证明自己的工作；多个 AI reviewer 寻找缺陷并投票，只有取得共识的问题才会发布。安全问题则会阻止合并。

这套安排想解决的，是让人工把时间花在需要判断的地方。测试提供可重复执行的验证，截图提供界面结果，AI reviewer 则补充寻找潜在缺陷。它们各自提供证据，供后续审查使用。

但「多个 AI 一致」仍不等于结论正确。原文没有说明 reviewer 是否使用不同模型、投票门槛是多少，也没有交代如何处理漏报和误报。能确认的是流程里有共识筛选，不能据此认定它已经消除了审查盲点。

谁写的不决定审批人数，改到哪里才决定

他们团队把改动分成三个风险等级：

• 低风险包括文档、文案，以及带有特定标记的增量改动，需要 0 个人工批准。
• 中风险是普通产品改动，需要 1 个人工批准。
• 高风险包括计费、自动更新器和 CI 工作流，需要 2 个人工批准。

分类器根据改动本身确定等级，不根据作者是谁。Agent 的批准也不能算作人的批准。

这里有两个边界容易被忽略。第一，0 个人工批准不等于跳过检查，前面的自动验证依然存在。第二，原文没有解释低风险里的「带标记的增量改动」具体如何界定，不能直接把所有新增代码都归到这一档。

风险分类让审查资源有了明确去向，但分类器本身也可能判断错误。原文没说误分级如何纠正，这会影响其他团队照搬它的可靠性。

最可借鉴的，是把过去的事故变成评测题

原文报告了三项结果：三个月内，合并 PR 数量翻倍；回滚减少 40%；一轮通过审查的 PR 占比从 65% 提升到 78%。

这些数字很直观，不过更容易落地的做法是：每次历史事故，都转成 AI reviewer 的评测用例。以后修改审查提示词，如果不能抓到更多过去出现过的缺陷，就不发布这次修改。

审查提示词也要用已知缺陷验证，不能只凭读起来更专业就上线。

这里的评测（eval），就是用已经知道答案的缺陷案例，检查 reviewer 能否识别问题。这样至少能判断一次提示词修改有没有改善对历史问题的识别能力，而不是只看它生成的评论是否详细。

我的判断

我赞同按风险分配人工审批，也赞同把历史事故沉淀为评测。相比每个 PR 都机械地要求相同人数批准，这种做法更能解释：为什么计费改动需要更多关注，文案修改可以走得更快。

但原文是一篇短文转述，称信息来自 Claude Code 团队在 claude.dev 于 2026 年 10 月发布的文章，没有提供完整实验设计。PR 数量、回滚和一轮通过率的变化，也缺少团队规模、改动粒度、统计口径及对照数据。它们可以作为团队报告的结果，不能直接当成这套流程的因果证明。

AI reviewer 的共识机制，也需要和已有的测试、静态检查、人工审查配合。多个 reviewer 如果共享同一种盲点，投票未必有帮助。历史评测同样只能覆盖已经见过的问题，对新类型缺陷有多大效果，原文没给答案。

能拿来做什么

• 给前端和 Node 仓库列一张风险表，先明确文案、普通功能、计费及 CI 改动各需要多少人工批准；原文没定义清楚的低风险类别，先保留人工判断。
• 要求 AI 提交 PR 时附上验证证据：功能改动提供测试结果，界面改动附截图，让 reviewer 能核对实现结果。
• 从历史回滚和线上事故中整理审查用例，每次调整 AI reviewer 提示词，都检查它能否识别这些已知缺陷。
• 在代码托管平台上区分 Agent 审查与人工批准，确保要求 1 人或 2 人审批的规则，不会被自动账号满足。