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

大家好，我是Tony Bai。

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

很多开发者跟我抱怨：

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

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

很多人将其归咎于“模型还不够强”，期待下一代 GPT 或 Claude 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（编码）物理分离。

1. 阶段一：架构师模式（The Architect）

• 只与 AI 讨论思路。输入：“我要把这个 Django 模块迁移到 FastAPI，请给出详细的迁移计划和步骤。”

• 产出物不是代码，而是一个plan.md。

• 关键点：人类必须在这个阶段介入 Review。如果 Plan 是错的，代码写得再快也是垃圾。

• 阶段二：泥瓦匠模式（The Builder）

• • 确认 Plan 无误后，再让 AI 按照plan.md的步骤，一步步生成代码。

  • 此时 AI 不需要思考“怎么设计”，它只需要思考“怎么翻译”。

  不要试图 One-shot（一次性）解决复杂问题。把大任务拆解为小任务，用文档（Markdown）作为上下文传递的介质，这才是工程化的正解。

  法则三：契约式防御 —— 用 TDD 锁死 AI 的“幻觉”

  “我怎么知道 AI 写的代码有没有隐藏 Bug？”

  答案是：你永远不应该信任 AI 写的代码，除非它通过了测试。

  在传统开发中，TDD（测试驱动开发）可能显得繁琐。但在 AI 时代，TDD 是性价比最高的“电子围栏”。

  破局之道：Spec-Driven TDD。

  1. 先写测试（Contract）：不要让 AI 直接写业务代码。先让它根据需求，生成单元测试（Test Cases）。这是你和 AI 签订的“契约”。

  2. 再写实现（Implementation）：让 AI 写代码去跑通这些测试。

  3. 循环验证：如果测试失败，把报错信息扔回给 AI，让它自我修正（Self-Correction）。

  通过 TDD，我们将对 AI 输出质量的“人工主观判断”，转化为了“计算机客观验证”。你不需要肉眼盯着每一行代码，你只需要盯着绿色的PASS。

  小结：从 Vibe Coding 到 AI Engineering

  AI 编程的门槛正在急剧降低，但交付高质量软件的门槛并没有变。

  那种“凭感觉”随便聊两句就能搞定项目的Vibe Coding时代即将过去。未来属于那些懂得如何用文档约束上下文、用规划拆解复杂度、用测试兜底质量的 AI 工程师。

  不要沉迷于 AI 的生成速度，要掌控系统的工程质量。

  ---

  🎯 深度实战：构建你的“AI 原生工作流”

  理念已经清晰，但落地还需要工具和技巧的支撑：

  • 一份生产级的CLAUDE.md到底该包含哪些 section？

  • 如何在Claude Code中高效实践Plan Mode？

  • 如何搭建一套自动化的SDD + TDD流水线，让 AI 自己写测试、自己修 Bug？

  如果你不想再被“90% 陷阱”折磨，希望从“拼运气的聊天者”进化为“掌控全局的架构师”，欢迎关注我的极客时间专栏《AI 原生开发工作流实战》。

  这不仅仅是一门工具教程，更是一套面向 AI 时代的软件工程方法论。我将带你把这些工程法则转化为可落地的 SOP，真正实现 10x 效率跃迁。

  扫描下方二维码，让 AI 真正为你所用。

  ---

  如果本文对你有所帮助，请帮忙点赞、推荐和转发！

  点击下面标题，干货！

  - 你的大脑是 CPU，别让 AI 把它挂起 (WAIT)

  - 还在当“上下文搬运工”？我写了一门课，帮你重塑AI开发工作流

  - 霸榜 GitHub 一周！Google 开源 ADK for Go，彻底终结 AI“炼丹”时代？

  - Linus 的名言要改了：Talk is cheap, show me the Spec

  - 给了机关枪，你却非要耍大刀：2025 年末，程序员 All in AI 的生存启示录

  - 别盲目梭哈 Agentic AI！先看清“确定性”的崩塌与“概率性”重建

  - Go 跌出 TIOBE 前十？别被排名骗了，这才是它的真实地位