1. plan模式到底是什么先说个场景你是不是也有过这种体验Claude Code 一接到任务就闷头改代码改完了你一看 diff它在不该动的地方动了一堆甚至在重构一个函数时顺手把另一个模块的变量名也改了。如果只是小工程还好项目一复杂这种“一腔热血直接动手”的风格很容易让代码库变得一团糟。我自己第一次意识到 plan 模式的价值是在一次对遗留模块做重构的时候。当时我让 Claude 直接执行“把支付模块的订单状态机抽成独立服务”结果它三分钟就把活干完了但我 review 代码时发现它为了完成任务把原本一个很清晰的策略模式改成了一个大 if-else还把日志格式也悄悄改了。功能没坏但代码风格和可维护性全部退化了那个 diff 看下来脑壳疼。这就是 plan 模式要解决的问题它把“想清楚再动手”变成了一道强制流程。在 plan 模式下Claude Code 只负责读代码、分析现状、研究方案、给出实施计划不会改任何文件不会执行任何可能产生副作用的命令。它先给你一份“施工图纸”你验收图纸没问题再让它切换到执行模式去动手。如果你是刚接触 Claude Code 的新手plan 模式是你最容易上头也最容易忽略的一个功能如果你已经用了一阵子但发现 Claude 经常“我行我素”那大概率是你没用 plan 模式来约束它的行为边界。这篇文章是我中英文系列教程里专门讲 plan 模式的一篇我会把它的使用场景、实操细节、踩坑经验一次说透。1.1 它和默认执行模式的本质区别Claude Code 默认打开之后你给它一个任务它默认会直接尝试完成任务读文件、写文件、跑命令一条龙。这很像你雇了一个行动力很强的实习生你说“把会议室整理一下”他不仅整理了会议室还顺手把茶水间的杯子也洗了顺便帮你把下周的会议都排好了——精神可嘉但未必是你想要的。plan 模式则把这个过程劈成两半对比维度默认执行模式plan 模式文件修改会读写修改代码和配置只读绝不写文件命令执行会执行测试、构建、脚本不执行有副作用的命令输出结果直接给出改完的代码输出分析、方案、步骤、风险提示适用场景需求明确、改动范围小需求复杂、改动范围大、存在多种实现路线的任务风险等级中到高低核心风险前置到计划阶段这里最核心的一句话plan 模式不是慢而是把思考过程显性化了。它不是限制 Claude 的能力而是让 Claude 在动手前先给你看到它脑子里在想什么你可以在它想偏之前及时叫停。1.2 为什么你需要一个“强制画图纸”的阶段很多人觉得“直接让它干不是更快吗”但如果任务复杂度上来了直接干往往意味着你要花更多时间去 review 和返工。我自己现在处理多文件改动、架构调整、依赖升级这类高影响任务时都强制先用 plan 模式。有个很现实的理由计划阶段修改的成本极低执行阶段修改的成本极高。让 Claude 多读一遍代码、多说一段分析成本只是几十秒但如果你让它直接写写歪了再重构轻则多花十分钟改重则在线上留一个隐蔽 bug。这就像你装修房子改图纸只需要动动笔墙砌错了再拆人工和材料都要重新花一遍。还有一层价值是审计和知识沉淀。plan 模式产出的那份计划天然就是一份设计文档。你可以把它保存下来当任务说明书用也可以贴在 pull request 描述里告诉 reviewer“这次改动为什么是这样的路线”。Claude 的思考过程不要让它只存在于对话流的角落里。2. 三种方式进入 plan 模式很多新用户有一个误解以为 plan 模式需要什么特殊开关其实 Claude Code 给它设计得非常轻量。进入 plan 模式有三种姿势每一钟适用的场景不太一样我按推荐程度给你排一排。2.1 启动时直接声明最稳的推荐姿势在终端里启动 Claude Code 时直接带上参数这是最不容易搞混的方式claude --mode plan这种方式的优点是一目了然Claude 从第一句对话起就处于“只读规划”心态不会出现“我嘴上说 plan 结果它手下留不住”的尴尬。适合你明确知道当前任务是需要先出方案的场景比如“评估一下我们这个项目的模块依赖边界”“梳理一下缓存层改造的影响面”。2.2 会话中用斜杠命令切换临时切角色的好办法如果你已经开了一个普通会话聊着聊着发现任务比预想复杂这时候不用退出重开直接在对话框输入/planClaude Code 就会把当前会话切到 plan 模式。切过去之后你前面聊过的上下文会完整保留它已经读过的文件、已经了解的背景都还在不会失忆。这一点非常关键——很多 CLI 工具切换模式时会把上下文弄丢Claude Code 在这一块做得比较自然。我常用的一个操作方式是这样的先用默认模式让 Claude 快速扫一眼代码库找到相关文件聊到具体方案时直接切 plan 模式让它收敛出一版正式计划。这样“探索阶段用默认模式规划阶段切 plan 模式”效率比一上来就 plan 要高。2.3 在当前目录下配置默认启动行为一劳永逸如果你希望这个项目目录下的 Claude Code 每次都自动进入 plan 模式可以在项目配置文件里设置默认行为{ defaultMode: plan }放在项目的.claude/settings.json里团队所有成员在 clone 这个仓库后都会默认以 plan 模式进入。适合对代码变更管控要求比较严格的团队或者你正在维护一个自己不熟悉的核心模块不希望 Claude 一上来就乱动。这三个方式之间没有任何冲突/plan命令是运行时切换启动参数是入口限定配置文件是默认值优先级大致是“会话内切换 启动参数 配置文件”。我建议你日常先记熟/plan这个命令因为它最灵活剩下的按需使用。2.4 怎么判断自己已经在 plan 模式里了识别是否生效有个非常直接的办法你让它修改代码它不会改而是给你一份计划或提示“这只是一个计划需要你确认后才执行”。熟悉的朋友还会注意到消息输出的格式有明显差异——plan 模式下的回复更结构化会围绕目标拆步骤甚至有明确的“接下来如果你同意我会按这个顺序执行”的引导。另外你可以在会话中输入/status查看当前状态一些配置项也会标识当前模式。不过那个信息比较隐晦我建议新手不要依赖状态查询直接用行为来判断给一个明确的小指令比如“帮我把 README.md 里的项目名改成 X”如果它没改而是告诉你“查找了几个引用位置计划修改 3 个文件请确认”那这个 plan 模式就是稳稳地生效了。3. 一个高质量的 plan 是怎么产出的进入 plan 模式只是起点真正决定任务成败的是拿到的那份 plan 质量。我在实际使用中琢磨出的结论是Claude 的 plan 水平很大程度取决于你喂给它的信息结构。不要甩一句“帮我重构这个模块”就干等你需要掌握怎么把任务描述成 Claude 能规划的样子。3.1 写 prompt 时给全四个要素以一个真实任务为例我需要让 Claude 把项目里一个 Python 定时任务脚本的配置方式从“环境变量”改成“配置文件”。这是我的描述方式先给出任务背景和现状包括项目技术栈是 Python Click当前配置项有哪些脚本入口在哪里再说约束条件包括“不能改动已有环境变量的兼容路径”“配置文件必须支持热加载吗——不需要重启生效即可”“配置文件的格式偏好是 YAML”然后给明确验收标准包括“旧的读取函数要保留但标记废弃”“测试用例要同步更新”“最终产出需要包含迁移说明”最后指定计划重点关注的风险点比如“任务调度系统对启动参数的依赖”。这四块信息给全了Claude 产出的 plan 就会非常有血有肉。它通常会给出一份包含“当前现状分析”“改动文件清单及原因”“具体实施步骤”“风险与兼容性处理”“测试方案”这些章节的完整计划。3.2 plan 输出里哪些部分要严格把关拿到计划之后很多人第一步就是扫一眼“看起来挺专业”然后直接说“执行”。但你至少要花五分钟做一次“计划评审”重点看三个地方第一个是文件清单是否超范围。它列出来的改动文件是否都是必要的如果它列出了三个老祖宗模块你要追问一句“为什么要动这两个文件有没有不动它们的方案”。第二个是步骤顺序是否合理。好的 plan 会按照“先加配置解析层再替换调用点最后迁移部署配置”的顺序推进而不是先删旧代码再写新的——那种顺序几乎是等着项目跑不起来。第三个是风险提示有没有落到执行层面。比如它说“配置文件不存在时需要提供默认值”这就是可执行的风险处理如果它写的是“需要注意兼容性”这种空话那就等于什么都没说你可以直接要求它把风险写具体。我习惯在评审后追加一句“计划确认逐步骤执行每完成一个阶段停下来汇报。”这样 Claude 在后面的执行阶段会完成一步就汇报一次进度你可以随时叫停而不是一股脑跑完再给你看结果。3.3 从 plan 到执行的衔接技巧plan 模式确认了计划之后接下来怎么让 Claude 动手常见做法是直接说“开始执行”或“按计划执行”。Claude Code 会从对话中识别你已确认计划切换回执行状态然后逐步实施。这里有个我强烈建议的细节在确认计划时亲手把计划中列出的步骤复述一遍并明确标注出步骤编号。例如“按你列出的步骤 1、2、3 执行。步骤 1 完成后先停下给我看关键文件的变化再继续步骤 2。”这样做的好处是Claude 会严格沿着那套已经确认过的路线走不太会出现“换了一种实现方式”的滑动跑偏。我自己踩过无数次“计划很好执行跑偏”的坑都是从这一步开始预防的。另外一个小经验是计划确认后如果需要暂时离开电脑最好先把输出保存一下。直接把 Claude 的 plan 复制到一个 markdown 文件里或者用 echo 命令存到指定目录比如存成docs/plan_20250610.md。这不仅便于你回来接手也能让后续执行阶段的参考对象更明确你可以说“按照 docs/plan_20250610.md 的计划执行”比在长对话流里回翻聊天记录高效得多。3.4 一个完整案例用 plan 模式整理日志模块为了让你直观感受真实产出我再展示一个比较完整的案例。我有一次要让 Claude 把一个项目里散落着十几个print()和logging混用的模块统一收敛成统一的structlog体系。在 plan 模式下我给的描述是“项目根目录是 src/app当前日志输出方式非常混乱print 和 logging 混用日志格式也不统一。约束不能改动核心业务逻辑新日志统一使用 structlog 的 JSON 格式测试模块内的 print 不影响运行时可不动。验收项目里所有业务代码的 print 日志全部清理干净structlog 初始化统一在入口模块完成所有 logger 命名统一为 logger structlog.get_logger(name)。”Claude 给出来的计划大致长这样先盘点所有使用 print/logging 的位置列出文件清单设计统一的 structlog 初始化配置方案放在入口函数和 config 模块逐个模块替换日志调用同时标注每处替换的改动点针对工具类和测试代码的特殊情况说明不动的原因最后给出自测方法包括怎么快速验证输出格式。整个计划逻辑通顺风险点也想到位。我特别注意到了一个细节它把“print 在脚本里作为用户输出时可保留”和“print 作为日志行为时必须替换”分开处理了。这就是 plan 模式的价值——在动手之前先把这些边界划清楚避免执行阶段一刀切。这份计划我保存下来以后执行阶段基本不用操心节奏完全可控。4. 我用 plan 模式踩过的坑用了小半年plan 模式给我解决了很多问题但也踩出了一些反模式。这里把它们一条条列出来都是真实发生过的希望你绕着走。4.1 最容易出现的“计划与执行脱节”问题计划写得挺好一执行就变样。印象最深的是有一次 Claude 在 plan 里明确说“采用装饰器方式实现中间件”结果执行到一半它换成了一段手动调用逻辑。我从汇报里发现时已经改了一部分只能让它退回去重来。后来我养成了确认计划时一并确认“实现路径细节”的习惯。你可以在 plan 审评阶段多问一个关键问题“你打算用的具体实现方式是哪种是装饰器、上下文管理器、还是回调函数”这样它执行时会更稳定地契合格。4.2 plan 模式不是万能挡箭牌它也会漏读文件有些新用户以为切到 plan 模式 Claude 就会把所有相关代码都看一遍其实不然。它同样受上下文窗口和扫描深度限制在大型代码库里也可能漏掉相关模块。我的经验是plan 模式产出方案前先明确要求它搜索相关文件并列出检索到的关键文件清单。如果清单里缺少了你心里清楚必须涉及的文件当场指出来要求补充这比在它给出计划后再质疑要高效。一句话你永远是最终负责人plan 只是辅助不是担保。4.3 别让开放式任务进入 plan 模式plan 模式最怕“目标大而空”。“帮我优化性能”“梳理一下代码结构”这类任务如果你只给这么一句话Claude 能给出一份看似面面俱到、实际上没有一个可执行重点的计划整份计划基本都是恭维和废话。你需要做“约束收敛”给范围、给边界、给不可逾越的红线。比如“只针对登录接口做性能优化目标是把 P95 延迟降 40%不要改动数据库表结构优先考虑缓存层和 SQL 查询”。范围一旦收敛plan 质量立刻提升一个层级。4.4 长会话中 plan 模式会积累冗余上下文这是我在实际使用中一个体会比较深的点一个会话如果在 plan 模式下聊了二三十轮上下文里会堆积大量“分析、对比、替代方案”的过程性内容。如果你反复切换执行和 plan这些过程性内容都会堆在上下文里既占空间又可能干扰后续决策。所以我现在养成了一个习惯一次会话只做一次“计划 执行”的闭环。如果任务是先讨论两三个备选方案再动手我会先让 Claude 用 plan 模式输出备选方案对比选定方案之后复制关键结论到一个新会话里继续避免旧上下文污染新的执行判断。如果你的任务很大需要用多个 plan 来回踢皮球那就整理出一份核心决策文件让它对照文件推进而不是在对话流里打转。4.5 第三方模型接入后的 plan 表现差异很多朋友会用 cc switch 之类的工具把 Claude Code 接上 DeepSeek、Qwen、GLM 等第三方模型。我要提醒的是不同模型在 plan 模式下的“规划能力”差异很大。有的模型在 plan 模式下表现得很像一个资深架构师但有的模型只是把需求复述一遍再列几个步骤深度不够。我个人的经验是接入第三方模型后plan 模式更要发挥“人工评审”这道关卡的作用。第三方模型的计划往往更需要你去追问细节、指出遗漏。不预设它一定会产出高质量方案更不要因为模型不会改文件就掉以轻心。这就好比你带着一个刚转行的实习生看现场你让他先说方案但他对建筑规范不熟你听完必须自己去核对承重墙位置一个道理。常见问题典型表现我的解法计划过大一份计划列了十几个文件执行要一小时拆成多个小计划一个会话只做一个阶段计划过浅步骤只有“修改 A 文件、修改 B 文件”追加追问“为什么改这些文件、替代路径有哪些”计划过空全是框架没有实现细节要求补充具体的实现路径、需要处理的边界场景计划过时基于早期代码现状和最新代码不一致先要求它重新读一遍关键文件再出新计划切换失效说了“恢复执行”它还是只出计划直接补一句“执行模式开始改代码”并确认状态5. 进阶玩法把 plan 模式和工作流组合起来到了这个阶段plan 模式对你来说已经不是“要不要用”的问题而是“怎么用得更好”的问题。下面这几个组合玩法是我目前在真实项目里高强度使用的策略分享给你参考。5.1 先计划、后分支、再按序执行我现在有一个比较固定的工作流特别是处理跨模块多文件的改造时第一步在默认模式下大概摸清楚代码库结构让 Claude 找出涉及的模块第二步切 plan 模式产出完整实施计划确认文件清单第三步让 Claude 建一个特性分支第四步回到执行模式按照计划阶段编号逐步落地每个步骤完成就停下看一次 diff。这套流程下来基本没有出现过“改完了但不知道改了什么”的情况而且演进过程里每个阶段的改动都在版本控制里清晰可查。核心逻辑是计划阶段不改代码执行阶段不意外发挥验收阶段有据可依。这也让我能放心把一些中型重构任务交给 Claude因为我在计划阶段已经看过了它的“施工图”。5.2 用 plan 模式做“Code Review 前置模拟”plan 模式还有个不那么显而易见的用途拿它当评审工具。比如我要 review 同事的改动但不太确定他的实现思路是否合理可以把相关代码带着上下文丢给 plan 模式让它“分析这个改动方案的潜在问题并给出一个替代方案”。这种用法并不是让 Claude 真去改代码而是让它输出分析和对比帮你快速建立对方案的判断框架。特别是牵扯到数据库迁移、第三方服务替换等高影响事项时plan 模式的“只动嘴不动手”属性让它天然适合做这种推演工作。5.3 中英文提示词对 plan 质量的影响标题里写了“中英文系列教程”关于提示词语言对 plan 质量的影响我可以直接说结论中文描述和英文描述都能产出高质量 plan但混搭术语时容易出问题。比如项目里混用了英文注释你在中文提示词里突然插一句英文的私有方法名Claude 基本也能理解。但在要求产出计划文档时如果你让它用英文生成计划文本有时候反而更结构化因为英文的“TODO”“Implementation Steps”这类表达在代码社区天然更紧凑。我的习惯是对话用中文要求输出计划正文时可以试英文看哪个更符合你的阅读习惯。没有绝对的好坏只有适配问题。5.4 和 cc switch 第三方 API 组合时的适配技巧最后说下第三方模型的适配技巧。如果你像我一样用 cc switch 接入 DeepSeek 或 Qwen 这类模型你会发现各家的系统提示词能力不同有的模型在“只读分析”场景下表现很好但指令遵循能力偏弱。此时我一般会在提示词里显式强调约束“请只输出分析计划不要修改任何文件不要执行任何命令。”这类第三方模型下plan 模式的护栏作用很大程度上靠 prompt 兜底。好消息是不管底层模型是谁只要你跑在 plan 模式里Claude Code 这个工具本身会限制文件写入和命令执行所以安全边界还是存在的只是计划内容质量需要你把关。6. 最后再分享一个实用技巧如果你看完这篇教程只记住一个操作那我推荐你记住这个把每一次 plan 输出保存成一个任务清单文件。我现在的习惯是在每次 plan 模式和 Claude 确认完方案之后让它先不要急着执行而是把计划的核心步骤写入项目的tasks/目录每个步骤一行后面留一个空复选框。比如它会生成类似这样的清单# 日志统一改造计划 - [ ] 步骤1盘点现有 print/logging 使用位置 - [ ] 步骤2在入口模块初始化 structlog JSON 配置 - [ ] 步骤3逐个模块替换日志调用 - [ ] 步骤4执行测试并确认输出格式这个文件既是执行的路线图也是验收的核对表。Claude 在执行时可以“对照清单推进”每完成一项就把方框勾上你随时打开文件就能看到任务进度。这个习惯让我在参与多任务并行时对每个任务的推进情况都了如指掌不用靠记忆和感觉。我个人在实际使用中最大的一个体会是plan 模式改变的不只是 Claude 的行为更重要的是改变了我的工作方式。以前我催着 AI 快点出活现在我习惯了先逼自己把需求想清楚再让 AI 按图施工。哪怕有些小需求我明知道十分钟就能搞完也会习惯性地在脑子里过一遍范围、约束和验收标准。这个习惯带来的效率提升比工具本身都大。希望这篇教程对你也有同样的价值。