AI Coding 真正难的不是写得快，是把工程边界立住
最近看了美团技术团队的一篇实践文章：《用Agent评测思路管理AI Coding，31万行代码AI重构的实践》。
记住的，不是“AI 帮他们重构了多少代码”，而是一个更实际的问题：
当 AI 已经成了主要编码产能，团队拿什么保证代码不会越写越散。
以前大家聊 AI Coding，常见话题是补全速度、生成质量、工具体验。这些都重要，但它们更像个人效率问题。真到团队里，麻烦不在“这段代码能不能写出来”，而在“写出来以后，整个系统会不会越来越难维护”。
AI 最大的特点不是聪明，而是听话。上下文里有什么，它就放大什么。代码库干净，它放大清晰的边界。代码库本来就乱，它也会把乱放大得更快。
AI 最容易放大的，不是 bug，是习惯
很多人担心 AI 写错代码，这个担心没问题。但在真实项目里，更常见的风险其实是它把旧习惯复制得又快又广。
如果仓库里已经有这些问题：
- 包结构按需求堆出来
- 领域对象到处漏
- 接口边界模糊
- 异常处理风格不统一
- 同一类逻辑在不同模块里各写一套
那 AI 很少会主动停下来告诉你：“这里该先收边界，再继续加代码。”
它更可能顺着现有模式继续补。今天补一处，明天补十处。等团队反应过来，技术债已经不是“还留着”，而是“开始扩散”了。
AI Coding 时代最重要的是边界。边界不稳，模型就只能学到一套摇晃的工程语言。
先让人对齐，再谈人机对齐
这篇实践里最认同的一点，是它没有一上来就迷信规则文件，而是先强调团队内部判断要统一。
这个顺序很关键。
很多团队现在喜欢直接写：
- Cursor Rule
- Claude Skill
- 各种代码规范
- 一堆“请遵守以下原则”的提示词
写这些当然有用，但前提是团队自己先知道“好的代码在这个系统里到底长什么样”。
比如：
- 什么逻辑应该留在领域层
- 什么逻辑应该下沉到基础设施层
- 什么接口算稳定
- 什么改法会把未来扩展锁死
这些问题如果团队内部都还没说清楚，那规则写得再漂亮，也只是把分歧格式化了。
判断很直接：
AI 可以放大共识，替代不了共识。
真正靠谱的顺序应该是：
- 人先把判断说清楚
- 团队把判断沉淀成规范
- 规范再转成 AI 能加载的约束
- 生成前约束模型，生成后继续校验
不然你看到的不是“人机对齐”，而是“每个人把自己的偏好喂给模型，然后期待全团队看起来像一个人写的”。
AI 适合扫全局，不适合替你定优先级
美团那篇文章里还有一个很好的分工方式：人先圈高风险区域，AI 再负责扫得更深、更广。
这是成熟用法。
复杂系统里的技术债，从来不是谁先看到谁就去改。真正难的是判断：
- 这个问题是不是会卡住接下来的需求
- 它是不是业务模型出了偏差的症状
- 现在改值不值
- 最小的改法是什么
这些判断，还是得靠人。
AI 擅长的是另外一件事：它不嫌累。你让它扫调用链、翻大量文件、找同类实现、比对模式，它比人有耐心得多。问题不在于它能不能看全，问题在于看完之后谁来决定先动哪里。
可以把这件事拆成两层：
- AI 负责降低“看全”的成本
- 人负责决定什么值得改
资深工程师的价值也会越来越往这边偏。以后真正稀缺的，未必是熟悉仓库坑位的人，而是能判断哪个坑现在该填，哪个坑该绕过去，哪个坑应该连带改出一条更稳路径的人。
重构要能被业务吞下去
他们没有把 31 万行重构做成一个孤立专项，而是把改造拆进业务迭代里，这一点很合理。
这件事说起来简单，做起来挺难。因为“边做需求边重构”有两种完全不同的结果。
坏的版本是：每个需求都顺手多改一点，最后范围失控，排期炸掉，团队从此一听“重构”就紧张。
好的版本是：你知道这次业务变化一定会碰到哪些老边界，顺手把那一段补齐，让以后同类改动少绕路。
差别就在拆解能力。
你得知道：
- 这次只动哪一层
- 哪些约束先补
- 哪些债可以这次顺手清
- 哪些债现在碰了反而更乱
如果没有这个拆解能力，AI 只会让“顺手改一点”变得更危险。因为它太容易扩写了。你本来只想补一个接口，它可能顺手把半个模块都改得像是合理的。
Pre-PR 这件事，以后大概率会变成标配
当 AI 把写代码的速度拉起来之后，瓶颈会自然往后移。最容易被顶爆的地方就是 Review。
这也是 Pre-PR 思路合理的原因。
正式发 PR 之前，先让 AI 按团队规则自查几轮，把低级问题和格式问题尽量前置掉。这样人工 Review 才不会一直耗在这些地方：
- 命名不统一
- 分层不对
- 空指针和边界遗漏
- 重复逻辑
- 明显违背团队约定的实现
这些问题不该全留给 Reviewer。
如果一个团队已经大量用 AI 写代码，但还没有把自查、Pre-PR、规则校验前移，那结果通常很别扭：代码来得更快了，Review 却更痛苦了，最后大家会对 AI 生成代码本身产生抵触。
人工 Review 更应该只盯真正重要的事：
- 方案是不是走对了
- 业务理解有没有偏
- 模型有没有把局部最优误当成全局最优
- 这次改动会不会让后面的路更窄
对 AI Coding 的判断
看完这篇实践，可以更确定一件事：
AI Coding 的分水岭，不是哪个模型更会写代码，而是哪支团队先把“约束系统”建起来。
真正决定结果的，不只是工具，而是这几件事有没有落地：
- 团队有没有共同的工程判断
- 这些判断有没有变成规则
- 规则有没有进到 AI 的工作流里
- 提交前有没有自动校验
- Reviewer 有没有从抓低级错误，转向判断方向
如果这些都没有，AI 只是在加速现状。现状好，它加速好结果。现状差，它加速坏结果。
AI Coding 不能只理解成“更快写代码”。它更像一面放大镜，也像一台复印机。它会把团队已经形成的东西，成倍放大。
工程治理反而变得更重要了。代码写得快，不代表系统会更稳。只有边界、规则和校验先站住，速度才真的值钱。