计划模式示例
以下是 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
- 小改动
- 简单查询
- 快速实验
最佳实践
- 审批前仔细审查 计划
- 发现问题就修改 计划
- 把复杂任务拆细
- 给出现实的时间估算
- 包含回滚策略
- 写明成功标准
- 为每个阶段安排测试

