企业官网建设流程全解析

带过的几个项目里，AI 编程助手换了一轮又一轮，最后留在工作流里的只有 Claud Code。不是因为它写代码快，而是因为它终于把"复杂任务"这件事处理得像个人了。尤其是它的Plan 模式，英文叫 Plan Mode，翻译过来就是"规划模式"：在真正动手改代码之前，先让模型把问题拆清楚、把步骤列出来、把风险标出来，给你一份可以审阅的计划，等你点头之后才进入执行。听起来很简单，但用过的都知道，这一层"前置规划"救回来的返工时间不是一点半点。

这篇文章我想围绕 Plan 模式展开，说清楚它解决什么问题、怎么进入、哪些任务该用、哪些任务别用，以及我在实际项目里用它的完整流程和踩过的坑。无论你是刚装好 Claude Code 想提高效率的新手，还是已经被它改代码改崩过几次的老用户，这篇都值得看一眼。

1. 先搞懂 Plan 模式到底在解决什么问题

1.1 没有规划时，Claude Code 最容易翻车的几个场景

先说几个真实翻车现场。我第一次用 Claude Code 重构一个项目里的用户认证模块，需求就一句话："把现有的 session 登录改成 JWT。"当时我正在普通模式下，心想这种任务 AI 不是分分钟搞定吗。结果它就真的直接开干了。改到一半，我发现它把工具函数、数据库模型、中间件全部动了一遍，而且新旧逻辑混在一起，代码里同时存在两套登录状态判断。测试跑不过，我又不敢让它继续修，因为上下文已经被改得乱七八糟，越修越乱。

这种问题不是孤例。多文件改动、跨模块依赖、老项目接手、批量替换逻辑，这些任务一旦让模型直接动手，它往往会在信息不足的情况下提前下判断。更糟的是，改错之后你再让它"接着改"，它会在错误的代码基础上继续叠，最终你不得不git checkout .重来。普通模式本质上是"边想边做"，它当然也会思考，只不过思考和执行是混在一起的，对于简单任务没问题，但对于复杂任务，这个节奏太快了。

1.2 Plan 模式和普通执行模式的核心区别

Plan 模式的核心区别可以浓缩成一句话：先给方案，再动代码。

普通模式下你提出需求，Claude Code 会直接开始读文件、写代码、跑命令，一气呵成。Plan 模式下你提出需求，它会先进入"规划阶段"，只读不改，输出一份计划文档给你看。这份计划通常包含它对你需求的理解、技术方案的拆解、分步执行步骤、涉及的文件清单，还有它识别出的风险点。

你看了计划，觉得哪里不对可以直接对话修改，计划改到你满意，再让它开始执行。相当于把"思考"和"执行"两个阶段强行拆开，让模型在动手前把所有信息都核实一遍。这个设计对复杂任务特别友好，因为 Claude Code 的能力再强，也还是会信息漏看、方向跑偏，而规划阶段就是专门用来兜住这些问题的。模型在规划时读过的文件、确认过的约束，会直接沉淀在执行阶段，执行时反而更稳。

1.3 Plan 模式的完整工作流是什么样

一个完整的 Plan 模式工作流大致是这样的：

1. 你输入需求，并处于 Plan 模式状态下。
2. Claude Code 先阅读你提到的文件，或者扫描项目结构，搞清楚现状。
3. 它输出一份规划文档，内容涵盖分析结论、实施步骤、风险与注意事项。
4. 你可以继续对话，对规划提出修改意见，让计划逐步收敛。
5. 你确认计划后，Claude Code 开始按步骤执行，并且每一步基本都在计划框架内推进。
6. 执行中如果出现计划外的问题，它会停下来向你汇报，而不是自作主张。

这个流程里最重要的一环其实是第 3 到第 5 步之间的"人审"。很多 AI 编程工具失败不是因为模型菜，而是因为"人审"环节被取消了。Plan 模式把人的判断重新拉回流程里，让模型在重大操作前先过一遍你的脑子。

2. 进入 Plan 模式的三种实用姿势

2.1 用 /plan 命令直接切换

最直接的方式是在 Claude Code 交互界面里输入/plan，回车。它会提示你当前已切换到规划模式，接下来你提出的需求都会先进入规划流程。等我用熟了之后，这个命令几乎成了我进入"复杂任务状态"的第一动作。

要注意的一点是，/plan是一个模式切换指令，不是一次性指令。也就是说，你输入一次之后，后续的多轮对话都会保持在规划模式下，直到你主动切回普通模式。这一点新手容易懵：我明明已经确认计划了，它怎么还在输出规划？因为模式没切回去。确认计划后如果它没有自动进入执行，你可以再输入一次/plan把它切回普通执行模式，或者看下当前模式指示。

2.2 用 Tab 键循环切换模式

Claude Code 交互界面里有一个比较隐蔽的入口：按 Tab 键可以循环切换工作模式。我用的版本里，常见的模式包括普通模式（normal）、自动接受编辑模式（auto-accept edits）、规划模式（plan）、跳跃式执行模式（skip-jumping）等。当你连续按 Tab 键时，输入框上面会有模式指示文字滚动变化，切到 Plan 时上面会明确显示 planning 或者 plan 之类的字样。

这个操作知道的人不多，但对日常流畅度帮助很大。我现在的肌肉记忆是：遇到复杂任务，先按一次 Tab，看看当前模式是不是 Plan，不是就再按几下切过去。不过不同版本的模式列表和顺序可能有差异，以你自己安装的版本界面为准，第一次用 Tab 的时候留意一下输入框顶部的提示条，别切过去了自己都没发现。

2.3 把 Plan 模式写进项目规范里

比手动切换更省事的方式，是在项目根目录的CLAUDE.md里写清楚：这个项目的哪些任务默认要用 Plan 模式。CLAUDE.md是 Claude Code 的项目记忆文件，每次对话启动时它都会读取里面的内容作为行为规范。

我一般会这样写：

## 工作方式 - 涉及 3 个及以上文件变更的任务，必须先使用 Plan 模式，规划确认后再执行。 - 涉及数据库结构变更或接口协议变更的任务，必须先使用 Plan 模式。 - 简单文案修改、单行 bug 修复、配置项调整，可以使用普通模式。

这样写的效果是，即使我某次忘了手动切模式，Claude Code 读到这些规则后也会主动建议"这个任务建议先用 Plan 模式规划"。真正把前置规划从个人习惯变成了项目级约束。

3. 什么任务值得交给 Plan 模式？我的选型判断

3.1 高价值场景：多文件重构、跨模块联调、需求落地

我用下来的经验是，这几类任务强烈建议使用 Plan 模式：

多文件重构。比如把整个模块从函数式风格改成类风格，或者把旧的错误处理逻辑统一替换成全局异常捕获。这类任务牵一发动全身，每一步都可能影响其他文件，非常需要先把改动边界画清楚。

跨模块联调。比如修改一个数据库表结构，顺便要改 ORM 模型、迁移脚本、查询接口、前端展示逻辑。Claude Code 如果直接动手，经常改到第三个文件就把前面几个文件的新逻辑给忘了，因为它们之间的依赖关系比模型上下文能容纳的信息更复杂。规划阶段它可以把每个文件的改动点和顺序列清楚，执行时才不会乱。

需求落地类。比如"给系统加上操作审计日志"，这不是单纯的写代码问题，还涉及要埋点哪些操作、日志存哪里、字段有哪些、是否需要异步写入、是否影响性能。Plan 模式下它会先跟你确认这些设计问题，而不是默认选一种方案埋头就干。

老项目接手。代码风格不熟、目录结构不熟、历史包袱重，这种场景下让 AI 先做规划等于逼它先读一遍代码再开口。它能避免很多"凭感觉改，结果和现有代码风格完全不搭"的问题。

3.2 低价值场景：单行修复、简单文案调整、纯格式化

也不是所有任务都值得走一遍规划。以下这些场景我用普通模式就够了：

单行 bug 修复，比如某个变量名拼错了、某个判断条件写反了，这种改完就能测的，没必要多一轮规划。文案修改，比如把按钮文字从"确认"改成"确定"，它改了也出不了大错。纯格式化、重命名一个局部变量、调整缩进，这种低风险操作走 Plan 模式反而浪费时间。

我在实际使用中总结了一个"三文件原则"：如果你预估这次改动涉及 3 个及以上文件，无脑用 Plan 模式；如果只涉及一两个文件而且改动点明确，普通模式直接跑就行。这个原则简单粗暴，但准确率很高，也不会让 Plan 模式的使用变得繁琐。

3.3 用一张表快速判断任务类型

这个表的判断逻辑其实很简单：风险越高的任务，越值得前置规划。规划本身不写代码，成本就是一次模型推理和一次人工审阅，几十秒的时间，但能省下的是几十分钟甚至几个小时的回滚和返工。

4. 实操过程：一次多文件重构的规划实录

4.1 规划前需要准备什么

很多人在 Plan 模式里翻车，不是因为模式不好用，而是因为需求没讲清楚。我建议在进入规划之前，先花 30 秒把下面几个信息准备好：

任务目标一句话说清。比如不是"优化这个模块"，而是"把用户模块的 password 校验从同步改为异步，并统一返回错误码格式"。涉及的范围明确一下。你可以直接说"相关文件在app/auth/目录下，不要动app/order/目录的内容"。边界和禁止项提前说。比如"不要修改数据库 schema""不要引入新的第三方依赖"，这些约束在规划阶段告诉它，比它执行到一半你再去喊停要有效得多。

我见过最典型的问题就是需求只有一句"优化性能"，然后 Claude 把缓存、索引、异步、算法全部改了一遍。不是它不能干，而是你没给它划边界。Plan 模式的规划质量，高度依赖你把需求描述成什么样子。

4.2 好的计划和坏的计划长什么样

一旦进入 Plan 模式，你提出需求后，Claude Code 会逐步读文件、出规划。这个规划的质量参差不齐，我见过的靠谱计划通常具备几个特征：

按阶段拆分，不是按文件拆分。好的计划会说：第一阶段梳理现有登录流程，确认 token 生成位置；第二阶段改认证中间件；第三阶段替换会话查询；第四阶段跑测试。而不是简单列一个"改文件A、改文件B"的清单。每步都有验收标准。好的计划每一步后面会标出"完成后验证 xxx 接口返回 401"这种可验证结果。有风险提示。好的计划会主动指出"注意这里旧 session 还有两处引用，需要在中间件中兼容处理"。

坏的计划则特征相反：直接给结论、没有过程分析；步骤之间跳跃太大；完全没有提及可能影响到的文件；把验证环节省略。碰到这种计划，千万不要直接确认，而是继续对话追问。我会在对话里直接说："这个计划太粗了，请把每个步骤涉及的函数名和文件路径列出来，并在每步后面加上验证方式。" Plan 模式的好处就在这里，计划不满意可以反复打磨，直到它变成一份你愿意签字的方案。

4.3 如何调整计划并确认执行

计划调整通常就是继续对话。你可以说"第三步和第四步顺序换一下""不要改utils.js里的公共函数""把冒烟测试加进最后一步"，Claude 会根据你的反馈重新输出修订后的计划。这个过程可能来回两三轮，但每一轮成本都很低，因为模型只是重新规划，没有写坏任何代码。

等计划满意了，就可以确认执行。在 Plan 模式下确认执行的方式各个版本略有不同，有的是直接输入 "确认按照计划执行"，有的是按快捷键批准。我习惯在确认时顺带加一句"完成每一步后简要汇报改动文件列表"，这样执行过程全程可追踪。确认之后，Claude Code 会按计划逐步实施，每一步的改动都对应规划里的节点，你在旁边能看到它没有跑偏。

4.4 中断与恢复的细节

Plan 模式执行中如果发现计划外情况，比如某个文件被外部工具改了、某个接口已经不存在了，它应该停下来汇报，而不是硬着头皮继续。如果它没停，你可以直接打断。我用的是 Esc 键中断当前操作，然后问它"现在做到第几步了？遇到什么问题了？"

中断之后想恢复执行也很简单，告诉它"继续执行计划，从第四步开始"。只要上下文还在，它就能接上。不过这里有个隐患：如果中途你执行了很多无关对话，上下文被挤占了，计划内容可能被遗忘。这时候可以再让它重新输出一遍当前计划的剩余部分，或者直接用/compact压缩上下文再继续。总之，确认一个核心习惯：在执行阶段，保持对话聚焦，不要夹带无关请求。

5. 常见问题与排查技巧实录

5.1 计划太粗或者太细，怎么调？

计划太粗是最常见的问题。它可能只写了"重构用户模块"四个字，然后就等着你确认。这时候不要含糊，明确要求它细化到文件级和函数级。我一般这样说："请把计划展开成 N 个步骤，每个步骤注明修改的文件、核心函数、改动目的，以及完成后的验证方法。"

计划太细也会发生，比如它把每个文件、每一行改动都列出来，计划比代码还长，审阅成本非常高。这种情况我会让它按"功能模块"聚合步骤，并限制步骤数量，比如"控制在 5 个步骤以内，每一步对应一个可测试的里程碑"。调计划就是在调模型的"工作节奏"，你给了明确坐标，它就不会走极端。

5.2 确认计划后没有自动执行怎么办

我遇到过一次比较迷惑的情况：计划出来了，我也说"确认"，但它还是停在规划状态，不肯动手。后来发现是模式没切回来。在 Plan 模式下，模型把输出计划当作当前唯一任务，确认之后它可能进入了等待下一步指令的状态，并没有自动切换执行模式。这时候的处理方式很简单：手动切回普通模式，或者直接补一句"现在开始执行第一个步骤"，明确告诉它进入执行阶段。这个机制在部分版本里会自动衔接，在部分版本里不会，是一个很容易让人误以为是 bug 的实际现象。

5.3 规划读到的代码不够准确怎么办

还有一种情况：Claude 在规划阶段输出的分析明显和你实际代码对不上，比如它说某个函数不存在，但你明明写过。这种问题通常不是它能力不够，而是它只读了你提到的文件，没读全相关代码。解决办法是主动把文件的完整路径塞给它，比如"请看app/services/OrderService.ts里的calculateTotal函数，规划时基于它的实际实现来写"。当你把相关文件路径喂够了，规划质量会立刻上一个台阶。

另外，如果你发现模型总是漏读文件，可以检查一下项目根目录有没有CLAUDE.md，以及里面有没有写清楚目录结构和关键模块的位置。这个文件相当于给模型的"工作简报"，写得好，规划阶段的读文件效率会高很多。

5.4 上下文太长导致规划被冲淡

复杂项目里跑 Plan 模式，最大的敌人是上下文长度。规划本身、你的人工反馈、执行过程日志，都会占用上下文窗口。如果项目上下文太大，可能出现一种现象：规划做得很完整，但执行到最后几步时，模型已经忘记了最初的约束条件。这个问题的缓解办法有几个：

及时压缩。执行到一半可以视情况输入/compact，让模型的对话历史被压缩成摘要，释放上下文空间。把关键约束写进CLAUDE.md，让它反复读取，而不是依赖对话里的临时记忆。分阶段执行。不要一次让计划里所有步骤全部跑完，而是让它跑完前两步，确认无误后再"继续执行剩余计划"，这样每一轮对话的上下文负担都会小很多。这个方法对我来说最实用，尤其碰到依赖关系复杂的重构。

5.5 个人踩坑记录：不要迷信计划本身

最后说一个我自己踩过的坑。有一段时间我过度信任 Plan 模式，以为有了计划就一定不会出问题。后来发现，计划只是"想清楚了"，执行还是会出幺蛾子，比如依赖版本冲突、环境变量缺失、外部服务连不上。Plan 模式降低的是"方向错误"的概率，不是"所有风险"的概率。所以我现在养成了一个习惯：计划确认后，按阶段验收，而不是全部跑完再看结果。每完成一个里程碑，我都会让 Claude Code 跑一下相关的测试或者手动验证一遍，确认无误再放行下一步。这样即使某个步骤执行坏了，我也知道是哪一步坏的，回滚成本极低。

6. 结合个人经验说点题外话

做复杂任务前置规划这件事，本质上是在与模型的不确定性对抗。Claude Code 的 Plan 模式给我最大的启发是：AI 编程的真正瓶颈不在写代码速度，而在纠错成本。代码写得快没用，改错之后排查、调试、回滚的时间才是真正的成本大头。Plan 模式把一部分错误在动工之前就拦截掉了，它不完美，但方向非常正确。

如果你刚开始接触 Claude Code，我的建议是强迫自己用一周的 Plan 模式，凡是觉得"这任务有点复杂"就切过去，哪怕多花一点时间。这周你会明显感受到两个变化：一是对模型行为的可控性大大提升，二是你的项目里突然多了很多"一次改对"的记录。等到你习惯了这种节奏，再回头用普通模式，你也会自然地更清楚哪些任务可以直接放手让它跑。

最后再分享一个实用小技巧：我经常在计划确认后，让 Claude Code 把计划摘要追加写入项目根目录的docs/plan-YYYYMMDD.md，当作当时的决策记录。这样既方便自己复盘，也给后续接手的人留了一份上下文。这种做法在团队协作里特别值钱，等于是让 AI 顺手帮你写了一份技术方案文档。