核心:先研究 → 出方案 → 人审核 → 再执行

Plan Mode = 只读的“技术方案模式”

1. 能做什么

  • 📖 读取项目文件、目录、配置、依赖
  • 🔍 搜索代码、追踪调用链、数据流
  • 🧩 分析需求影响哪些文件、接口、数据库、测试
  • ❓ 发现需求不明确时进行反问
  • 📝 输出实施计划、风险、测试方案

不会:

  • ❌ 修改源码
  • ❌ 创建文件
  • ❌ 执行修改项目状态的命令

2. 什么时候用

场景为什么先 Plan
多文件开发梳理前后端、接口、测试影响
重构旧项目先分析依赖,避免改 A 崩 B
复杂 Bug先定位问题,再动代码
升级框架找 Breaking Changes 和兼容问题
安全审计检查认证、权限、密钥、输入校验
Docker / 部署改造分析 Compose、环境变量、端口、CI/CD
需求不明确先让 AI 澄清需求
一句话:复杂任务先 Plan,简单任务直接做。

3. 和其他模式的区别

模式核心行为适合
Default操作前通常询问日常开发
Accept Edits自动接受编辑明确的小/中型修改
Plan Mode只读分析 + 出方案复杂开发、重构、排查
Auto Mode根据风险自动处理熟悉项目和权限边界

最重要的区别

Plan Mode:告诉你“怎么做”

执行模式:直接“帮你做”

4. 常用入口

/plan
claude --permission-mode plan

一次性分析:

claude --permission-mode plan -p "分析当前 Docker 部署架构,列出安全和可用性改进方案"

5. 推荐工作流

需求
 ↓
Plan Mode
 ↓
分析代码库
 ↓
输出方案
 ↓
人工审核
 ↓
执行修改
 ↓
测试
 ↓
Review Diff

Plan 时重点要求 AI 输出

  1. 当前架构 / 调用链
  2. 影响文件
  3. 修改顺序
  4. 数据库变更
  5. 风险与边界情况
  6. 测试计划
  7. 回滚方案

6. 推荐 Prompt

先不要修改任何文件。

分析这个项目目前的 XXX 功能。

我的目标是:XXX
限制条件:XXX
必须兼容:XXX

请输出:
1. 当前架构和关键调用链
2. 需要修改的文件及原因
3. 数据库/接口影响
4. 风险和边界情况
5. 测试计划
6. 推荐实施顺序

先只分析,不执行修改。

🧠 记忆口诀

复杂任务:先 Plan;方案确认后再 Code。