写Claude Code教程的人不少但专门把plan模式单独拎出来讲透的还真不多。我日常在终端里用Claude Code做开发尤其是接手那些别人留下的老项目时最怕的就是AI一上来就动手改代码——改得又快又自信结果方向错了返工成本比手工写还高。后来我把Claude Code切到plan模式让AI先按兵不动只读代码、出方案、列改动清单确认无误之后再切回执行让它动手。这一套先谋后动的打法直接把我的返工率降了一大截。这篇文章就专门拆Claude Code的plan模式它和默认执行模式的区别是什么怎么进入、怎么用、怎么配合第三方模型比如DeepSeek、Qwen、GLM这些用出效果以及我踩过的坑和排查经验。不管你是刚装好Claude Code的新手还是已经在VS Code、Ubuntu、macOS里跑了一段时间的老用户看完都能直接用起来。1. plan模式到底是什么为什么需要它1.1 Claude Code的手比脑子快问题Claude Code默认处在执行模式官方叫act模式也有人叫execute模式。在这个模式下你给的需求它会直接响应读文件、改代码、跑命令、甚至帮你提交git一气呵成。对熟练用户来说这确实爽但对很多人来说问题也出在这里——AI一旦理解偏了动手越快错得越远。特别是刚接一个复杂需求、还没理清楚项目结构的时候这种手比脑子快的鲁莽会带来很痛的结果。我自己的经历是有一次让Claude Code给一个老服务加个缓存逻辑它直接从入口Controller一路改到Mapper层改了十几个文件。结果我一看它把整个数据流都理解错了想要缓存的是热点数据它却给全量列表加了一层缓存。这种事故其实很常见因为AI的工作记忆有限项目越大越复杂它对需求上下文的理解就越容易跑偏。plan模式就是为了治这个毛病。它不是让Claude Code什么都不做而是让它切换到一个只读、只规划、不落地修改的工作状态。在这个模式下模型可以放心大胆地去翻代码、查依赖、读文档、分析影响面但就是不会碰你的实际文件。你要拿到的是一个清晰的、结构化的实施计划而不是一顿操作猛如虎后的烂摊子。1.2 plan模式和act模式的分工边界说得直白点plan模式负责纸上谈兵act模式负责真枪实弹。我自己习惯把这两者类比成画施工图和进工地干活的关系没有图纸直接砌墙十有八九要砸掉重来有了图纸再动工每一步都知道自己在干什么。在具体操作上两个模式的边界非常清楚操作类型plan模式act模式默认读取文件、搜索代码支持支持分析依赖、梳理调用链支持支持修改、新建文件禁止支持删除文件禁止支持执行终端命令只读类命令可执行全部可执行输出最终plan支持可选一开始有人觉得plan模式没用光说不做其实是你没在正确的场景用它。plan模式的价值不在于执行而在于把执行之前的所有不确定性摊到桌面上。它让AI先展示它对需求的理解、对代码结构的判断、对改动方案的取舍而你作为开发者可以在它动手之前把方向纠偏。这种模式特别适合解决复杂问题、重构任务、跨模块改造以及多人协作时需要对改动方案达成一致的场景。1.3 哪些场景最适合切到plan模式根据我自己的使用频率plan模式在下面几种场景下价值最大接手陌生项目刚拉下来的代码库先让AI在plan模式里跑一遍把它对项目结构、关键模块、技术栈的理解整理成文档比自己一行行翻代码快得多。跨模块需求评估一个功能改动涉及前端、后端、数据库多层改动时先让AI列出每层要改什么、会影响什么再决定要不要动工。重构与迁移重构最怕影响现有功能plan模式可以把改动面、风险点、兼容性方案先理清楚再动手。排查疑难Bug让AI先做根因分析定位到具体文件甚至具体行号再切回act模式修复效率远比直接让它看着办高。还有一个容易被忽略的场景当你通过第三方API接入不同模型时比如DeepSeek、Qwen、GLMplan模式尤其好用。这些模型没有官方Claude那样成熟的工具调用习惯直接放手让它改代码出问题的概率更大。先让它走plan模式输出方案你人工确认逻辑没问题再执行等于是给不熟悉的模型加了一道保险栓。2. 进入plan模式的前置准备与环境配置2.1 Claude Code的安装与版本前置条件要用plan模式首先你得有一个能跑起来的Claude Code环境。官方给出的安装方式很直接npm一行命令npm install -g anthropic-ai/claude-code安装之前建议先确认Node.js版本我实测下来Node.js 18以上比较稳低于这个版本有可能在启动时报错或者缺少依赖。装完以后运行一下claude --version能看到版本号说明安装成功。Claude Code的更新也走npm官方推荐用内置命令claude update进行升级升级逻辑会自动拉取最新稳定版并替换当前安装。我在项目里遇到过因为版本过老导致plan模式行为不一致的问题所以建议每次开工前先更新到最新版本。注意一点如果你是通过npx临时启动Claude Code那每次都会拉取最新包虽然方便但网络要求更高正式干活我还是推荐全局安装。在操作系统方面macOS和Linux原生支持得最好Windows环境下我建议配合WSL使用纯Windows的PowerShell终端里功能有缺失尤其是交互式模式切换的按键体验会差一些。2.2 登录方式、API Key与第三方模型接入Claude Code启动后两种主流认证方式一是用Anthropic账号登录在终端里走OAuth流程二是直接配置API Key适合走API计费或者使用第三方网关的场景。注册账号和不注册的体验差异很大登录账号可以直接使用订阅额度而不登录则有些功能会受限建议正规使用还是先完成账号绑定。这里额外多说一句热词里很多人问能不能不登录用其他模型答案是可以但要走API兼容层。具体来说Claude Code支持通过环境变量指向兼容的模型服务地址例如export ANTHROPIC_BASE_URLhttps://your-api-endpoint export ANTHROPIC_AUTH_TOKENyour-token配置好之后Claude Code会用这个端点替代默认的Anthropic API。很多人用这个办法接入DeepSeek、Qwen、GLM之类的国产模型配合cc switch这类工具可以一键切换多个模型端点。我自己的体会是模型切换完全可行但每个模型的plan能力差异很大有些模型在plan模式下给出的方案特别泛这时候需要你手动加强约束条件后面第三章我会专门讲约束怎么给。2.3 VS Code集成与其他编辑器接入用VS Code跑Claude Code也很常见。最简单的做法是直接在VS Code的集成终端里启动claude命令全键盘操作不用切窗口。官方还提供了编辑器插件可以在编辑器里直接唤起对话面板方便看到代码上下文。我个人的习惯是终端为主、面板为辅复杂项目用面板看代码对照纯命令操作直接终端更快。另一个热词里提到Claude Code桌面版我的看法是官方目前的主推形态仍然是CLI工具很多第三方封装了桌面界面但我建议优先用官方CLI加VS Code插件功能最全、升级最及时。等官方正式桌面版出来再迁移也不迟。另外无论用哪种编辑器强烈建议在项目根目录放一个CLAUDE.md文件。这个文件是Claude Code的项目记忆相当于给它看的团队Wiki。plan模式在执行分析时会优先读取这个文件里的项目说明、代码规范、模块边界等信息用来校准它的理解。我在一个中大型项目里写了300行的CLAUDE.md之后plan模式输出的方案质量肉眼可见地提升强烈推荐。2.4 进入plan模式的三种方式准备就绪后进入plan模式有三种方法任选其一在对话输入框里输入/plan回车后立即切换到plan模式。这是最直观的方式也方便在输入过程中随时切换。按Tab键循环切换模式。Claude Code默认在execute、plan等模式之间循环每按一次Tab命令行提示符的状态指示会跟着变化。按ShiftTab反向循环切回之前的模式。切换之后注意看终端UI的状态指示区它会明确显示当前模式。我建议刚开始用的时候每次切换都瞄一眼状态避免自己以为在plan模式其实还在act模式结果AI又直接动了手。还有一个实用命令/status可以查看当前会话的模式、模型和上下文占用情况排查问题时非常有帮助。3. plan模式的完整实操流程与核心技巧3.1 一个标准需求怎么在plan模式下走通以我最近做一个给工单系统加自动提醒的功能为例完整走一遍plan模式的工作流。第一步先切到plan模式然后我把需求和约束一次性讲清楚我想给工单系统加一个自动提醒功能当工单超过24小时未处理时自动通知负责人超过48小时未处理自动升级通知到主管。请在不动现有业务流程的前提下给出一个最小改动方案。注意不能改动数据库表结构通知渠道用现有的站内信和邮件不要引入新的消息队列。这一步的关键是把边界划清楚。我没说帮我加个提醒功能就完事而是给了触发条件、升级规则、硬性约束不改表、不加MQAI在plan模式下就会沿着这些边界去做代码调研和方案设计而不是天马行空地给你设计一套分布式任务调度。第二步它会开始翻代码。plan模式下你会看到它的工具调用基本都是读操作比如搜索文件、读取代码、分析路由配置等。这个过程可能会持续几分钟取决于项目大小耐心等它把上下文收集够。第三步AI会输出一份结构化的plan通常包含需求理解、涉及的现有模块、改动文件清单、每个文件的具体改动点、依赖关系、风险提示。这份plan就是我前面说的施工图。第四步我把plan里的关键决策和实际代码逻辑对照检查一遍发现它有一步说要改工单状态机的代码但我清楚这块代码特别脆弱稍有不慎会影响自动关闭流程。于是我在plan里追加了一条约束状态机这部分只能加旁路逻辑不允许改主流程。AI会根据我的反馈调整plan把改动收敛到监听事件的地方。第五步确认plan没问题后按Tab切回act模式让AI按plan逐项执行。这样整个执行过程有据可依每改一步你都知道它在干嘛。3.2 给AI画边界的三个关键参数很多人在plan模式里走不通根源不在于AI笨而在于给的约束太少。我总结了一套给约束的模板每次写需求的时候都会把这几项填满成功标准告诉AI做到什么程度算完成。比如新逻辑不影响现有工单自动关闭流程24小时提醒只在工作日生效。禁区列表明确哪些不能碰。比如不要修改数据库结构不要动第三方支付模块不使用新增依赖。验收方式让AI在plan里写清楚准备怎么自测。比如通过单元测试覆盖提醒触发条件提供手工测试脚本。这三项填得越具体plan模式的输出就越接近可执行状态。我见过很多人抱怨AI给的方案太抽象其实多半是需求本身太抽象。你把成功标准写明白了它自然知道该往哪个方向细化。3.3 plan模式与第三方模型配合的实用技巧聊回第三方模型接入。用cc switch这类工具切换模型后plan模式的行为会有明显不同。官方Claude模型的规划能力最强尤其擅长在大型代码库里做多文件影响分析DeepSeek、Qwen这些模型代码能力也够用但在plan模式下表现的主动调研意识会弱一些它可能不翻代码就急着给方案。针对这个问题我的经验是换模型后进入plan模式前先给一条强制指令比如在给出plan之前必须先读取项目目录结构和相关模块代码并在plan里列出你实际读取过的文件清单。这一条能有效逼着模型先做事前分析。另外第三方模型的上下文窗口和官方模型不同对于大型项目建议在plan模式里先手动指定分析路径缩小检索范围比如只需要分析modules/ticket和notify这两个目录避免它在整个仓库里大海捞针浪费上下文还输出一堆废话。3.4 plan模式的产物如何留存与迭代plan模式产出的方案别用完就丢。我的做法是把重要的plan粘贴到项目的docs/plans/目录下文件名按日期加功能命名比如2025-06-10-ticket-reminder.md。这么做有三个好处第一执行过程中如果发现偏差可以随时回头对照原始plan看是执行走样还是plan本身就有问题。第二上线之后如果出了Bug翻一下当时的plan能快速回忆起设计意图和改动范围。第三后续类似需求可以直接拿历史plan当模板AI在plan模式下给出的结构化方案比人从零写要省力得多。我还会在plan执行完后追加一段实际执行结果与计划差异的备注。时间久了这套文档就是你和AI协作的经验库。这也是我博客系列里强调的工作流思想工具会变、模型会变但先规划、再执行、留记录的方法论不会过时。4. 高频问题与排查实录4.1 plan模式下光说不做是出Bug了吗这是我被问得最多的问题。很多新手刚切到plan模式发了个需求结果AI长篇大论写了一堆计划就是不碰代码于是以为工具卡了或者坏了。这不是故障是设计。plan模式的核心定位就是纸面工作它不修改任何文件你可以把它的输出当成一份可执行的设计文档。等你看完plan、确认无误再切回默认的act模式它才会按计划动手。想明白这个分工你就不会困惑了。判断标准很简单状态栏显示plan模式时它说我想修改XX文件是正常的状态栏显示act模式时它还在磨磨唧唧不干活那才是需要排查的问题。后者通常是因为需求不清导致AI不敢动手这时候补充约束条件、缩小任务范围往往比直接催它更有效。4.2 切换模式失效或快捷键冲突怎么办我在一些终端环境里遇到过Tab键切不过去的情况。排查思路先确认你的终端是否把Tab键拦截了。比如某些终端插件会把Tab绑定给补全功能Claude Code就接收不到切换指令。此时改用/plan命令切换或者检查终端快捷键配置。另一个常见问题是模式切换后UI状态没变化。我建议用/status确认当前模式如果显示和预期不符直接输入/plan强制切换再不行就退出会话重新开一个。这些问题绝大多数是终端环境导致的与Claude Code本身关系不大。4.3 计划太泛没有可落地的执行步骤如果你的plan输出像是综述文章列了一堆了解需求、设计架构、编码实现、单元测试这种套话那就是约束给少了。我在3.2节里提到的三个关键参数——成功标准、禁区列表、验收方式——就是治这个病的药。另外你可以直接要求AI按固定格式输出plan我会用这样的句式请把方案按以下结构输出 1. 需求理解摘要50字内 2. 现有代码影响面分析必须列出具体文件和关键函数 3. 改动步骤按依赖顺序排列每步标注涉及文件和改动内容 4. 风险与验证方案 5. 不涉及范围说明强制格式是有效的手段因为Claude Code这类大模型很吃输出格式约束这一套给定了结构之后它反而能发挥得更好。4.4 第三方模型接入后plan质量下降热词里很多人用cc switch接入DeepSeek、Qwen、GLM后发现plan模式输出的方案没有官方模型细致有时还会出现凭空捏造文件路径的情况。这确实是模型能力差异导致的。应对措施我试下来比较有效的是两条一是给模型提供更多锚点比如在plan模式里明确告诉它以src/api/ticket.js为入口分析工单模块锚点越多模型越不容易跑飞二是降低单次plan的复杂度把一个大需求拆成多个子任务每次只规划一小块质量会明显提升。这和带新人是一个道理你让新人一口气设计整个系统他多半给你画大饼你让他先设计一个接口他就能给出靠谱的细节。4.5 计划与实际执行结果不一致有时候plan阶段说得好好的切到act模式执行完发现代码改动和plan对不上比如plan说要改A文件结果执行时动了B文件。这种情况往往有三个原因。第一plan模式读取代码时依赖的上下文已经过期比如另一个开发者在执行前改了代码。第二act模式下模型对plan的理解出现偏差尤其当plan文本很长时模型可能遗漏细节。第三自己手动改动过代码没有同步给AI。对应的排查方法是执行前先用/compact或者新开会话确保上下文是新鲜的执行后逐文件核对git diff和plan里的文件清单对照。如果差异较大不要硬改直接回退本次改动重新在plan模式下修订方案再执行。宁可慢一点别把不确定的改动带上线。4.6 长任务与上下文超限plan模式的输出本身已经很占上下文了如果一个项目的规划加上执行放在同一个会话里很容易触发上下文超限尤其是接入上下文窗口较小的第三方模型时。表现是AI开始忘记最初的plan内容或者回答质量断崖式下降。我的解决方案是plan和执行严格分会话。plan阶段确认满意后把这个plan的关键要点写到一个临时文件里比如docs/plans/current-plan.md然后结束当前会话新开会话后让AI读取这个文件再开始执行。这样既保留了plan的核心信息又不会因为历史对话太多而挤占执行时的上下文空间。5. 写在最后的几句实在话接触plan模式这段时间我最大的感受是它改变的不仅是Claude Code的使用方式更是我和AI协作时的心态。以前我总想着让AI快点干活出了错再修结果很多时候修比写还累。现在我会先花几分钟让AI把方案摊开看一眼改动范围发现问题当场纠正整个过程反而更快。如果你刚接触Claude Code我建议你把plan模式当成默认工作流接需求先进plan方案确认后再切act。等你熟练了、对项目的掌控力增强了可以再根据具体情况灵活跳过一些规划步骤——但至少在重构、跨模块改动、接手新项目这三个场景里plan模式值得你每次都打开。这套先谋后动的习惯配合CLAUDE.md项目记忆和plan文档留存慢慢你就会发现AI写代码的返工率真的可以降得很低。