2026-10-17 · 当时的记录
Agent能连续写代码以后，团队还要判断哪些改动可以合入。Claude Code团队10月15日介绍的流程，把审查前移到写代码时：先展示测试、构建等执行结果，再由新上下文检查；提交给团队合并的一组改动称PR，进入PR后分别进行缺陷与安全审查，并按风险确定人类批准要求。合并队列、分阶段开放和回滚承担后续防线。
自动化也会制造工作。一项PR曾一夜经历五十多轮检查与修复；团队追查发现，反复提出的内容约59%在第一次审查时已经存在。于是限制轮数，随后集中看新差异，一次指出整类问题并抑制重复发现。这里改变的是作者与审阅者互相触发新修改的过程，不能仅用评论多少衡量质量。
为防止少审等于漏审，团队每天回放经工程师确认的历史事故，并让审查器检查已知干净的PR，记录可能诱发有害修改的意见。作者自报6月至9月合并PR翻倍以上、回滚占比下降超过40%，但多项机制一起改变，尚不能归因到某个模型或轮数限制。外部评论进一步追问：机器承担阅读后，人是否还保有接手故障所需的系统理解。
本次记录的观点：Addy Osmani、Morgan Westlee Lunt、Qing Wang · status_quo69 · csallen
回到当期正文 ↗
查看依据
信息来源：Addy Osmani、Morgan Westlee Lunt、Qing Wang · claude.dev · 发现渠道：Simon Willison · 引文博客 · 发现渠道：Hacker News · 原始讨论 · 阅读原文：团队工程记录（页面日期10月15日） · 外部分析：status_quo69 · 经验反例：csallen2026-10-17 · 当时的记录
当 Agent 能连续提交改动，逐行人工审查很容易形成队列。Claude Code 团队介绍的流程是：提交前先运行测试、构建并由新上下文检查；PR 上分别进行缺陷与安全审查；按照改动风险决定需要多少人批准，再通过合并队列、分阶段发布和回滚控制后果。PR 即提交给团队讨论与合并的一组代码改动。这里的自动检查不代替规定的人类批准。
团队还遇到自动审查自身制造的忙碌：一条改动一夜经历五十多轮检查和修复，后来发现约59%的反复发现原本就在代码里。于是给轮数设限，后续集中看新差异，要求一次指出整类问题，并避免重复报告。同批内部前后统计中，平均通过所需审查从2.08轮降到1.32轮。
怎样确认只是少折腾，而非漏查？作者将历史事故和回滚做成每日评测，还检查已知干净的 PR，数清评论是否会诱使人作出有害修改。效果报告来自自家仓库，尚不足以证明相同流程在别的团队同样省人力。
本次记录的观点：Addy Osmani、Morgan Westlee Lunt、Qing Wang · status_quo69 · csallen
回到当期正文 ↗
查看依据
原文 · 原始依据