Claude Code Planning Mode 实战指南从 REST API 到安全加固的五大规划场景示例claude-howto【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howtoPlanning Mode 是 Claude Code 中先规划、后实施的两阶段工作流Claude 先针对复杂任务产出结构化实现计划经你审阅、修改与批准后才开始写代码。本文基于 claude-howto 仓库中 vi/09-advanced-features/planning-mode-examples.md 的五个真实场景REST API 构建、数据库迁移、前端重构、安全加固、性能优化完整展示规划模式产出的计划形态并结合仓库中 09-advanced-features/README.md 的配置说明与 09-advanced-features/config-examples.json 的场景化配置讲解如何激活、配置并最大化利用 Planning Mode。读完你将能直接上手/plan学会拆解任务、评估风险、设定验收标准让 Claude 按你的意志分阶段执行。一、Planning Mode 的两阶段机制Planning mode 允许 Claude 在动手实现之前先完整思考复杂任务产出一份可审阅、可批准的计划。根据 09-advanced-features/README.md 的定义它是一种两阶段方法Planning Phase规划阶段Claude 分析任务创建详细的实现计划包括分阶段步骤、时间估算、涉及文件与技术选型。Implementation Phase实施阶段计划获得批准后Claude 按计划逐步执行。/plan同时也是一个内置斜杠命令用于Enter plan mode进入规划模式在 01-slash-commands/README.md 的内置命令参考表中有所记载。激活 Planning Mode 的四种方式方式命令/操作说明斜杠命令/plan 任务描述在 REPL 会话内直接进入规划模式最常用CLI 参数claude --permission-mode plan启动时即以 plan 权限模式运行配置文件{permissions: {defaultMode: plan}}设为默认权限模式每次启动都先规划快捷键Shift Tab/Alt MWindows/Linux在多个权限模式间循环切换其中包含 plan在 plan 权限模式下Claude 只能读取文件纯研究模式不做任何编辑这在 09-advanced-features/README.md 的权限模式表格中明确列出。这保证了规划阶段不会产生任何未经批准的副作用。二、为什么需要 Planning Mode有规划与无规划的对比原文档第一个示例开头就给出了一个发人深省的对照。对于同一个任务Build a REST API for a blog为博客构建 REST APIUser: Build a REST API for a blog Claude: Ill create the API... [Starts coding immediately, may miss requirements]没有规划模式Claude 立即开始编码可能会遗漏需求——例如没有提前设计数据表结构、没有规划认证流程、没有考虑分页与所有权校验导致返工。使用规划模式Claude 先产出一份从项目初始化到测试、文档、部署的完整计划等你确认后再开工。这正是 Planning Mode 的核心价值把边想边写变成先想清楚再写。三、示例一构建 REST API博客系统当用户输入/plan Build a REST API for a blog时Claude 产出的计划将任务分解为 8 个阶段、36 个步骤覆盖从零搭建到上线交付的全过程Phase 1: Project Setup项目初始化15 分钟初始化 Node.js 项目并引入 Express配置 TypeScript安装依赖express、pgPostgreSQL 驱动、jwt、joi校验配置环境变量搭建项目目录结构Phase 2: Database Layer数据层30 分钟设计数据库 schemausers表id, email, password_hash, created_atposts表id, user_id, title, content, published, created_at, updated_atcomments表id, post_id, user_id, content, created_at创建迁移文件配置数据库连接池实现数据模型Phase 3: Authentication认证45 分钟实现用户注册端点实现基于 JWT 的登录端点创建认证中间件使用 bcrypt 实现密码哈希实现 token 刷新逻辑Phase 4: Posts API40 分钟GET /api/posts—— 列出所有已发布文章带分页GET /api/posts/:id—— 获取单篇文章POST /api/posts—— 创建文章需认证PUT /api/posts/:id—— 更新文章需认证 所有权校验DELETE /api/posts/:id—— 删除文章需认证 所有权校验GET /api/users/:id/posts—— 获取某用户的文章Phase 5: Comments API30 分钟GET /api/posts/:id/comments—— 获取文章评论POST /api/posts/:id/comments—— 添加评论需认证DELETE /api/comments/:id—— 删除评论需认证 所有权校验Phase 6: Validation Error Handling校验与错误处理30 分钟使用 Joi 添加请求校验实现全局错误处理器添加输入净化实现限流rate limitingPhase 7: Testing测试60 分钟为模型编写单元测试为认证端点编写集成测试为文章端点编写集成测试为评论端点编写集成测试达成 80% 代码覆盖率Phase 8: Documentation Deployment文档与部署30 分钟使用 Swagger 生成 API 文档创建带安装说明的 README添加 Docker 配置搭建 CI/CD 流水线计划摘要信息预计耗时4.5 小时待创建文件约 25 个核心技术栈Express、PostgreSQL、JWT、TypeScriptAPI 端点汇总认证 2 个、文章 6 个、评论 3 个共11 个端点计划末尾Claude 会询问Ready to proceed? (yes/no/modify)。用户回答yes后Claude 从 Phase 1 开始逐阶段系统化实施。值得注意的细节计划中每个端点都明确标注了是否需要认证、是否做所有权校验数据库表预先设计好字段。这种先定契约、再写代码的方式能显著减少实现阶段的模糊地带。四、示例二MongoDB 到 PostgreSQL 数据库迁移数据库迁移是高风险的长期任务原文档用/plan Migrate from MongoDB to PostgreSQL展示了如何用 7 个阶段、34 个步骤的系统计划驾驭这类复杂迁移Phase 1: Analysis Preparation分析与准备Day 1分析当前 MongoDB schema识别数据关系与约束记录当前数据量与增长率设计等价的 PostgreSQL schema规划数据类型映射识别潜在迁移挑战Phase 2: PostgreSQL SetupDay 1搭建 PostgreSQL 数据库创建含表、索引、约束的 schema配置连接池配置备份策略Phase 3: Dual-Write Implementation双写实现Day 2-3创建数据库抽象层实现向两个数据库的双写添加数据一致性检查在 staging 部署双写监控问题Phase 4: Data Migration数据迁移Day 4为 MongoDB 创建数据导出脚本为 PostgreSQL 创建数据导入脚本实现数据转换逻辑在生产数据副本上试运行迁移校验迁移后的数据完整性Phase 5: Gradual Cutover渐进切换Day 5-7在生产环境启用双写分批迁移历史数据持续校验数据一致性同时监控两个数据库修复任何数据同步问题Phase 6: PostgreSQL PrimaryPostgreSQL 转正Day 8将读操作切换到 PostgreSQL监控查询性能优化慢查询继续双写以保证安全Phase 7: MongoDB RetirementMongoDB 退役Day 9-10停止向 MongoDB 写入保留 MongoDB 作为备份两周从代码中移除 MongoDB 依赖归档 MongoDB 数据下线 MongoDB 实例计划中显式声明的关键决策信息预计耗时10 天风险等级高回滚策略保持双写MongoDB 持续运行成功标准零数据丢失、性能回退 5%、所有测试通过主要风险迁移期间数据不一致、查询性能退化、应用停机、数据丢失缓解措施双写模式保障安全、渐进切换、持续监控、快速回滚能力当用户回复Modify - lets add a rollback plan for each phase修改计划为每个阶段添加回滚方案时Claude 会输出为每个阶段补充了回滚流程的更新版计划。这个交互展示了 Planning Mode 的可修改性——计划不是一次定稿的文档而是可以反复迭代的活文件。五、示例三React 类组件到 Hooks 重构前端大范围重构同样适合规划模式。原文档用/plan Refactor our React app from class components to hooks展示了一个 8 阶段、37 步骤、总耗时 39 小时的重构计划Phase 1: Preparation Analysis准备与分析2 小时审计所有类组件找出全部 .jsx/.tsx 文件按复杂度分类简单仅有 state约 15 个组件中等有生命周期方法约 23 个组件复杂多个生命周期、refs约 8 个组件识别需要更新的第三方库创建组件依赖关系图规划迁移顺序叶子节点优先Phase 2: Setup Tooling工具配置1 小时升级 React 到 v18配置 hooks 相关的 ESLint 规则创建转换模板配置自动化测试开始前创建 checkpointPhase 3: Migrate Simple Components迁移简单组件4 小时转换简单有状态组件15 个用useState替换this.state用 state setter 替换this.setState每个组件转换后即测试更新测试Phase 4: Migrate Medium Components迁移中等组件8 小时转换含生命周期方法的组件23 个用useEffect替换componentDidMount用useEffect替换componentDidUpdate用useEffectcleanup 替换componentWillUnmount全面测试Phase 5: Migrate Complex Components迁移复杂组件12 小时转换复杂组件8 个用useRef替换 refs为共享逻辑提取自定义 hooks处理边界情况多个 useEffect扩展测试Phase 6: Shared Logic Extraction共享逻辑提取6 小时识别跨组件的重复逻辑创建自定义 hooksuseAuth、useFetch、useLocalStorage、useDebounce重构组件以使用自定义 hooks独立测试自定义 hooksPhase 7: Performance Optimization性能优化4 小时在必要处添加React.memo使用useCallback优化使用useMemo优化分析并修复性能回退Phase 8: Cleanup Documentation清理与文档2 小时移除无用的类组件工具代码更新文档更新编码规范为团队创建迁移指南计划中的策略性内容预计耗时5 天39 小时待修改文件46 个组件风险等级中等迁移顺序叶子组件无依赖→ 中层组件 → 顶层容器组件 →App.jsx最后测试策略每个组件的单元测试、用户流程的集成测试、视觉回归测试、性能基准成功指标所有测试通过、无视觉回归、性能保持或提升、包体积无明显增大这个示例的关键洞察是先做组件依赖图、按依赖顺序迁移——从叶子组件开始可以确保每个阶段都处于可编译、可测试的状态而不是一次性大规模替换导致排错困难。六、示例四Web 应用安全加固安全加固涉及面广、优先级高原文档用/plan Implement comprehensive security for our web app展示了包含 9 个阶段、50 个步骤、10 天周期的全面安全计划Phase 1: Security Audit安全审计Day 1运行自动化安全扫描器npm audit、Snyk审查依赖漏洞检查 OWASP Top 10 合规性审计认证流程审查数据处理实践记录当前安全缺口Phase 2: Authentication Hardening认证加固Day 2-3实施强密码要求添加密码强度指示器登录实现限流失败多次后账户锁定实现 2FATOTP改进会话管理实现安全的密码重置流程Phase 3: Authorization Access Control授权与访问控制Day 3-4实现 RBAC基于角色的访问控制在所有端点添加权限检查实施最小权限原则为敏感操作添加审计日志实现资源级权限Phase 4: Data Protection数据保护Day 4-5实现静态加密敏感字段确保所有通信使用 TLS/SSL实现安全的会话存储在日志中遮蔽 PII 数据实施数据保留策略添加安全的文件上传处理Phase 5: Input Validation Sanitization输入校验与净化Day 5-6在所有端点实现输入校验添加 XSS 防护Content Security Policy实现 SQL 注入防护参数化查询添加 CSRF 防护实现请求体大小限制添加文件上传类型校验Phase 6: Security Headers Configuration安全头与配置Day 6添加安全响应头Strict-Transport-SecurityX-Content-Type-OptionsX-Frame-OptionsX-XSS-ProtectionContent-Security-Policy正确配置 CORS禁用不必要的 HTTP 方法移除服务器版本头Phase 7: Monitoring Logging监控与日志Day 7实现安全事件日志添加异常检测设置入侵检测实现实时告警创建安全仪表盘Phase 8: Testing Documentation测试与文档Day 8-9执行渗透测试运行安全扫描器测试所有安全功能创建安全文档培训团队安全实践创建事件响应计划Phase 9: Compliance Policies合规与策略Day 10GDPR 合规检查创建隐私政策实现数据主体权利添加 cookie 同意机制创建安全策略文档安全改进汇总认证7 项增强授权5 项增强数据保护6 项增强输入校验6 项增强基础设施9 项增强监控5 项增强合规OWASP Top 10、GDPR成功标准零严重漏洞、OWASP Top 10 全部缓解、安全评分 90/100、所有渗透测试问题解决注意计划中每个风险等级Critical与优先级High都被显式标注且安全领域的专业术语RBAC、TOTP、CSRF、CSP被准确使用——这体现了规划模式在需要跨领域专业知识的任务中的价值。七、示例五电商网站性能优化最后一个示例针对/plan Optimize our slow e-commerce website展示了 8 个阶段、47 个步骤、约 50 小时2 周的性能优化计划其特点是每个阶段都给出预期的量化收益Phase 1: Performance Audit性能审计4 小时运行 Lighthouse 审计分析 Chrome DevTools 性能剖析测量 Core Web VitalsLCP、FID、CLS识别性能瓶颈建立性能基线指标当前指标指标当前值目标值LCP4.2s2.5sFID280ms100msCLS0.250.1Page Load8.3s3sPhase 2: Image Optimization图片优化6 小时将图片转为 WebP 格式实现响应式图片为图片添加懒加载优化图片体积压缩为图片接入 CDN添加图片占位符预期收益加载时间 -40%Phase 3: Code Splitting Lazy Loading代码分割与懒加载8 小时实现基于路由的代码分割懒加载非关键组件拆分 vendor 包优化 chunk 体积实现动态导入为关键资源添加预加载预期收益初始包体积 -30%Phase 4: Caching Strategy缓存策略6 小时实现浏览器缓存Cache-Control添加 service worker 支持离线实现 API 响应缓存为数据库查询添加 Redis 缓存实现 stale-while-revalidate配置 CDN 缓存预期收益API 响应时间 -50%Phase 5: Database Optimization数据库优化8 小时添加数据库索引优化慢查询100ms实现查询结果缓存添加连接池在合适处反规范化实现数据库读副本预期收益数据库查询时间 -60%Phase 6: Frontend Optimization前端优化10 小时压缩 JavaScript压缩 CSS移除无用 CSSPurgeCSS实现关键 CSS延迟非关键 JavaScript减小 DOM 体积优化 React 渲染memo、useMemo为长列表实现虚拟滚动预期收益JavaScript 执行时间 -35%Phase 7: Network Optimization网络优化4 小时启用 HTTP/2实现资源提示preconnect、prefetch减少 HTTP 请求数量启用 Brotli 压缩优化第三方脚本预期收益网络时间 -25%Phase 8: Monitoring Testing监控与测试4 小时搭建性能监控Datadog/New Relic添加真实用户监控RUM创建性能预算配置自动化 Lighthouse CI在真实设备上测试目标指标90 分位LCP 2.0s、FID 50ms、CLS 0.05、Page Load 2.5s优先级排序图片优化快速见效代码分割高影响缓存高影响数据库优化关键前端优化打磨这个示例演示了规划模式在量化驱动任务中的用法每个阶段都带预期收益最终给出明确的性能目标让实施阶段始终有可衡量的验收标准。八、Planning Mode 的进阶配置与使用技巧除了/plan斜杠命令仓库 09-advanced-features/README.md 还补充了多项规划模式的高级配置可直接提升使用体验1. 模型别名opusplan—— 规划用 Opus、执行用 Sonnetclaude --model opusplan design and implement the new APIopusplan模型别名让规划阶段使用更强的 Opus 模型推理更充分、计划更周全执行阶段自动切换为 Sonnet速度更快、成本更低。这是规划模式与模型路由组合的典型实践。2. 外部编辑器修改计划CtrlG在规划模式下按下CtrlG可在外部编辑器打开当前计划进行精细的大段修改后保存回 Claude Code。相比逐字回复修改这更适合大计划的批量调整。3. 计划文件的命名规则v2.1.112 更新自 v2.1.112 起计划文件以产生它的 prompt 命名而非之前的随机单词使其更易于浏览和复用。这意味着你可以把一份精心打磨的计划保存下来作为后续同类任务的模板。4. 规划模式的写操作约束v2.1.136 更新自 v2.1.136 起plan 模式无条件阻止所有文件写入即使存在匹配的Edit(...)权限规则也无法绕过——此前一个宽松的Edit(...)规则可能在 plan 模式下放行写入该漏洞已被关闭。如果你的工作流依赖旧行为请先退出 plan 模式ShiftTab再编辑文件。5. 通过配置文件预设规划模式在 09-advanced-features/config-examples.json 中仓库提供了一个现成的Code Review Mode场景配置将defaultMode设为plan并配合高推理强度环境变量{ model: claude-sonnet-5, permissions: { defaultMode: plan }, env: { CLAUDE_CODE_EFFORT_LEVEL: high } }同样的文件里还有security_audit场景defaultMode: planCLAUDE_CODE_EFFORT_LEVEL: max。这体现了规划模式的一个高频用途把 Claude 变成只读的代码审查/审计助手——它能深入阅读代码并给出专业建议但无法修改任何文件。6. 通用权限模式设置将以下 JSON 合并到你的settings.json中即可把 plan 设为默认模式{ permissions: { defaultMode: plan } }设置后每次启动 Claude Code 都会先进入规划模式适合以审查和研究为主的工作流。九、核心要点收益、适用场景与最佳实践原文档的 Key Takeaways 部分系统总结了规划模式的使用方法论Planning Mode 的六大收益清晰度Clarity开始前就有清晰路线图可估算Estimation获得时间与工作量估算风险评估Risk Assessment提前识别潜在问题优先级Prioritization任务按逻辑顺序排列批准机制Approval执行前审阅与批准可修改Modification根据反馈调整计划何时使用规划模式✅ 总是应该使用多天项目团队协作关键系统变更学习新概念复杂重构❌ 不要使用Bug 修复小改动简单查询快速实验七条最佳实践批准前仔细审阅计划——计划的审阅价值大于生成价值发现问题时主动修改计划——用Modify而非将错就错分解复杂任务——拆成可独立验证的阶段估算现实的时间框架——参考示例中的阶段耗时粒度包含回滚策略——尤其对高风险变更如数据库迁移添加成功标准——让每个阶段有可衡量的完成定义每个阶段都规划测试——将测试嵌入计划而非事后补充十、结语把规划模式变成你的开发习惯从本文五个示例可以看出Planning Mode 的价值远不止多一步确认它为**新功能REST API、迁移MongoDB→PostgreSQL、重构Class→Hooks、安全加固、性能优化**五类典型任务提供了可复用的规划范式——按阶段分解、明确时间与风险、带验收标准、可修改可回滚。配合opusplan模型别名、CtrlG外部编辑和配置文件预设规划模式可以深度融入你的日常开发工作流。关于更多高级能力如权限模式、自动模式、后台任务可继续阅读 09-advanced-features/README.md 与仓库中 08-checkpoints/README.md 等章节。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude Code Planning Mode 实战指南：从 REST API 到安全加固的五大规划场景示例（claude-howto）
Claude Code Planning Mode 实战指南从 REST API 到安全加固的五大规划场景示例claude-howto【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howtoPlanning Mode 是 Claude Code 中先规划、后实施的两阶段工作流Claude 先针对复杂任务产出结构化实现计划经你审阅、修改与批准后才开始写代码。本文基于 claude-howto 仓库中 vi/09-advanced-features/planning-mode-examples.md 的五个真实场景REST API 构建、数据库迁移、前端重构、安全加固、性能优化完整展示规划模式产出的计划形态并结合仓库中 09-advanced-features/README.md 的配置说明与 09-advanced-features/config-examples.json 的场景化配置讲解如何激活、配置并最大化利用 Planning Mode。读完你将能直接上手/plan学会拆解任务、评估风险、设定验收标准让 Claude 按你的意志分阶段执行。一、Planning Mode 的两阶段机制Planning mode 允许 Claude 在动手实现之前先完整思考复杂任务产出一份可审阅、可批准的计划。根据 09-advanced-features/README.md 的定义它是一种两阶段方法Planning Phase规划阶段Claude 分析任务创建详细的实现计划包括分阶段步骤、时间估算、涉及文件与技术选型。Implementation Phase实施阶段计划获得批准后Claude 按计划逐步执行。/plan同时也是一个内置斜杠命令用于Enter plan mode进入规划模式在 01-slash-commands/README.md 的内置命令参考表中有所记载。激活 Planning Mode 的四种方式方式命令/操作说明斜杠命令/plan 任务描述在 REPL 会话内直接进入规划模式最常用CLI 参数claude --permission-mode plan启动时即以 plan 权限模式运行配置文件{permissions: {defaultMode: plan}}设为默认权限模式每次启动都先规划快捷键Shift Tab/Alt MWindows/Linux在多个权限模式间循环切换其中包含 plan在 plan 权限模式下Claude 只能读取文件纯研究模式不做任何编辑这在 09-advanced-features/README.md 的权限模式表格中明确列出。这保证了规划阶段不会产生任何未经批准的副作用。二、为什么需要 Planning Mode有规划与无规划的对比原文档第一个示例开头就给出了一个发人深省的对照。对于同一个任务Build a REST API for a blog为博客构建 REST APIUser: Build a REST API for a blog Claude: Ill create the API... [Starts coding immediately, may miss requirements]没有规划模式Claude 立即开始编码可能会遗漏需求——例如没有提前设计数据表结构、没有规划认证流程、没有考虑分页与所有权校验导致返工。使用规划模式Claude 先产出一份从项目初始化到测试、文档、部署的完整计划等你确认后再开工。这正是 Planning Mode 的核心价值把边想边写变成先想清楚再写。三、示例一构建 REST API博客系统当用户输入/plan Build a REST API for a blog时Claude 产出的计划将任务分解为 8 个阶段、36 个步骤覆盖从零搭建到上线交付的全过程Phase 1: Project Setup项目初始化15 分钟初始化 Node.js 项目并引入 Express配置 TypeScript安装依赖express、pgPostgreSQL 驱动、jwt、joi校验配置环境变量搭建项目目录结构Phase 2: Database Layer数据层30 分钟设计数据库 schemausers表id, email, password_hash, created_atposts表id, user_id, title, content, published, created_at, updated_atcomments表id, post_id, user_id, content, created_at创建迁移文件配置数据库连接池实现数据模型Phase 3: Authentication认证45 分钟实现用户注册端点实现基于 JWT 的登录端点创建认证中间件使用 bcrypt 实现密码哈希实现 token 刷新逻辑Phase 4: Posts API40 分钟GET /api/posts—— 列出所有已发布文章带分页GET /api/posts/:id—— 获取单篇文章POST /api/posts—— 创建文章需认证PUT /api/posts/:id—— 更新文章需认证 所有权校验DELETE /api/posts/:id—— 删除文章需认证 所有权校验GET /api/users/:id/posts—— 获取某用户的文章Phase 5: Comments API30 分钟GET /api/posts/:id/comments—— 获取文章评论POST /api/posts/:id/comments—— 添加评论需认证DELETE /api/comments/:id—— 删除评论需认证 所有权校验Phase 6: Validation Error Handling校验与错误处理30 分钟使用 Joi 添加请求校验实现全局错误处理器添加输入净化实现限流rate limitingPhase 7: Testing测试60 分钟为模型编写单元测试为认证端点编写集成测试为文章端点编写集成测试为评论端点编写集成测试达成 80% 代码覆盖率Phase 8: Documentation Deployment文档与部署30 分钟使用 Swagger 生成 API 文档创建带安装说明的 README添加 Docker 配置搭建 CI/CD 流水线计划摘要信息预计耗时4.5 小时待创建文件约 25 个核心技术栈Express、PostgreSQL、JWT、TypeScriptAPI 端点汇总认证 2 个、文章 6 个、评论 3 个共11 个端点计划末尾Claude 会询问Ready to proceed? (yes/no/modify)。用户回答yes后Claude 从 Phase 1 开始逐阶段系统化实施。值得注意的细节计划中每个端点都明确标注了是否需要认证、是否做所有权校验数据库表预先设计好字段。这种先定契约、再写代码的方式能显著减少实现阶段的模糊地带。四、示例二MongoDB 到 PostgreSQL 数据库迁移数据库迁移是高风险的长期任务原文档用/plan Migrate from MongoDB to PostgreSQL展示了如何用 7 个阶段、34 个步骤的系统计划驾驭这类复杂迁移Phase 1: Analysis Preparation分析与准备Day 1分析当前 MongoDB schema识别数据关系与约束记录当前数据量与增长率设计等价的 PostgreSQL schema规划数据类型映射识别潜在迁移挑战Phase 2: PostgreSQL SetupDay 1搭建 PostgreSQL 数据库创建含表、索引、约束的 schema配置连接池配置备份策略Phase 3: Dual-Write Implementation双写实现Day 2-3创建数据库抽象层实现向两个数据库的双写添加数据一致性检查在 staging 部署双写监控问题Phase 4: Data Migration数据迁移Day 4为 MongoDB 创建数据导出脚本为 PostgreSQL 创建数据导入脚本实现数据转换逻辑在生产数据副本上试运行迁移校验迁移后的数据完整性Phase 5: Gradual Cutover渐进切换Day 5-7在生产环境启用双写分批迁移历史数据持续校验数据一致性同时监控两个数据库修复任何数据同步问题Phase 6: PostgreSQL PrimaryPostgreSQL 转正Day 8将读操作切换到 PostgreSQL监控查询性能优化慢查询继续双写以保证安全Phase 7: MongoDB RetirementMongoDB 退役Day 9-10停止向 MongoDB 写入保留 MongoDB 作为备份两周从代码中移除 MongoDB 依赖归档 MongoDB 数据下线 MongoDB 实例计划中显式声明的关键决策信息预计耗时10 天风险等级高回滚策略保持双写MongoDB 持续运行成功标准零数据丢失、性能回退 5%、所有测试通过主要风险迁移期间数据不一致、查询性能退化、应用停机、数据丢失缓解措施双写模式保障安全、渐进切换、持续监控、快速回滚能力当用户回复Modify - lets add a rollback plan for each phase修改计划为每个阶段添加回滚方案时Claude 会输出为每个阶段补充了回滚流程的更新版计划。这个交互展示了 Planning Mode 的可修改性——计划不是一次定稿的文档而是可以反复迭代的活文件。五、示例三React 类组件到 Hooks 重构前端大范围重构同样适合规划模式。原文档用/plan Refactor our React app from class components to hooks展示了一个 8 阶段、37 步骤、总耗时 39 小时的重构计划Phase 1: Preparation Analysis准备与分析2 小时审计所有类组件找出全部 .jsx/.tsx 文件按复杂度分类简单仅有 state约 15 个组件中等有生命周期方法约 23 个组件复杂多个生命周期、refs约 8 个组件识别需要更新的第三方库创建组件依赖关系图规划迁移顺序叶子节点优先Phase 2: Setup Tooling工具配置1 小时升级 React 到 v18配置 hooks 相关的 ESLint 规则创建转换模板配置自动化测试开始前创建 checkpointPhase 3: Migrate Simple Components迁移简单组件4 小时转换简单有状态组件15 个用useState替换this.state用 state setter 替换this.setState每个组件转换后即测试更新测试Phase 4: Migrate Medium Components迁移中等组件8 小时转换含生命周期方法的组件23 个用useEffect替换componentDidMount用useEffect替换componentDidUpdate用useEffectcleanup 替换componentWillUnmount全面测试Phase 5: Migrate Complex Components迁移复杂组件12 小时转换复杂组件8 个用useRef替换 refs为共享逻辑提取自定义 hooks处理边界情况多个 useEffect扩展测试Phase 6: Shared Logic Extraction共享逻辑提取6 小时识别跨组件的重复逻辑创建自定义 hooksuseAuth、useFetch、useLocalStorage、useDebounce重构组件以使用自定义 hooks独立测试自定义 hooksPhase 7: Performance Optimization性能优化4 小时在必要处添加React.memo使用useCallback优化使用useMemo优化分析并修复性能回退Phase 8: Cleanup Documentation清理与文档2 小时移除无用的类组件工具代码更新文档更新编码规范为团队创建迁移指南计划中的策略性内容预计耗时5 天39 小时待修改文件46 个组件风险等级中等迁移顺序叶子组件无依赖→ 中层组件 → 顶层容器组件 →App.jsx最后测试策略每个组件的单元测试、用户流程的集成测试、视觉回归测试、性能基准成功指标所有测试通过、无视觉回归、性能保持或提升、包体积无明显增大这个示例的关键洞察是先做组件依赖图、按依赖顺序迁移——从叶子组件开始可以确保每个阶段都处于可编译、可测试的状态而不是一次性大规模替换导致排错困难。六、示例四Web 应用安全加固安全加固涉及面广、优先级高原文档用/plan Implement comprehensive security for our web app展示了包含 9 个阶段、50 个步骤、10 天周期的全面安全计划Phase 1: Security Audit安全审计Day 1运行自动化安全扫描器npm audit、Snyk审查依赖漏洞检查 OWASP Top 10 合规性审计认证流程审查数据处理实践记录当前安全缺口Phase 2: Authentication Hardening认证加固Day 2-3实施强密码要求添加密码强度指示器登录实现限流失败多次后账户锁定实现 2FATOTP改进会话管理实现安全的密码重置流程Phase 3: Authorization Access Control授权与访问控制Day 3-4实现 RBAC基于角色的访问控制在所有端点添加权限检查实施最小权限原则为敏感操作添加审计日志实现资源级权限Phase 4: Data Protection数据保护Day 4-5实现静态加密敏感字段确保所有通信使用 TLS/SSL实现安全的会话存储在日志中遮蔽 PII 数据实施数据保留策略添加安全的文件上传处理Phase 5: Input Validation Sanitization输入校验与净化Day 5-6在所有端点实现输入校验添加 XSS 防护Content Security Policy实现 SQL 注入防护参数化查询添加 CSRF 防护实现请求体大小限制添加文件上传类型校验Phase 6: Security Headers Configuration安全头与配置Day 6添加安全响应头Strict-Transport-SecurityX-Content-Type-OptionsX-Frame-OptionsX-XSS-ProtectionContent-Security-Policy正确配置 CORS禁用不必要的 HTTP 方法移除服务器版本头Phase 7: Monitoring Logging监控与日志Day 7实现安全事件日志添加异常检测设置入侵检测实现实时告警创建安全仪表盘Phase 8: Testing Documentation测试与文档Day 8-9执行渗透测试运行安全扫描器测试所有安全功能创建安全文档培训团队安全实践创建事件响应计划Phase 9: Compliance Policies合规与策略Day 10GDPR 合规检查创建隐私政策实现数据主体权利添加 cookie 同意机制创建安全策略文档安全改进汇总认证7 项增强授权5 项增强数据保护6 项增强输入校验6 项增强基础设施9 项增强监控5 项增强合规OWASP Top 10、GDPR成功标准零严重漏洞、OWASP Top 10 全部缓解、安全评分 90/100、所有渗透测试问题解决注意计划中每个风险等级Critical与优先级High都被显式标注且安全领域的专业术语RBAC、TOTP、CSRF、CSP被准确使用——这体现了规划模式在需要跨领域专业知识的任务中的价值。七、示例五电商网站性能优化最后一个示例针对/plan Optimize our slow e-commerce website展示了 8 个阶段、47 个步骤、约 50 小时2 周的性能优化计划其特点是每个阶段都给出预期的量化收益Phase 1: Performance Audit性能审计4 小时运行 Lighthouse 审计分析 Chrome DevTools 性能剖析测量 Core Web VitalsLCP、FID、CLS识别性能瓶颈建立性能基线指标当前指标指标当前值目标值LCP4.2s2.5sFID280ms100msCLS0.250.1Page Load8.3s3sPhase 2: Image Optimization图片优化6 小时将图片转为 WebP 格式实现响应式图片为图片添加懒加载优化图片体积压缩为图片接入 CDN添加图片占位符预期收益加载时间 -40%Phase 3: Code Splitting Lazy Loading代码分割与懒加载8 小时实现基于路由的代码分割懒加载非关键组件拆分 vendor 包优化 chunk 体积实现动态导入为关键资源添加预加载预期收益初始包体积 -30%Phase 4: Caching Strategy缓存策略6 小时实现浏览器缓存Cache-Control添加 service worker 支持离线实现 API 响应缓存为数据库查询添加 Redis 缓存实现 stale-while-revalidate配置 CDN 缓存预期收益API 响应时间 -50%Phase 5: Database Optimization数据库优化8 小时添加数据库索引优化慢查询100ms实现查询结果缓存添加连接池在合适处反规范化实现数据库读副本预期收益数据库查询时间 -60%Phase 6: Frontend Optimization前端优化10 小时压缩 JavaScript压缩 CSS移除无用 CSSPurgeCSS实现关键 CSS延迟非关键 JavaScript减小 DOM 体积优化 React 渲染memo、useMemo为长列表实现虚拟滚动预期收益JavaScript 执行时间 -35%Phase 7: Network Optimization网络优化4 小时启用 HTTP/2实现资源提示preconnect、prefetch减少 HTTP 请求数量启用 Brotli 压缩优化第三方脚本预期收益网络时间 -25%Phase 8: Monitoring Testing监控与测试4 小时搭建性能监控Datadog/New Relic添加真实用户监控RUM创建性能预算配置自动化 Lighthouse CI在真实设备上测试目标指标90 分位LCP 2.0s、FID 50ms、CLS 0.05、Page Load 2.5s优先级排序图片优化快速见效代码分割高影响缓存高影响数据库优化关键前端优化打磨这个示例演示了规划模式在量化驱动任务中的用法每个阶段都带预期收益最终给出明确的性能目标让实施阶段始终有可衡量的验收标准。八、Planning Mode 的进阶配置与使用技巧除了/plan斜杠命令仓库 09-advanced-features/README.md 还补充了多项规划模式的高级配置可直接提升使用体验1. 模型别名opusplan—— 规划用 Opus、执行用 Sonnetclaude --model opusplan design and implement the new APIopusplan模型别名让规划阶段使用更强的 Opus 模型推理更充分、计划更周全执行阶段自动切换为 Sonnet速度更快、成本更低。这是规划模式与模型路由组合的典型实践。2. 外部编辑器修改计划CtrlG在规划模式下按下CtrlG可在外部编辑器打开当前计划进行精细的大段修改后保存回 Claude Code。相比逐字回复修改这更适合大计划的批量调整。3. 计划文件的命名规则v2.1.112 更新自 v2.1.112 起计划文件以产生它的 prompt 命名而非之前的随机单词使其更易于浏览和复用。这意味着你可以把一份精心打磨的计划保存下来作为后续同类任务的模板。4. 规划模式的写操作约束v2.1.136 更新自 v2.1.136 起plan 模式无条件阻止所有文件写入即使存在匹配的Edit(...)权限规则也无法绕过——此前一个宽松的Edit(...)规则可能在 plan 模式下放行写入该漏洞已被关闭。如果你的工作流依赖旧行为请先退出 plan 模式ShiftTab再编辑文件。5. 通过配置文件预设规划模式在 09-advanced-features/config-examples.json 中仓库提供了一个现成的Code Review Mode场景配置将defaultMode设为plan并配合高推理强度环境变量{ model: claude-sonnet-5, permissions: { defaultMode: plan }, env: { CLAUDE_CODE_EFFORT_LEVEL: high } }同样的文件里还有security_audit场景defaultMode: planCLAUDE_CODE_EFFORT_LEVEL: max。这体现了规划模式的一个高频用途把 Claude 变成只读的代码审查/审计助手——它能深入阅读代码并给出专业建议但无法修改任何文件。6. 通用权限模式设置将以下 JSON 合并到你的settings.json中即可把 plan 设为默认模式{ permissions: { defaultMode: plan } }设置后每次启动 Claude Code 都会先进入规划模式适合以审查和研究为主的工作流。九、核心要点收益、适用场景与最佳实践原文档的 Key Takeaways 部分系统总结了规划模式的使用方法论Planning Mode 的六大收益清晰度Clarity开始前就有清晰路线图可估算Estimation获得时间与工作量估算风险评估Risk Assessment提前识别潜在问题优先级Prioritization任务按逻辑顺序排列批准机制Approval执行前审阅与批准可修改Modification根据反馈调整计划何时使用规划模式✅ 总是应该使用多天项目团队协作关键系统变更学习新概念复杂重构❌ 不要使用Bug 修复小改动简单查询快速实验七条最佳实践批准前仔细审阅计划——计划的审阅价值大于生成价值发现问题时主动修改计划——用Modify而非将错就错分解复杂任务——拆成可独立验证的阶段估算现实的时间框架——参考示例中的阶段耗时粒度包含回滚策略——尤其对高风险变更如数据库迁移添加成功标准——让每个阶段有可衡量的完成定义每个阶段都规划测试——将测试嵌入计划而非事后补充十、结语把规划模式变成你的开发习惯从本文五个示例可以看出Planning Mode 的价值远不止多一步确认它为**新功能REST API、迁移MongoDB→PostgreSQL、重构Class→Hooks、安全加固、性能优化**五类典型任务提供了可复用的规划范式——按阶段分解、明确时间与风险、带验收标准、可修改可回滚。配合opusplan模型别名、CtrlG外部编辑和配置文件预设规划模式可以深度融入你的日常开发工作流。关于更多高级能力如权限模式、自动模式、后台任务可继续阅读 09-advanced-features/README.md 与仓库中 08-checkpoints/README.md 等章节。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考