重新定义Windows上的安卓应用体验：APK安装器的革命性突破
2026/7/13 1:10:19
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 Review | Review 标准本身没有被团队清晰定义 |
| 让 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 可执行的 Rule
AI Rule 不应该写成口号，而应该写成可检查的约束。
不好的写法：
请写出高质量代码，注意架构优雅。更好的写法：
修改后端代码时必须执行以下检查： 1. 如果新增 Controller 返回值，确认没有直接返回 PO。 2. 如果新增 Repository 方法，确认 SQL 查询有分页、索引字段或调用方数量限制。 3. 如果修改状态枚举，搜索所有 switch、if、数据库状态值映射和前端展示文案。 4. 如果新增跨模块依赖，说明依赖方向是否符合现有分层。 5. 输出变更说明时必须包含影响范围、验证方式和回滚建议。规则越接近可执行检查，AI 越容易稳定遵守。
第三步：用 AI 做技术债扫描，但由人确定优先级
我会把扫描任务拆成几类，让 AI 分批处理：
| 扫描方向 | AI 任务 | 人的判断 |
|---|---|---|
| 数据对象泄露 | 搜索 PO/Entity 是否跨层返回 | 是否立即改，还是等业务需求触达 |
| 性能隐患 | 搜索无分页查询、循环查库、N+1 调用 | 判断真实流量和数据量 |
| 状态管理 | 搜索状态枚举、魔法值、重复判断 | 确认统一模型和兼容方案 |
| 异常处理 | 搜索吞异常、只打印日志、返回不一致 | 确定用户可感知错误语义 |
| 测试缺口 | 对照核心链路找缺失用例 | 决定哪些必须补，哪些可以暂缓 |
这一步不能让 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 才不是一个更快的代码搬运工具，而是一个能被团队稳定驾驭的工程生产力系统。
感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！