Claude Code: Coding Plan(编程计划)

最后更新:2026-08-31

Coding Plan 让 Claude Code 从"想到哪做到哪"变成"先想清楚再做"——复杂任务前先出方案,确认后再执行。

💡 提示:Coding Plan 本质是让 Claude Code 在动手前先输出计划,包含步骤、影响范围、风险评估,你确认后再执行。这避免了"改了一半发现方向不对"的浪费。

📋 前置知识:第二十四章 Agent SDK

1. 你将学到


2. Coding Plan 工作机制

(1) 流程对比

100%
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。

📖 小节


📝 作业

  1. 基础题(难度⭐):对一个 3 步修改任务使用 /plan,审查计划后执行,对比无计划直接执行的效果差异。
  2. 进阶题(难度⭐⭐):用 Coding Plan 完成一个 5 步以上的重构任务,每步创建检查点并验证。
  3. 挑战题(难度⭐⭐⭐):对一个 10+ 步的大型迁移任务,生成 Plan 后分段执行,记录每个 Phase 的 Token 消耗和耗时。
Web-Tutorial.com

Web-Tutorial 技术团队

由多位开发者共同维护的编程教程平台。每篇教程由对应领域的开发者编写和审核,确保内容准确可靠。如发现任何问题,欢迎向我们反馈。

100%

🙏 帮我们做得更好

我们是刚上线的编程教程站,几个人的小团队,精力有限。页面虽经检查,难免还有疏漏——链接失效、排版错乱、内容有误、语言生硬……

如果您发现了,麻烦告诉我们,我们会在收到反馈后第一时间进行修复,再次感谢您的光临 🙏