31万行代码如何交给AI重构？美团团队的治理方法论

当一个系统从不足5万行代码膨胀到31万行，月均承载16个需求，其中约八成是业务需求——而团队还要同时消化旧架构的技术债，这件事还能交给AI吗？美团业务研发平台给出的答案不是"让模型重写一遍"，而是先把标准统一，再让模型执行。这套思路来自他们管理AI编码的实践，也来自他们本就熟悉的Agent评测经验：先拉齐人的判断，再检查机器与人的判断能否一致。

重构的真正难点：复杂性藏在能力组合里

据原文介绍，这套系统底层支持6种多模态数据评测，上层又有不同的任务视图、业务动作、标签和动态分配机制。复杂性不只是文件多，而是能力之间存在大量组合——一个接口变化，可能牵动多条业务流。

团队归纳出三个重构动因：业务模型扩展能力不足，新增业务形式往往要新增一套实现；过去按需求建包，逻辑混杂、缺乏清晰分层；团队规模和技术背景变得更多样，AI又承担了大量编码工作。不同人给出不同设计、不同上下文，模型就会沿不同风格继续生成代码。生成速度提高并不会自动带来结构收敛，系统需要明确边界，新增代码才能向同一方向生长。

第一阶段：专家定向，模型扩查

面对大量隐式逻辑和兼容分支，团队没有从头逐行阅读，而是采用"专家经验定向、模型辅助排查"的方法：先圈定高优方向，例如业务模型、数据库查询性能、状态管理和索引，再让模型沿这些方向扫描调用关系。人决定哪些问题属于高优先级、哪些值得先改。

分工依据很清楚：模型适合扩展排查范围，而业务影响和修复价值仍需人的判断。扫描发现还要回到代码中核实。这一步团队梳理出三项最高优先级和两项次高优先级技术债，并借助模型定位了十个隐藏较深的性能隐患。

值得保留的边界是：发现更多问题，与知道哪个问题该先解决，是两个不同环节。更可靠的迁移方式是先说明风险类别和核验依据，再判断发生概率、影响范围与修复成本。

第二阶段：先统一共识，再写进规则

第二阶段的核心，是把团队共识放到工具配置之前。如果开发者对某个职责属于哪一层都没有共识，即使共享同一份配置，也可能各自解释成不同版本。工程上的启发是：规则冲突要先回到具体例子讨论，形成可复查的判断。

原文落地了工程分层、业务域模型和仓储层规约，并将基础要求配置成始终生效的模型规则；针对容易产生分歧的编排类与能力类职责，先在组内统一，再沉淀为编码时逐步加载的技能。两类形式对应不同层次——基础边界持续约束生成，任务知识在需要时提供细节。

提交前的预审环节，也不只是让模型生成一份文档。从工程角度看，最好用真实改动观察规则是否有效：有没有拦住旧问题，是否误伤合理实现，文字约束与代码检查能否相互支撑。

模型规则与技能：在AI编码工具链中，“规则”通常指始终注入到模型上下文中的约束（如分层规范、命名约定），确保每次生成都遵守基础边界；“技能”则是按需加载的指令包，在特定任务（如编排类代码编写）时提供细节指导。两者结合，既能持续约束生成风格，又能为复杂场景提供灵活知识，避免规则冲突或上下文过载。

迁移阶段：治理的是偶合，不是目录

3月至4月的迁移阶段，团队把按需求组织的代码逐步迁移到入口、应用、基础设施和公共四层结构，同时按业务域组织。重点不是目录调整，而是治理深度偶合，尤其是持久化数据对象在调用链上层层传播的问题。如果上层接口直接依赖底层表结构，一次存储变化就可能要求多处修改。

围绕底层对象泄露，文章给出三个连续动作：先补齐业务对象与数据转换层，集中原本散落的转换逻辑；再在应用层重建接口契约，阻止底层数据对象直接向上流动；最后沿新契约修复上游调用链的参数依赖。这是一条连贯路径，只做第一步——比如增加了业务对象却仍让调用方读取持久化对象——依赖就没有真正收口。

检查迁移是否成功，不能只统计文件移动数量，还要观察原本不该知道底层细节的地方是否真的不再依赖。模型可以承担大量重复改写，人则需要检查新契约是否准确表达业务含义、兼容路径有没有被遗漏。为此，负责人先亲自完成两个最复杂包的改造，把判断和操作沉淀成模型可执行的标准流程，其他成员再按流程指导模型迁移剩余包，自己聚焦业务语义验收和代码审查。团队用这种方式完成了十余个核心包的工程结构迁移。关键是先用真实难题把流程跑通，而不是凭空写一份指导书。

对更深的业务模型重构，团队采用把技术债拆进日常高优需求的方式：某个核心功能迭代时顺势设计新业务模型，另一个功能升级时再完成质检业务模型改造，三月下旬已完成相关全量迁移。文章称之为"零排期重构"——没有申请专门的重构时间，并不代表重构不消耗工作量；负责人打样、规则制定、兼容迁移和审查都是真实投入。可借鉴的是把改造与当期业务目标绑定，降低争取资源的难度，但不能理解为任何技术债都能免费解决。若改造风险已超出当前迭代的控制能力，继续拆分通常比强行塞入更稳妥。

深度偶合：指模块间通过隐式依赖（如直接引用底层数据结构）形成的强耦合，比接口耦合更难察觉和治理。在分层架构中，持久化对象（如数据库表对应的实体）沿调用链向上传播，导致上层业务逻辑与存储细节绑定。治理深度偶合需要引入业务对象与数据转换层，并在应用层重建契约，阻断底层对象泄露。

编码提速之后，审查成了新拥堵点

团队发现代码审查成为新的瓶颈，于是重新分工：模型处理规范问题并做业务逻辑初筛，人更多在前置方案评审中判断方向、在审查时判断实现是否符合方案与业务逻辑。这不是取消代码审查，而是调整人工注意力的分配。评估提效要看从方案到合入的完整周期，避免只看生成速度却忽视下游积压。

预审机制要求研发提交前先让模型进行多轮自查，覆盖规范、异常处理、一致性、扩展性和性能等问题，再按模板提交说明，重点交代改动点、影响范围和需要人关注的业务逻辑。这里可以加一道核验：自动生成的说明必须与实际差异相符，尤其检查未列出的影响和不确定项——说明写得完整，并不证明分析完整。

原文还尝试了两种模型互审方式：用能力更强的模型审查其他模型生成的代码，以及让不同厂商模型交叉审查。团队认为这能扩大检查覆盖面，但文章没有给出可通用于其他项目的准确率保证。多个模型也可能共享盲点，重复得出同一个错误结论。交叉意见最好回到代码位置、执行路径和测试证据上比较；出现分歧时，真正有价值的是弄清各自依据，而不是按模型数量投票。

模型互审：让一个模型审查另一个模型生成的代码，或让不同厂商模型交叉审查，以扩大检查覆盖面。但需注意，模型可能共享训练数据中的盲点，导致重复错误结论。交叉意见应回到代码位置、执行路径和测试证据上比较，而非简单按模型数量投票。

测试：先定范围，再谈生成

团队由研发兼任测试，曾探索两条路线。第一条让模型自动生成全部用例、人最后把关，很快暴露问题：模型依赖需求文档，容易漏掉隐式关联的高危场景，又发散出许多低价值边缘用例，反而增加审查负担。与专业测试团队交流后，他们选择了第二条：人先确定测试范围和风险等级，再由模型扫描代码补充步骤。

流程上，第一步从流量监控和代码变更两个方向收集受影响接口，由人审核最终范围并排除误报；第二步模型阅读代码，回答改动有多大、分支在哪里、旧数据能否兼容，再由人判断风险等级和测试深度。代码差异与真实使用提供不同角度，相互补充——流量清单看似天然完整，但仍需人补充业务链路和历史约束。

第三步使用判定表先拆后合，生成尽可能精简的用例组合，由人检查分组合理性并补充特殊场景。这里有个容易误用的地方：把最小组合当作最低数量目标。精简应建立在风险和条件已覆盖的前提上，关键差异被合并掉，数量少只会掩盖遗漏。最后生成接口与验证维度的覆盖矩阵并标记覆盖项，由人确认是否有盲区。矩阵能把散落在文字用例里的对应关系显式展示出来，但如果最初没有列出某个重要维度，表格再完整也发现不了遗漏，所以覆盖确认要同时看矩阵内部空白和矩阵定义本身是否准确。

判定表：一种系统化设计测试用例的方法，通过列出条件与动作的组合，先拆分再合并，生成精简且覆盖关键场景的用例集。在AI辅助测试中，人先确定测试范围和风险等级，模型利用判定表生成组合，再由人检查分组合理性并补充特殊场景，避免模型发散出低价值边缘用例。

这套方法对团队意味着什么

回顾全文，最有价值的并非31万行这个规模，而是它如何把快速生成带来的治理问题拆成可执行环节。原文报告了具体迁移与排查成果，但没有提供适用于所有系统的提效比例，也不能据此认为自动重构已经没有风险。需要具备的条件包括：能够判断架构边界的人、可反复执行的迁移流程，以及对业务语义和历史兼容的验收能力。

如果想借鉴，可以沿原文顺序推进：核心开发圈定高优方向、借助模型盘清技术债；统一分层建模和依赖标准，把共识放进规则与技能；负责人完成一个复杂模块并沉淀迁移流程后再推广；最后建立提交预审与人工业务验收。每一步都需要具体产物——技术债清单、契约梳理、审查说明——才能判断方法是否真正执行。不必复制原文所有层名和工具配置，但应保留这个顺序：先做判断，再约束生成，用实际改动核验。

这次实践收束到一个具体变化：工程师除了写代码，还要设计和维护一个让模型可靠产出的环境。这个环境由团队共识、常驻规则、任务技能、迁移流程、提交预审和测试验收共同组成。借鉴时最值得先做的，是挑一个真实难题，把如何判断、如何迁移、如何验收全部跑通。只有这样的经验沉淀下来，模型带来的速度才更可能转化为持续交付能力。