Addy Osmani、Morgan Westlee Lunt、Qing Wang · claude.dev · 阅读原文
原始来源：Addy Osmani、Morgan Westlee Lunt、Qing Wang · claude.dev
发现渠道：Hacker News · 原始讨论
当 Agent 能连续提交改动，逐行人工审查很容易形成队列。Claude Code 团队介绍的流程是：提交前先运行测试、构建并由新上下文检查；PR 上分别进行缺陷与安全审查；按照改动风险决定需要多少人批准，再通过合并队列、分阶段发布和回滚控制后果。PR 即提交给团队讨论与合并的一组代码改动。这里的自动检查不代替规定的人类批准。
团队还遇到自动审查自身制造的忙碌：一条改动一夜经历五十多轮检查和修复，后来发现约59%的反复发现原本就在代码里。于是给轮数设限，后续集中看新差异，要求一次指出整类问题，并避免重复报告。同批内部前后统计中，平均通过所需审查从2.08轮降到1.32轮。
怎样确认只是少折腾，而非漏查？作者将历史事故和回滚做成每日评测，还检查已知干净的 PR，数清评论是否会诱使人作出有害修改。效果报告来自自家仓库，尚不足以证明相同流程在别的团队同样省人力。
可信度 65 · 重要性 84 · 新颖度 76
技术与主题
Agent 系统 · AI 编程 · 评测与基准 · Automated Code Review · Regression Testing · Risk-based Approval
Addy Osmani、Morgan Westlee Lunt、Qing Wang
原作者描述内部审查迭代；下面是一句实际原文及译文。
status_quo69
针对同一团队文章里按需生成代码解释的安排；属于阅读分析与担忧。
忠实转述（非原句）：他质疑文章是否真正处理了共享代码知识这个问题：如果只在需要时让模型搜索并解释一个局部，得到的信息仍取决于这次搜索的质量；这不等于人已经形成了对系统的理解。他没有提供该团队因此发生故障的独立证据。
csallen
同串回应系统无人理解的担忧；表述来自个人经验。
忠实转述（非原句）：他认为测试和版本历史允许回滚后调查，也认为模型通常能解释自己生成的代码。他说自己的使用中，Claude 会建议把复杂问题拆小；有经验的工程师也会谨慎处理重要代码。这些是他的经验判断，不能作为每次恢复都会成功的保证。
编辑评读
这份材料最值得保留的正面证据，是它没有把“发现更多问题”当成唯一目标。Agent 往往会把轻微建议也落实成修改，一次噪声能触发新提交和新一轮审查。因而控制误报不只是提高评论观感，而是减少系统主动制造的新工作。已知干净的改动和诱发有害修改的计数，补上了只用事故集测召回的盲区。
但是风险分层把判断转移到了另一处：分类器漏判敏感改动，会让后续流程走上较轻的路径。仓库路径规则、明确保留的人类批准和回滚条件才是这个方案的完整上下文。不能把其效果摘出来推广成“代码都可无人审”。HN 的 status_quo69 追问团队怎样保有系统理解，csallen 则认为测试、版本记录与解释能力有助恢复。真正能分辨这两种期待的，是陌生故障发生时谁能找到正确范围、多久定位，以及是否留下不可逆后果。原文的前后统计没有单独识别这些因素。
需要留意
- 作者团队自报，前后统计未隔离人员、改动组合与其他工程变化。