企业官网建设流程全解析

写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模式"没用，光说不做"，其实是你没在正确的场景用它。plan模式的价值不在于执行，而在于把执行之前的所有不确定性摊到桌面上。它让AI先展示它对需求的理解、对代码结构的判断、对改动方案的取舍，而你作为开发者，可以在它动手之前把方向纠偏。这种模式特别适合解决复杂问题、重构任务、跨模块改造，以及多人协作时需要对改动方案达成一致的场景。

1.3 哪些场景最适合切到plan模式

根据我自己的使用频率，plan模式在下面几种场景下价值最大：

• 接手陌生项目：刚拉下来的代码库，先让AI在plan模式里跑一遍，把它对项目结构、关键模块、技术栈的理解整理成文档，比自己一行行翻代码快得多。
• 跨模块需求评估：一个功能改动涉及前端、后端、数据库多层改动时，先让AI列出每层要改什么、会影响什么，再决定要不要动工。
• 重构与迁移：重构最怕影响现有功能，plan模式可以把改动面、风险点、兼容性方案先理清楚，再动手。
• 排查疑难Bug：让AI先做根因分析，定位到具体文件甚至具体行号，再切回act模式修复，效率远比直接让它"看着办"高。

还有一个容易被忽略的场景：当你通过第三方API接入不同模型时（比如DeepSeek、Qwen、GLM），plan模式尤其好用。这些模型没有官方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_URL=https://your-api-endpoint export ANTHROPIC_AUTH_TOKEN=your-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，命令行提示符的状态指示会跟着变化。
• 按Shift+Tab反向循环，切回之前的模式。

切换之后注意看终端UI的状态指示区，它会明确显示当前模式。我建议刚开始用的时候，每次切换都瞄一眼状态，避免自己以为在plan模式，其实还在act模式，结果AI又直接动了手。

还有一个实用命令：/status，可以查看当前会话的模式、模型和上下文占用情况，排查问题时非常有帮助。

3. plan模式的完整实操流程与核心技巧

3.1 一个标准需求怎么在plan模式下走通

以我最近做一个"给工单系统加自动提醒"的功能为例，完整走一遍plan模式的工作流。

第一步，先切到plan模式，然后我把需求和约束一次性讲清楚：

我想给工单系统加一个自动提醒功能：当工单超过24小时未处理时，自动通知负责人；超过48小时未处理，自动升级通知到主管。请在不动现有业务流程的前提下，给出一个最小改动方案。注意：不能改动数据库表结构，通知渠道用现有的站内信和邮件，不要引入新的消息队列。

这一步的关键是把边界划清楚。我没说"帮我加个提醒功能"就完事，而是给了触发条件、升级规则、硬性约束（不改表、不加MQ），AI在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写代码的返工率真的可以降得很低。