Claude Code 团队怎样做代码审查？Addy Osmani 分享了一套内部流程：PR 前验证、分层自动检查、按风险安排人工审批，再把线上事故变成审查系统的评测题。

有几个具体做法值得参考：① 提 PR 前，先让 Agent 拿出运行结果。

运行测试、执行构建，或把界面截图与设计稿对比。完成后，再由一个使用全新上下文的子 Agent 审查 diff。团队还会用内部 Skill 找 bug、精简改动、检查端到端行为和 UI 规范。反复出现的问题，会回收到 Skill、lint 规则或项目说明里处理。

② 项目说明和审查规则各司其职。

CLAUDE.md 交代技术栈、约定、目标和非目标，大仓库里保持简短，通过链接补充资料。REVIEW.md 由代码负责人写，说明这一块最怕什么出错、哪些路径可以忽略、哪些细枝末节不要纠缠。

发现问题要给出文件与行号，没问题也要明确说清。团队还会单独检查审查器有没有遵守这些规则。

③ AI 的发现，也要经过验证。

每个 PR 都先接受 Claude 审查，把 diff 放进整个代码库和 PR 意图里判断：有没有解决问题、是否适配现有系统、会不会破坏其他部分。多个 Agent 找问题，再由另一组 Agent 投票核实，过滤纯风格和清理类意见，区分新引入的问题与已有问题。

代码审查和安全审查中未关闭的问题都会阻止合并。作者可以修复，也可以说明理由后关闭误报；测试、类型检查和构建等仍是独立的阻断条件。

④ 人工审批按改动风险分配。

文档改动、普通产品改动、计费或 CI 等高风险改动，需要的关注不同。风险由改动内容决定；较宽松的审批路径只对仓库信任名单里的作者开放，敏感路径有额外要求。Agent 的批准不能抵扣必须由人完成的审批，Agent 写出的 PR 仍由操作者负责。

批准针对具体 commit。后续如果出现系统无法担保的新提交，例如 Agent 又推送了改动，或有人手动解决合并冲突，就需要重新审批。

⑤ Agent 互相审查，真的可能停不下来。

他们遇到过一个 CLI PR：写代码的 Agent 和审查 Agent 一夜往返超过 50 轮，最后靠人工叫停。用 git blame 回查后发现，审查器不断指出的代码中，约 59% 在第一轮时就已经存在。后续审查反复挖出旧问题，继续触发修改和新一轮审查。

团队随后调整规则：三轮后要求作者重新考虑方案；前几轮之后，复审只看新增 diff；报告一类错误，让作者一次处理同类问题；不重复报告已经指出的问题。历史代码则另外安排夜间扫描，并开始追踪一个 PR 要多少轮才能通过。

⑥ 用真实事故检验审查器，也测它会不会误导修改。

把引发事故的 PR、后续修复和回滚收集起来，由熟悉代码的工程师确认 bug 位置与正确性，形成每天运行的评测集。每次调整审查系统，都用整套案例重新评估。

同时观察人怎样处理审查意见：修复、驳回、解释为有意设计，还是认为无关紧要。还会拿已知干净的 PR 测试，检查审查器是否提出可能造成有害修改的建议。

⑦ 合并和发布也承担质量检查。

合并队列把改动放到最新 main 上重新跑检查，防止两个各自通过测试的 PR 合起来出问题。新功能通常放在功能开关后，先给内部员工使用，再逐步发布；公开版本先进入 latest，stable 稍后跟进。

出了问题，可以关闭功能开关或回滚，事故复盘再追问哪一层本应发现它。

⑧ 人仍然要判断方向、架构和验证盲区。

团队把人的注意力留给：这件事该不该做、高风险代码、会影响后续开发的架构选择，以及测试输出、命令和截图等证据。

省下多少人工，要同时看审查耗时和修复故障的耗时；回滚率、事故率上升，就可能只是把工作推迟到了上线以后。

⑨ 少读日常 diff 后，要补上理解代码的方式。

需要改某个模块时，团队成员会让 Claude 针对那一块生成讲解，有人还会生成可视化材料。日常工作在开放频道里讨论，其他人可以尽早指出方向问题，作者也可以及时关闭 PR 或换方案。

小中型改动上线后出了问题，通常由最了解上下文的作者修复，事故复盘则关注系统如何改进。

原文：x.com/addyosmani/status/2114604912520921136

HOW I AI程序员