先别改代码：Plan mode 怎么进、怎么批、怎么回来
大改一上来就写文件，后面往往要整段回滚。Plan mode 把节奏反过来：先摸清现状、写出可编辑的方案，你点头之后才动手。状态栏会亮着 plan mode，提醒它现在不能改源码。
小到改一行、修一个文件，没必要绕这一圈。不熟的模块、跨目录重构、牵动权限和测试边界的活，才值得先规划。
怎么进
三种入口，效果一样：
- 反复按
Shift+Tab，直到状态栏显示 plan mode - 会话里跑
/plan - 启动时带上：
claude --permission-mode plan
进了之后，它只能读文件、搜代码、提方案。写源码、改配置这类会动仓库的动作，要等你批准计划之后才放开。
想和别的权限模式对照：沙箱与 allow / ask / deny 见 权限怎么配；分类器驱动的免确认路径见 Auto mode 配置。Plan mode 管的是「先规划再实现」，不是分类器，也不是 acceptEdits 那种批量同意编辑。
规划阶段实际在干什么
它会探索仓库结构、读关键文件、比较几种改法，然后把计划写成 Markdown。这份计划可以打开编辑器改：删掉你不认同的步骤、补上约束、把「先测再改」写死。
常见会看到的内容包括：
- 要动哪些目录和入口
- 依赖顺序（先抽接口还是先迁调用方）
- 风险点：破坏性命令、共享类型、跨包引用
- 建议的验证步骤：单测、类型检查、手工冒烟
你批的是这份文档，不是某一句聊天里的口头承诺。改计划比事后扯皮便宜。
批准之后会发生什么
批准计划后，会话退出 plan mode，进入实现阶段。状态栏上的 plan mode 标记会消失。此时它按你刚批过的步骤改代码。
实现中途若发现方向偏了——比如摸到了计划里没写的耦合——可以再切回 plan mode：同样用 Shift+Tab 或 /plan。不必推倒重来整个会话；补一版计划、再批一次，继续干。
| 阶段 | 能不能改源码 | 你要做什么 |
|---|---|---|
| Plan mode 开着 | 否，只读探与提案 | 审 Markdown 计划，改完再批 |
| 批准后实现 | 是 | 看 diff、跑测试、必要时再进 plan |
| 中途重进 plan | 再次只读 | 修订计划，避免顺着错误假设写下去 |
和 Auto mode、acceptEdits 别混
- Plan mode：先方案后动手；适合陌生区和大范围改动
- Auto mode：工具调用过分类器；deny / ask 仍先生效，见 Auto mode 配置
- acceptEdits：倾向自动接受文件编辑，不等于「先规划」
三者可以按任务叠用，但不要指望「开了 Auto 就等于开了 Plan」。不熟的大重构，宁可先 plan；已知的一文件小修，直接改更快。
远程或云端派发任务时，本地还在 plan 里犹豫，远端可能已经按别的权限在跑。分工见 Remote Control 与云端派发。多 worktree 并行时，每个树各自的 plan 状态也不共用，见 Worktree 用法。
什么时候用，什么时候跳过
适合：
- 第一次碰的子系统
- 要动公共 API、迁移目录、拆包
- 你自己也说不清「该先改哪」
可以跳过：
- 改错别字、补一条日志
- 你已经写好完整 patch 思路，只差它落地
- 时间极紧、且回滚成本极低的一次性脚本
Skills 适合固化「碰到某类任务再加载」的流程；Plan mode 适合「这一次还没想清楚」。两者怎么搭配，可对照 Skills 指南。硬性「不许碰某路径」仍要靠权限与 Hooks，见 CLAUDE.md 与 Hooks。
实操小结
Shift+Tab或/plan进入，确认状态栏是 plan mode- 让它读、搜、写 Markdown 计划；你直接改计划文本
- 批准后退出 plan，开始改代码
- 飘了就再进 plan，补约束再批
- 小修别硬套；大重构别省这一步
Plan mode 的价值不是多一个开关，而是把「想清楚」和「写下去」拆开。批的是可编辑的计划，回来的入口也始终开着。