AI 编程的“90% 陷阱”：为什么你生成代码 1 分钟，修 Bug 却要 1 小时？

十二月 17, 2025

本文永久链接 – https://tonybai.com/2025/12/17/ai-programming-90-percent-trap-generation-vs-bug-fix

大家好，我是Tony Bai。

在 AI 辅助编程普及的第三年，我观察到一种奇怪的现象，我称之为“AI 时代的开发疲劳”。

很多开发者跟我抱怨：

“一开始觉得 AI 简直是神，几秒钟就能生成一个模块。但用久了发现，它生成的代码总是‘乍一看很完美，一跑全是坑’。
简单的逻辑还能应付，一旦涉及到复杂的业务重构，它写的代码往往是 90% 可用，剩下 10% 充满了隐蔽的 Bug、过时的库引用和糟糕的结构。
结果是：AI 帮我省了 30 分钟敲代码的时间，我却花了 2 小时去 Review 和填坑。”

这就是典型的“90% 陷阱”。

很多人将其归咎于“模型还不够强”，期待下一代 GPT 或 Claude X Opus 能彻底解决问题。

但作为一名长期研究 AI 原生工作流的架构师，我要告诉你一个残酷的真相：

问题不在模型，而在你的工作流。

大多数人还在用“抽盲盒”的方式在通过聊天框（Chat）写代码——这叫 Vibe Coding（氛围编程），而不是 Engineering（工程）。

要跨越这最后 10% 的死亡谷，我们需要把 AI 开发从“聊天”升级为“工程”。以下是我总结的三个核心法则。

法则一：上下文工程 —— 给 AI 发一本“员工手册”

为什么 AI 总是记不住你的代码规范？为什么它总是喜欢用 any 类型，或者引入你明令禁止的第三方库？

因为你把 AI 当成了“搜索引擎”，而不是“新入职的员工”。

每次开启一个新的 Chat Session，对 AI 来说都是第一天入职。如果你不给他发一本“员工手册”，它当然会按照通用的（平庸的）标准来写代码。

破局之道：固化上下文（Context Pinning）。

在 AI 原生开发中，项目根目录下的 规则文件（如 .cursorrules 、CLAUDE.md或constitution.md等）是项目的灵魂。

这不是简单的 Prompt，这是你的架构宪法。

不要每次都重复说：“仅使用 Go标准库中的net/http包，别用第三方web开发框架”。
把它写进规则文件。并且，这是一个动态的过程：一旦 AI 在某次对话中犯了错，不要只在对话框里纠正它，要把纠正后的规则反写回规则文件中。

把规则文件看作是 Live Documentation（活文档）。它是你项目架构、代码风格和最佳实践的“唯一真理来源”。有了它，AI 就不再是那个健忘的实习生，而是懂你习惯的资深搭档。

法则二：模式分离 —— 先做“架构师”，再做“泥瓦匠”

许多人使用 AI 的方式是：直接把一坨复杂的代码扔进去，说“帮我重构它”。

这违背了软件工程的分治思想。LLM 的推理能力是有限的，当它同时兼顾“理解旧逻辑”、“设计新架构”和“编写具体代码”时，它的注意力（Attention）会发散，导致逻辑坍塌。

破局之道：Plan Mode（规划模式）。

高效的 AI 工作流必须将 Planning（规划） 和 Coding（编码） 物理分离。

阶段一：架构师模式（The Architect）
- 只与 AI 讨论思路。输入：“我要把这个 Django 模块迁移到 FastAPI，请给出详细的迁移计划和步骤。”
- 产出物不是代码，而是一个 plan.md。
- 关键点： 人类必须在这个阶段介入 Review。如果 Plan 是错的，代码写得再快也是垃圾。
阶段二：泥瓦匠模式（The Builder）
- 确认 Plan 无误后，再让 AI 按照 plan.md 的步骤，一步步生成代码。
- 此时 AI 不需要思考“怎么设计”，它只需要思考“怎么翻译”。