AI 代码提审后，谁来承担审查成本

同事用 AI 很快写完一个大改动，为什么接手评审的人反而更忙了？作者认为，代码生成把成本推到了下游：提交者交来大量代码，评审者却要重新确认需求、理解实现，再判断所谓的验证是否可信。

这篇文章的建议很明确：开工前约定什么才算完成，用实际检查证明结果，并限制每次提交的规模。它值得读的地方，在于把「AI 代码质量」的问题，落到了团队可以执行的交付规则上。

代码写得快，成本可能落在别人身上

作者团队梳理了过去一年约 7,000 条与 coding agents 协作有关的 Hacker News 评论，筛出 178 条工程师描述实际出错经历的评论。其中 23 条涉及别人生成的 AI 代码，接手者需要评审、修复或维护；这 23 条里有 6 条被他们评为高严重程度，比样本中的其他主题都多。

这些数字能说明他们发现了一组反复出现的问题，但不能据此推算行业发生率。评论来自主动发言者，筛选又聚焦失败经历，文章也没交代严重程度的具体评级标准。

案例比数字更直观：

• 有工程师花了数小时评审外包提交的 3,800 行 shell 脚本，对方却答不上来系统的基本问题。
• 有同事把半成品交给模型续写，交回来的实现偏离了业务需求。
• 另一个团队交付的功能，需要接手者花一周多删改和重新设计，才能适配主 API，最后显得进度慢的却是修复者。
• 有些「验证脚本」只会打印作者预期的结果，并没有证明功能真的运行正确。

还有负责人为了赶预算放行外包生成的代码，之后持续还债。开源维护者则把大量生成式 PR 比作针对注意力的拒绝服务攻击。

提交速度提高，并不等于团队完成工作的速度提高。

为什么只要求评审更严格还不够

面对这些问题，常见反应是逐行严查、限制新人使用 agent，或者直接停止与问题外包合作。

这些办法可能有用，但作者指出，它们都发生在工作完成之后。评审者收到的仍然是一份 diff 和一段说明，而且两者可能出自同一个人，甚至同一个 agent。评审者得先猜清楚「到底应该做什么」，才能判断代码有没有做好。

作者提出了五条交付规则。

第一，开工前写明需求和验收标准，精确到可以通过测试检查。比如「提交后显示成功」还不够，还得明确什么操作成功、什么条件下失败。否则评审只能围绕实现反推需求。

第二，提交者不能单方面修改验收标准。如果实现做不到，就顺手把「完成」的定义改掉，验收便失去了约束力。这里要保护的是标准的修改权，文章没有说清业务需求确实变化时该走什么流程。

第三，证明必须来自实际执行的检查。测试要在 CI 中触发目标行为，而不是打印一条成功消息，也不能只凭作者保证。

第四，限制提交规模。大到无法有效评审的变更，要拆分或退回。文章没有给出统一的行数上限，重点是团队是否具备审清它的能力。

第五，所有人使用同一套门槛。无论代码来自人工、agent、外包还是资深工程师，都检查它是否完成约定的事情。

评审需要一份事先确定、提交者不能随意改动的依据。

DynoKore Keel 把这些规则落实到了哪里

作者团队的大部分代码由 agents 编写，因此接收「别人的 AI 输出」是日常工作。他们开发的 DynoKore Keel，试图让变更在进入评审前就有明确依据。

需求、验收标准和任务都是有版本记录的条目，每次变更都需要追溯到这些条目。测试必须证明相应验收标准成立，编码 agent 无权修改验收标准。

此外，一个独立的 reviewer agent 会检查每个 merge request，测试本身的修改也包括在内。任务只有在需求追溯链存在，并通过 Keel 的 readiness check 后，才能标记为完成。

大白话解释，这套流程要回答三个问题：为什么改、拿什么证明改对了、谁有权修改判断标准。

这里需要区分设计与效果。文章介绍了他们怎么做，却没有提供上线前后的评审耗时、缺陷率或返工量对照。作者也承认，团队规模很小，「同事」大多是 agents，还没验证这套机制在拥有大量人类作者的大型组织中能否成立。他们正在通过 design partners 探索这一点。

我的判断

我赞成把需求和证明前移，尤其是「测试也需要评审」这一条。提交者如果同时控制实现、测试和验收定义，很容易形成一套内部自洽、却偏离业务的结果。独立依据能让评审少做一部分需求考古。

但这仍然是一套有合理解释的工程经验，文章没有给出对照数据，不能替 DynoKore Keel 背书。

通过 CI 也不代表需求完整。测试可能漏掉关键场景，验收标准也可能一开始就写错。独立 reviewer agent 是否真能发现编码 agent 的盲点，原文同样没有提供证据。

与「逐行看得更仔细」相比，这套办法更适合控制进入评审的工作量；与限制 AI 使用相比，它也更容易统一执行。不过，团队未必需要先采购或搭建专门系统。已有的需求记录、修改审批、CI 和 PR 拆分规则，也能承载其中相当一部分做法。

能拿来做什么

• 给 AI 编程任务先写可检查的验收条件。涉及前端交互或 Node 接口时，把触发条件、预期结果和失败行为写清，再让 agent 开始实现。
• 把验收标准的修改单独交给负责人确认。agent 发现条件无法满足时，应报告差异，不能直接修改标准让任务通过。
• 评审时要求提供真正执行目标行为的 CI 检查，并检查测试改动是否削弱了原有约束。终端打印成功、作者口头保证，都不能代替验证。
• 为团队约定可评审的提交规模。遇到包含大量无关修改、无法一次理解的 PR，就要求按可独立验证的目标拆分，避免让评审者承担整包返工。