AI 代码激增，审查瓶颈在判断次数

AI 写代码越来越快，审查队列却可能越来越长。原文的核心判断是：团队真正缺的不是读代码的速度，而是判断每次改动是否完成任务的能力。面对大量 Agent 提交，把需求带进审查，比单纯增加 AI 审查工具更关键。

作者围绕 CodeRabbit、Kodus 和 GitHub Copilot code review，比较了需求从哪里进入、遗漏由谁确认、什么时候重新检查。对程序员有用的，是一套挑选和配置审查工具的方法；但文中没有团队落地后的效率对照数据，不能把它当成已经验证的提效公式。

审查为什么会被小改动拖住

作者引用 LinearB 的 2026 年软件工程基准，样本超过 810 万个 pull request。Agent PR 的代码行数中位数为 89 行，第 75 百分位为 293 行；无辅助开发在第 75 百分位为 157 行。审查开始前的等待时间，第 75 百分位分别是 17.6 小时和 3.4 小时。

这里要分开看。89 行说明不少 Agent PR 体量不大，但同一百分位下，293 行高于 157 行，不能拿这组数字证明「Agent PR 普遍更小」。它们也没有直接证明等待更久一定由 Agent 引起。作者提出的「改动更多、更碎」是全文的问题设定，所引数据只支撑了其中一部分。

这个设定仍然切中日常工作：十个小 PR，需要十次理解意图、判断边界、确认是否可以合并。总行数相近，判断次数却可能差很多。

作者因此主张，把「这段代码看起来对不对」改成「它完成了任务里的哪些要求」。前者容易让审查者每次重新理解上下文；后者有固定参照，可以列出已交付和未交付的项目。

需求必须进入审查上下文，否则模型再强，也只能围绕 diff 做判断。

不过，固定的是需求清单，不是验证成本。确认一个需求是否满足，仍可能需要读完整条调用链、检查测试，甚至运行系统。原文最后也承认，这套机制不会消除人工读代码的必要性。

工具能不能理解任务，先看它从哪里取需求

原文比较的三条路径，差别首先出在输入。

CodeRabbit 从 PR 描述里的关联关系读取 issue。GitHub 使用 fixes #123、closes #123 这样的语法；Jira 和 Linear 使用完整任务 URL。在 Azure DevOps，它还会读取原生 Development 界面关联的工作项，最多使用 200 个有效工作项。已删除或无权限读取的项目会被跳过，其余继续处理。

它给出的判断是 addressed、not addressed 或 unclear。但 issue 的评论和讨论线程不在分析范围内。需求正文说支持一种行为，后来在评论里决定取消，审查工具可能仍然按旧要求判断。因此，「已经关联 issue」和「拿到了完整需求」是两回事。

Kodus 的 Business Logic Validation 会依次从 PR 标题、分支名、描述中找任务 ID，再向连接的 Linear、Jira、Notion 或 Git Issues 读取任务。只有 tracker 返回完全匹配的 ID，引用才成立，避免把 UTF-8、gpt-5 这样的字符串误认成工单。

每个 PR 最多检查三个任务，还会跟进父任务和子任务；没有连接 tracker 时，可以把任务文本粘进命令。检查结果细到每条需求，状态包括 MET、PARTIAL、MISSING、CHECK MANUALLY、NOT IN TASK，并附上判断依据所在的文件和行号。

GitHub Copilot code review 则需要更谨慎地描述。按作者查阅的公开文档，它会参考仓库自定义指令和 review effort level，但配置文档及概念页没有说明承载本次任务要求的输入。

这只能得出「根据文档，需求检查能力未知」，不能推断产品内部一定没有相关能力。仓库规范告诉工具代码应该怎么写，本次需求告诉工具这次应该交付什么，两者解决的问题不同。

发现遗漏之后，谁能让它通过

生成缺项清单只是第一步。真正影响流程的是：谁有权认定这个缺项可以接受，这个决定能保留多久。

CodeRabbit 的关联 issue 评估会报告状态，但原文所查文档没有说明逐条需求的关闭机制。审查者有异议时，可以通过评论和标签处理。它的 Slop Detection 也不会阻止合并：识别出低质量 PR 后，会在 walkthrough 评论里警告，部分平台还会加标签，由维护者判断如何处置。

Kodus 则提供明确的 ACCEPTED 状态，而且接受缺项的人不能是 PR 作者。权限要求随平台变化：GitHub 需要 write access，GitLab 需要 Developer 或以上权限，Bitbucket、Azure Repos 和 Forgejo 需要组织成员身份。

只要任务文本不变，接受决定会保留到后续复检；任务被编辑后，相关需求必须重新接受。这个规则把「这次允许少做一点」变成有责任人的记录，也避免需求变了却继续沿用旧结论。

但 ACCEPTED 不等于强制合并门禁。原文明确说，Kody 的评论是信号，不是 status check，本身不会阻止合并。CodeRabbit 也没有在这里提供自动拦截的保证。

复检频率同样需要主动配置。CodeRabbit 会在后续审查中重新检查已加标签的 PR，完整分析没有发现问题后才清除发现。Kodus 默认在首次审查时检查，之后通过评论或强制审查触发；也可以配置成需求仍有缺项时，每次 push 都检查。

每次 push 都复检，就会让每次 push 都产生一次新的验证。

作者还提到工具定价中的每开发者补充额度和文件数量上限，但没有给出具体价格或额度。能拿走的判断是：自动检查也有成本，不能只看单次结果是否方便，还要看提交频率会把它重复多少次。

我的判断

我认同把任务要求带进审查。对前端和全栈开发来说，代码符合仓库规范，不代表筛选条件、错误提示、接口边界都按需求完成了。让审查结果逐项对应验收要求，至少能让讨论有明确落点。

但作者关于扩展性的结论偏强。需求数量固定，只能限制检查项目的数量，不能保证每项检查都便宜。跨文件行为、权限边界和隐含约束，未必能靠一行 MET 可靠确认。

这套做法还有一个组织前提：任务正文要完整、可验证，并且持续维护。临时决定都留在聊天记录里，或者一个 PR 混入多个未记录的改动，工具拿到的参照本身就不完整。Kodus 最多三个任务、CodeRabbit 不读 issue 讨论，也都是实际边界。

与只读 diff 的审查相比，需求校验补上了交付意图；与测试、人工审查相比，它提供的是另一层证据。原文没有报告误报率、漏报率，也没有给出启用前后的等待时间或人力变化，所以「更能应对规模增长」目前仍是有道理的工程主张和经验判断，不能直接当作效果承诺。

能拿来做什么

• 先抽查现有 PR 是否关联了可解析的任务，再决定是否启用需求校验。标题、分支和描述都没有任务引用，连接 tracker 也很难发挥作用。
• 给前端或 Node 任务写出能逐条验收的行为，并把讨论后的最终决定回填任务正文。尤其使用 CodeRabbit 时，不要指望 issue 评论里的变更自动进入检查。
• 试用工具时，核对一条需求从输入到输出的完整链路：工具读到了什么、依据哪段代码判断、哪些结果要求人工确认。不能只凭审查评论的数量判断效果。
• 在 Agent 频繁 push 的仓库里，先确定复检节奏和缺项接受人，再扩大使用范围；同时核实仓库已有的合并规则，避免把提示性评论误当成会阻止合并的检查。