Plan Mode：在执行前安全探索和规划

核心观点：Plan Mode是Claude Code中最被低估的功能。在做出大的改动前，用Plan Mode进行只读探索，能避免80%的后悔决策。

关键词：Plan Mode、只读模式、复杂决策、架构设计、风险评估、代码分析

导读

你将学到：

• 什么是Plan Mode以及为什么它很强大
• Plan Mode与普通模式的核心区别
• 何时应该使用Plan Mode
• 如何有效地使用Plan Mode
• Plan Mode配合代码审查的工作流
• 常见的Plan Mode使用模式
• 避坑指南：Plan Mode的限制

适合人群：中级开发者，特别是需要做架构决策或处理复杂变更的开发者

阅读时间：20分钟 |难度：中级 |实用度：4/5

前置知识：

• 已阅读本系列前4篇基础文章
• 理解基本的代码库结构
• 有过大型代码重构的经验

问题场景

你需要做一个重大的架构改动。在直接开始之前，你想让Claude帮你：

• 分析现有代码的结构
• 提出改动方案和权衡
• 识别潜在的风险点
• 规划实施步骤

但你有顾虑：如果直接启动Claude Code，它会自动开始修改文件。我想先看看计划，再决定是否执行。

这就是Plan Mode存在的原因。

为什么这很重要？

在复杂任务中，做决策的成本模型：

总成本 = 决策成本 + 实施成本 + 修复错误成本

• 没有Plan Mode：直接实施 → 发现问题 → 回滚修改 → 重新实施（高风险）
• 使用Plan Mode：先规划 → 验证方案 → 实施 → 很少需要修改（低风险）

实际数据：

• 用Plan Mode的大型变更：成功率85-90%
• 不用Plan Mode的大型变更：成功率40-50%

核心概念

什么是Plan Mode？

Plan Mode是Claude Code的一个特殊运行模式，Claude会：

1. 只读取代码，不修改任何文件
2. 分析项目结构和现有实现
3. 提出一个详细的计划
4. 等待你的批准再执行

Plan Mode vs 普通模式

什么时候用Plan Mode？

应该用：

不必要用：

• 小bug修复
• 添加简单功能
• 代码格式化
• 文档更新

使用Plan Mode

步骤1：启动Plan Mode

# 方式1：直接启动claude --plan# 方式2：在现有会话中切换# （如果Claude Code支持）/plan# 验证是否在Plan Mode# Claude会提示："现在进入Plan Mode。我将分析代码库..."

步骤2：提出需求和背景

在Plan Mode中，你需要：

1. 清晰说明想要做什么
2. 提供背景信息
3. 指出关键约束

好的提示示例：

你：我需要重构认证系统。 背景： - 当前使用session-based认证 - 需要支持多客户端（web + mobile） - 用户量约100万 目标： - 迁移到JWT认证 - 保证向后兼容（逐步迁移） - 不增加显著的性能开销 问题： - 如何规划这个迁移？ - 有什么风险点？ - 实施步骤是什么？ 已有约束： - 不能停机 - 必须在2周内完成 - 现有token认证方式可以保留

Claude会回复一个详细的计划。

步骤3：审查和讨论计划

Claude的回复通常包含：

我的分析： 当前状态： - 使用Django session认证 - 存储在PostgreSQL中 - 平均日活用户：10万 提议的方案： 步骤1：添加JWT支持（不破坏现有session） - 创建jwt_tokens表 - 添加生成和验证JWT的工具函数 - 新客户端可以选择JWT或session 步骤2：迁移现有客户端 - Web客户端优先（容易更新） - 然后是移动客户端 - 使用feature flag控制转换 步骤3：清理旧的session逻辑 - 在2个月的观察期后移除 风险评估： - 中等风险：token泄露可能性 缓解：使用https + 短期token + refresh机制 - 低风险：性能问题 缓解：使用缓存 + 异步验证 关键文件： - apps/users/models.py (添加JWT token表) - apps/users/auth.py (JWT逻辑) - apps/users/views.py (JWT端点) 所需时间： - 步骤1：3天 - 步骤2：7天 - 步骤3：3天 总计：13天（在目标范围内）

步骤4：给出反馈和调整

如果计划不满意，你可以：

你的反馈选项： 拒绝选项： 你：我不同意这个方案。有什么替代方案吗？ 调整选项： 你：计划总体不错，但我想改下步骤2。 不用feature flag，改为URL参数来选择认证方式。 这样可以避免代码部署管理的复杂性。 质疑选项： 你：JWT token的泄露风险如何具体缓解？ 能详细说明refresh token的机制吗？ 追问选项： 你：新的JWT端点应该支持什么样的refresh流程？ 是否需要建立token黑名单？

Claude会根据你的反馈调整计划。

步骤5：批准并执行

一旦满意，你可以：

你：计划看起来很好。现在请执行步骤1。 或者： 我同意这个方案。请开始实施。

Claude会退出Plan Mode，进入普通模式开始修改代码。

常见使用模式

模式1：架构评估

在决定采用新的技术栈或架构前，先用Plan Mode评估。

你：我们考虑从单体架构迁移到微服务。 现有系统： - 单个Django应用 - PostgreSQL数据库 - 5个开发者 - 日活用户10万 约束： - 团队规模有限 - 不能有停机时间 问题： 1. 这个迁移值得吗？ 2. 有什么关键的技术决策？ 3. 分几个阶段进行？ 4. 需要多长时间？ Claude会分析： - 当前系统的瓶颈 - 微服务的真实收益 - 实现的复杂度 - 替代方案（如Django Celery） - 时间和成本估计

模式2：大型重构规划

重构代码时，先规划再执行。

你：我想重构支付处理模块。 当前问题： - 支付逻辑与订单逻辑耦合 - 测试困难 - 难以支持新的支付方式 目标： - 清晰的支付抽象 - 易于测试 - 易于扩展新的支付网关 现有支付方式： - Stripe - 支付宝 - 本地测试支付 Claude会提供： - 推荐的架构设计 - 接口定义 - 实施步骤 - 风险点 - 向后兼容性考虑

模式3：性能优化规划

在优化前，评估哪些改动最有价值。

你：我们的API响应时间超过500ms（P99）。 已知的热点： - 数据库查询慢 - 没有缓存 - 序列化开销 约束： - 不能改变数据库schema（需要保持兼容） - 有缓存基础设施（Redis） - 不能改变API返回格式 问题： 1. 哪些优化能获得最大收益？ 2. 实施优先级是什么？ 3. 有什么技术方案？ Claude会分析： - 当前的性能瓶颈 - 各种优化的预期收益 - 实施难度 - 建议的优化顺序 - 每步的预期改进

模式4：代码库理解

加入新项目或接手旧项目时，用Plan Mode快速理解结构。

你：我刚加入这个项目，还不了解代码库。 问题： 1. 这个项目的核心架构是什么？ 2. 主要的数据流是什么？ 3. 关键的文件和模块是什么？ 4. 如果我想添加新功能，应该在哪里改动？ 5. 有什么重要的约定我应该知道？ Claude会： - 分析整个项目结构 - 生成项目地图 - 识别关键模块 - 说明数据流 - 提出学习路径

Plan Mode与代码审查的配合

完整流程

第一阶段：规划（Plan Mode） 你 → 提出需求 Claude → 生成计划 你 → 审查和讨论 目标 → 得到批准的计划 第二阶段：实施（普通模式） Claude → 执行计划修改代码 你 → 审查改动 目标 → 代码合并 第三阶段：反馈（Plan Mode） 如果需要后续改进 回到第一阶段...

推荐的团队工作流

# 1. 技术负责人使用Plan Mode评估claude --plan 你（技术负责人）： 分析这个重构方案是否合理[提出详细的技术问题][讨论和调整方案]# 2. 开发者执行实施gitcheckout -b feature/refactoring claude 你（开发者）： 我已经审查了技术负责人批准的计划。 现在请按照计划执行。# 3. 代码审查# 在Pull Request中进行代码审查# 确保Claude遵循了计划# 4. 合并gitmerge feature/refactoring

高级技巧

技巧1：迭代式规划

不是一次性完整规划，而是逐步细化。

第一轮： 你：高层上，我们如何重构这个系统？ Claude：提出5个高层方案 第二轮： 你：我选择方案3。现在详细说明实施步骤。 Claude：详细的实施计划 第三轮： 你：步骤2的数据迁移如何进行？ Claude：详细的迁移策略

技巧2：对比分析

同时分析多个可能方案。

你：我们有两个可能的方向： 方案A：使用NoSQL数据库 优点：易扩展 缺点：事务支持差 方案B：保持SQL但优化查询 优点：保持一致性 缺点：扩展性有限 请分析： 1. 哪个方案更适合我们？ 2. 每个方案的实施成本？ 3. 长期的可维护性？ Claude会详细对比两个方案

技巧3：风险分析

在规划时重点关注风险。

你：制定这个规划时，请特别关注： 1. 数据完整性风险 - 迁移过程中可能的数据丢失 - 回滚方案 2. 性能风险 - 新系统的性能指标 - 性能回归的检测 3. 兼容性风险 - 与现有系统的兼容性 - 客户端的适配 4. 人力风险 - 需要多少人力？ - 需要什么技能？ Claude会针对每个风险详细分析

Plan Mode的限制

限制1：不能实际执行

Plan Mode局限： - 不能真正运行代码 - 不能执行性能测试 - 不能确认部署工作 解决方案： - 用Plan Mode做初步分析 - 实施一小部分代码（原型） - 进行实际测试验证

限制2：基于现有代码的分析

Plan Mode局限： - 基于当前代码库的理解 - 无法预测未来的变化 解决方案： - 定期重新评估（项目演进后） - 考虑未来的扩展空间 - 询问Claude长期的可维护性

限制3：可能遗漏隐含假设

Plan Mode局限： - Claude可能遗漏某些业务规则 - 可能不了解隐含的约束 解决方案： - 在Plan Mode中详细说明背景和约束 - 包含所有相关的CLAUDE.md信息 - 明确提出隐含的假设

避坑指南

错误1：Plan Mode中说明不足

错误： 你：重构这个模块。 改进： 你：重构支付模块。 背景： - 当前与订单逻辑耦合 - 需要支持多种支付方式 - 已有的方式：Stripe、支付宝 约束： - 必须向后兼容 - 不能改变现有API签名 - 需要保证原子性 问题： 1. 应该如何设计抽象？ 2. 如何保证事务一致性？ 3. 如何处理第三方失败情况？

错误2：忽视Plan Mode的建议

错误流程： Claude在Plan Mode中提出的警告和建议 → 你选择忽视 → 进入普通模式执行 → 真的遇到了Claude警告的问题 → 浪费时间修复 改进： 认真听取Claude在Plan Mode中的所有建议 特别是风险和可行性警告

错误3：Plan Mode用于不适合的任务

不适合用Plan Mode的情况： 1. 简单的bug修复 → 直接用普通模式 2. 一行代码的改动 → 直接用普通模式 3. 文档更新 → 直接用普通模式 4. 已经充分理解的需求 → 直接用普通模式 只用Plan Mode处理： - 架构决策 - 大型变更 - 复杂设计 - 有多个可选方案的情况

错误4：在Plan Mode中过度讨论

错误： 在Plan Mode中讨论了2小时 得到了一个方案 然后又在普通模式中发现需要修改 改进： - 在Plan Mode中充分讨论和迭代 - 确保方案已经充分论证 - 只在方案确定后进入普通模式

实战案例

案例：电商平台的库存管理系统重构

背景： - 现有库存系统存在超卖问题 - 在促销期间经常超卖 - 需要支持分布式部署 使用Plan Mode： 第一轮对话： 你：我们的库存系统有超卖问题。 如何重构来解决？ Claude： 分析：现有系统使用乐观锁，在高并发下会出现超卖。 建议：使用悲观锁或Redis原子操作。 第二轮： 你：详细说明两个方案的权衡。 Claude： 方案A (悲观锁)： - 优点：实现简单，ACID保证 - 缺点：性能受限，可扩展性差 方案B (Redis)： - 优点：高性能，易扩展 - 缺点：需要额外的Redis，故障处理复杂 第三轮： 你：考虑我们的架构（分布式，高并发）， 哪个方案更合适？ Claude： 对你的场景，方案B更合适。 关键实施点： 1. Redis库存作为真实来源 2. 数据库作为持久化 3. 一致性检查机制 第四轮： 你：如何处理Redis故障的情况？ Claude： 故障处理方案： 1. 自动故障转移到备用Redis 2. 故障期间降级到悲观锁 3. 恢复后的同步机制 完整计划已生成。你同意吗？ 最后： 你：同意。现在请执行。 （从Plan Mode切换到普通模式）

总结与要点

Plan Mode的核心价值

关键原则

Plan Mode的核心原则： 1. 规划优于盲目执行 - 花20%时间规划，节省80%的调整 2. 讨论优于假设 - 在Plan Mode中充分讨论，避免误解 3. 分析优于凭感觉 - Claude的分析往往比我们的直觉更全面 4. 迭代优于一次定型 - 在Plan Mode中逐步细化，直到满意

一句话总结

Plan Mode是你在执行前的"暂停按钮"，让你在低成本的只读模式中充分思考和规划，大幅降低大型变更的风险和成本。

下一步行动

1. 立即尝试：对你当前项目的某个改动使用Plan Mode
2. 体验差异：对比"Plan Mode规划"vs"直接执行"的结果
3. 建立习惯：任何超过5%改动的任务都用Plan Mode
4. 团队推广：教会团队成员使用Plan Mode

推荐阅读

本系列相关文章

• 上一篇：Git工作流规范 - 确保Plan Mode的改动安全
• 后续：Slash命令与Skills - 自动化常见任务
• 后续：Hooks - 事件驱动的自动化

官方资源

• Claude Code文档 - Plan Mode: https://code.claude.com/docs
• Best Practices for Complex Changes: https://www.anthropic.com/engineering

常见问题

Q: Plan Mode会分析多久？
A: 取决于项目大小。通常：小项目（<100文件）1-2分钟；大项目（>1000文件）5-10分钟。

Q: Plan Mode生成的计划有多准确？
A: 通常80-90%准确。计划中的架构和步骤一般都很合理，但具体细节可能需要在执行时调整。

Q: 可以在Plan Mode中要求Claude提出多个方案吗？
A: 完全可以。这是Plan Mode的强项——比较多个方案的优缺点。

Q: Plan Mode和普通模式之间可以切换吗？
A: 不能无缝切换。通常是完成Plan Mode讨论后，启动新的普通模式会话来执行。

Q: 如果在普通模式中发现问题，可以回到Plan Mode调整吗？
A: 可以。启动新的Plan Mode会话，基于现有代码库提出调整方案。

最后的话

Plan Mode代表了一种设计哲学：在复杂系统中，好的规划远比快速执行更重要。

很多开发者因为追求速度而跳过规划，结果反而浪费了更多时间在修复和返工上。

学会使用Plan Mode，就是学会"慢下来思考"。这个看似低效的步骤，其实是最高效的。

恭喜！你现在已经掌握了Claude Code从规划到执行的完整周期：Plan Mode规划 → Git工作流执行 → 代码审查验证。

下一篇文章将介绍Slash命令和Skills，让你的常见任务自动化——敬请期待！