适合使用
- 涉及多文件的修改
- 架构级别的变更
- 实现新功能
- 不熟悉的代码库
- 高风险操作
计划驱动开发
对于非平凡的任务，直接编码往往不是最优选择。计划驱动开发通过 /plan 模式让 Claude 先以只读方式探索代码库，然后提出实现方案供你审批，最后再执行。
- 进入计划模式（
Shift+Tab按两次） - Claude 以只读方式探索代码库
- Claude 将计划写入
.claude/plans/ - 你审查并批准（或要求修改）
- Claude 按计划执行实现
/plan 工作流详解
Section titled “/plan 工作流详解”第一步：进入计划模式
Section titled “第一步：进入计划模式”通过 Shift+Tab 切换模式（按两次循环：普通 -> 自动接受 -> 计划）：
# 按 Shift+Tab 两次进入计划模式# UI 上会显示 Plan Mode 指示器也可以直接提出复杂问题，自动触发计划模式：
如何重构认证系统以支持 OAuth？第二步：Claude 探索
Section titled “第二步：Claude 探索”在计划模式下，Claude 会：
- 读取相关文件
- 搜索代码模式
- 理解现有架构
- 不做任何修改
第三步：Claude 编写计划
Section titled “第三步：Claude 编写计划”Claude 在 .claude/plans/[name].md 创建计划文件：
# 计划：为 OAuth 重构认证系统
## 概要在保留现有邮箱/密码认证的同时添加 OAuth 支持。
## 需要修改的文件- src/auth/providers/index.ts（添加 OAuth 提供者）- src/auth/middleware.ts（处理 OAuth 令牌）- src/config/auth.ts（OAuth 配置）
## 需要新建的文件- src/auth/providers/oauth.ts- src/auth/providers/google.ts
## 实现步骤1. 创建 OAuth 提供者接口2. 实现 Google OAuth 提供者3. 更新中间件以检测令牌类型4. 添加 OAuth 路由5. 更新配置模式
## 风险- 迁移期间可能中断现有会话- 不同提供者之间的令牌格式差异第四步：你来审查
Section titled “第四步：你来审查”审查要点：
- 完整性 — 所有需求是否覆盖
- 正确性 — 方案是否适合你的代码库
- 范围 — 是否存在过度设计
第五步：批准并执行
Section titled “第五步：批准并执行”看起来不错，按计划执行。或要求修改：
修改计划：除了 Google OAuth，也添加对 GitHub OAuth 的支持。何时使用计划模式
Section titled “何时使用计划模式”可以跳过
- 单行修复
- 拼写错误修正
- 简单问题查询
- 添加注释
计划文件结构
Section titled “计划文件结构”计划存储在 .claude/plans/ 目录，自动生成文件名。
典型的计划包含以下部分
Section titled “典型的计划包含以下部分”# 计划：[标题]
## 概要[1-2 句概述]
## 背景[为什么需要这个变更]
## 需要修改的文件[将要变更的现有文件列表]
## 需要新建的文件[新文件列表]
## 需要删除的文件[要移除的文件，如有]
## 实现步骤[有序的步骤列表]
## 测试策略[如何验证变更]
## 风险与缓解措施[可能出问题的地方和应对方案]
## 待解决问题[开始前需要确认的事项]与其他工作流的结合
Section titled “与其他工作流的结合”计划 + TDD
Section titled “计划 + TDD”# 进入计划模式（Shift+Tab 按两次），然后：
我需要实现一个速率限制器。先规划测试用例，再规划实现方案。Claude 会按照 TDD 的正确顺序同时规划测试和实现。
计划 + 规范驱动
Section titled “计划 + 规范驱动”# 进入计划模式（Shift+Tab 按两次），然后：
查看 CLAUDE.md 中的支付处理规范。创建一个满足所有验收标准的实现计划。计划 + 任务分解
Section titled “计划 + 任务分解”批准计划后，Claude 可以分解为任务：
已批准。根据此计划创建任务并开始实现。明确指定范围
Section titled “明确指定范围”# 太模糊改善 API
# 更好为 /users 端点添加基于游标的分页。保持与现有客户端的向后兼容性。要求修改计划
Section titled “要求修改计划”计划看起来不错，但：- 添加网络故障的错误处理- 暂时跳过缓存优化- 包含回滚方案用于架构决策
Section titled “用于架构决策”# 进入计划模式（Shift+Tab 按两次），然后：
我在考虑两种状态管理方案：A) Redux ToolkitB) Zustand
探索代码库，推荐哪个更合适。.claude/plans/ 中的计划天然就是决策文档：
- 记录选择特定方案的原因
- 预期变更的文件列表
- 实现顺序的依据
进阶：自定义 Markdown 计划
Section titled “进阶：自定义 Markdown 计划”内置计划 vs 自定义计划
Section titled “内置计划 vs 自定义计划”| 因素 | 内置计划模式 | 自定义 .md 计划 |
|---|---|---|
| 持久性 | 上下文压缩时丢失 | 压缩后仍然存在，可共享 |
| 审查方式 | 基于聊天，线性 | 结构化文件，可查看 diff |
| 迭代方式 | 在对话中来回 | 标注文件，重新运行 |
| 共享状态 | 仅限当前会话 | 人与 Agent 之间的”共享可变状态” |
| 适用场景 | 标准功能，30 分钟内的任务 | 复杂功能，架构决策 |
决策规则：已知范围用计划模式。预期可能有误解或需要明确签字确认方案时，用自定义 .md 计划。
三阶段工作流
Section titled “三阶段工作流”┌──────────────────────────────────────────────────────┐│ 阶段 1: 研究 ││ → 强调式提示词 → research.md（写入文件，而非口述） │├──────────────────────────────────────────────────────┤│ 阶段 2: 规划（标注循环） ││ → plan.md 草稿 → 人工标注 → Agent 更新 → 重复 ││ → 退出条件：计划已批准，无待解决问题 │├──────────────────────────────────────────────────────┤│ 阶段 3: 实现 ││ → 机械式执行，所有决策已在之前完成 │└──────────────────────────────────────────────────────┘阶段 1：深度研究
Section titled “阶段 1：深度研究”Claude 默认会浅尝辄止。使用强调性语言迫使它深入：
深入研究此代码库中的认证系统。深入了解会话管理的复杂细节。覆盖边缘情况、现有模式以及任何不明显的依赖关系。
将发现写入 research.md — 不要实现任何东西。阶段 2：标注循环
Section titled “阶段 2：标注循环”核心环节。在任何实现之前迭代 plan.md 直到准备就绪：
基于 research.md，写一个实现 [功能] 的计划。
包含：方案、受影响的文件路径、关键决策的代码片段、考虑的权衡、以及待解决问题。
写入 plan.md。不要实现任何东西。标注示例：
## 方案使用存储在 httpOnly cookie 中的 JWT 令牌。<!-- 人工标注：✓ 同意。但也考虑刷新令牌轮换 -->
## 待解决问题- [ ] 是否应该在中间件中处理令牌过期？<!-- 人工标注：是的，集中处理 — 不要留给每个路由 -->退出标准 — 计划就绪的条件：
- 没有待解决问题
- 权衡已记录并达成一致
- 文件路径具体明确（不是”某个认证文件”）
- 关键代码片段展示了方案，而不仅仅是描述
阶段 3：机械式实现
Section titled “阶段 3：机械式实现”计划批准后，实现变成了纯执行 — 不再有创造性决策：
实现 plan.md 中的所有内容。按顺序逐项完成。完成后用 [x] 标记已完成的任务。不要在任务之间停下来确认 — 一直做完。| 技巧 | 说明 | 时机 |
|---|---|---|
| 择优实施 | 实现 plan.md 的部分内容 | 计划太大，需分批交付 |
| 范围裁剪 | 在实现前从计划中移除条目 | 降低风险，聚焦核心 |
| 参考式引导 | 指向现有代码：“像 auth.ts 那样做” | 确保一致性 |
| 回退重来 | git revert + 用更窄的计划重启 | 计划出了问题，干净重来 |