计划模式示例
以下是 Claude Code 中有效使用计划模式的真实示例。
示例 1：构建 REST API
不使用计划模式
用户：给博客做一个 REST API
Claude：我来创建这个 API……
[立刻开始编码，可能漏掉需求]
使用计划模式
用户：/plan 给博客做一个 REST API
Claude：我来为这个博客 API 制定一份完整计划。
## 博客 REST API 实现计划
### 阶段 1：项目初始化（15 分钟）
1. 初始化带 Express 的 Node.js 项目
2. 配置 TypeScript
3. 安装依赖（express、pg、jwt、joi）
4. 配置环境变量
5. 搭建项目结构
### 阶段 2：数据库层（30 分钟）
6. 设计数据库 schema
- users 表（id、email、password_hash、created_at）
- posts 表（id、user_id、title、content、published、created_at、updated_at）
- comments 表（id、post_id、user_id、content、created_at）
7. 创建迁移文件
8. 搭建数据库连接池
9. 实现数据库模型
### 阶段 3：认证（45 分钟）
10. 实现用户注册接口
11. 实现带 JWT 的登录接口
12. 创建认证中间件
13. 使用 bcrypt 添加密码哈希
14. 实现 token 刷新逻辑
### 阶段 4：Posts API（40 分钟）
15. GET /api/posts - 获取所有已发布文章（支持分页）
16. GET /api/posts/:id - 获取单篇文章
17. POST /api/posts - 创建新文章（需要认证）
18. PUT /api/posts/:id - 更新文章（需要认证，检查所有权）
19. DELETE /api/posts/:id - 删除文章（需要认证，检查所有权）
20. GET /api/users/:id/posts - 获取某个用户的文章
### 阶段 5：Comments API（30 分钟）
21. GET /api/posts/:id/comments - 获取文章评论
22. POST /api/posts/:id/comments - 添加评论（需要认证）
23. DELETE /api/comments/:id - 删除评论（需要认证，检查所有权）
### 阶段 6：校验与错误处理（30 分钟）
24. 使用 Joi 添加请求校验
25. 实现全局错误处理器
26. 添加输入清洗
27. 实现速率限制
### 阶段 7：测试（60 分钟）
28. 为模型编写单元测试
29. 为认证接口编写集成测试
30. 为文章接口编写集成测试
31. 为评论接口编写集成测试
32. 达到 80%+ 的代码覆盖率
### 阶段 8：文档与部署（30 分钟）
33. 使用 Swagger 生成 API 文档
34. 创建包含安装说明的 README
35. 添加 Docker 配置
36. 搭建 CI/CD 流水线
**预估时间**：4.5 小时
**需要创建的文件**：约 25 个
**关键技术**：Express、PostgreSQL、JWT、TypeScript
**API 端点概览**：
- 认证：2 个端点
- 文章：6 个端点
- 评论：3 个端点
- 总计：11 个端点
准备继续吗？（yes/no/modify）
用户：yes
Claude：开始阶段 1：项目初始化……
[按阶段系统性实现]
示例 2：数据库迁移
使用计划模式
用户：/plan 将数据库从 MongoDB 迁移到 PostgreSQL
Claude：这是一次复杂迁移。我来制定详细计划。
## MongoDB 到 PostgreSQL 的迁移计划
### 阶段 1：分析与准备（第 1 天）
1. 分析当前 MongoDB schema
2. 识别数据关系和约束
3. 记录当前数据量和增长速率
4. 设计对应的 PostgreSQL schema
5. 规划数据类型映射
6. 识别潜在迁移挑战
### 阶段 2：PostgreSQL 准备（第 1 天）
7. 搭建 PostgreSQL 数据库
8. 创建包含表、索引和约束的 schema
9. 配置连接池
10. 制定备份策略
### 阶段 3：双写实现（第 2-3 天）
11. 创建数据库抽象层
12. 实现同时向两个数据库写入
13. 添加数据一致性检查
14. 在预发布环境部署双写
15. 监控问题
### 阶段 4：数据迁移（第 4 天）
16. 为 MongoDB 创建数据导出脚本
17. 为 PostgreSQL 创建数据导入脚本
18. 实现数据转换逻辑
19. 在生产数据副本上执行初次迁移
20. 验证迁移后数据完整性
### 阶段 5：渐进切换（第 5-7 天）
21. 在生产环境开启双写
22. 分批迁移历史数据
23. 持续验证数据一致性
24. 监控两个数据库
25. 修复任何数据同步问题
### 阶段 6：PostgreSQL 作为主库（第 8 天）
26. 将读操作切换到 PostgreSQL
27. 监控查询性能
28. 优化慢查询
29. 继续保留双写作为安全措施
### 阶段 7：MongoDB 退役（第 9-10 天）
30. 停止向 MongoDB 写入
31. 保留 MongoDB 作为两周备份
32. 从代码中移除 MongoDB 依赖
33. 归档 MongoDB 数据
34. 下线 MongoDB 实例
**预估时间**：10 天
**风险等级**：高
**回滚策略**：保持 MongoDB 运行并开启双写
**成功标准**：
- 零数据丢失
- 性能回退小于 5%
- 所有测试通过
**关键风险**：
1. 迁移过程中的数据不一致
2. 查询性能下降
3. 应用停机
4. 数据丢失
**缓解措施**：
- 采用双写模式保障安全
- 渐进式切换
- 持续监控
- 快速回滚能力
是否按此计划继续？（yes/no/modify）
用户：modify - 我们给每个阶段都加上回滚方案
Claude：我已经为每个阶段补充了回滚流程……
示例 3：前端重构
用户：/plan 把我们的 React 应用从 class 组件重构为 hooks
Claude：我来制定一个系统化的重构计划。
## React Class 到 Hooks 迁移计划
### 阶段 1：准备与分析（2 小时）
1. 审查所有 class 组件（查找所有 .jsx/.tsx 文件）
2. 按复杂度分类：
- 简单型（仅 state）：约 15 个组件
- 中等型（生命周期方法）：约 23 个组件
- 复杂型（多个生命周期、refs）：约 8 个组件
3. 识别需要更新的第三方库
4. 创建组件依赖图
5. 规划迁移顺序（先叶子节点）
### 阶段 2：环境与工具（1 小时）
6. 将 React 升级到 v18+
7. 为 hooks 配置 ESLint 规则
8. 创建转换模板
9. 配置自动化测试
10. 在开始前创建一个检查点
### 阶段 3：迁移简单组件（4 小时）
11. 转换简单的有状态组件（15 个）
12. 用 `useState` 替换 `this.state`
13. 用状态 setter 替换 `this.setState`
14. 每个组件转换后都进行测试
15. 更新测试
### 阶段 4：迁移中等复杂组件（8 小时）
16. 转换带生命周期方法的组件（23 个）
17. 用 `useEffect` 替换 `componentDidMount`
18. 用 `useEffect` 替换 `componentDidUpdate`
19. 用 `useEffect` 清理函数替换 `componentWillUnmount`
20. 做充分测试
### 阶段 5：迁移复杂组件（12 小时）
21. 转换复杂组件（8 个）
22. 用 `useRef` 替换 refs
23. 为共享逻辑提取自定义 hooks
24. 处理边缘情况（多个 `useEffect`）
25. 做深入测试
### 阶段 6：提取共享逻辑（6 小时）
26. 识别组件之间重复的逻辑
27. 创建自定义 hooks：
- `useAuth`
- `useFetch`
- `useLocalStorage`
- `useDebounce`
28. 将组件重构为使用自定义 hooks
29. 独立测试自定义 hooks
### 阶段 7：性能优化（4 小时）
30. 在需要的地方添加 `React.memo`
31. 使用 `useCallback` 优化
32. 使用 `useMemo` 优化
33. 分析并修复性能回退
### 阶段 8：收尾与文档（2 小时）
34. 移除未使用的 class 组件工具
35. 更新文档
36. 更新编码规范
37. 为团队编写迁移指南
**预估时间**：5 天（39 小时）
**需要修改的文件**：46 个组件
**风险等级**：中
**迁移顺序**：
1. 叶子组件（无依赖）
2. 中层组件
3. 顶层容器组件
4. `App.jsx`（最后）
**测试策略**：
- 每个组件的单元测试
- 用户流程的集成测试
- 视觉回归测试
- 性能基准测试
**成功指标**：
- 所有测试通过
- 没有视觉回归
- 性能保持或提升
- 打包体积没有明显增加
继续吗？（yes/no/modify）
示例 4：安全实现
用户：/plan 为我们的 Web 应用实现完整安全方案
Claude：我来制定一份全面的安全实施计划。
## Web 应用安全实施计划
### 阶段 1：安全审计（第 1 天）
1. 运行自动化安全扫描器（npm audit、Snyk）
2. 检查依赖中的漏洞
3. 核对 OWASP Top 10 合规性
4. 审查认证流程
5. 审查数据处理方式
6. 记录当前的安全缺口
### 阶段 2：认证加固（第 2-3 天）
7. 实现强密码要求
8. 添加密码强度检测器
9. 对登录接口实施限流
10. 在多次失败后锁定账户
11. 实现 2FA（TOTP）
12. 改进会话管理
13. 实现安全的密码重置流程
### 阶段 3：授权与访问控制（第 3-4 天）
14. 实现 RBAC（基于角色的访问控制）
15. 为所有端点添加权限检查
16. 实现最小权限原则
17. 为敏感操作添加审计日志
18. 实现资源级权限
### 阶段 4：数据保护（第 4-5 天）
19. 对敏感字段实施静态加密
20. 确保所有通信都使用 TLS/SSL
21. 实现安全的会话存储
22. 在日志中对 PII 数据做脱敏
23. 实现数据保留策略
24. 添加安全的文件上传处理
### 阶段 5：输入验证与清洗（第 5-6 天）
25. 为所有端点实现输入校验
26. 添加 XSS 防护（Content Security Policy）
27. 实现 SQL 注入防护（参数化查询）
28. 添加 CSRF 防护
29. 实现请求大小限制
30. 添加文件上传类型校验
### 阶段 6：安全头与配置（第 6 天）
31. 添加安全响应头：
- Strict-Transport-Security
- X-Content-Type-Options
- X-Frame-Options
- X-XSS-Protection
- Content-Security-Policy
32. 正确配置 CORS
33. 禁用不必要的 HTTP 方法
34. 移除服务器版本头
### 阶段 7：监控与日志（第 7 天）
35. 实现安全事件日志
36. 添加异常检测
37. 搭建入侵检测
38. 实现实时告警
39. 创建安全仪表盘
### 阶段 8：测试与文档（第 8-9 天）
40. 执行渗透测试
41. 运行安全扫描器
42. 测试所有安全功能
43. 编写安全文档
44. 培训团队的安全实践
45. 编写事件响应计划
### 阶段 9：合规与政策（第 10 天）
46. 检查 GDPR 合规性
47. 创建隐私政策
48. 实现数据主体权利支持
49. 添加 cookie 同意机制
50. 编写安全政策文档
**预估时间**：10 天
**风险等级**：严重
**优先级**：高
**安全改进摘要**：
- 认证：7 项增强
- 授权：5 项增强
- 数据保护：6 项增强
- 输入校验：6 项增强
- 基础设施：9 项增强
- 监控：5 项增强
**合规性**：OWASP Top 10、GDPR
**成功标准**：
- 零严重漏洞
- 所有 OWASP Top 10 风险都得到缓解
- 安全评分高于 90/100
- 所有渗透测试问题都已解决
继续吗？（yes/no/modify）
示例 5：性能优化
用户：/plan 优化我们这个很慢的电商网站
Claude：我来制定一份完整的性能优化计划。
## 电商网站性能优化计划
### 阶段 1：性能审计（4 小时）
1. 运行 Lighthouse 审计
2. 分析 Chrome DevTools 性能剖析结果
3. 测量 Core Web Vitals：
- LCP（Largest Contentful Paint）
- FID（First Input Delay）
- CLS（Cumulative Layout Shift）
4. 找出性能瓶颈
5. 创建基线性能指标
**当前指标**：
- LCP：4.2s（目标：<2.5s）
- FID：280ms（目标：<100ms）
- CLS：0.25（目标：<0.1）
- 页面加载：8.3s（目标：<3s）
### 阶段 2：图片优化（6 小时）
6. 将图片转换为 WebP 格式
7. 实现响应式图片
8. 为图片添加懒加载
9. 优化图片大小（压缩）
10. 为图片接入 CDN
11. 添加图片占位符
**预期影响**：加载时间减少 40%
### 阶段 3：代码拆分与懒加载（8 小时）
12. 实现基于路由的代码拆分
13. 懒加载非关键组件
14. 拆分第三方依赖包
15. 优化 chunk 大小
16. 实现动态导入
17. 为关键资源添加预加载
**预期影响**：初始 bundle 体积减少 30%
### 阶段 4：缓存策略（6 小时）
18. 实现浏览器缓存（Cache-Control）
19. 为离线支持添加 service worker
20. 实现 API 响应缓存
21. 为数据库查询添加 Redis 缓存
22. 实现 stale-while-revalidate
23. 配置 CDN 缓存
**预期影响**：API 响应时间减少 50%
### 阶段 5：数据库优化（8 小时）
24. 添加数据库索引
25. 优化慢查询（>100ms）
26. 实现查询结果缓存
27. 添加连接池
28. 在合适地方做反规范化
29. 实现数据库只读副本
**预期影响**：数据库查询时间减少 60%
### 阶段 6：前端优化（10 小时）
30. 最小化并压缩 JavaScript
31. 最小化并压缩 CSS
32. 移除未使用的 CSS（PurgeCSS）
33. 实现关键 CSS
34. 延迟加载非关键 JavaScript
35. 减少 DOM 规模
36. 优化 React 渲染（`memo`、`useMemo`）
37. 为长列表实现虚拟滚动
**预期影响**：JavaScript 执行时间减少 35%
### 阶段 7：网络优化（4 小时）
38. 启用 HTTP/2
39. 实现资源提示（preconnect、prefetch）
40. 减少 HTTP 请求数量
41. 启用 Brotli 压缩
42. 优化第三方脚本
**预期影响**：网络耗时减少 25%
### 阶段 8：监控与测试（4 小时）
43. 搭建性能监控（Datadog/New Relic）
44. 添加真实用户监控（RUM）
45. 制定性能预算
46. 搭建自动化 Lighthouse CI
47. 在真实设备上测试
**预估时间**：50 小时（2 周）
**目标指标**（90 分位）：
- LCP：<2.0s（从 4.2s 降低）✅
- FID：<50ms（从 280ms 降低）✅
- CLS：<0.05（从 0.25 降低）✅
- 页面加载：<2.5s（从 8.3s 降低）✅
**预期收入影响**：
- 每快 100ms，转化率提升 1%
- 目标：缩短 5.8s，约带来 58% 的转化率提升
- 预估额外收入：显著
**优先级顺序**：
1. 图片优化（快速收益）
2. 代码拆分（高影响）
3. 缓存（高影响）
4. 数据库优化（关键）
5. 前端优化（打磨）
是否按此计划继续？（yes/no/modify）
关键要点
计划模式的优势
- 清晰：开始前就有明确路线图
- 可估算：能给出时间和工作量预估
- 风险评估：能尽早发现潜在问题
- 优先级排序：任务按合理顺序推进
- 可审批：执行前先审阅并确认
- 可调整：根据反馈及时修改计划
什么时候使用计划模式
✅ 建议始终使用于： - 多日项目 - 团队协作 - 关键系统变更 - 学习新概念 - 复杂重构
❌ 不建议使用于： - 修 bug - 小改动 - 简单查询 - 快速实验
最佳实践
- 审批前仔细审查 计划
- 发现问题就修改 计划
- 把复杂任务拆细
- 给出现实的时间估算
- 包含回滚策略
- 写明成功标准
- 为每个阶段安排测试