ARTICLE · 1279927

90% 代码是 AI 写的,我们是怎么做代码审查的?

发布时间：2026-10-30 12:51:22 最近访问：2026-10-30 12:51:22

大家好，我们是 AI的工程师。

之前我们对外提过一嘴：在 Claude Code 这个项目里，大概 90% 的代码全都是 Claude 自己敲出来的。

很多同行私信问我们：“你们的代码量得多恐怖？人肉看代码眼睛不瞎吗？”“到底还有没有人认真看代码？万一线上被 AI 搞崩了，究竟谁背锅？”

实不相瞒，在最开始的时候，我们也被自己折腾得够呛。今年 5 月，我们内部大代码库每天合并的变更大概是 2,500 次，到了 9 月，这个数字直接坐火箭蹿到了 30,000 多次。

如果还按老办法，让工程师每行每句去盯，我们全队不吃不喝不睡觉也看不完。

但我们交出了一份挺反常识的成绩单：从 6 月到 9 月，我们合并到主干的代码量翻了一倍多，但线上出故障被迫回滚（Revert）的比例，反而下降了 40% 以上。

今天我就以第一人称，掏心窝子跟大家聊聊：我们到底是怎么扛过这场“AI 代码海啸”的，中间踩了哪些哭笑不得的坑，以及我们现在的这套玩法。

一、先转过脑子：别把“人肉盯代码”当成免死金牌

大家以前做 Code Review，习惯是立一道“事后门禁”：

❌ 传统审查模式（事后门禁 · 所有人都在等）工程师敲代码 ➔ 发起 PR ➔ 挂起干等同事排期 ➔ 同事肉眼逐行挑错 ➔ 提格式小意见打回 ➔ 重新修改 ➔ 勉强通过 ➔ 合并上线（依然可能暴雷）

这种模式在 AI 时代彻底死了。

我们后来想明白了一件事：“这段代码有没有被真人肉眼扫过”，根本不代表它稳不稳。真正的关键在于：这段改动到底可能在什么地方暴雷？到底是用自动化工具拦住它靠谱，还是必须人脑来判断？

如果一个初级 Bug 明明一条脚本就能测出来，你非要把一个资深工程师从深度思考里拽出来肉眼查半天，这纯粹是巨大的资源浪费。

所以我们把整个审查动作彻底“左移”，变成了像打字时的实时拼写检查：

✅ 现代 AI 审查模式（实时持续纠错 · 绝大多数低级错误根本出不了本地）AI 结对编写代码 ➔ 本地工具实时自检（跑测试/比对截图） ➔ Subagent 旁观审查（消除低级破损） ➔ 发起 PR（代码已极度健康） ➔ 多机器人并行初审 + 交叉投票 ➔ 人类仅针对高危架构审视

维度对比	❌ 传统人肉审查模式	✅ 现代 AI 连续审查体系
审查发生时机	开发完成后的“终点站门禁”	编写代码时的“实时拼写纠错”
最大时间消耗	挂起等待同事排期与格式挑刺	机器毫秒级响应，几乎零排期
人类精力分配	80% 精力在看语法、命名与格式	100% 精力留给架构设计与业务风险
核心安全假设	迷信“人眼看过了就等于没问题”	“只要可被自动化衡量的，全交给机器验证”

而且大家千万别自欺欺人——审代码偷懒省下来的时间，如果全变成半夜线上报警、爬起来通宵救火的时间，那叫转移债务，根本不叫提效。

所以我们的底线非常硬：绝大多数 PR 只要最多一个人（甚至就是提 PR 的作者自己）过目就能合入，但前提是——线上的回滚率和事故率绝对不能抬头！

二、我们改动的“七道过滤网”

现在在我们团队，一段代码从工程师电脑（或者直接在 Slack 会话里吩咐 Claude）敲出来，到真正发布到用户面前，要经历一套像漏斗一样的“七层防护网”：

1. 还没提 PR 之前，先让 AI 自己把屁股擦干净

以前我们问 Claude：“写完了吗？”它说：“搞定了！”结果一跑连编译都过不去。现在我们立了规矩：绝不听它吹牛，必须给它能运行的手段。

让它自己跑跑测试；
让它在无头浏览器或者手机模拟器里点一点，截张图比对一下；
跑完之后，把终端的真实运行输出拿给我们看。

同时，我们还会派另一个带着全新记忆的“独立 AI 小助手”，站在旁观者角度把刚刚写好的 Diff 挑一遍刺。很多低级错误在这个阶段就被捏死了。

为了让 AI 明白规矩，我们在根目录放了两个很短的小文件：

CLAUDE.md
：写明技术栈、代码规矩、什么事千万不能干。
REVIEW.md
：每个模块负责人写明“在这个目录下什么才叫真正的 Bug”。比如文档目录，说谎造假就是 Bug；配置目录，路由配错就是 Bug。而且要求它指出问题时必须给出确切的文件名和行号，严禁凭空瞎猜。

2. PR 上的 CI 硬门禁

这一步大家都很熟悉：代码规范 Lint、类型检查、多操作系统全平台自动化测试、打包构建。一个很普通的 CLI PR，在任何人看它之前，后台几十项自动化检查就已经在疯狂跑了。

3. 多 AI 会审与投票机制（把“废话意见”全滤掉）

PR 提交后，Claude 会自动阅读完整的代码上下文进行大体检。

但这里我们吃过大亏：如果 AI 天天在 PR 下面留一堆“缩进不太好看”、“建议提取个变量”这种无聊的废话，工程师会看吐，AI 作者也会当真跑去改。

于是我们设计了多智能体交叉投票机制：

📋 多 Agent 自动化会审与去噪流转链路：
并发探测
：多个专门的 Bug 探测 Agent 并行扫描（Agent A 查逻辑漏洞、Agent B 查异常边界、Agent C 查调用破损）；
汇总候选
：探测 Agent 将所有嫌疑点送入独立的“评审裁决委员会”；
独立投票过滤
：委员会多 Agent 交叉核查并投票，纯代码格式/风格挑刺直接丢弃，只保留真实缺陷；
打标留评
：按严重程度打标（Important 重大 / Nit 琐碎轻微 / Pre-existing 历史遗留），以行内 Comment 形式推送到 PR；
安全专属模型扫描
：独立并行介入，拥有一票否决权；
作者必须闭环
：代码作者必须逐条修改代码或说明正当理由，未清空禁止合入。

每一条发出来的意见，作者必须正面回应——要么改代码，要么解释为什么这是故意设计的。甚至在夜里，会有 AI 自动接单把这些意见改好，等我们第二天上班时，PR 已经自己优化过一轮了。

4. 拥有一票否决权的安全审查

安全检查完全独立出来跑。只要安全模型觉得某行代码有隐患，且你没有给出正当理由或者修复它，这个 PR 就算天王老子来了也合不进去。

5. 看改动有多危险，再决定要不要叫人来看

我们彻底废除了“不管改啥都得找人 Approve”的一刀切做法，全看这次改动的危险程度：

风险等级	典型代表场景	人工审批硬性要求
低风险 (Low)	纯文档、界面文字文案、纯内部测试特性、置于 Feature Flag 后的纯增量改动	自动化审查与安全门禁全部变绿后，无需任何人工审批即可合入
中风险 (Medium)	常规业务产品改动，以及缓存机制、自动升级模块、系统提示词等敏感区域变更	至少 1 名人类审批
高风险 (High)	最底层的核心枢纽代码，以及系统明确规定必须两人把关的高危路径	必须 2 名人类审批

这里有个铁律：谁让 AI 写的这段代码，谁就是法定第一责任人。AI 留下的 Approval 永远不能当人头数来凑数。

6. 合并队列与灰度缓冲

两个 PR 各自测试都是好的，合到一块就可能打架。所以我们上 Merge Queue（合并队列），把代码放到主分支的最新环境里完整跑一遍。

合入之后，新功能通常先挂在 Feature Flag（特性开关）后面，只对我们 Anthropic 自己的员工生效。我们全公司每天高强度使用，绝大部分 Regression（功能倒退）在内部就被揪出来了。向外发布时，先推给 latest 尝鲜通道，最后才进 stable 稳定版。

7. 最后一招：把撤退路线修得无比顺畅

人不是神仙，AI 也不是，漏洞总有可能溜出去。所以我们的最后一道防线是：极速止损。开关关掉只需要几秒，不用重新打包部署；Revert 代码随时一键点下去。

我们团队有一位同事说得很透辟：“故意放慢开发节奏确实能降低出错率，但那只是因为你干的活变少了。我们宁愿选择把发现问题、撤销错误的速度打磨到极致。”

三、我们经历过的最大翻车现场：AI 之间的无限互扯

我们在探索自动化时，踩过一个特别经典的坑。

有一阵子，我们让一个 AI 负责写代码，另一个 AI 负责审查。结果有天夜里，一个 CLI 的小 PR 直接失控了：审代码的 AI 提了一条意见，写代码的 AI 屁颠屁颠跑去改；改完提交上去，审代码的 AI 又挑出新毛病……两个家伙在深夜互掐了整整 50 多轮！

第二天早上我们到公司一看，整个 PR 记录全被刷爆了，赶忙手动掐死。

我们赶紧去扒拉底层数据，用 git blame 深入追踪到底在吵什么，结果发现了让人哭笑不得的事实：AI 反复挑刺的代码里，有 59% 从第一轮就一直躺在那里！

那个审代码的 AI 根本没发现什么新 Bug，纯粹是在每一轮循环里，闲着没事把历史旧代码翻出来反复挑刺吹毛求疵。

审查机制对比	❌ 改造前：死循环互撕 (曾跑了整整 50+ 轮)	✅ 改造后：强制收敛四原则 (单轮通过率升至 78%)
交互流转过程	AI 作者提 Commit ➔ AI 审阅者全量排查 ➔ 翻出历史旧账挑刺（59% 是旧代码）➔ AI 作者被迫改动 ➔ AI 审阅者再翻出更多旧账……	1. 设 3 轮硬封顶：超过 3 轮未收敛强制叫停并摇人2. 仅看新增 Diff：第 2~3 轮只复审新增改动，严禁翻历史旧账3. 按缺陷大类归纳：指出整类问题让作者一次性改全4. 去重禁复读：已提过的意见不得重复出现
实战数据结果	两个 AI 深夜互掐刷爆 PR，永远无法合并	5轮以上 PR 从 8.9% 暴跌至 1.5%；平均审查轮次降至 1.32 次

规矩一立，立竿见影：单轮就通过的 PR 占比直接涨到了 78%，需要 5 轮以上的 PR 从接近 9% 暴跌到了 1.5%，平均审查轮次降到了 1.32 次。

四、人类工程师的真正战场：不看琐碎代码，我们到底在看什么？

既然绝大多数常规代码都让机器或者作者自己把关了，那资深工程师把省下来的宝贵心力，究竟花在什么地方？

把一个高级工程师从深度心流状态中拽出来，去肉眼查一个多层括号或者拼写错误，成本极其高昂。在我们的体系里，人类真正的核心职责被收拢到了这 5 件机器永远替代不了的事：

🧠 人类工程师的 5 大不可替代阵地：1. 决定要不要做 (方向与品味) ➔ 2. 审视高危雷区 (支付/升级/CI) ➔ 3. 把关架构范式 (防坏基因传染) ➔ 4. 严审测试证据链 (读日志与截图) ➔ 5. 承担法定最终责任 (You land it, you own it)

决定“要不要做”（Direction & Taste）
：AI 让敲代码的边际成本趋近于零，这带来了一个新麻烦：发起一个毫无意义的改动实在太容易了。人类必须在源头上问一句：“这真的是用户需要的吗？值不值得为了这个特性引入新的认知负担？”
死盯高危雷区（Risky Code）
：比如账单计费（Billing）、客户端静默自动升级（Auto-updater）、以及能直接改写发布流水线的 CI 脚本。这些地方一旦暴雷就是灾难级的，必须强制由人类两人交叉把关。
把关架构范式（Architectural Patterns）
：在 AI 时代，坏的架构模式具有极强的传染性。如果一段糟糕的抽象代码溜进了主干，接下来的几天里，Claude 就会在全仓库其他模块里学着它的样子疯狂“复制粘贴”。人类必须把守住代码的“遗传基因”。
审阅“证据链”，而不是靠脑补猜（Reading the Evidence）
：很多团队所谓的肉眼 Review，就是眯着眼睛把 Diff 脑内过一遍，觉得“差不多”就点了 Approve。在我们团队，审阅者必须看硬核证据：

跑了哪条测试命令？返回的真实终端日志是什么？
改动 UI 的话，前后对比的真实渲染截图在哪？
各种边缘报错时，给出的错误提示是否准确？
我们的铁律：如果你说不清楚自动化检查可能会漏掉什么，那你就老老实实做一次深度审查，绝不能糊弄着随便点通过。

对产出承担最终责任（Accountability）
：不管这行代码是 Claude 写的还是人手敲的，只要合并上线，敲回车的那个人就要对后果全权兜底。

顺便聊聊“沉没成本”：AI 时代如何痛快地调转方向？

以前做开发，一个工程师吭哧吭哧写了两周的代码，哪怕方向走偏了，或者架构设计不理想，在评审会上也很难轻易推翻——因为这里面凝结了巨大的个人情绪和“沉没成本”，谁提一句“要不关了别合了”，就像是在否定同事的人格。

但在我们这里，关掉一个写得差的 PR，没有任何心理包袱。

因为这段代码可能只是 Claude 花了 3 分钟生成的。大家在公开的 Slack 频道里随时讨论：有人发了一句“这个方案好像把底层路由搞复杂了，上个月我们是不是定过另一个解法？”，作者看一眼觉得有道理，顺手就把 PR 给点了 Close。

几百行代码作废，作者完全不心疼，再吩咐 Claude 按新方向写一份就是了。这种极轻的心理负担，让团队能以极快速度试错并随时掉头。

五、同行常问我们的两个敏感问题

Q1：全让机器去看了，团队新人怎么了解代码库？

很多工程师最担心的就是这个：“以前我们都是靠看同事的 PR 了解系统细节的，现在大家都不看了，系统岂不是成了黑盒？”

我们的回答非常现实：在我们团队，没有任何人能把整套代码的完整全貌装在脑子里，说实话，也根本没这个必要。

读一个改了一行文案、修了一个微小分支的 PR，除了浪费半小时，对你理解核心架构毫无帮助。

我们的做法是：按需实时学习。比如你明天需要改动“配置管理”这个模块，你不需要去翻过去半年的几十个 PR，直接让 Claude 针对这个模块当场写一份深度架构分析，甚至让它当场画一个交互式的调用流程图（Artifact）。

几分钟之内，你看到的就是当前代码库最真实、最新的逻辑。这比人脑记忆靠谱十倍。

Q2：万一真出了线上事故，怎么处理？

我们的团队文化叫：“You land it, you own it”（谁合入，谁兜底）。

如果你合入的代码出了问题，通常由你负责把它修好或者立刻回滚。但我们绝不搞“追责抓内奸”那一套，因为：

让你修是因为你刚刚碰过它，上下文最热；
每次复盘会，我们最关心的不是批评谁，而是问一句：“在我们前面那七道防线里，到底为什么没能拦住它？哪一道该打补丁？”

更重要的是，我们会把每一次事故变成审查工具自我进化的“磨刀石”：

🔄 事故驱动的 Eval 持续进化闭环：线上事故 / 紧急回滚 ➔ 资深工程师确认 Bug 真实位置与根因 ➔ 录入团队每日 Eval 评测题库 ➔ 对审查 AI 提示词与工具做调整 ➔ 在全量题库上自动化跑分测试 ➔ 拦截率上升且误报率不增加 ➔ 更新审查 Agent 上线部署

我们之后对审查机器人做的任何改进，都必须在这套考卷上跑一遍，分数更高才准上线。

六、分阶段落地实操手册（可以直接抄作业的 Checklist）

如果你也想带领团队从沉重的肉眼 Review 泥潭里爬出来，不必一步登天。我们在实战中摸爬滚打出来的很多工程组件，今天在现成工具链里都能直接用：

🚀 四阶段渐进式落地路径：阶段 1：提 PR 前 (本地前置自检) ➔ 阶段 2：发起 PR 时 (CI 与多智能体会审) ➔ 阶段 3：审批准入 (按改动风险分级) ➔ 阶段 4：合并与线上 (队列灰度与事故转 Eval)

1. 在发起 PR 之前（本地阶段）

写好短小精悍的 CLAUDE.md：讲清楚项目技术栈、代码硬规范，挂载本地 Git Hooks 自动触发代码格式化与 Lint 检查。
按模块建立 REVIEW.md：代码 Owner 写清“在本目录下什么才算真正 Bug”，把过去反复提过的评审意见归纳进去，明确禁止吹毛求疵的格式空话。
本地运行前置自检：使用 /code-review、/security-review 或唤起独立全新记忆的 Subagent，先挑刺一轮并跑完本地单测。

2. 在发起 PR 时（自动化与多 Agent 阶段）

规范化 PR 模板：硬性要求填写三个核心问题——“这次改动是怎么测试的？”、“潜在风险是什么？”、“万一出事怎么回滚？”。
接入自动化 AI 审查与安全门禁：在单个仓库先试点（如引入 GitHub Action），未通过安全扫描或存在未闭环的严重缺陷前，严格禁止合并。
按系统核心度匹配审查深度：核心模块开 Deep 深度审查（允许更长耗时并发找深层逻辑漏洞），边缘模块开 Quick 快速审查。
严格限制 AI 评审轮数（设置 3 轮上限）：前几轮复审只看新增 Diff，严禁反复翻历史旧账；超过 3 轮直接叫停并人工接管。

3. 在审批准入阶段（人类把关阶段）

按改动风险分级，而不是按作者资历分级：从低危（纯文档/Flag内）免人审，到高危强制双人审，制定清晰明确的阶梯标准。
使用 CODEOWNERS 锁定敏感核心资产：权限验证、计费、自动升级与 CI 部署脚本，必须有指定人类专家把关。
禁止机器代签与过期审批自动作废（Dismiss Stale Approvals）：机器的绿灯绝不能顶替人头数；一旦合入了新的 Commit，原有的人类 Approval 立即失效，必须重新审视。