Claude Code: Coding Plan(编程计划)
最后更新:2026-08-31
Coding Plan 让 Claude Code 从"想到哪做到哪"变成"先想清楚再做"——复杂任务前先出方案,确认后再执行。
💡 提示:Coding Plan 本质是让 Claude Code 在动手前先输出计划,包含步骤、影响范围、风险评估,你确认后再执行。这避免了"改了一半发现方向不对"的浪费。
📋 前置知识:第二十四章 Agent SDK
1. 你将学到
- Coding Plan 的工作机制
- 触发与使用方式
- 计划审查与修改
- 计划执行与验证
- 最佳实践
2. Coding Plan 工作机制
(1) 流程对比
graph LR
subgraph 无Plan
A1[指令] --> B1[直接执行]
B1 --> C1[可能跑偏]
end
subgraph 有Plan
A2[指令] --> B2[生成计划]
B2 --> C2[审查确认]
C2 --> D2[按计划执行]
D2 --> E2[验证结果]
end
| 模式 | 步骤 | 风险 | Token消耗 |
|---|---|---|---|
| 直接执行 | 指令→执行 | 方向错误浪费大 | 低(如果成功) |
| Coding Plan | 指令→计划→确认→执行 | 方向可控 | 略高(计划步骤) |
(2) 何时使用 Coding Plan
| 场景 | 是否需要 Plan | 原因 |
|---|---|---|
| 多文件重构 | ✅ 需要 | 影响范围大 |
| 架构变更 | ✅ 需要 | 方向不可逆 |
| 数据迁移 | ✅ 需要 | 数据风险高 |
| 修复简单 Bug | ❌ 不需要 | 影响范围小 |
| 添加单文件 | ❌ 不需要 | 风险低 |
▶ 示例 1: 触发 Coding Plan
TEXT
📖 仅展示
# 方式1:使用 /plan 命令
> /plan 将认证从 Session 迁移到 JWT
# 方式2:指令中包含"先出计划"
> 将认证从 Session 迁移到 JWT,先出计划再执行
# 方式3:自动触发(大任务时 Claude Code 自动出计划)
> 重构整个项目的错误处理
Claude Code:
这个任务影响范围较大,让我先制定计划:
3. 计划生成
(1) 计划结构
TEXT
📖 仅展示
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Coding Plan: Session → JWT 认证迁移
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## 目标
将认证方式从 Session 迁移到 JWT
## 影响范围
- 修改文件: 12 个
- 新增文件: 3 个
- 删除文件: 2 个
- 数据库变更: 无
## 执行步骤
### Step 1: 创建 JWT 工具模块
- 新建 src/auth/jwt.ts
- 实现 token 生成、验证、刷新
- 编写单元测试
### Step 2: 修改认证中间件
- 修改 src/middleware/auth.ts
- 从 Session 验证改为 JWT 验证
- 保持接口不变
### Step 3: 修改登录/注册路由
- 修改 src/routes/auth.ts
- 返回 JWT token 替代设置 Session
### Step 4: 修改受保护路由
- 修改 8 个路由文件
- 调整认证检查方式
### Step 5: 清理 Session 代码
- 删除 session 相关配置
- 删除 express-session 依赖
## 风险评估
- 🔴 高风险: 中间件迁移可能影响所有已登录用户
- 🟡 中风险: Token 刷新逻辑需要仔细设计
- 🟢 低风险: 工具模块独立,不影响现有代码
## 预估
- Token: ~80K
- 时间: ~15 min
- 费用: ~$1.60
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
确认执行?[y/n/modify]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▶ 示例 2: 审查和修改计划
TEXT
📖 仅展示
# 修改计划
> Step 5 不需要删除 Session,保留兼容期2周
Claude Code:
更新计划:
Step 5: 保留 Session 兼容
- 不删除 express-session
- 添加双认证支持(Session + JWT)
- 2周后清理 Session 代码
确认?[y/n/modify] y
开始执行...
4. 计划执行与验证
(1) 逐步执行
TEXT
📖 仅展示
# 确认后按步骤执行
[Step 1/5] 创建 JWT 工具模块
→ Creating src/auth/jwt.ts
→ Creating tests/jwt.test.ts
→ Running: npm test -- jwt.test.ts
✅ Step 1 完成
/checkpoint "jwt-module-complete"
[Step 2/5] 修改认证中间件
→ Modifying src/middleware/auth.ts
→ Running: npm test -- auth.test.ts
✅ Step 2 完成
/checkpoint "middleware-complete"
[Step 3/5] 修改登录/注册路由
→ Modifying src/routes/auth.ts
→ Running: npm test -- auth.test.ts
✅ Step 3 完成
(2) 遇到问题时的处理
TEXT
📖 仅展示
[Step 4/5] 修改受保护路由
→ Modifying src/routes/user.ts
→ Running: npm test
❌ 3 tests failed
分析原因:部分路由依赖 req.session,JWT 模式下不存在
修正方案:在中间件中将 JWT payload 映射到 req.user
→ Modifying src/middleware/auth.ts (添加映射)
→ Re-running: npm test
✅ Step 4 完成
▶ 示例 3: 完整 Plan + Execute 流程
TEXT
📖 仅展示
> /plan 将 Express 迁移到 Fastify
Claude Code 生成计划:
Step 1: 安装 Fastify 依赖
Step 2: 创建 Fastify 应用入口
Step 3: 转换中间件为 Fastify 插件
Step 4: 转换路由定义
Step 5: 转换错误处理
Step 6: 更新测试配置
Step 7: 清理 Express 依赖
影响: 修改 28 个文件,新增 5 个,删除 4 个
风险: 中(路由语法差异大)
> 确认执行
[Step 1-3 完成] /checkpoint "fastify-core"
[Step 4 完成] /checkpoint "routes-converted"
[Step 5-6 完成] /checkpoint "error-and-test"
[Step 7 完成] /checkpoint "cleanup"
> 运行全量测试
✅ All 134 tests passed
迁移完成!
5. 最佳实践
(1) 计划审查清单
| 检查项 | 说明 |
|---|---|
| 影响范围 | 修改/新增/删除了哪些文件? |
| 风险评估 | 高/中/低风险点是什么? |
| 回滚方案 | 每步能否回滚? |
| 依赖关系 | 步骤间是否有顺序依赖? |
| 测试策略 | 每步如何验证? |
| Token 预估 | 总消耗多少?是否在预算内? |
(2) 执行纪律
| 规则 | 说明 |
|---|---|
| 逐步确认 | 每步完成后检查再继续 |
| 检查点 | 关键步骤后创建检查点 |
| 测试先行 | 每步运行测试验证 |
| 及时调整 | 遇到问题回计划阶段修改 |
| 成本监控 | 每步检查 /cost |
(3) 常见陷阱
| 陷阱 | 说明 | 避免方法 |
|---|---|---|
| 计划太粗 | 步骤不具体 | 要求细化到文件级别 |
| 跳过审查 | 直接确认 | 仔细审查每步影响 |
| 不建检查点 | 出错无法回滚 | 关键步骤后 /checkpoint |
| 忽略测试 | 步骤完成不验证 | 每步运行测试 |
| 死磕计划 | 计划不合理也不改 | 发现问题及时调整 |
6. 综合示例:大型迁移的完整 Plan
TEXT
📖 仅展示
> /plan 将整个微服务项目从 JavaScript 迁移到 TypeScript
Claude Code 生成详细计划:
## Phase 1: 基础设施(1-2小时)
Step 1: 安装 TypeScript 和类型定义
Step 2: 创建 tsconfig.json(宽松模式先迁移)
Step 3: 配置构建脚本
## Phase 2: 共享模块(2-3小时)
Step 4: 迁移 shared/types/ (5 files)
Step 5: 迁移 shared/utils/ (8 files)
Step 6: 迁移 shared/constants/ (3 files)
## Phase 3: 服务模块(3-4小时,可并行)
Step 7: 迁移 user-service/ (12 files)
Step 8: 迁移 order-service/ (15 files)
Step 9: 迁移 payment-service/ (10 files)
## Phase 4: 严格模式(1-2小时)
Step 10: 启用 strict 模式
Step 11: 修复所有类型错误
Step 12: 全量测试验证
总影响: 修改 53 个文件,新增 8 个
预估 Token: ~200K (需分段)
预估费用: ~$4.00
> 分 Phase 执行,每个 Phase 完成后 /checkpoint
[Phase 1 完成] /checkpoint "ts-infra"
[Phase 2 完成] /checkpoint "shared-modules"
[Phase 3 Step7完成] /checkpoint "user-service"
[Phase 3 Step8完成] /checkpoint "order-service"
[Phase 3 Step9完成] /checkpoint "payment-service"
[Phase 4 完成] /checkpoint "strict-mode"
✅ 全量测试通过,迁移完成!
❓ 常见问题
Q Coding Plan 多消耗多少 Token?
A 计划步骤约增加 10-20% Token。但避免了方向错误的浪费,总体反而更省。
Q 计划可以保存吗?
A 可以。计划以 Markdown 格式输出,复制保存到文件即可。下次可直接参考。
Q 小任务也需要 Plan 吗?
A 不需要。简单 Bug 修复、单文件添加等小任务直接执行更高效。Plan 适合影响范围大的任务。
Q 计划生成后必须按计划执行吗?
A 不一定。你可以修改计划、跳过步骤、调整顺序。Plan 是指导不是约束。
Q 能生成多个计划对比吗?
A 可以。让 Claude Code "生成2-3种方案并对比",选择最优方案执行。
Q Plan 和 Skill 有什么区别?
A Plan 是针对当前任务的临时规划,Skill 是可复用的标准流程。一次性大任务用 Plan,重复工作流用 Skill。
📖 小节
- Coding Plan 让复杂任务先规划再执行,避免方向错误
- 触发方式:
/plan、指令中要求出计划、大任务自动触发 - 计划包含:步骤、影响范围、风险评估、Token 预估
- 执行纪律:逐步确认、检查点、测试验证、及时调整
- 多步骤任务推荐 Plan + Checkpoint 组合
📝 作业
- 基础题(难度⭐):对一个 3 步修改任务使用
/plan,审查计划后执行,对比无计划直接执行的效果差异。 - 进阶题(难度⭐⭐):用 Coding Plan 完成一个 5 步以上的重构任务,每步创建检查点并验证。
- 挑战题(难度⭐⭐⭐):对一个 10+ 步的大型迁移任务,生成 Plan 后分段执行,记录每个 Phase 的 Token 消耗和耗时。