AI 代码占比 40% 之后，我把团队的 Code Review 规范推翻重写了
上个月组里出了个不大不小的线上事故。一个跑了半年的积分服务，某天凌晨开始线程池打满，接口大面积超时。接手的同事查了两天，日志、监控、heap dump 翻了个遍，最后在一段并发处理的逻辑前停住了——他看不懂这段代码为什么要这么写。
翻 git blame，提交记录都在，作者是去年离职的一位同事。微信上问了他，他的原话是：“当时跑起来报了个错，我让 Cursor 改了三版，第三版不报错了，我就合了。”
注意，不是"我分析了竞态条件然后修复了"，是"第三版不报错了"。这两个东西的区别，后面细说。
这种事今年我已经见了三次，细节各不相同，剧本是一样的。所以这篇想认真聊一个问题：AI 生成的代码，到底算谁的。
一段代码是不是你的，不看提交记录
我后来给自己立了一个判断标准，标准就两条：
第一，不借助任何 AI，你能不能把这段代码的工作原理讲清楚？第二，出了 bug，你能不能自己把嫌疑范围缩小到具体的模块？
两条都能做到，这个仓库就是你的。做不到，你在里面提交过一万行，它也不是你的——你只是个看管员。代码在物理意义上挂在你的 git blame 里，但系统的地图不在你脑子里。更糟的情况是，地图谁脑子里都没有，它只存在于一个上下文窗口只有那么大的模型的一次对话里，而那次对话早就关了。
这不是抠字眼。所有者和看管员对 AI 的用法是完全不同的两种东西。所有者拿 AI 当提速器：方案自己想，边界条件自己列，AI 负责把体力活干掉，产出逐行过目。看管员拿 AI 当外包：把 issue 原文粘进去，出来什么合什么，测试挂了就把报错信息再粘回去，直到绿了为止。前者的速度是真的快，后者的速度是记账技巧——账单后面再付。
国外有个工程师 Paolo Galeone 写过一篇同主题的文章，里面有个说法我很喜欢：AI 是放大器。放大良好的工程习惯，速度和质量可以兼得；放大懒惰，仓库里堆的就是噪音。这个判断我完全同意，但他描述的环境还是偏理想了。落到我们这边的开发环境里，有几个特有的东西，会把这个问题放大得更快。
AI 没有让写代码变便宜，它把成本挪到了读代码上
先说一个被汇报材料集体忽略的事实：软件成本的大头从来不是写代码，是理解和维护。这个结论在软件工程里不算新，几十年的老共识了。AI 改变的是成本的结构，而不是总量。
它把"写"这一段的价格打到了接近零。但"读"和"改"的价格一分没降——甚至涨了。因为 LLM 生成的代码有一个非常讨厌的特性：它看起来都是对的。命名规范，注释齐全，异常都 catch 了，结构工整得像教科书。错误藏在第四层调用里，藏在一个没包对范围的事务里，藏在那个只有凌晨三点的大促流量才会踩到的边界条件上。这种代码的 review 成本，比一个水平一般的人写的糙代码更高，因为你的警惕性会被表面的整洁度骗走。
于是团队的真实瓶颈换位置了。以前卡的是写代码的带宽，现在写代码近乎无限供给，卡的是 review 的带宽。一个高级工程师，以前一周手写两千行，那两千行他是真懂；现在 AI 辅助下一周能"产出"八千行，但他认真读得动的还是两千行。多出来的六千行去了哪里？要么没读就合了，要么读了个大概。两种都是欠条。
这就是为什么"AI 提效 X%"这类数字我很怀疑。它统计的全是产出侧，理解成本这一项压根不在分子分母里。代码本身不是资产，能被人理解的代码才是资产；没人能理解的代码是负债，而且是要付利息的负债。vibe 出来的代码利息还特别高——因为连原作者改它之前，都得先去问一遍模型。债务的利息要用你唯一的还款能力（review 带宽）来付，而这个带宽并没有因为 AI 变大。
想通这一层，再看下面几个现象就顺理成章了。
我们这边的几个放大器
"牛仔式编程"哪里都有，不是我们的特产。但有几样东西是我们这个环境特有的，它们在给这个问题加杠杆。
**渗透率成了 KPI。**这两年不少公司把"AI 代码生成占比"写进了研发效能指标，我真见过写进 OKR 的。方向能理解，但这个指标落地必走形。代码占比是天下最好刷的数字：让 AI 把注释重写一遍，占比涨了；把现成的函数让 AI"重构"一遍，占比又涨了。于是大家开始为指标生产代码，而不是为需求生产代码。古德哈特定律的又一次准时兑现。更麻烦的是，这个 KPI 隐含地鼓励看管员行为——占比要高，最好的办法就是别自己写、也别细看。
**CR 文化本来就薄。**说句得罪人的实话：国内相当一部分团队的 merge request 审批，就是"+1"“ok”"看着没问题"三连，审批是个流程节点，不是质量活动。这个基础盘是既有的，不是 AI 造成的。但 AI 十倍的产出速度压上来，一个本来就摇摇欲坠的东西直接塌了。以前好歹 MR 量少，遇到看不懂的还能把作者叫过来问两句；现在一天五个 MR，每个八百行，工整，带注释，看着都没问题。人的审查意志就是这么被磨没的。
**流动率。**互联网一年换一波人不是新闻。以前接手祖传代码，作者好歹还在职，拉个会把设计意图问出个七七八八。现在接手一个 vibe 出来的仓库：作者离职了，而作者本人也解释不了。你只能让一个新的 AI 去猜上一个 AI 的意图，一层套一层，每套一层，猜错的概率乘一次。这是祖传代码的 2.0 版本，1.0 好歹有个人证。
还有个小的，但每天都很烦人：群聊里的 AI 复制粘贴。你在飞书上认认真真写了三百字的技术方案，对面甩回来一段一眼模型腔的回复，结尾还带着"希望这对您有所帮助"。Galeone 在他那篇文章里管这个叫新的网络礼仪问题，我觉得都说轻了——对方不是不知道这样不礼貌，他是连装一下都懒得装了。对这种人我现在的做法就是不理。你敷衍你的，我节约我的。
不指望自觉，指望门禁
道理讲完了，讲讲做法。原则先亮出来：**不指望人的自觉，指望工具链。**自觉这个东西，在 deadline 和绩效面前一文不值，包括我自己的。
我们组后来立的规矩，挑能落地的说：
**AGENTS.md（或 CLAUDE.md，看你用什么工具）进仓库，进版本控制。**里面写清楚技术栈约束、目录结构、禁止事项——比如"新依赖必须在群里过完才能引"“不许绕过统一的钱款出入口”。这是给所有 AI 工具的一份共享规则，谁来都读同一份。改这个文件必须走 review，因为它实际上就是团队和 AI 之间的契约。契约不进版本控制、只存在于每个人的一次性对话里，那不叫契约，叫许愿。
**本地 pre-commit 挡第一道。**lint、格式化、secrets 扫描（gitleaks 挺好用），提交前本地先跑一遍。这一步挡的全是低级问题，成本几乎为零，但它把 review 的注意力省下来留给真正需要人脑的部分——逻辑和边界。
**CI 门禁做实，覆盖率看增量不看总量。**SonarQube 之类的质量门禁接上，但覆盖率一定按 diff 算：新增代码的覆盖率低于阈值，这个 MR 就不让合。全量覆盖率是个特别自欺的指标，十年老代码把分母撑得巨大，新代码裸奔也能混过去。增量覆盖率才暴露当下的真实情况。
**AI 占比可以统计，但不进考核。**commit 规范里打个标就行，数据留作团队自己的参考——比如发现某个模块 AI 占比畸高且 bug 集中，那是有价值的信号。但一旦写进 KPI，参考上一篇的放大器理论，它会被刷到失去意义。
**review 最低标准具体化。**不接受"看了，没问题"这种审批语。对 AI 参与度高的代码，reviewer 有权指着任意一段问"这里为什么这么写"，答不上来就退回。这条执行起来最得罪人，也最关键。而且得配套说清楚：答不上来不丢人，谁都有被 AI 带着跑的时候；答不上来还坚持合进去，那才是问题。
最后补一条边界，免得走向另一个极端：**一次性脚本、验证想法的 demo、跑完就扔的东西，想怎么 vibe 就怎么 vibe。**两小时的探索性代码，为它上全套门禁属于行为艺术。门禁是给要长期活着的代码准备的。而判断一段代码属于哪一类，恰恰是工程师手里还没被替代的能力之一——这个判断本身经常就是架构决策。
最后
工具没有任何问题，我自己每天也在用，回头率根本回不去。有问题的是把"产出速度"当成唯一的那根轴，其他所有东西——理解、审查、所有权——都默认它们会自动跟上。它们不会。
模型会继续变强，这一点不改变上面任何一句：你解释不了的代码，就不是你的代码。它躺在你的仓库里，但它不在你的能力里。等哪天它出事，你也只会是那个在现场翻 heap dump 的看管员。
观点部分受 Paolo Galeone 的文章 Use Your Brain: Engineering Standards in the Age of LLMs 启发，事故案例和落地做法来自笔者团队的实际经历，欢迎评论区交流你们的门禁方案。
