AI Coding 的真正分水岭：从“会生成代码”到“会治理代码”

AI Coding 不是让 AI 多写代码而是让团队会治理代码本文是阅读美团技术团队《用Agent评测思路管理AI Coding —— 31万行代码AI重构的实践》后的思考、理解和落地应用整理。原文发布于 2026-05-08修改于 2026-05-23。本文不复述原文所有细节而是围绕“AI Coding 如何被工程化治理”展开自己的理解。文章目录AI Coding 不是让 AI 多写代码而是让团队会治理代码先说结论我对原文最有价值的三个理解1. “人人对齐”比“提示词写得好”更靠前2. AI 擅长“看全”人必须负责“判断重要”3. 技术债可以被产品迭代“顺带消化”但前提是拆得足够细我会如何把这套思路应用到自己的项目第一步建立“工程共识清单”第二步把共识变成 AI 可执行的 Rule第三步用 AI 做技术债扫描但由人确定优先级第四步设计 Pre-PR让人工 Review 从基础错误中解放出来一个小型落地案例把“新增功能”变成“顺带还债”业务需求顺带消化的技术债不在本次处理的范围验收标准这套方法的边界可复用落地清单适用范围与验证方式总结先说结论很多团队引入 AI Coding 后第一反应是追求“生成更多代码”。但读完美团这篇实践后我更强烈的感受是AI Coding 的核心问题不是产能而是治理。当 AI 可以快速生成代码时低质量代码的产生速度也会同步提升。如果团队没有统一分层、命名、领域边界、测试策略和 Review 标准AI 不会自动把系统带向更好的架构。相反它会顺着已有混乱继续补代码让技术债以更快速度增长。所以 AI Coding 真正要建设的不是一个“会写代码的助手”而是一套“让 AI 在正确约束下产出代码的工程环境”。我对原文最有价值的三个理解1. “人人对齐”比“提示词写得好”更靠前原文里最值得借鉴的点是把 Agent 评测中的标准对齐思路迁移到 AI Coding 管理中先让团队对工程判断达成共识再把共识沉淀成 AI 可以执行的规则。这对很多团队很有启发。我们经常看到这样的情况表面动作实际问题写了很长的 AI Rule团队自己对分层边界没有统一理解要求 AI 严格遵守架构代码库里已有大量反例AI 会优先模仿上下文让 AI 做 Code ReviewReview 标准本身没有被团队清晰定义让 AI 自动生成测试风险等级和验收边界仍然没人判断因此AI Rule 不是起点而是团队共识的固化结果。没有“人人对齐”直接做人机对齐最后很容易变成每个人都拿 AI 生成一套自己的工程风格。我的理解是AI Coding 治理的第一步不是安装工具而是回答几个工程问题这个项目的领域边界怎么划哪些对象可以跨层传递哪些必须被收口Controller、Application、Domain、Infrastructure 分别承担什么职责什么样的改动必须补测试什么样的问题可以交给 AI 自动审查什么必须人工判断这些问题如果没有被团队明确下来AI 只会提高“分歧被写进代码”的速度。2. AI 擅长“看全”人必须负责“判断重要”原文提到团队借助 AI 在复杂调用链中定位了多个隐藏较深的性能隐患。这个案例背后有一个非常关键的变化过去高级工程师的优势之一是能凭经验看穿复杂系统现在 AI 可以帮助更多人快速获得全局扫描能力。但这不等于人的经验不重要了。相反人的价值从“我能不能看完”变成“我能不能判断哪些值得改”。我认为可以把技术债治理拆成两类能力能力更适合谁做原因全局扫描、调用链梳理、重复模式发现AI适合批量、穷举、跨文件检索风险分级、收益判断、改造顺序设计人需要业务上下文、交付压力和架构取舍迁移脚本、重复结构改造、模板化补齐AI 人验收规则明确但影响面大业务语义确认、兼容性决策、上线节奏人需要承担结果责任所以 AI 不是替代工程经验而是把经验的重心前移了。以前经验体现在“我知道哪里可能有坑”现在更体现在“AI 找出一堆坑后我知道先处理哪个、放弃哪个、如何不影响业务节奏”。3. 技术债可以被产品迭代“顺带消化”但前提是拆得足够细很多重构失败不是因为技术方案错而是因为重构被包装成了一个巨大专项范围大、收益滞后、业务方感知弱、上线风险高。原文的做法更务实把技术债拆进业务需求在真实迭代里逐步消化。我对这一点的理解是渐进式重构不是“不排期”而是把重构拆到足够小小到它可以成为业务需求的一部分。比如一个订单系统存在如下技术债订单状态散落在多个服务中重复判断。数据库 PO 对象被 Controller 直接返回。查询接口没有分页保护。复杂筛选逻辑分散在多个 Mapper 中。如果直接说“我要重构订单模块”大概率很难排期。但如果下一个业务需求是“新增订单异常处理视图”就可以顺带做几件事新增统一的订单状态枚举和转换层。在 Application 层定义新的查询返回对象。只改本次需求触达的接口不全量迁移。给新增视图补齐最小回归用例。在 PR 文档里记录剩余旧接口的迁移清单。这样每次只吃掉一块债务但系统方向是持续变好的。我会如何把这套思路应用到自己的项目如果把原文方法迁移到一个中小型后端项目我不会一开始就追求复杂的 Agent 平台而会先做一套轻量闭环。第一步建立“工程共识清单”先写一份短文档控制在 1 到 2 页重点不是面面俱到而是把高频分歧讲清楚。示例# 工程共识清单 ## 分层规则 - Controller 只做参数接收、权限校验入口和响应组装。 - Application 负责编排业务流程不直接写 SQL。 - Domain 负责核心业务规则和状态流转。 - Infrastructure 负责数据库、缓存、外部 API 等技术细节。 ## 对象传递规则 - PO 不允许返回到 Controller。 - DTO 不允许下沉到 Repository。 - 复杂查询必须有 Request 对象禁止散落多个同义参数。 ## AI Coding 规则 - 生成代码前先读取同模块既有风格。 - 修改跨层调用时必须说明影响范围。 - 新增状态、枚举、字段时必须搜索所有旧分支。 - 不允许凭空新增未使用的抽象层。这份文档的价值不在于“文档很好看”而在于它能变成 AI Rule、Code Review 清单和新人上手标准。第二步把共识变成 AI 可执行的 RuleAI Rule 不应该写成口号而应该写成可检查的约束。不好的写法请写出高质量代码注意架构优雅。更好的写法修改后端代码时必须执行以下检查 1. 如果新增 Controller 返回值确认没有直接返回 PO。 2. 如果新增 Repository 方法确认 SQL 查询有分页、索引字段或调用方数量限制。 3. 如果修改状态枚举搜索所有 switch、if、数据库状态值映射和前端展示文案。 4. 如果新增跨模块依赖说明依赖方向是否符合现有分层。 5. 输出变更说明时必须包含影响范围、验证方式和回滚建议。规则越接近可执行检查AI 越容易稳定遵守。第三步用 AI 做技术债扫描但由人确定优先级我会把扫描任务拆成几类让 AI 分批处理扫描方向AI 任务人的判断数据对象泄露搜索 PO/Entity 是否跨层返回是否立即改还是等业务需求触达性能隐患搜索无分页查询、循环查库、N1 调用判断真实流量和数据量状态管理搜索状态枚举、魔法值、重复判断确认统一模型和兼容方案异常处理搜索吞异常、只打印日志、返回不一致确定用户可感知错误语义测试缺口对照核心链路找缺失用例决定哪些必须补哪些可以暂缓这一步不能让 AI 直接改。先让 AI 产出候选清单再由人标注 P0、P1、P2。否则很容易出现“AI 修了很多不重要的问题但真正的风险还在”的情况。第四步设计 Pre-PR让人工 Review 从基础错误中解放出来我比较认同原文对 Review 的重新定位AI Coding 提高编码速度后Code Review 会成为新的瓶颈。如果不改变 Review 方式团队只是把压力从开发阶段转移到了审查阶段。一个可落地的 Pre-PR 模板可以这样设计## 变更目标 - 本次解决什么业务问题或技术债 ## 影响范围 - 涉及接口 - 涉及表 - 涉及定时任务/消息/缓存 ## AI 自查结果 - 分层规则检查 - 对象泄露检查 - 性能风险检查 - 状态兼容检查 - 异常处理检查 ## 人工重点 Review 点 - 需要 Reviewer 判断的业务语义 - 可能存在争议的架构取舍 - 上线后重点观察指标 ## 验证方式 - 单元测试 - 接口测试 - 回归场景 - 回滚方式这个模板的核心是分工AI 负责先过滤规范类、重复类、可扫描类问题人负责判断业务语义、架构取舍和上线风险。Pre-PR 的价值不是替代人工 Review而是把基础规范、明显 Bug、性能和异常处理等问题先过滤掉让人工 Review 聚焦真正需要工程判断的部分。一个小型落地案例把“新增功能”变成“顺带还债”假设项目要新增“客户风险标签”功能旧系统里客户标签逻辑分散在多个接口中并且有不少硬编码判断。如果用原文思路我会这样拆业务需求新增客户风险标签展示支持按标签筛选客户列表。顺带消化的技术债把散落的标签判断收口到CustomerTagService。新增CustomerRiskTag枚举替换本次链路中的魔法字符串。新增CustomerTagQueryRequest避免 Controller 继续堆参数。给筛选接口补分页和索引字段说明。不在本次处理的范围不迁移所有历史标签接口。不重构客户画像全部模型。不调整前端所有旧页面展示。验收标准新功能链路不再新增硬编码标签判断。新接口不直接暴露数据库对象。新增筛选有分页限制。旧接口行为保持兼容。PR 文档记录后续待迁移接口。这样做的好处是重构不是脱离业务的额外动作而是被绑定到一次真实需求交付中。每次只改一小段但每次都把系统往正确方向推一点。这套方法的边界这篇美团实践很有参考价值但不能简单照搬到所有团队。第一团队必须有人能做技术判断。AI 可以帮忙扫描但如果没人能判断 P0/P1、没人能定义分层边界扫描结果只会变成一堆看起来很忙的待办。第二规则不能一次写太多。中小团队如果一上来就写几十页规范很可能没人维护AI 也很难稳定遵守。更现实的方式是从最痛的 3 到 5 条规则开始。第三渐进式重构需要持续记录。不申请专项排期不代表不管理进度。每次顺带消化了什么债、还剩什么债、哪些旧链路不能动都要写进技术债台账。第四Pre-PR 不能变成形式主义。如果 AI 自查只是复制模板人工 Review 仍然要从头看那它没有降低成本。Pre-PR 必须能把“哪些问题已经自动检查过哪些问题需要人重点看”讲清楚。可复用落地清单如果现在就要在项目里试起来我建议按下面顺序做选一个最痛模块不全项目铺开。写 5 条以内的工程共识规则。把规则改写成 AI 可执行检查项。让 AI 先扫描技术债不直接改代码。人给债务清单分 P0、P1、P2。选择一个真实业务需求绑定一个小债务一起处理。由主力开发者先完成一次样板迁移。把迁移步骤沉淀成 SOP。后续类似改动让 AI 按 SOP 执行。所有 PR 必须带 Pre-PR 自查和验证说明。适用范围与验证方式这套方法更适合已经有一定代码规模、多人协作、需求持续迭代并且开始大量使用 AI Coding 的项目。如果只是个人 Demo 或一次性脚本完整引入 Rule、Skill、Pre-PR 和技术债台账可能会显得过重。我会用下面几个指标验证它是否真正有效验证项判断方式AI 生成代码是否更稳定同类需求中分层错误、对象泄露、命名不一致问题是否减少Review 成本是否下降Reviewer 是否能少看基础规范问题更多关注业务语义技术债是否被持续消化每个迭代是否至少关闭一小项已登记债务重构是否影响业务交付需求交付周期和线上缺陷是否没有明显恶化规则是否可维护新人能否根据 Rule 和 SOP 完成一次小范围改造如果执行两到三个迭代后只有文档变多、会议变多、Review 仍然从头看那么说明这套机制没有真正进入工程流水线需要缩小规则范围优先保留最能减少返工的检查项。总结读完这篇文章后我最大的收获是AI Coding 的成熟度不取决于团队用了多强的模型而取决于团队有没有能力把工程判断沉淀成可执行约束。AI 可以让代码生成更快也可以让技术债增长更快。真正的关键在于人要先定义什么是好代码、什么是正确边界、什么是值得优先处理的问题然后再让 AI 在这些约束里工作。所以我更愿意把 AI Coding 看成一种新的工程治理方式人负责目标、标准、优先级和责任边界AI 负责扫描、生成、迁移和自查。只有这两部分配合起来AI 才不是一个更快的代码搬运工具而是一个能被团队稳定驾驭的工程生产力系统。感谢阅读记得点赞、关注、收藏欢迎各位评论区交流