案例复盘：美团用 Agent 评测思路管理 31 万行 AI 重构

用评测思维管 AI Coding，顺序比工具重要。

最值得抄的是那条主线：先「人人对齐」，再「人机对齐」。团队先对分层、建模、依赖边界形成共识——「1 个『独裁者』好过 10 个『民主者』」——再把共识固化为 always 级 AI Rule 与 Skill。排查阶段的做法同样可复制：专家圈定高危边界、AI 做穷举扫描，有限投入就摸清 3 个 P0、2 个 P1 技术债，还顺带定位了 10 个隐蔽的性能隐患。

要提醒成立前提：零排期重构的前提是你能支配自己的需求池，受客户节奏约束的交付场景里，「顺带」的部分往往排期一紧就先被砍；拉齐标准的强角色是单点，人一撤共识就开始蒸发，关键规范要有第二责任人。质量兜底也别只压在 CR 上——机械迁移里人眼抓得住风格、抓不住行为漂移，等价性验证要跟上。

本周就能做的一步：把团队对分层与建模的共识写成一页纸，先让人人对齐，再谈 AI Rule。

—— FDEChina编辑部 · 实战派

一、背景

案例主体是美团内部一个负责 Agent 评测业务的团队（公司技术博客口径）。其 Agent 评测系统长期承载多个核心业务场景，同时承担数据生产、流程编排、质量控制与多人协作：底层支持 6 种多模态数据评测，上层有多种核心任务视图与精细化业务动作，配套十余种质检机制。系统从 2025 年 6 月的不足 5 万行代码扩展到 31 万行，保持月均 16 个需求（80% 业务需求加 20% 技术需求）的高负荷迭代；团队一年左右规模增至 3 倍，成员背景覆盖高并发、机器学习离线训练、管理后端与实习生，且 90% 以上的代码由 AI 辅助编写。

二、问题

团队复盘直指一个反直觉的事实：AI Coding 不会自动收敛复杂度——没有统一规范约束时，不同人用 AI 写出的代码风格各异，系统反而加速腐化。三个痛点集中爆发：业务模型扩展能力不足，几乎每新增一种业务形式都要新增代码，形成「烟囱式」开发；长期「按需求建包」让 Controller 等复杂逻辑揉在一个包里，31 万行体量下的「面条式代码」让日常开发牵一发而动全身；团队一年扩张 3 倍、背景多样，再叠加 90% 以上代码由 AI 生成，若不建立硬性规范，系统将以极快的速度产生不可控的腐化与新债。而业务处于探索期，需求又急又模糊——既不可能停下来做专项，也不能放任新债生长。

三、方案

团队把本职工作里的 Agent 评测方法论迁移到工程治理，核心是一条标准对齐主线：「人人对齐→人机对齐」。先由一位强有力的角色拉齐产品、运营、算法、QA 等所有角色的工程标准——「1 个『独裁者』好过 10 个『民主者』」；再把共识固化为 AI 可执行的约束：工程分层规范、业务域模型规约与仓储层规约落地为 always 级 AI Rule，前置到预 CR 环节约束编码过程；围绕「编排类」与「能力类」的职责边界做组内统一，共识沉淀为编码时渐进式加载的 Skill。顺序至关重要：团队没有先形成共识时，同一份规范会被不同人解释成不同版本，AI Rule 写得再好也是一纸空文。

四、实施过程

重构沿三个阶段推进（公司技术博客口径，2026 年 2 月至 4 月）。

阶段一：定义问题（2 月）。面对看不完的 31 万行代码，团队采用「专家经验定向 + AI 辅助排查」：核心开发圈定高危排查边界，AI 负责穷举扫描，快速摸清业务模型缺陷、数据库查询性能隐患、状态管理与索引等技术债，共梳理出 3 个 P0 与 2 个 P1 技术债；工程师还借 AI 在短时间内定位了 10 个隐藏极深、肉眼极难发现的性能隐患。

阶段二：制定 AI 友好规范（2 月底完成）。把规范从文档落地为 always 级 AI Rule，并前置到预 CR 环节，帮助研发在提交前完成基础规范校验；针对最容易产生分歧的领域职责划分，将「编排类/能力类」的组内共识沉淀为 Skill。

阶段三：渐进式重构与质量兜底（3-4 月）。其一，工程分层与解耦：把面条式代码迁移到 Starter / Application / Infrastructure / Common 四层架构，先由重构主 R 亲自完成两个最复杂包的迁移并沉淀标准化迁移 SOP，其余成员按 SOP 指导 AI 完成剩余包迁移，快速完成十余个核心包的结构迁移。其二，零排期重构：把技术债拆解为业务需求的「顺带动作」，借核心功能迭代落地全新业务模型、借功能升级完成质检业务模型全量迁移，没有申请一天专门的重构时间。其三，质量保障：引入 Pre-PR 机制，提交前先用 AI 多轮自查修复规范类问题；人工 Review 从「你写得对吗」转向聚焦技术方案符合性与业务逻辑；用高阶模型审查低阶模型产出，并用不同厂商模型互审以扩大覆盖面；测试确定「人工主导、AI 辅助」路线——全自动生成用例的路线因缺乏全局业务认知、易漏隐性高危场景而被放弃，团队 100% 的需求由研发兼任测试。

五、结果

以下均为公司技术博客口径，未经独立核实。重构在不停止业务交付的前提下完成：十余个核心包完成工程结构迁移；核心数据模型与质检业务模型完成平滑升级与全量迁移（兼容多条业务链路与多视图、多区域的交叉验证）；技术债梳理以有限投入定位 3 个 P0、2 个 P1，并发现 10 个性能隐患，全程没有申请专门的重构排期。文中同时给出两条定性判断：「经验」的价值正从「能看全」转移到「能判断什么重要」；工程师的重心从「写代码」转向「设计并维护一个能让 AI 可靠产出代码的工程环境」。

六、约束

这套打法的成立条件值得看清：零排期重构的前提是团队能支配自己的需求池，能把技术债拆进高优需求「顺带」消化，且拆解精度依赖很强的技术判断力；标准对齐依赖一位强有力的拉齐角色，这本身构成单点；规范的价值在 90% 以上代码由 AI 生成的场景才被充分放大；Pre-PR 与 AI CR 要求团队接受人工 Review 的角色重定义——这是流程改造，不只是引入工具。

七、可复用经验

先人人对齐，再固化 AI Rule。顺序不能反：团队对分层与建模没有共识时，任何 Rule 都会被解释出多个版本。适用前提：有能拍板拉齐标准的角色。
主 R 打样、SOP 分发、全组并行。让最熟的人先跑通完整样板，把步骤沉淀为 AI 可执行的 SOP 再复制，比人人摸索快且稳。
技术债拆为需求的顺带动作。适合能支配需求池的团队；受客户节奏约束的交付场景，建议给顺延的债务项设升级机制，避免台账空转。
CR 前移。AI 提速后 CR 会成为新瓶颈，Pre-PR 自查让人工 Review 聚焦业务语义，这一步不能省。
测试人工主导、AI 辅助。全自动用例生成已被该团队实践证伪，Human-in-the-loop 更稳——与 Agent 评测领域「人机一致率达标才可信」的门槛一脉相承。

中国语境差异：文内场景是大厂自有业务团队；对外部客户交付的 FDE 项目，AI Rule 与规范还要同时适配客户侧代码库约束与安全审批，落地时需多留一层适配成本。

八、来源

原文：用Agent评测思路管理AI Coding —— 31万行代码AI重构的实践，美团技术团队博客，tech.meituan.com，2026-05-07；
口径说明：本篇数据（31 万行、月均 16 个需求、90% 以上 AI 生成、3 个 P0、10 个性能隐患等）均为公司技术博客口径，未经独立核实。