辽宁
一个反直觉的结论：AI Coding 不会自动让代码变好，没有规范约束，反而会加速腐化。
最近看到美团技术团队的一篇实战复盘，非常硬核！
他们用 AI 完成了一次 31万行代码的大重构 ——全程没有申请一天专项排期，90% 以上代码由 AI 辅助生成，最终不仅完成了技术债清偿，还没有影响正常业务交付。
整篇文章我反复读了两遍，核心是四条经验。
第一条：先对齐人，再约束 AI。
这是整篇文章最重要的一句话。
很多团队上了 AI 编码工具后，直接让 AI 生成各种编码规范，然后配成 Rule 让大家遵守。
但美团踩过坑后发现：如果团队本身没有统一共识，AI Rule 写得再好也是一纸空文——不同人会把同一条规范解释成不同版本，系统反而以更快的速度腐化。
正确顺序是： 先让团队对齐（人人对齐），再把共识固化为 AI 的约束（人机对齐）。
真正的瓶颈不在工具，在人。
第二条：AI 让"经验"的价值边界变了。
过去，资深工程师的核心价值是"能看全"——要靠三年经验积累才能建立代码全局感。
现在，AI 接管了这件事。把方向给它，全量扫描几分钟出来。
但 "能判断什么最重要" 这件事，AI 给不了。
哪个技术债值得优先改？哪个模块要重点关注？这些判断，还是得靠人。
经验的价值没有消失，只是从"看全"转移到了"判断"。
第三条：技术债不需要排期，需要拆解能力。
这是最反直觉的一条，也是我觉得最有价值的部分。
传统思路处理技术债无非两条路：推倒重来，或者申请专项排期。两条路都很难——前者风险太大，后者资源争不到。
美团走了第三条路： 把技术债拆解成业务需求的"顺带动作" ，借着每次业务迭代渐进式消化。
举个例子：某个核心功能要迭代，顺手把底层数据模型重构了；另一个功能要升级，顺便把质检业务模型全量迁移了。
31 万行代码，就这么一点一点吃掉的，全程业务没停。
这需要极强的拆解能力：要知道哪些技术债能"搭便车"，哪些不行；既不能让重构拖慢交付，也不能让业务绕过技术债继续堆新债。
这本质上是一种 把技术工作像业务需求一样迭代消化 的思维方式。
第四条：AI 编码提速之后，Code Review 才是新瓶颈。
木桶效应。
AI 编码效率上去了，结果 CR 开始堵。如果不解决这个瓶颈，AI 带来的提效红利会被 CR 吞掉。
他们的解法是建立 Pre-PR 机制 ：提交代码前，必须先用 AI 按团队规范自查一遍，把基础问题过滤掉，再提交给人 Review。
这样，人工 CR 的重心就从"你写得对吗"转移到了"我们是否在用正确的方式解决正确的问题"。
人的注意力，用在了值得用的地方。
最后说一句：
AI Coding 的本质变化，不是"写代码变快了"，而是 工程师的职责从"写代码"变成了"设计一个让 AI 能可靠产出代码的工程环境" 。
这个环境包括：规范、架构、Rule、SOP、CR 机制……
谁能把这个环境建好，谁就真正用好了 AI。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
