Plan First 原则

Plan First 原则

社区高手复盘里有一句话被反复引用：

Plan First 是高手与菜鸟的分水岭。

不是用得更贵的订阅、不是 prompt 写得更花哨，而是动手之前先想清楚。这一篇讲透为什么先 plan、怎么 plan、以及什么时候反而不用 plan。

官方四阶段：Explore → Plan → Implement → Commit

Claude Code 官方 best-practices 里把一次任务的标准流程画成四阶段：

1. Explore（探索）——Plan 模式下读文件、摸清现状，不动手。
2. Plan（规划）——制定实现计划：做什么、怎么拆、先做哪块。
3. Implement（实施）——切出 Plan 模式，真正动手改代码。
4. Commit（提交）——提交 + 开 PR。

前两步都在「想」，第三步才开始「做」。顺序不能反——一上来就 Implement，等于没看地图就开车。

低阶 vs 高阶 prompt

高手复盘里有个对比，直接戳中要害。

低阶 prompt：

帮我实现一个 OAuth2 刷新令牌的功能。

Claude 收到这种指令，会立刻开始写——但它对项目一无所知，只能按通用模式硬写，写完多半对不上你项目的约定。

高阶 prompt：

Think step by step. Outline a detailed plan before writing any code.

加一句话，行为完全不同。Claude 会先停下来，把方案列出来：要改哪些文件、边界情况有哪些、风险在哪、按什么顺序做。你审完方案再让它动手。

这中间的差距，就是「先想后做」。低阶是「指令执行」思维——给个目标，让它冲；高阶是「先对齐再干」思维——先在方案层面达成一致，再写代码。

一份合格的 Plan 应该有什么

不是随便列两句「我打算这么做」就叫 plan。高手的 plan 输出通常包含四块：

要素	内容	防的是什么
功能拆解	把大功能拆成可独立交付的小块	一把梭，无法审查
边界情况	空输入、超时、并发、权限边界	happy path 主义，上线踩雷
风险点	可能影响范围、不确定的依赖、容易错的地方	改完才发现动到别人
实现顺序	先做哪块、哪块依赖哪块	顺序错，来回返工

举个真实的 plan 长这样：

## 实现 token 自动刷新

### 功能拆解
1. 新增 refreshToken() 工具函数
2. 在 HTTP 拦截器里挂上 401 自动刷新
3. 并发请求去重（同一时刻只刷一次）

### 边界情况
- refresh token 也过期 → 跳登录页
- 多个请求同时 401 → 只触发一次刷新
- 刷新期间新请求 → 排队等刷新完成

### 风险点
- src/legacy/auth.js 老逻辑不能动，要兼容
- 刷新接口有 5s 限流

### 实现顺序
1→2→3，每步做完跑测试

你看完这个 plan，心里就有底了——边界都想过、风险都标了、顺序也合理。这时候让它去写，出问题的概率比「直接冲」低一个量级。

思考成本前置，避免返工

为什么非要先 plan？本质是成本前置。

写代码之前改方案，改的是几行文字，成本几乎为零。写完代码再发现方向错了，改的是几十上百行代码、连带测试、可能还有已经依赖这段代码的其他模块——成本是前者的几十倍。

打个比方：装修前画图纸改个墙的位置，橡皮一擦就行；装修完要把砌好的墙砸了重砌，那是真砸钱。Plan First 就是「画图纸」阶段把问题想清楚，避免后面「砸墙重砌」。

而且 plan 阶段 Claude 是只读的，不会把你的代码改乱。你想推翻重来，只是丢掉一份文字方案，没有任何代码代价。这让「推翻重来」变得极廉价——而这正是好方案诞生的土壤。

何时该跳过 plan

Plan First 不是宗教，不是每件事都要走一遍四阶段。高手复盘里明确点了几种可以跳过 plan 的场景：

• 改 typo——「把第 42 行的 recieve 改成 receive」，没有比这更明确的事，直接改。
• 加 log——「这里加一行 console.log 看看变量」，没什么可想的。
• 重命名变量——「把 a 重命名成 userCount」，机械操作。

共同特征是：没有决策、没有边界、没有风险。这种活 plan 是浪费——你想的比写的还多。

判断标准很简单：这件事有没有需要权衡的地方？ 有，就 plan；没有，就直接做。强行给改 typo 套四阶段，那是形式主义，反而拖慢节奏。

Plan 模式的小技巧

• 明确说「step by step」——这两个词在 prompt 里有奇效，能触发模型更细致地拆解。
• 要求列边界情况——别只说「给我个方案」，加一句「列出所有边界情况和风险」。
• 方案不满意就 push back——plan 是只读的，让它重做方案零成本，别凑合。
• 方案定了再切出 plan mode——很多新手看完 plan 就忘了还在 plan mode，结果让 Claude 改代码它不动，因为它被锁住只能读。

一句话总结

Plan First 是先想后做：Explore 探索 → Plan 出方案（含拆解、边界、风险、顺序）→ Implement 动手 → Commit 提交。改 typo、加 log、重命名可以跳过；有决策的事，思考成本前置永远比返工便宜。

---

下一步，去看 会话管理——怎么给每个任务开一个有名字的会话，做完能回溯。🚀