AI Coding 蜜月期之后——代码生成不是瓶颈了，那瓶颈在哪？

症状

我经历过一次印象非常深的「蜜月期幻灭」。

一个新功能需求——给数据系统的一组算子上补一种跨时间分区的计算——我把它交给了当时最新一代模型驱动的 Agent。结果相当惊人：不到两个工作日，从分析现有代码、理解需求、设计方案，到写功能、补测试、生成文档，它全走完了，初步测试也没发现明显问题。按传统流程，这种需求涉及底层执行逻辑和多个算子，人工开发往往要数周。我当时的第一反应不是怀疑，是兴奋：AI Coding 的效率确实被严重低估了。

然后测试范围扩大，问题开始成批出现。最折磨人的是：它不是「代码写错了」。需求理解基本正确，算法设计也没明显问题。真正的问题是——**它没有掌握几十万行代码背后那些分散的技术约束**：哪些分区方式有特殊限制、哪些数据类型还没支持、哪些能力只存在于 SQL 层而函数式接口没实现、哪些历史遗留限制会影响新功能。这些约束分散在代码、文档和老人的脑子里，从没被集中写下来，Agent 当然不知道。

最终测试阶段炸出几个大类、几十个预期外问题，功能「两天写完」，测试和返工花了两周。

如果你也在经历类似的事——用 AI 写代码明显变快了，但项目没有变快：合入 PR 变快了，Review 却开始排队；需求实现了，上线前测试暴露的问题比以前更多；你总觉得「得盯着它」，结果盯它比写它还累——这篇是写给同类人的。它不是某个工具的使用教程，是几个把 AI Coding 真正放进生产环境的人，用各自的「蜜月期幻灭」换来的共识：**代码生成已经不是瓶颈了，瓶颈转移了。**

原因

先回答那个反直觉的问题：AI 生成代码的速度已经快到夸张（有公司新产生代码的 75% 由 AI 生成，有团队几乎 99% 的输出 token 来自 Coding Agent），为什么你的交付速度没跟上？

**第一，交付链路上只有「编码」这一格提速了。** 一个需求从提出到上线，远不止写代码：需求分析、方案设计、开发、Review、测试、联调、上线。AI 只优化了其中「开发」一格——甚至只优化了「写代码」这个动作。Review 还是人看，测试还是人跑，需求还是人理。瓶颈没有消失，只是从「写不出来」转移到了「验证不过来」「约束说不清」。

**第二，隐性约束是 Agent 的盲区。** 一个成熟系统的代码库里，散落着大量「没写成文档的规矩」：哪块逻辑有历史包袱、哪个接口只能这么调、哪种写法会触发已知的性能陷阱。人靠经验、靠问、靠踩过坑记住它们；Agent 没有这些——它只有你喂给它的上下文。**需求它可以理解对，但「你们公司的历史」它无从知道。** 这不是模型不够聪明，是知识没有被喂到它嘴边。

**第三，上下文是预算，不是窗口。** 窗口再大，常驻内容越多，缓存命中率越低、每轮成本越高。很多人把整个仓库、两万行日志直接糊进去，窗口是没爆，但「该记住的没记住，该丢掉的没丢掉」——Agent 被噪声淹没，输出质量反而下降。

**第四，生成越快，校验越贵。** 以前代码写得慢，错误也产生得慢；现在错误是流水线式的。没有配套的验证机制（测试怎么断、审查看什么、降级怎么走），AI 的高速度只会把错误更快地送进生产。

所以 AI Coding 的提效公式不是「AI 写代码快 = 项目快」，而是：

> 项目速度 = 生成速度（AI 已解决）+ 约束清晰度（没解决）+ 验证效率（没解决）+ 人的判断（越来越贵）

下面每一条，都是把「生成快」真正变成「项目快」的做法——它们不是一家之言，是几套独立实践反复验证的共识。

解法

下面每条经验都按「现象 → 做法 → 为什么」展开。它们不是一家之言，而是多篇独立实践里反复出现的共识。

### 经验 0（L1 一句话结论）：瓶颈不在生成，在「验证 + 约束 + 环境」

**别再把 AI Coding 当打字机用——生成已免费，真正决定速度的是：①约束清不清楚（AI 知不知道你公司的规矩），②验证快不快（测试/审查/归因），③环境齐不齐（知识、权限、降级链）。** 没时间？只看这条。经验 1-5 讲具体怎么做。

### 经验 1：先给交付链路测速——AI 只优化了「编码」一格

现象：团队用上 AI Coding 后，我一度以为效率起飞，直到看了真实数据：单功能的编码时间确实从几天压到几小时，但需求澄清、Review、测试修复的时间一条没动。整体交付周期只缩短了一点点，瓶颈变成了「代码进来太快，人看不过来」。

做法：①把交付链路拆成格子：需求分析 → 方案设计 → 编码 → Review → 测试 → 联调 → 上线；②给每个格子记一个真实耗时（别估，翻两周的项目记录）；③标出 AI 只优化了哪一格，剩下最长的格子就是你的真瓶颈；④按瓶颈排投入：Review 慢就拆小 PR + 审查清单，测试慢就把测试做成 AI 也跑的护栏，需求糊就先写方案再动手。

为什么：人天生会高估「自己正在做的事」的改进。测速表是打破幻觉的最低成本手段——它把「AI 让我变快了」这种模糊感觉，变成「编码 3h→0.5h，Review 还是 4h」这种可行动的事实。瓶颈从来不是「你觉得」的那个，是数据说的那个。

### 经验 2：把隐性约束显性化——AI 不知道的规矩，写成它开工前必读

现象：那次跨时间分区功能翻车后我复盘：Agent 对需求的理解是对的，但它不知道「哪些能力只在 SQL 层、函数式接口还没实现」「哪种分区方式有历史限制」——这些约束在代码里、在老人脑子里，就是不在 Agent 能读到的地方。同样的事也发生在团队里：AI 生成的代码风格统一、结构漂亮，但一碰核心模块就踩进历史坑。

做法：①建一份「约束清单」文档：这个系统有哪些已知限制、哪些能力只存在于某层、哪些写法是雷区、哪些历史包袱不能动——每次 AI 开工前强制它先读；②把「踩过坑的判据」沉淀成规范：哪条判据是被驳回后改的、哪个正则踩过坑、哪次额度撞了，写下来，下一篇/下次任务它自动照办；③知识要让它「能检索」，而不是「背下来」：文档、Skill、示例库，放 Agent 能查的地方，比塞进 prompt 更持久；

④新人能踩的坑，Agent 一样会踩——约束清单同时就是新人手册。

为什么：Agent 不会「知道」它没被喂过的东西，但它有个优点：你只要写一次，它每次都照办，不会像人一样忘。**隐性约束显性化的过程，等于把团队的部落知识翻译成机器可读的规范**——这件事本身是复利：写一次，整个团队和所有 Agent 长期受益。

### 经验 3：上下文是预算，不是窗口——给 Agent 做减法

现象：给 Agent 配 prompt 的时候，我一开始是「能加就加」：鼓励它、解释背景、重复步骤。直到我逐句做了一次测试——「删掉这句话，行为会变吗？」——才发现删掉四分之一后行为毫无变化。常驻内容每多一句，都是此后每一轮对话都要支付的成本；窗口大不等于可以浪费。

做法：①逐句测试：任何一句 prompt，删掉它行为不变就删——典型可删的是「Be thorough」「This is crucial」这类鼓励话和废话前缀；②正面表述优先：写「编辑前先读文件」，不写「别忘了读文件」——否定式反而让被禁止的行为更「可及」；③技能一技能一使命：功能重叠的删、纯包装器的删、能内嵌成格式规则的删——技能列表本身每次都要注入；

④保护该保护的：配置、规则文件加入保护列表，别让自动压缩把「规矩本身」裁了；

⑤按百分比设压缩阈值，别按绝对值——换模型换窗口不用重新调参。

为什么：上下文经济学的核心是：**每个 Token 都是常驻成本，删掉一行废话，收益在整个会话周期里持续兑现。** 你省下的不是一次调用的钱，是每次会话都少付一遍的成本。配置工程的减法比加法难，也值钱得多。

### 经验 4：给 Agent 配「环境」，不是配「嘴」——权限、校验、降级链

现象：只读 Agent（探索、审查、诊断类）我一开始只给它一条禁令「不要编辑」，结果它该跑的命令还是跑，有一次差点执行了危险操作。后来我把权限模型改成「默认全拒 + 显式白名单」：编辑 deny、任务 deny、bash 只放行 `git status`/`git diff`/`git log`/`rg` 这类只读命令——风险面立刻收敛。

同样，代码审查我后来用双轴：一条轴对照规范（风格、命名、结构），一条轴对照规约（正确性、边界、安全），两条轴交叉，比单一审查准得多。

做法：①只读角色权限一律白名单：默认全拒，只放行确需的只读命令；敏感文件（.env 等）双向把关——读取 deny，压缩保护列表里也要有，防止内容被裁进摘要再泄露；②校验机制比规则本身值钱：双轴审查、校准基线、降级链（便宜模型搞不定就升级、执行失败就重新规划）——让系统在不确定时依然收敛；③明确动作边界：`look into X` 不等于 `fix X`，前者只查不改；

两个执行 Agent 绝不重叠写同一个文件；

④基础设施是杠杆不是替代品：数据库、计算引擎、中间件这些经过生产验证的确定性能力，AI 该做的是理解意图、选择和组合它们，而不是「重新实现」。

为什么：AI 写代码的能力越强，它拥有的权限就越该被当回事。**给 Agent 配环境（权限、知识、校验、降级），比给它写更多话术重要得多**——话术提高单次质量，环境决定长期上限。让 AI 承担「实现」，让工程体系承担「约束」，让基础设施承载「确定性」，你才腾得出手去做判断。

### 经验 5：人往「判断」上走——问题定义、验证、责任兜底

现象：面试 AI Coding 相关岗位时，我最怕听到候选人把 AI 聊得像新闻联播：DeepSeek、Agent、上下文窗口、多模态、MCP，一个词接一个词。一问「你自己怎么判断 AI 写得对不对」，马上开始虚。判断一个人是不是真的会用 AI，就看他的回答里是否自然出现「我先想，让 AI 跑，我检查/判断」的节奏。

做法：①把「写出来」的时间让给「定义清楚」：需求、边界、验收标准写清楚再开工，比让 AI 猜更省总账；②验证优先：不信任 AI 的「看起来对」，信单测、日志、审查、回归——AI 会放大能力，也会放大问题：本来会拆问题的人用 AI 更快，没有判断力的人用 AI 只会更快地把错误提交上去；

③归因而不是换模型：觉得慢，先拆是读得慢（精简上下文）、想得慢（关推理）、写得慢（限制输出）还是模型本身慢（任务分级）；

④把「责任不可剥夺」焊死在流程里：「AI 告诉我这么做的」不是借口，上线决策、风险兜底永远是人签字。

为什么：当代码本身在变便宜，人的价值不会消失，只会转移：**判断、架构、经验、责任越来越贵。** 面试官问「AI 会不会替代你」，不是在考套话，是在看你能不能说出「AI 会替代低价值执行动作，但不会替代问题定义、方案取舍、责任兜底和上线决策」。未来的竞争，不属于写代码最快的 AI，而属于工程环境更好、约束更清晰、判断更贵的人。