90% 代码交给 AI 后，团队真正稀缺的不是写代码的人
胡新宇
Published on 2026-08-05
美团 31 万行代码 AI 重构实战。90% 代码由 AI 生成后，团队真正稀缺的，是治理 AI 输出的能力，不是写代码的人。详解人人对齐→人机对齐、Pre-PR 机制、AI Coding 时代的工程治理新契约。
90% 代码交给 AI 后，团队真正稀缺的不是写代码的人
2026 年 2 月，美团 Agent 评测团队面对一个让人哭笑不得的局面：31 万行代码，每月 16 个需求，90% 以上由 AI 生成。但代码库的腐化速度，没有因为 AI 提速而放缓，反而在加速。
这听起来反直觉，但符合逻辑。AI 把"写代码"这个动作的门槛打到了几乎为零，但团队层面的代码治理能力，才是新时代的真瓶颈。这篇文章想把美团这套 31 万行 AI 重构的实战经验拆开给你看：他们做对了什么，又踩过了哪些坑。
一、为什么 AI Coding 越普及，系统越腐化？
很多人以为 AI Coding 的瓶颈是模型不够聪明。错的离谱。
美团团队一开始也是这么想的。他们用 AI 辅助扫描代码库时发现：模型不仅能看懂代码，还能在极短时间内定位 10 个资深工程师靠肉眼读三年也读不出来的性能隐患（来源：美团技术博客）。AI 帮你"看全"代码的能力，已经不是问题。
问题在于"看全"之后怎么办。
当一个团队 90% 的代码由 AI 生成，工程师只负责提需求和 Review，团队规模一年内扩大三倍、技术背景横跨高并发/机器学习/管理后端/实习生时，AI 会把每个人写代码的微小差异无限放大。一个人用 AI 写出"汉堡式"代码，另一个人用 AI 写出"意大利面式"代码，AI 不负责拉齐风格，它只负责忠实执行 prompt。
结果就是：一个 31 万行的复杂业务系统里，Controller 包里揉着十几种业务逻辑，PO 对象在调用链里到处泄露上浮，技术债以 AI 的速度累积。
这就是 AI Coding 时代的真实矛盾：产能被 AI 解放了，但治理能力没有跟上。
二、美团的解法：把 Agent 评测的思路搬过来
美团团队找到的解法很反直觉——用做 Agent 评测的思路，做 AI Coding 的治理。
为什么这两件事能扯到一起？因为 Agent 评测的核心问题是"如何让机器和人的判断对齐"，AI Coding 的治理核心问题是"如何让 AI 和团队的工程标准对齐"。底层逻辑是同一套。
他们拆成两步：
第一步：人人对齐。 先让团队对工程分层、建模方式、依赖边界达成共识。这一步需要 1 个"独裁者"角色统一所有相关方的标准。文中明确说"1 个独裁者好过 10 个民主者"，因为共识比正确更重要。
第二步：人机对齐。 等团队自己先统一了判断，再把共识固化为 AI 可以执行的约束——AI Rule + Skill。Rule 用来约束通用规范（如 always 级别的工程分层规则），Skill 用来处理最容易产生分歧的领域职责划分（如"编排类"与"能力类"的边界）。
顺序至关重要。如果团队自己没达成共识，AI Rule 写得再漂亮也会被不同人解释成不同版本。很多团队以为配置好 AI Rule 就万事大吉，真正的瓶颈在人，不在工具。
这一步的洞察很值钱：AI 不是用来替代人的判断，而是用来放大已对齐的判断。如果团队的判断本身没对齐，AI 只是把混乱等比放大。
三、怎么让重构不停业务？
行业里谈重构，通常只有两条路：要么推倒重来，要么申请专项排期。美团走了第三条路——把技术债拆成业务需求的"顺带动作"，借着迭代渐进式消化。
具体怎么做？
第一步是借助 AI 完成工程分层与解耦重构。他们从"按需求建包"的面条式代码，迁移到标准四层架构（Starter / Application / Infrastructure / Common）+ 业务域组织结构。重点不只是物理目录调整，而是借机治理 PO 对象在调用链中的泄露问题。
迁移过程不是"全组一起上"，而是**"主 R 打样 → SOP 分发 → 全组并行执行"**：重构负责人先亲自迁移两个最复杂的包，把过程中形成的标准操作固化成 SOP，其他成员按照 SOP 指导 AI 完成剩余工作，自己聚焦业务语义验收和 Code Review。
第二步是把技术债绑定到具体业务需求上。比如借着某个核心功能迭代，顺势落地全新业务模型；借着另一个功能升级，重新设计质检业务模型，3 月下旬一次性迁移全量，兼容多条业务链路。
这一步最难的不是技术，是拆解精度——哪些业务需求能"顺带"消化哪些技术债，需要逐个判断。判断错一次，要么重构拖慢业务，要么业务绕过技术债继续堆新债。
但回报也很明显：他们没有申请一天专门的重构时间，就在不停止业务交付的前提下完成了核心数据模型的平滑升级。
四、AI Coding 时代，CR 必须换一种玩法
AI 提效的下一个瓶颈，很快出现在 Code Review 环节。
代码生成速度被 AI 压缩到极致，但 Review 速度还是人工的。结果就是 CR 变成全链路最堵的瓶颈——AI Coding 的提效红利会被 CR 瓶颈吞掉。
美团的解法是让 CR 的角色重新定义：
- 人工 CR 的价值，从"你写得对吗？"转变为"我们是否在正确的约束下解决正确的问题？"
- AI 审查规范类问题，做业务逻辑初筛
- 人重点在前置技术方案评审环节把关，Review 代码是否符合技术方案
具体机制是 Pre-PR（预审）：
- 提交代码前，RD 必须先用 AI 审查代码进行多轮自查，修复所有 AI 能发现的问题
- AI 根据代码改动按模板自动生成 PR 文档（改动点、影响范围、需重点 Review 的业务逻辑）
- Reviewer 拿到的是"已过滤掉基础规范错误"的高质量代码，只需聚焦核心业务语义
他们还试了两种更野的路：高阶模型审查低阶模型（GPT-4 审 GPT-3.5 出的代码）和不同厂商模型对抗互相审核（用 Claude 审 GPT 的代码，用 GPT 审 Claude 的代码）。实测下来后者覆盖面更全，因为不同厂商的能力差异化能形成互补。
这套组合拳打下来，AI Coding 的提效红利才真正落到交付物上。
五、经验的价值正在重新定价
美团这次重构最有意思的副产物，是他们对"经验"这个概念的重新理解。
过去，"能看全"是资深工程师的核心壁垒——你得在系统里泡三年，才能建立起对调用链、隐式依赖、历史兼容逻辑的全局感知。这是过去十几年软件工程里最值钱的能力之一。
AI 把"看全"的门槛打到了几乎为零。AI 可以在几小时内把 31 万行代码的潜在性能隐患全部枚举出来，资深工程师逐行阅读也做不到。
但"看全"门槛降低后，经验的价值没有消失，而是迁移了——从"能看全"转移到"能判断什么重要"。
什么值得改、什么可以放一放、什么是真正的隐患什么是边缘情况——这些判断，AI 暂时还做不了，因为它没有业务上下文、没有历史决策记忆、没有"这个改动会影响张三负责的模块"的人际感知。
所以 AI Coding 时代最稀缺的能力，不是写代码，是判断。判断什么值得做、判断什么必须现在做、判断什么是表面问题什么是根因——这些才是团队真正值钱的能力。
美团那 10 个被 AI 挖出来的隐藏性能隐患，最终还是要靠人判断"哪些 P0、哪些 P1、哪些可以延后"。AI 解决产能，人解决优先级。
写在最后
如果你正带着一个 AI Coding 团队，这篇文章的结论可以浓缩成三句话：
第一，AI 是放大器，不是治理工具。 你团队对齐的程度，决定了 AI 帮你放大的是秩序还是混乱。
第二，治理的优先级永远高于生成。 AI Rule 是表层，团队共识才是底层。先人人对齐，再人机对齐。
第三，Code Review 是新的工程瓶颈。 AI Coding 提效后，CR 不跟上，提效红利会被堵在 Review 队列里烂掉。
美团那 31 万行代码的故事，最终指向的不是一个 AI Coding 的胜利，而是一个朴素的事实：任何提效工具的最终收益，都取决于治理它的那个团队。
工具越强，对人的要求越高——这是 AI Coding 时代所有技术领导者都必须接受的新契约。