当团队99%的代码来自AI

最近我在协助一个团队做一轮重构，也因此近距离看了一段时间他们使用 AI Coding 的过程。AI 参与得很深，夸张一点说，99% 的代码都由它生成。团队起初很兴奋，这很正常，写代码的速度确实起来了，很多过去要磨一下午的样板逻辑、接口适配、重复劳动，现在很快就能铺开，活也往前拱得飞快。

但看久了，我心里开始发紧。倒也不是 AI 总写错，坦白讲，它很多时候写得还算像样；真正让人不踏实的，是一些隐藏 bug 在开发阶段并没有露头，到了部署、联调，甚至更后面才慢慢冒出来，Code Review 面对一大片已经长好的代码，也很难把那些暗处都照见。

失控

我后来慢慢想明白，团队先失控的，多半不在代码量。人手写代码的时候，会在敲每一行的间隙里，顺手做掉很多细碎但要命的思考，输入输出是什么，边界条件卡在哪里，异常要不要兜，依赖有没有副作用，本地环境和测试环境到底一样不一样。这些东西平时不觉得珍贵，AI 把生成动作提速之后，那部分原本揉在书写过程里的思考，也就被整段压缩了。代码出来得更快，理解和验证却没同步补上。麻烦便从这里起身。

这也是为什么 Code Review 会突然变难。大家并没有忽然变笨，只是评审者接到手里的，常常已经是一整片成形的实现，作者中途那些犹豫、取舍、反复试错，很多都没在代码生长的过程中露出来。于是 CR 很容易看见表层逻辑，看见命名，看见结构，甚至看见一些明显的坏味道，却不那么容易看见边界条件、环境差异、兼容细节这些更阴的地方。代码写快了，理解代码的时间却没有平白多出来。

人总要还账的。

再往下看，我反倒觉得把锅全甩给 AI，多少有些偷懒。这个团队面对的场景本来就不轻松，既要兼容单体版本，也要兼容微服务版本，环境里的中间件还得同时照顾 PgSQL 和 MySQL，本地开发环境与测试环境又不是完全同一套。在这种局面里，开发自测天然容易遗漏，换个人手写，很多坑也未必躲得过去。AI 只是把这些原本就不稳的地方，放大得更快了一点。

护栏

想通这一层之后，很多动作就会变得很自然。我一边观察，也一边陪着他们补前面的护栏，先搭框架，再逐步少量地补逻辑，不再贪图一口气把整块功能都吐出来；强控每次提交的代码量，尽量把 CR 的心智负担压下来；让不同的 AI 彼此做审阅，也让团队内部一起走读代码，互相学习，互相挑刺；继续加厚自动化测试与集成测试。这些事看起来零零散散，其实都在补同一个窟窿，写代码变快之后，前置思考和后置验证都得一并加厚，不然人迟早会跟不上。

我这个人对 TDD 一向有些执拗，看得越久，越觉得自动化测试，乃至性能测试，都得更早地进入开发环节。以前大家总觉得测试是开发后面的事情，代码写完了，再去补验证，再去跑环境，再去看性能。但在多版本兼容、多环境兼容的重构里，很多雷其实埋得很早，等到提测、部署、联调那一步再发现，代价已经不小了。既然问题在开发阶段就种下，验证最好也在开发阶段就跟上。此事宜早，不宜迟。

所以我最近还有一个更激进的念头，若是前面的约束能够立住，AI 其实不只可以写代码，它还可以接管更多流程，审核、部署、持续集成、自动化验证，乃至一些重复性的门禁动作，都可以慢慢往前推。做软件工程咨询这些年，我越来越觉得自己的价值，未必在替团队回答“用不用 AI”，更多时候，是帮他们把前面的工程约束重新站稳。旧船太松，装不住这样的新桨。

泡沫

不过副作用也已经露头了。最近我看 AI 生成测试用例，也常有一种哭笑不得的感觉，它很容易一下子写出很多，看起来面面俱到，甚至有些漂亮，细看却有不少重复、无效，或者只是为了把覆盖率数字抬上去。这些测试留在仓库里，表面上像是质量更好了，流水线跑起来却越来越慢，团队也要花更多时间维护一批并不那么值钱的东西。的确，测试也会长出自己的泡沫。

所以我越来越觉得，AI 时代真正该守住的，不是“人必须亲手写多少代码”这种姿态。更要紧的，是先把问题想清楚，把边界想清楚，把验证想清楚，把哪些该交给 AI，哪些仍要自己盯死，想清楚。少用 AI，并不能解决这件事，沿用旧流程去接这样一种新的生成速度，也同样解决不了。真正要重写的，恐怕是整套研发流程里那些原来依赖“人边写边想”才能勉强兜住的地方。把这些前置工作站稳了，AI 接管更多流程未尝不可；站不稳，它只会把原来那些摇摇欲坠的地方，更快地推到你眼前。

下一篇，我想接着聊聊 Code Review。很多问题，恰恰都是从那里开始变得暧昧起来的。

2026年03月22，Leon