Plan-first 提示模板

Plan-first 提示模板

Plan First 原则 那篇讲了「为什么」要先想后做。这一篇给你「怎么写」——把抽象原则变成可以直接抄的 prompt 模板。

低阶 vs 高阶：一句话的差距

高手复盘里有个对比，堪称教学经典。

低阶 prompt：

帮我实现 XXX 功能

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

高阶 prompt：

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

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

差距在哪？「step by step」+「before writing any code」这两个词触发了模型的规划行为——不是玄学，是模型在训练时见过太多这种结构，知道见到这种词应该先想后做。

官方四阶段：可以直接抄的 prompt 模板

官方 best-practices 把一次任务的标准流程画成四阶段：Explore → Plan → Implement → Commit。每一步都有现成的 prompt 模板。

第 1 步：Explore（探索）

> read @src/auth and understand how we handle sessions and login.
> tell me which files are involved, how the flow works, and what
> external dependencies we rely on. don't change anything yet.

关键点：

• 明确说「read」——让它去读，不是凭空想。
• 指给具体目录 @src/auth——圈定范围。
• 明确说「don’t change anything yet」——锁住它的手，这一步只读。

Explore 这步最适合甩给子代理，让它在独立上下文里读一大堆文件，主会话只拿到一份摘要。详见 探索陌生代码库。

第 2 步：Plan（规划）

> I want to add Google OAuth. What files need to change?
> Create a plan including: feature breakdown, edge cases,
> potential risks, and suggested implementation order.
> Don't write code yet.

关键点：

• 明确问「What files need to change」——逼它具体到文件。
• 要求四块输出：功能拆解、边界情况、风险点、实现顺序。这是 plan 的标配。
• 「Don’t write code yet」——再次锁手。

输出长这样：

## Google OAuth 实现方案

### 功能拆解
1. 安装 google-auth-library 依赖
2. 在 @src/auth/oauth.ts 新增 GoogleStrategy
3. 在路由层加 /auth/google/callback
4. session 里写入 user.googleId

### 边界情况
- 用户邮箱已注册过本地账号 → 合并还是拒绝？
- Google 返回的 email 未验证 → 拒绝登录
- OAuth state 不匹配 → 拒绝，防 CSRF
- refresh token 持久化策略

### 风险点
- @src/legacy/auth.js 老逻辑不能动，要兼容
- 现有 session 中间件要改，影响所有登录方式
- Google 限流：每秒 100 次调用

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

第 3 步：Implement（实施）

> implement the OAuth flow from your plan. write tests for each
> step, run the test suite after each step, and fix any failures
> before moving to the next step.

关键点：

• 「from your plan」——让它照刚才定的方案走，不要自由发挥。
• 「write tests for each step」——边写边补测试。
• 「run the test suite after each step, fix failures before moving on」——把验证循环塞进每一步，不让它一口气冲到底。

这一步切出 Plan 模式（Shift+Tab 或退出 plan mode），Claude 才能动文件。

第 4 步：Commit（提交）

> commit with a descriptive message and open a PR.
> include a summary of what changed, why, and how to test.

关键点：

• 「descriptive message」——别让它写「update code」这种废 message。
• 「why, and how to test」——PR 描述里要写清楚动机和验证方法，方便 reviewer。

Ctrl+G：在编辑器里改方案

Plan 模式下 Claude 把方案铺出来后，你不必盯着终端逐字读。按 Ctrl+G 可以在编辑器里打开这份 plan——像编辑代码一样编辑它。

• 删掉不想要的步骤
• 调整顺序
• 补上它没想到的边界
• 改完存盘，让 Claude 照改后的方案走

这就像建筑师先画图纸给你看，你拿红笔批改，确认无误了再动土。这一招在方案复杂时特别值钱——逐字读 plan 容易看漏，编辑器里改一遍心里有底。

思考成本前置：为什么非先 plan 不可

本质是成本前置。

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

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

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

何时该跳过 plan

Plan-first 不是宗教，不是每件事都要走一遍四阶段。官方和社区都明确点了几种可以跳过的场景：

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

判断标准很简单：这件事能不能一句话描述清楚 diff？ 能，就直接做；不能，就先 plan。

强行给改 typo 套四阶段，是形式主义，反而拖慢节奏。Plan 是为「有决策、有边界、有风险」的事服务的——没决策的事，plan 是浪费。

任务	跳过 plan？	理由
改 typo	跳	diff 一句话能说完
加调试 log	跳	没决策没风险
重命名变量	跳	机械操作
加 OAuth 登录	不跳	多文件、有边界、有风险
重构 auth 模块	不跳	影响范围大
修一个模糊的 bug	不跳	根因未知，要先探索

模板速查

把上面所有 prompt 压成一份速查：

# Explore（先探索）
read @<dir> and understand how <feature> works.
tell me <questions>. don't change anything yet.

# Plan（再规划）
I want to <goal>. What files need to change?
Create a plan including: feature breakdown, edge cases,
potential risks, and suggested implementation order.
Don't write code yet.

# Implement（再动手）
implement <goal> from your plan. write tests for each step,
run the test suite after each step, fix failures before
moving on.

# Commit（最后提交）
commit with a descriptive message and open a PR.
include a summary of what changed, why, and how to test.

抄走，按你的任务填空。

一句话总结

Plan-first 是可复制的模板：低阶「帮我实现 XXX」vs 高阶「Think step by step. Outline a detailed plan before writing any code.」四阶段 Explore→Plan→Implement→Commit 都有现成 prompt，Ctrl+G 在编辑器里改方案。改 typo、加 log、重命名变量能一句话说清 diff 就跳过。

---

下一步，去看 反馈循环设计——让 Claude 在每一步都能验证自己做得对不对。🚀