12. 计划模式（Plan Mode）

本章你将学到

• 为什么需要「先计划再执行」
• 推荐的四阶段工作流
• 计划模式的进入方式和快捷键
• 什么时候不需要计划模式

12.1 为什么要先计划

直接告诉 Claude「帮我实现 X」有一个风险：它可能一上来就开始写代码，但写了一半才发现方向错了，这时代码库已经一团糟。

计划模式的价值：

1. 让 Claude 先读懂相关代码，而不是凭猜测动手
2. 让你在它真正动手前检查、修改、确认方案
3. 避免方向错误导致的大量返工

「先探索，再规划，最后写码」是 Claude Code 官方推荐的核心工作流。

12.2 进入计划模式

三种方式进入计划模式（Claude 只能读取文件，不能修改任何东西）：

# 方式 1：启动时直接进入
claude --permission-mode plan

# 方式 2：会话中用 Shift+Tab 循环到 plan
# 状态栏会显示当前权限模式

# 方式 3：输入斜杠命令
/plan

12.3 推荐四阶段工作流

阶段 1：探索（Explore）

进入计划模式后，让 Claude 阅读相关代码，充分理解现状：

阅读 /src/auth 目录，理解我们是怎么处理 session 和用户登录的

重点关注：
- token 存储方式
- session 过期处理
- 登录失败锁定逻辑

探索阶段 Claude 跑偏了怎么办

症状：它在看不相关的文件、答非所问、或者直接跳过来给你"方案"了。

纠正：

• ❌ 别说"你错了" —— 它会道歉但接下来还是错
• ✅ 明确指路 —— "先别给方案，先打开 src/auth/session.ts 看清楚 token 怎么签发的"
• ✅ 要求列出已读 —— "把你刚才读过的文件列出来 + 每个文件的核心作用一句话"，能立刻发现它漏看了什么

阶段 2：规划（Plan）

有了充分了解后，要求 Claude 给出详细的实施方案：

我想加 Google OAuth 登录。基于你刚才的了解：
1. 需要改哪些文件？
2. 新增哪些文件？
3. Session 流程会有什么变化？
4. 有什么潜在风险？

给我一个完整的实施计划，暂时不要动代码。

在编辑器里修改计划

按 Ctrl+G 可以在你的默认编辑器（VS Code 等）里直接编辑当前的 plan。 你可以修改、删减、补充 Claude 的计划，改完保存后 Claude 会按你修改后的版本执行。

规划阶段方案不对怎么办

症状：方案漏了关键点、用了你不喜欢的技术栈、改的文件不对。

3 种纠正方式（从轻到重）：

1. 追加修正（小幅偏差）

   你的方案漏了 token 刷新逻辑。补一段：
   - 当 access_token 过期时，怎么用 refresh_token 续期？
   - 续期失败怎么把用户踢到登录页？

2. 明确否决某条（中等偏差）

   方案第 3 条不行——我们不用 JWT，已经在用 session cookie。
   按 session cookie 的方式重新写第 3 条。

3. 整盘重来（方向完全错）

   方案方向不对。我们的 session 不存数据库，是无状态的。
   你刚才看了 `src/auth/jwt.ts` 没？再去看一次，重新规划。

关键原则：不要直接进实施阶段救火。在 plan 阶段反复打磨方案，比在 implement 阶段一边写一边改成本低得多。

阶段 3：实施（Implement）

确认方案后，退出计划模式（再按 Shift+Tab），让 Claude 按计划执行：

方案看起来不错，按计划实现 OAuth 流程。
实现完后给 callback handler 写测试，跑测试，修复所有失败的测试。

实施阶段 Claude 偏离方案怎么办

症状：它开始改方案外的文件、跳了某些步骤、或者引入了你没批准的依赖。

纠正：

• 立刻打断 —— 不要等它写完再说。Esc 中断当前回合
• 回到方案对照 —— "停一下，对照你之前的计划——刚才改 src/utils/logger.ts 是计划里的哪一步？"
• 必要时回滚 —— git diff 看实际改动，不想要的直接 git checkout <file>
• 再切回 plan 模式重新规划 —— 偏离严重时，别硬掰，进 plan 模式重新理一遍

如果偏差是因为方案本身不够细：把这个偏差作为反馈写进 CLAUDE.md，下次它就知道这个项目的约束。

阶段 4：提交（Commit）

测试都通过了，写一个描述性的 commit 信息并提交，然后开一个 PR。
PR 描述里解释为什么要做这个改动。

12.4 什么时候不用计划模式

计划模式主要解决「不确定性」问题。如果任务很小且你很确定，就不必计划：

情况	建议
改一个错别字	直接改，不用计划
加一条日志语句	直接改
重命名一个变量	直接改
实现一个全新的模块	用计划模式
重构整个认证系统	必须用计划模式
不熟悉这段代码	用计划模式
涉及多个文件的改动	建议用计划模式

判断标准：用一句话能完整描述的 diff，就不用计划；需要画流程图才能说清楚的，就要先计划。

12.5 让 Claude 采访你（高级技巧）

面对大型功能，连你自己可能都没想清楚所有细节。可以让 Claude 先「采访」你：

我想做一个用户积分系统。在写代码之前，请用问题的方式采访我，
覆盖：技术实现方案、数据模型、边界情况、与现有系统的集成方式。

不要问显而易见的问题，专注于我可能没考虑到的难点。
采访完后，把完整的需求 spec 写到 SPEC.md。

然后开一个新会话来执行这个 spec，保持上下文干净。

---

下一步：技能（Skills）