AI - Tony Bai

本文永久链接 – 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 不需要思考“怎么设计”，它只需要思考“怎么翻译”。

不要试图 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 真正为你所用。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/12/14/dont-let-ai-put-your-brain-cpu-in-wait

大家好，我是Tony Bai。

先问一个扎心的问题：当你给 ChatGPT、Cursor 或 Claude Code 发送了一个复杂的 Prompt 之后，接下来的 30 秒到 1 分钟里，你在干什么？

我观察过很多开发者，90% 的人是这样的：

双手离开键盘，甚至抱在胸前，眼睛死死盯着屏幕上那个闪烁的光标，看着文字一个字一个字地蹦出来。心里默默念叨：“快点，再快点……”

在计算机科学里，这叫什么？

这叫 I/O 阻塞（Blocking I/O）。

在这个场景里，AI 是那个慢速的 I/O 设备（就像早期的磁带机或机械硬盘），而你——拥有几十亿神经元、算力无法估量的人类大脑（CPU），却因为等待这个 I/O 响应，被迫挂起（WAIT），处于完全闲置的状态。

这不仅仅是时间的浪费，这是算力的极大浪费。

很多开发者抱怨：“AI 有时候太慢了，打断了我的思路。”

但事实的真相可能是：不是 AI 慢，而是你的“调度算法”还停留在单核时代。

职场新分层：单核工作者 vs. 多核工作者

随着 AI 能力的普及，代码生成的质量差距正在缩小。未来的竞争壁垒，将从“你会写什么 Prompt”转移到“你如何管理与 AI 的并发交互”。

这导致了两种工作模式的分化，我们可以通过下面这张 “大脑CPU” 调度时序图来直观对比：

模式 A：单核工作者（同步阻塞）
* 特征： 就像单核 CPU 跑单线程程序。发完指令后，必须盯着屏幕等结果，算力被强行挂起（Wait）。
* 痛点： 图中红色的区域就是被浪费的生命。只要 AI 稍微卡顿，你的工作流就被切断了。

模式 B：多核工作者（异步并发）
* 特征： 就像现代操作系统的分时调度（Time-sharing）。人脑作为 OS Scheduler，维护着多个任务的状态。
* 优势： 图中绿色的区域显示，当 AI 在后台“搬砖”时，你的大脑立刻切换（Switch）到下一个任务（编写 Spec B）。
* 收益： 在 AI 响应延迟短期内无法消除的前提下，模式 B 的产出效率是模式 A 的 2 倍甚至更多。

第一性原理：如何优化大脑的“调度算法”？

既然“多核模式”效率极高，为什么 99% 的人做不到呢？

核心难点在于“上下文切换（Context Switching）”的成本。

做过底层开发的都知道，CPU 在切换线程时，必须执行一个昂贵的操作：Save Context（保存现场）和 Restore Context（恢复现场）。

人脑也是一样，甚至更弱。

根据认知心理学的“米勒定律”，人类的工作记忆（Working Memory，相当于 CPU 的 L1 Cache）容量极小，只有 7±2 个单位。

当你从“编写 Go 后端”切换到“调试 Vue 前端”时，你的 L1 Cache 会瞬间被清空。等你切回来时，你需要重新阅读代码、重新回忆变量名——这个过程就是“冷启动”，极度消耗能量。

所以，要实现高效的“人脑并发调度”，我们不能靠死记硬背，必须利用第一性原理优化我们的交互协议。

上下文卸载 (Context Offloading)

计算机如何解决内存不足的问题？虚拟内存（Swap）。 把不用的数据换出到硬盘里。

我们要模仿这个机制。不要试图在脑子里维持与 AI 的对话状态。

凡是发给 AI 的任务，必须是一个“全量的、自包含的数据包”。在这个数据包里，包含了 AI 完成任务所需的所有背景、约束和目标。

一旦发送出去，你的大脑应当能彻底遗忘（Forget）这个任务，清空 L1 Cache 去处理下一个线程，直到收到“完成”的中断信号。

无状态交互 (Stateless Interaction)

目前的“Chat 模式”是典型的有状态（Stateful）交互。你必须记得上一句说了什么，下一句才能接得上。这是并发的天敌。

高效的调度算法要求我们采用无状态（Stateless）交互。

每一次与 AI 的交互，都应该是一次独立的 API 调用。我不关心你记不记得上下文，我会在这一次指令中把上下文重新传给你。

我们可以用一张系统架构图来理解这种“大脑调度优化”：

结论很明显：

要让大脑 CPU 不阻塞，关键不在于你思考得有多快，而在于你是否拥有一个“外部存储（External RAM）”机制。

你需要一种介质，能够帮你低成本地固化上下文，让你敢于放手（Fire），也方便你随时捡起（Resume）。

那么，在软件工程领域，这种“固化上下文的介质”叫什么呢？

落地实战：Spec 就是你的“外部存储”

答案就是 Spec（规范说明书）。

而这种全新的开发范式，我们称之为 SDD (Spec-Driven Development，规范驱动开发)。

为什么“聊天（Chat）”是并发的天敌？

目前主流的“Chat-based Coding”本质上是同步且有状态的。

你输入：“把这个函数改一下。”
AI 问：“改成啥样？”
你回：“像上次那个一样。”

这就完了。 你的大脑被迫挂载了海量的历史上下文，你必须在线，必须记得“上次”是指哪次。一旦去回个邮件，回来你就断片了。

SDD 如何实现“异步并发”？

在 SDD 工作流中（特别是配合像 Claude Code、Gemini Cli 这样的新一代 CLI 编码智能体工具），交互模式发生了质变：

Context Offloading（上下文固化）： 你不再在对话框里碎碎念，而是打开一个 Markdown 文件（Spec），把接口定义、业务逻辑、边界条件、甚至测试用例全部写下来。写完的那一刻，你的大脑内存就释放了。
Stateless Execution（无状态执行）： 你将这个 Spec 文件投喂给 AI。对于 AI 来说，这是一个全量的、自包含的原子任务。它不需要知道你昨天说了什么，它只需要根据这份文档执行。
Fire and Forget（即发即忘）： 指令发出后，你不需要盯着光标。AI 在后台读文档、写代码、跑测试。你可以立刻切换到下一个 Spec 的编写中。

让我们看下这张 SDD 并发工作流时序图：