AI代码审查5个月实战复盘：bug下降82%、41条规则库与团队认知转变——AI协作实验室第6篇
AI协作实验室系列：十年Java老兵的真实AI编程踩坑记录。不发教程，只发踩坑记录。本文是系列第6篇（终篇）——五个月AI代码审查实验收官复盘：数据曲线、规则库结构，以及团队成员对"写好代码"的理解发生了怎样的变化。
AI代码审查5个月实战复盘：bug下降82%、41条规则库与团队认知转变
一个四人 Java 后端团队，用 Claude Code 生成代码 + 自建五关审查清单 + Skill 规则库 + GitHub Actions 自动 PR 扫描，跑了五个月。本文是这个实验的最终复盘，包含完整数据曲线、规则库结构拆解，以及比数据更值得记录的团队成员认知转变。
一、五个月核心数据：bug 从月均 11 个降到 2 个
线上 bug 统计口径与前五篇一致（生产环境经监控、告警、客服工单确认的真实问题，同等类型和规模交付）：
| 月份 | 关键动作 | 线上 bug 数 |
|---|---|---|
| 第 1 月 | AI 生成 + 纯人工 review（30 天实验期） | 11 |
| 第 2 月 | 上线五关人工审查清单 | 8 |
| 第 3 月 | 清单固化为 Claude Code Skill | 5 |
| 第 4 月 | 规则库团队共享 + AI 自动扫描 PR | 4 |
| 第 5 月 | 上线四问决策框架 | 2 |
从峰值 11 降到 2，降幅约 82%。第 5 个月的两个 bug 分别是文案错误和上游渠道字段长度变更，严格说不属于 AI 生成代码引入的缺陷。
另外两个过程指标：
- PR 平均合并周期：从 32 小时缩短到 9 小时。原因是"判空""加锁""命名格式"类低价值评论基本消失——作者侧 AI 生成时规避，reviewer 侧 AI 扫描时兜底。
- 规则库规模：从 0 增长到 41 条，详见下一节。
二、41 条审查规则库的结构
团队 Skill 仓库中的规则按五关分类：
| 分类 | 条数 | 代表性规则 |
|---|---|---|
| 安全检查 | 11 | 用户传入 URL 必须同时通过白名单与私有 IP 段校验 |
| 并发安全 | 9 | 余额/库存/计数器字段禁止裸 SELECT + UPDATE |
| 事务边界 | 8 | 外部调用必须放入 afterCommit 回调 |
| 空指针防护 | 7 | MQ 消息体字段必须按"可能为空"处理 |
| 需求评审 | 6 | 生成代码前必须声明并发模型/上游输入/失败语义 |
这套规则库有两个关键机制：
其一，规则元数据。 每条规则标注：谁添加、对应哪次线上故障、添加时间、为什么、什么时候不适用。后两条源于一次"规则反审作者"事件——规则的撰写者自己被 AI 引用其规则拦下后，坚持要求所有规则写清适用边界。
其二，规则与代码同流程评审。 新增规则单独提交并说明原因，修改规则关联对应故障记录，删除规则说明失效理由。规则库因此同时成为团队的"故障编年史"。
三、团队成员的四个认知转变
1. Tech Lead（十年经验）：从写代码的人变成写规则的人。 工作构成中业务编码占比降至三成以下，主要时间用于将新故障翻译为规则、评审规则变更、处理规则冲突。一条规则在团队所有 AI 实例和所有 PR 中生效，经验杠杆显著放大。
2. 资深工程师：从规则作者变成被规则审的人。 其制定的"批量 RPC 超过 50 条必须分批"规则，两周后拦下了他自己的 PR（缺少 checkpoint 断点续传机制）。此后他撰写的规则固定附带"为什么"与"什么时候不适用"两条附录。他的总结是：规则写出去那一刻，就不属于你了。
3. 网关/权限负责人：从凭感觉拍板变成先答四问。 四问框架（最坏会怎样/为什么不能现在修/谁来拍板/怎么保证不忘）最初是为一次深夜热修复复盘总结的。现在他忽略 AI 警告的 PR 评论固定写为"因为 A、B、C 三个条件同时成立，所以风险可控"——直觉没有变，但直觉被翻译成了可讨论、可复盘的判断链路。
4. 新人（三年经验，AI 原生）：没有"以前"的另一种成长。 其问题不是守旧而是过度信任 AI。五个月后的变化：41 条规则中贡献 13 条（团队第一），并能独立完成完整的四问决策流程。对 AI 原生一代而言，"把经验翻译成规则"不是转型，而是基本功。
四、终篇结论：经验没有贬值，只是换了存在的地方
五个月前这个系列提出的问题是：AI 把写代码的门槛降到零之后，资深工程师的经验还值不值钱？
五个月后的答案是：经验没有贬值，经验存在的地方发生了变化——从个人头脑中的隐性直觉，变为仓库中可检索、可评审、可执行的显性规则。AI 没有让经验贬值，它只是迫使团队把经验从"玄学"变成"显学"。写不清楚的经验在 AI 面前无法生效，写得清楚的经验则会被 AI 放大执行。
五、给其他团队的落地顺序参考
这个系列五篇方法论文章对应的落地顺序，可供参考：
- 先做一次基线对照实验，拿到自己团队的真实数据（第一篇）；
- 把线上 bug 分类复盘，归纳成人工审查清单（第二篇）；
- 清单执行稳定后，固化为 AI 可加载的 Skill 规则文件，附正反例代码（第三篇）；
- 规则库团队共享，配合 CI 胶水层实现 PR 自动扫描，规则变更与代码同流程评审（第四篇）；
- 为"规则之外的手动忽略"建立四问决策框架，决策记录留在 PR 中可复盘（第五篇）。
五步的收益递减，但每一步堵住的是不同类型的漏洞，不建议跳步。
用系列的两句话收束全文：
规则是给 AI 的，判断才是给人的。规则让人少走弯路，判断让人走自己的路——而人走过的路，最终又会沉淀为新的规则。
本文是精简的技术摘要版，完整的叙事细节、四个人的转变过程和系列收束感言，我写在了公众号同名文章《bug 从 11 个降到 2 个的那个月，我回答了五个月前失眠时的问题》里。
GitHub wangheng19901021/skills 开源了全部审查规则与团队 Skill 模板，持续更新。AI协作实验室系列共 6 篇，至此完结。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
8
0- 0
已为社区贡献2条内容
所有评论(0)