大家好，我是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（编码）物理分离。
阶段一：架构师模式（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。
先写测试（Contract）：不要让 AI 直接写业务代码。先让它根据需求，生成单元测试（Test Cases）。这是你和 AI 签订的“契约”。
再写实现（Implementation）：让 AI 写代码去跑通这些测试。
循环验证：如果测试失败，把报错信息扔回给 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 前十？别被排名骗了，这才是它的真实地位
