一个反直觉的结论：AI Coding 不会自动让代码变好，没有规范约束，反而会加速腐化。

最近看到美团技术团队的一篇实战复盘，非常硬核！

他们用 AI 完成了一次 31万行代码的大重构 ——全程没有申请一天专项排期，90% 以上代码由 AI 辅助生成，最终不仅完成了技术债清偿，还没有影响正常业务交付。

整篇文章我反复读了两遍，核心是四条经验。

打开网易新闻 查看精彩图片

第一条：先对齐人，再约束 AI。

这是整篇文章最重要的一句话。

很多团队上了 AI 编码工具后，直接让 AI 生成各种编码规范，然后配成 Rule 让大家遵守。

但美团踩过坑后发现：如果团队本身没有统一共识，AI Rule 写得再好也是一纸空文——不同人会把同一条规范解释成不同版本，系统反而以更快的速度腐化。

正确顺序是： 先让团队对齐（人人对齐），再把共识固化为 AI 的约束（人机对齐）。

真正的瓶颈不在工具，在人。

第二条：AI 让"经验"的价值边界变了。

过去，资深工程师的核心价值是"能看全"——要靠三年经验积累才能建立代码全局感。

现在，AI 接管了这件事。把方向给它，全量扫描几分钟出来。

但 "能判断什么最重要" 这件事，AI 给不了。

哪个技术债值得优先改？哪个模块要重点关注？这些判断，还是得靠人。

经验的价值没有消失，只是从"看全"转移到了"判断"。

第三条：技术债不需要排期，需要拆解能力。

这是最反直觉的一条，也是我觉得最有价值的部分。

传统思路处理技术债无非两条路：推倒重来，或者申请专项排期。两条路都很难——前者风险太大，后者资源争不到。

美团走了第三条路： 把技术债拆解成业务需求的"顺带动作" ，借着每次业务迭代渐进式消化。

举个例子：某个核心功能要迭代，顺手把底层数据模型重构了；另一个功能要升级，顺便把质检业务模型全量迁移了。

31 万行代码，就这么一点一点吃掉的，全程业务没停。

这需要极强的拆解能力：要知道哪些技术债能"搭便车"，哪些不行；既不能让重构拖慢交付，也不能让业务绕过技术债继续堆新债。

这本质上是一种 把技术工作像业务需求一样迭代消化 的思维方式。

第四条：AI 编码提速之后，Code Review 才是新瓶颈。

木桶效应。

AI 编码效率上去了，结果 CR 开始堵。如果不解决这个瓶颈，AI 带来的提效红利会被 CR 吞掉。

他们的解法是建立 Pre-PR 机制 ：提交代码前，必须先用 AI 按团队规范自查一遍，把基础问题过滤掉，再提交给人 Review。

这样，人工 CR 的重心就从"你写得对吗"转移到了"我们是否在用正确的方式解决正确的问题"。

人的注意力，用在了值得用的地方。

最后说一句：

AI Coding 的本质变化，不是"写代码变快了"，而是 工程师的职责从"写代码"变成了"设计一个让 AI 能可靠产出代码的工程环境" 。

这个环境包括：规范、架构、Rule、SOP、CR 机制……

谁能把这个环境建好，谁就真正用好了 AI。