🚀 第 11 篇：计划模式 (Plan Mode) —— 先思考再动手的编程哲学

🎯 本篇导读（核心大纲）

贪婪的代价：为什么“一句话写个淘宝”听起来很爽，最后却一定会得到一座无法维护的“代码屎山”？

认知升级 (SDD)：真正的商业级开发，绝不是随性而为的 Vibe Coding。规范驱动开发（SDD）才是超级个体的护城河。

杀手锏功能 (Plan Mode)：揭秘 Claude Code 等高阶工具的“计划模式”——剥夺 AI 的代码修改权，强迫它先当“架构师”再当“泥瓦匠”。

文档驱动实战：如何将远期、中期、短期的工作拆解并写入 Markdown 文档，实现像管理真人员工一样的“按图施工”？

零成本质检 (TDD)：用机器验证机器。让 AI 帮你写测试用例，构建真正坚不可摧的自动化流水线。

📍 一、 贪婪的代价：“一句话编程”带来的代码灾难

在上一篇中，我们感受了 Vibe Coding（直觉编程）的巨大魔力。只要你会说话、会截图，就能让 AI 变出一个酷炫的网页。

于是，很多初学者在尝到甜头后，欲望开始膨胀。他们打开 AI 编程工具，敲下一行极其宏大的指令： “帮我开发一个类似小红书的社交 APP，要有用户登录、图文发布、评论点赞，还要有推荐算法，直接把代码写好。”

紧接着，AI 开始疯狂输出。看着屏幕上瀑布般滚动的代码，你觉得这简直是奇迹。但当代码停止，你点击运行的那一刻，奇迹变成了灾难： 页面白屏、数据库连不上、终端里弹出一大堆红色的报错。你让 AI 去修复错误 A，结果它把原本正常的模块 B 给改坏了；你再去修 B，它又把 C 弄崩溃了。聊了几十轮之后，AI 彻底陷入了精神分裂，你只能绝望地把整个项目删掉重来。

为什么会这样？ 因为你用管理“玩具”的方式，去管理了一个“工程”。大模型的上下文记忆是有限的，当任务过于庞大、缺乏中间步骤的约束时，它就会不可避免地产生幻觉。它会忘记自己前面写过的变量，甚至重新创造出一些已经存在的功能，导致代码冗余和逻辑冲突。

在企业级或复杂的个人项目中，靠着直觉“走一步看一步”的写法，最终一定会堆砌出一座无法维护的**“屎山（Spaghetti Code）”**。

想要跨越这个深水区，你必须掌握一套全新的编程心法——先思考，再动手。

💡 二、 认知升级：规范驱动开发 (SDD)

当 AI 替代了敲击键盘的体力活，写代码就不再是核心难点，“理清思路并制定规范”变成了最昂贵的能力。

在硅谷的极客圈，真正的高手正在推崇一种叫做 SDD (Spec-Driven Development，规范驱动开发) 的模式。

这种模式的底层哲学是：绝不让 AI 在没有图纸的情况下直接施工。

在一个专业的开发流程中，你应该花 80% 的时间去跟 AI 讨论架构、拆解步骤、定义验收标准，只花最后的 20% 时间让它去生成代码。正如造一栋摩天大楼，图纸设计好了，砌砖只是水到渠成的事。

要实现这种“先立规矩后干活”的哲学，你就必须用好现代 AI 编程工具中最核心的机制——计划模式 (Plan Mode)。

🧠 三、 杀手锏：给 AI 装上“刹车”的 Plan Mode

在使用诸如 Claude Code 这样强大的终端数字员工时，为了防止它一上来就“瞎写”代码，系统提供了一个绝妙的设计——你可以让它进入计划模式（Plan Mode）。

1. 什么是计划模式？ 在这个模式下，AI 被强制剥夺了直接修改文件的权限。它就像是被暂时绑住了双手，只能用“大脑”来思考。

当你在计划模式下提出一个复杂需求（比如：帮我做一个图书管理系统，要有图书、作者、出版社这三张表的外键关联），AI 不会直接去写底层逻辑。相反，它会像一个资深的架构师一样，为你输出一份极其详尽的实施计划（Plan）。

2. 一份优秀的 Plan 包含什么？ 它会把这个庞大的任务拆解成非常清晰的步骤：

  • 第一步：创建项目目录结构与基础环境。
  • 第二步：设计数据库的表结构，并建立一对多、多对多的关联。
  • 第三步：编写后端的增删改查（CRUD）接口。
  • 第四步：编写前端页面并进行接口联调。
  • 第五步：编写测试用例并执行验证。

3. 你的角色：最严苛的审阅者 当计划列出来之后，不要急着点“同意”。AI 也会提示你：“我们准备开始进行代码的编写了。”这个时候你千万不要直接就让 AI 去写！

你必须逐字逐句地审阅这份计划：有没有遗漏的技术选型？有没有理解错你的需求？有没有重复造轮子？一旦发现不懂或不对的地方，立即在计划模式下打回，让它重新解释和修改，直到这份“施工图纸”完美无缺。

这种将复杂任务拆解，一步步往下走的方式，极大地降低了 AI 出错的概率。

🛠️ 四、 落地实操：把计划固化为“Markdown 宪法”

确认了计划后，很多人的下一步是让 AI 顺着记忆往下写。但在高阶的 AI 工程学里，还有一项极具威力的**“存档”动作**。

1. 将计划写入外部文档 当你们在对话框里敲定了远期、中期、短期的三个阶段工作内容后，你要给它下达一个关键指令：

“请将我们刚才确定的这三个阶段的实施计划，详细地写入项目根目录下的*readme.md（或plan.md）文件中。”*

2. 文档驱动的“分阶段实行” 为什么要多此一举写到文件里？因为对话框的记忆是脆弱的（上下文会被挤出），而写进文件里的文档，就是这个项目的“实体宪法”。

把它们写到文档里有一个巨大的好处：这个文档会天然地告诉你，第一阶段应该做什么，第二阶段应该做什么。

在接下来的开发中，你不要让 AI 一口气全做完。你可以框出第一阶段（Phase 1）的内容，对 AI 说：

“请仔细阅读*plan.md，现在我们只专注实现第一阶段（比如：基础的登录功能）。第二和第三阶段的复杂逻辑先不要碰。”*

这样做，既利用了 AI 在早期思考时的“全局观与全面性”，又在执行时为它戴上了“紧箍咒”，确保它不会因为过度发散而去实现不需要的代码，从而保证项目干净整洁。

3. 建立“汇报机制” 既然你把 AI 当成了牛马员工，那就要建立管理规范。 在你的全局提示词里，必须加上一条铁律：“以后你每做完一件事、实现完一个 feature，都必须回到plan.md这个文档里进行标记，把已完成的任务打上勾（打 X），并简要反馈遇到的问题。”

通过这种方式，即使你第二天重新打开电脑，新唤醒的 AI 只要读一眼这个文档，就能瞬间知道昨天干到了哪里，今天该从哪一步接力。

🚀 五、 终极护城河：零成本的测试驱动开发 (TDD)

在软件工程领域，有一个大牛们极度推崇、但普通程序员因为嫌麻烦而极少去做的开发模式——TDD (Test-Driven Development，测试驱动开发)。

简单来说就是：在写业务代码之前，先写测试代码。 比如你要写一个“计算购物车总价”的函数。在 TDD 模式下，你先写一段测试程序：“如果传入了两个 10 块钱的苹果，期望返回的结果必须是 20。如果不是 20 就报错。” 写完测试程序后，再去写真正的计算函数，直到测试程序亮起代表通过的“绿灯”。

过去，这种方法耗时耗力。但在今天，让 AI 来做 TDD 驱动开发，对你来说是绝对的零成本！

在你的计划里，一定要把**“编写单元测试”**纳入验收标准。 当 AI 实现完一个功能后，不要自己去点鼠标肉眼测试。你直接让 AI 产出测试脚本，让它通过命令去跑。

如果报错了怎么办？ 我们在上一篇讲过，只要是有明确反馈（报错日志）的场景，就是 AI 最擅长的领域。你把报错信息丢给 AI，它会自己去修复代码，再次运行测试，直到全绿通过。这种**“用机器验证机器”、“用 AI 监督 AI”**的工作流，才是你一个人单挑一个团队底气所在。

🏁 结语：慢，就是快

古人云：“谋定而后动。”这句话在 AI 时代，被赋予了极其具象的工程意义。

“一句话生成全站”的视频，只存在于博眼球的短视频演示里。在真实的业务战壕中，跑得最远的人，往往是那些愿意在前期“磨洋工”的人。

他们耐心地梳理业务逻辑，冷静地审视 AI 给出的 Plan，严苛地制定 Markdown 规范文档，然后才慢条斯理地按下执行的按钮。

当你掌控了“计划（Plan）”的权力，敲代码就成了最廉价的体力活。 在这场生产力大爆炸中，请牢牢守住你作为“人类项目经理”的终极壁垒——思考的深度，与制定规则的能力。