先给方案再动手

Plan First

也常被叫作：先说方案别急着改先讨论再执行

怎么跟 AI 说通常止于「概念」约 2 分钟读完

你可能会这么说

「他一上来就开始改，改了一大堆，方向还是错的。」

先给方案再动手 Plan First

让 AI 先说清打算怎么做、动哪里，你确认之后它再动手。

这是投入产出比最高的一句话，因为最贵的错误是方向错误。方向错了，改得越多越糟——你不仅要回滚代码，还要重新判断哪些是它原本改对的。

先给方案的成本很低：一段几十字的说明，你花二十秒就能看出方向对不对。而它省掉的是一整轮返工。

方案里要看三样东西：它打算改哪些文件、分几步、有没有可能影响到别处。 尤其是第三样——如果它说「顺便调整一下数据结构」，你就知道这次要谨慎了。

有个使用技巧：改动越大越要用，小改动可以直接做。判断标准很简单——如果结果不对，你能一眼看出是哪里引起的吗？ 能，就直接改；不能，就先要方案。

先给方案这个习惯还能顺便暴露一个更早的问题：它到底听懂你的需求没有。 让它复述目标时，你会立刻发现理解偏差——有时候它理解的和你说的根本不是一回事，而这个问题在「直接动手」的模式下要等它改完代码你才看得到。方案阶段发现理解错，改一句就行；代码阶段发现理解错，得从头再来。

对很复杂或者你自己也没想清的任务，可以更进一步：让它给两三个不同方案对比。 每个方案一句「做什么、动哪里、代价是什么」，你选一个，或者把两个方案的优点拼起来。这比你自己硬想一个方案再传达给它更快，也常常得到更好的方案——它的备选方案会提醒你没想到的取舍。

长什么样真实可交互，不是截图

需求→它给方案→你确认/修正→它动手→验收

✕ 直接动手改了 14 个文件，方向错了
你要判断哪些该留、哪些该退

✓ 先给方案三行字，你花 20 秒看出方向不对
零成本改正

同一个错误，发生在方案阶段几乎不要钱，发生在代码阶段要还很久。

拆开看，里面有这几块

1
它的理解 Restated goal
让它先用自己的话复述你的需求。理解错在这一步就能发现。
2
实施步骤 Steps
分几步、每步做什么。步骤太多说明这次任务该拆。
3
影响范围 Impact
会改哪些文件、可能影响什么。最需要你盯的一项。
4
不确定点 Open questions
它拿不准的地方。这才是你真正需要回答的问题。

容易搞混？这样区分

先给方案再动手 ≠ 一次只改一件事 One change at a time

先给方案管的是方向对不对（做之前）；一次只改一件事管的是出错时能不能定位（做的时候）。两个一起用，返工率会明显下降。

看一次只改一件事

什么时候用得上

大改动前

重构、换库、改数据结构，一律先要方案。

你自己也没想清时

让它给两三个方案对比，你选一个。比你硬想一个更快。

它已经跑偏时

停下来，让它先说清打算怎么做。别在错误方向上继续追加指令。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

先不要动手改任何文件。请先给我方案，包含四部分：

1. 你理解的需求是什么（用你自己的话复述一遍）
2. 你打算分几步做，每步做什么
3. 会改动哪些文件，有没有可能影响到我没提到的地方
4. 你现在还不确定的地方（如果有，直接问我）

我确认之后会说"开始"，在那之前不要修改任何文件。

如果你认为这个需求本身有问题、或者有更简单的做法，也在方案里直接说，不用照我的思路走。

最后那句很重要：它给了 AI 反驳你的许可。很多时候你要的方案不是最优的，而它默认不会主动否决你。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「概念」这层：只是说清了要做什么，还没有任何东西在跑。

要亲眼看到这些，才算数

它复述的需求和你的意思一致吗？不一致就在这里改，别让它去改代码。
步骤数量合理吗？超过五六步的任务，考虑拆成两次。
影响范围里有没有你没预料到的文件？有就追问原因。
它真的没有动手吗？看一眼有没有文件被改动。说了先给方案却已经改了，是个重要信号。

它常这么糊弄你

给了方案，同时已经把代码改完了。你以为在确认方案，其实在事后追认。
方案写得非常笼统（「优化相关模块」），你看不出它要动什么——这种方案等于没给。
方案里不提影响范围。这一项恰恰是最需要你判断的。
你说「方案不对」，它立刻换一个完全不同的方案，但同样笼统。这时该怀疑它其实没看懂需求。

方案阶段本身停在「概念」层——这正是它便宜的原因：在最便宜的地方发现最贵的错误。

考考你选一个你觉得对的

什么时候最该要求「先给方案再动手」？

# 先给方案再动手 (Plan First)

> 让 AI 先说清打算怎么做、动哪里，你确认之后它再动手。

**你可能会这么说**：他一上来就开始改，改了一大堆，方向还是错的。

这是投入产出比最高的一句话，因为最贵的错误是方向错误。方向错了，改得越多越糟——你不仅要回滚代码，还要重新判断哪些是它原本改对的。 先给方案的成本很低：一段几十字的说明，你花二十秒就能看出方向对不对。而它省掉的是一整轮返工。 方案里要看三样东西：它打算改哪些文件、分几步、有没有可能影响到别处。 尤其是第三样——如果它说「顺便调整一下数据结构」，你就知道这次要谨慎了。 有个使用技巧：改动越大越要用，小改动可以直接做。判断标准很简单——如果结果不对，你能一眼看出是哪里引起的吗？ 能，就直接改；不能，就先要方案。 先给方案这个习惯还能顺便暴露一个更早的问题：它到底听懂你的需求没有。 让它复述目标时，你会立刻发现理解偏差——有时候它理解的和你说的根本不是一回事，而这个问题在「直接动手」的模式下要等它改完代码你才看得到。方案阶段发现理解错，改一句就行；代码阶段发现理解错，得从头再来。 对很复杂或者你自己也没想清的任务，可以更进一步：让它给两三个不同方案对比。 每个方案一句「做什么、动哪里、代价是什么」，你选一个，或者把两个方案的优点拼起来。这比你自己硬想一个方案再传达给它更快，也常常得到更好的方案——它的备选方案会提醒你没想到的取舍。

**也叫**：先说方案、别急着改、先讨论再执行

## 你可以这样告诉 AI

```text
先不要动手改任何文件。请先给我方案，包含四部分：

1. 你理解的需求是什么（用你自己的话复述一遍）
2. 你打算分几步做，每步做什么
3. 会改动哪些文件，有没有可能影响到我没提到的地方
4. 你现在还不确定的地方（如果有，直接问我）

我确认之后会说"开始"，在那之前不要修改任何文件。

如果你认为这个需求本身有问题、或者有更简单的做法，也在方案里直接说，不用照我的思路走。
```

## 怎么验证他真的做到了

通常止于层级：**概念** — 只是说清了要做什么，还没有任何东西在跑

- [ ] 它复述的需求和你的意思一致吗？不一致就在这里改，别让它去改代码。
- [ ] 步骤数量合理吗？超过五六步的任务，考虑拆成两次。
- [ ] 影响范围里有没有你没预料到的文件？有就追问原因。
- [ ] 它真的没有动手吗？看一眼有没有文件被改动。说了先给方案却已经改了，是个重要信号。

常见糊弄：
- 给了方案，同时已经把代码改完了。你以为在确认方案，其实在事后追认。
- 方案写得非常笼统（「优化相关模块」），你看不出它要动什么——这种方案等于没给。
- 方案里不提影响范围。这一项恰恰是最需要你判断的。
- 你说「方案不对」，它立刻换一个完全不同的方案，但同样笼统。这时该怀疑它其实没看懂需求。

来源：https://mickerbook.com/reference/t/plan-first/