AI 编写并审查代码：当合规控制失去原义

Anthropic 近日披露，Claude 现已编写其合并到生产代码库中的 80% 以上代码，而这一比例在 Claude Code 于 2025 年 2 月推出时尚处于个位数。与此同时，越来越多的代理开始承担代码审查工作，人类逐行阅读输出的频率大幅下降。这一变化正与现行合规框架发生正面冲突——几乎所有 SOC 2 或 ISO 27001 项目仍要求「变更在部署前须由第二位合格人员审核并批准」。控制语句还在，但已无法描述实际发生的工作。

失效的控制：PR 审批的式微

十年来，拉取请求（PR）审批一直是变更管理的标准证据：一名工程师发起 PR，另一位评论或点击通过，平台留下一条带两个名字的整洁记录。然而，当代理既写代码又做审查时，所谓「人工审批」要么缺失，要么流于形式。控制或许仍能通过审计，却不再具备原本的含义。

工程师可能为了留下证据而对未阅读的差异点击通过，审计也可能中途发现那位「第二审核人」已经数月未真正审过任何东西。前者从内部腐蚀制度，后者则带来仓促而尴尬的整改。与其等到被动应对，不如主动重新设计这一控制。

代码审查原本承担的五项职能

回看过去，PR 审批其实把五件事打包进了一次 GitHub 点击：

• 缺陷检测：在代码进入生产前发现 bug。
• 意图验证：确认变更解决了正确的问题。
• 独立性：由没有作者偏见的第三方审视工作。
• 知识传递：第二位人类由此理解这项变更。
• 问责：审批背后附着一个具体的人名。

其中，缺陷检测通常是人们最先提到的理由，却也是最弱的一项。人类审阅动辄上千行的差异时往往只是略读，差异一旦超过几百行，审查有效性便急剧下降。审计人员接受 PR 审批，并非因为它能可靠地发现 bug，而是因为它提供了其余四项——尤其是独立性与问责——的可读证据。

代理同时占据写作与审查两侧

如今，代理既写代码也写测试，其他代理则负责审查 PR。专用工具扫描逻辑错误、安全漏洞与回归，按严重度排序，并在通过既定门槛后自动合并变更。这背后的经济学逻辑清晰：自动化正确性检查变得更便宜也更准确，而人类注意力始终是稀缺资源。让资深工程师去逐行阅读一份 2000 行的代理产出，既增加不了多少保障，又消耗了宝贵的判断力。

审查本身并未消失，只是工作产物的验证走向了自动化，人类注意力向「差异之上」的决策上移。关注的焦点不再是「代理写对了没有」，而是「它是否在做正确的事、遵循了正确的规则」。Anthropic 内部也以类似方式描述这一转变：少关心 Claude 是否把事情做对，多关心 Claude 是不是在做对的事。

尚未被命名的独立性问题

最直接的质疑是：同一个模型既写又审，等于一个心智在检查自己的工作，作者与审查者会共享同样的盲区。这一风险确实存在，但模型并非确定性的——「把这个功能上线」与「找出让它回滚的缺陷」会催生不同的工作，目标、上下文、脚手架与采样都会变化，两次运行可能在不同位置出错。

真正关键的是双方失误的相关性。降低相关性有三条路径：

• 给双方设置不同的目标：作者努力让变更通过，审查者努力打破它；第二次审视应当是对抗性的，而非礼貌的。
• 让审查者从干净上下文起步，不继承作者的合理化解释与半成形的心智模型，仅基于差异与规格审视更易发现被作者忽略的错误。
• 使用与作者无关的工具链：属性测试、契约测试、模糊测试、静态分析与执行环境应置于写作代理控制之外，代理既不编写也不编辑这些检查。

对抗性提示并不能解决全部独立性问题。某些错误源于训练数据中固有的共识，提示无法填补模型知识的空缺。因此，外部「测试脚手架」比再增加一轮审查更重要——属性测试、模糊测试、静态分析与执行并不是模型，不会共享模型的盲区，作者与审查者都认同的错误仍须经过双方均未撰写的检查才能存活。

脚手架同样无法覆盖一切。新的逻辑判断仍依赖对抗性角色与干净上下文，部分风险始终存在，无论由人类还是机器执行审查。理解这一点，也是看待「maker-checker」机制的合理方式：金融控制从来不要求审核人必须是另一种人，它要求的只是岗位分离、独立可见性与驳回权——独立性是结构性的。