Claude Code Plan 模式：省 token 的规划式编程
Claude Code Plan 模式是一种”只读规划、先审后改”的工作方式：进入该模式后，AI 只读代码、搜索、分析，给出完整的修改计划，等你确认后才真正动手写文件。 它的核心价值是把”想清楚”和”动手改”拆成两步——既省 token，又避免 AI 在你没看明白前就把代码改乱。
这篇讲清 claude code plan 模式是什么、解决什么痛点、什么时候该用、怎么进入退出，以及新手常踩的坑。用的工具是 Claude Code。
Plan 模式是什么，和默认模式有什么不一样
默认情况下，你给 Claude Code 一句需求，它会边想边改：读几个文件、立刻动手编辑、再继续读、再改。改得快，但有两个问题——你看不到它的整体思路，而且它可能在误解需求的情况下就把一堆文件改了。
Plan 模式把节奏改成两段式：
| 默认模式 | Plan 模式 | |
|---|---|---|
| 行为 | 边读边改，直接落盘 | 只读不改，先出计划 |
| 你的角色 | 事后审改动 | 事前审计划 |
| 适合 | 小改、明确的活 | 大改、不熟的代码 |
| token | 容易反复试错烧 token | 规划一次，执行更聚焦 |
一句话：默认模式是”先干再说”，Plan 模式是”先画图纸再施工”。
为什么它能省 token、还更稳
很多人以为多一道”规划”会更费 token，其实反过来。
省 token 的逻辑：AI 乱改最贵的不是那次改动，而是改错之后的反复返工——它改了、你发现不对、它再读再改、又不对……每一轮都在重复读上下文、重复生成 diff。Plan 模式让它一次性把方案想透，执行阶段目标明确，少走回头路，整体 token 反而更省。
更稳的逻辑：计划是纯文本，你扫一眼就知道它有没有理解错需求、有没有漏掉边界情况、要不要动到不该动的文件。在它写第一行代码之前拦下来，比改完再回滚成本低得多。
这也和 Claude Code 的上下文管理（规划中）思路一致——把有限的上下文花在”想对”上，而不是”试错”上。
拿一个真实场景对比一下。 假设你要给一个电商后台加”订单批量导出”功能，涉及路由、service 层、导出脚本、前端按钮四个文件。用默认模式，常见走法是：AI 先改了 service 层，你跑起来发现它没处理分页导致大订单量超时；它再改分页逻辑，又发现前端按钮没传时间范围参数；来回三四轮，每一轮它都要重新读一遍相关文件、重新生成一遍上下文里的历史对话，token 消耗是线性叠加的。换成 Plan 模式，第一轮它就会在计划里写清楚”分页策略用游标而不是 offset，避免大数据量超时；前端需要新增时间范围选择器”——这些坑在计划文本里一行字就能暴露，你在动手前就把它堵上了，执行阶段基本一次过。省的不是某一次改动的 token，是省掉了那两三轮本来会发生的返工。
什么时候该用 Plan 模式
不是每个任务都需要。给你一个判断口诀：活越大、代码越陌生、越怕改坏，就越该先 Plan。
建议用 Plan 模式的场景：
- 大改动：跨多个文件的重构、加一个完整功能模块、改公共数据结构或接口。
- 不熟的代码库：刚接手的项目，你自己都没把握它会动到哪，先让 AI 摸清再说。
- 高风险改动：碰核心逻辑、迁移、删除、改配置——改坏了排查成本高。
- 需求本身没想透：你也想借规划过程把方案捋清楚。
不必用、直接干更快的场景：
- 改个错别字、调一行样式、加一句日志这类一目了然的小活。
- 你已经非常清楚要改哪几行、心里有完整方案。
简单说：小活别为流程付税，大活别为效率冒险。
还有一类中间地带容易判断错：看起来是小活、实际牵一发动全身的改动。比如”把用户表的 id 字段从自增整数改成 UUID”，听着像一行 schema 改动，实际会牵出外键、缓存 key、日志埋点、第三方接口传参等一串隐藏依赖。判断标准别只看”改动本身有几行”，要看这行改动的影响半径——影响半径大，哪怕表面是”一行改动”，也该走 Plan。
怎么写一份能让计划更准的初始需求
Plan 模式再好，喂给它的需求太糙，计划照样跑偏。这里有个实用清单，动手前花两分钟对着过一遍：
- 说清楚范围边界：不是”优化一下登录逻辑”，而是”只改前端的 loading 状态和错误提示文案，不动后端接口”。范围越明确，AI 探索时就越不会顺手去碰你没打算改的文件。
- 给出验收标准：告诉它”改完之后，用户输错密码 3 次要弹出验证码”，比”让登录更安全”具体得多——验收标准模糊，计划里的实现方案也会模糊。
- 提前说明约束条件：技术栈限制（比如”不能引入新依赖”）、兼容性要求（“要兼容老版本 API”）、风格偏好（“按现有目录结构来”），这些提前说，计划就不用来回改。
- 主动提供上下文线索：如果你已经知道大概会牵扯哪几个文件或模块，直接点名告诉它，能省掉它一轮”到处搜索确认”的探索成本。
需求给得越具体，计划审起来就越轻松——这也是”先想清楚”这件事该往前再推一步的地方：你和 AI 一起想清楚，而不是只指望它单方面想清楚。
怎么进入和退出 Plan 模式
Plan 模式是 Claude Code 内置的运行模式，进入方式以官方文档为准（不同版本入口可能微调，常见是快捷键切换模式或在启动/会话中指定）。无论入口怎么变，使用流程是固定的三步：
- 进入 Plan 模式，提出需求。AI 开始只读探索：读文件、搜索、分析依赖，不写任何改动。
- 审计划。它给出一份”打算怎么改”的清单——动哪些文件、加什么、删什么、为什么。你重点看：理解对不对、范围有没有越界、有没有漏。
- 确认后执行。计划没问题就放行，AI 切到执行、按计划落盘；不满意就直接在计划上提修正，它重新规划，不浪费一次改动。
关键心态：Plan 阶段你是审图纸的甲方，执行阶段才放它进场施工。
一份”合格的计划”长什么样，给你一个对照标准。 差的计划长这样：“我会优化订单导出功能，修复分页问题，调整前端展示”——这三句话谁都能说，但完全看不出具体动作。合格的计划应该逐条列到文件和函数级别，类似：“1）修改 order/service.ts 的 exportOrders 函数，把 offset 分页换成基于 created_at 游标的分页，避免深分页超时；2）在 order/routes.ts 新增查询参数 startDate/endDate 的校验；3）前端 OrderExportButton.tsx 新增时间范围选择器组件，默认取最近 30 天。“你审计划时，就是拿这个标准去卡——凡是只说”优化""调整""处理一下”这种动词而没有落到具体文件和改动点的条目，都值得追问一句”具体怎么改”，别急着点确认。
新手常见坑
- 坑 1：计划太笼统就放行。 计划写得含糊（“优化一下相关模块”）不要急着确认，让它说清具体动哪些文件、怎么改。模糊的计划 = 模糊的执行。
- 坑 2：把 Plan 当万能。 小改动还套 Plan，纯属给自己加流程。看需求体量决定。
- 坑 3：不看计划直接 yes。 Plan 模式的全部价值在”你审了”。不审就放行，等于退回默认模式还多花了一道规划。
- 坑 4：忘了它在只读。 Plan 模式下文件不会变，别等着看 diff——那是确认执行之后的事。
- 坑 5：撞上输出长度限制时计划被截断。 大型重构的计划可能很长，若遇到 Claude Code 的额度与限制（规划中），可让它分模块、分阶段出计划，每段审完再继续。
常见问题
Plan 模式会不会更费 token？ 通常更省。它省的是”改错—返工—再改”的反复消耗。把方案一次想透、执行更聚焦，整体往往比边想边改更省。
Plan 模式下 AI 会改我的文件吗？ 不会。规划阶段只读不写——读代码、搜索、分析、出计划。只有你确认计划、它切到执行阶段，才会真正落盘。
计划不满意怎么办？ 直接在计划上提修正意见，让它重新规划，不需要先执行再回滚。这正是先审后改的好处：改图纸比拆墙便宜。
小任务也要开 Plan 模式吗？ 不建议。改错别字、调一行样式这种一目了然的小活，开 Plan 反而拖慢节奏。把它留给大改动和不熟的代码。
怎么进入 Plan 模式？ 它是 Claude Code 内置的运行模式，具体入口（快捷键或参数）随版本可能微调，以官方文档为准；但”只读规划 → 审计划 → 确认执行”的流程是稳定的。
👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。