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 启发事故案例和落地做法来自笔者团队的实际经历欢迎评论区交流你们的门禁方案。 AI 代码占比 40% 之后，我把团队的 Code Review 规范推翻重写了
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 启发事故案例和落地做法来自笔者团队的实际经历欢迎评论区交流你们的门禁方案。