美团：31万行代码AI重构实录案例，当90%代码由AI生成，你该怎么管？

前两天，美团技术团队发了一篇文章，讲他们怎么用AI重构一个31万行的Agent评测系统。

说实话，这个数字本身就挺吓人的——31万行，90%以上由AI生成，团队一年内膨胀到3倍，技术背景还五花八门，有搞高并发的、有搞机器学习离线训练的、有搞管理后端开发的，还有实习生。

这画面太熟悉了。

很多团队现在都面临同样的困境：AI Coding让代码产出速度猛涨，但系统复杂度也跟着猛涨。不同人用AI写出来的代码风格千奇百怪，系统不是在收敛，而是在加速腐化。

美团技术团队的做法，把这个问题从「无解」变成了「有路径」。

而且有意思的是，他们做Agent评测出身，最后用评测Agent的思路来解决AI Coding的管理问题——这也算是一种「自己给自己看病」。

先看他们遇到了什么。

问题一：业务模型扛不住了

这套Agent评测系统底层支持6种多模态数据评测，上层构建了多种核心任务视图和十几种质检机制。业务交互越来越复杂，旧数据模型的扩展能力不够，每新增一种业务形式都得写一堆新代码。

问题二：代码严重腐化

过去长期「按需求建包」，Controller和各种复杂逻辑揉在一个包里，形成了严重的面条式代码。31万行的体量下，牵一发而动全身，开发体验极差。

问题三：AI Coding加速了腐化

注意，这不是AI Coding的问题，是「缺乏规范的AI Coding」的问题。当90%的代码都由AI生成，没有硬性架构规范约束，不同背景的人各自用AI写，系统会以极快的速度产生不可控的新债。

很多团队觉得AI Coding能自动收敛代码质量。这是错觉。AI不会纠偏，它只会放大当前的模式——如果代码库本身风格混乱，AI会把这个混乱加速放大。

那他们怎么做的？

我读完整个实践过程，最打动我的是三个阶段。

第一阶段：人定方向，AI做脏活

要重构31万行代码，最大的困境是什么？

量太大，看不完，也看不全。

过去要靠经验丰富的工程师在系统里泡三年，才能建立起对调用链、隐式依赖的全局认知。但现在，AI把「看全」这个门槛打到了几乎为零。

他们的方法很简单：由核心开发圈定高风险的排查边界，然后让AI在这个边界内做穷举扫描。

效果很猛。

仅仅投入了有限的资源，就完成了3个P0级和2个P1级技术债的梳理。更让人意外的是，工程师利用AI辅助精准定位了10个隐藏极深、靠肉眼几乎发现不了的性能隐患——这些隐患藏在复杂的调用链深处，即使再资深的工程师，逐行阅读也很难全部找到。

这就引出了一个值得深思的问题：经验的价值到底在哪？

第二阶段：人人对齐，再人机对齐

这是我觉得最有启发的部分。

他们团队做Agent评测业务，长期沉淀出一套核心理念——先让产品、运营、算法、QA所有角色的评测标准对齐（一个「独裁者」好过十个「民主者」），对齐后再通过模型选型和指标优化实现人机对齐。

管理AI Coding的底层逻辑一模一样：

先通过规范拉齐团队对工程标准、分层原则、依赖边界的理解（人人对齐），再把共识固化为AI可执行的Rule和Skill（人机对齐）。

顺序不能反。

很多团队以为配置好AI Rule就完事了。但真正的瓶颈不在工具，在人。团队自己没对齐，AI Rule写得再好也会被不同人解释成不同版本。

他们最终沉淀的产出包括：工程分层规范、业务域模型规约、仓储层规约——全部落地为AI编码时always加载的Rule，并前置到预CR环节。

第三阶段：零排期重构

这一点最反常识。

行业里谈重构，通常两条路：要么推倒重来，要么申请专项排期。他们走了第三条路：把技术债拆解为业务需求的「顺带动作」，借着迭代渐进式消化。

没有申请一天专门的重构时间。

具体操作是：借着某个核心功能的迭代需求，顺势设计并落地了新的业务模型；借着另一个功能升级需求，设计新的质检业务模型并完成全量迁移。

核心难点在哪？拆解的精度。

哪些业务需求能「顺带」消化哪些技术债，需要逐个判断——既不能让重构拖慢业务交付，也不能让业务需求绕过技术债继续堆新债。这需要极强的技术判断力。

但一旦跑通，重构就不再是与业务争资源的零和博弈。

另外还有一个细节特别值得注意：他们建立了Pre-PR机制。

为什么？因为AI极大压缩了编码时间，压力系统性地转到了Code Review环节。如果CR效率不提升，AI Coding的提效红利会被CR瓶颈全部吞掉。

他们的方案：提交前先用AI审查代码进行多轮自查，修复AI能发现的所有问题（规范类、Bug类、异常处理、一致性等），确认通过后再提交PR。Reviewer拿到的是已经过滤掉基础错误的代码，只需聚焦核心业务语义。

还用了高阶模型审低阶模型、不同厂商模型互审的策略。

说到这，几个关键的判断值得记住：

第一，AI不会自动收敛复杂度，没有规范约束，AI只会成倍放大混乱。

第二，经验的价值正在从「能看全」转移到「能判断什么重要」——AI把看全的门槛打平了，但判断优先级还是人的活。

第三，当90%代码由AI生成，工程师的工作重心应该从写代码转向设计并维护一个能让AI可靠产出代码的工程环境。

第四，重构不一定要排期，可以拆解到业务需求里顺带消化。这需要判断力，但一旦跑通就一劳永逸。

这篇文章让我最感慨的不是方法论本身，而是他们用做评测的思维做工程治理——自己的业务沉淀反过来给了自己一套管理AI Coding的框架。

这大概就是所谓「你的工作本身就藏着答案」。

全文链接：美团技术团队原文