# 03 — 要計畫，不要 code

> **這一條的投報率最高，而且今天就能用。**

## 一句話

> **計畫階段的錯誤改一行字，實作階段的錯誤改三個檔案。**

AI 的預設行為是直接開始寫。這很合理 —— 它快，而且大部分時候寫得出來。
問題是：**它寫得出來的東西，不代表是你要的東西**，而發現這件事的時間點決定了代價。

---

## 直接複製（對話裡用）

```
先不要寫 code。給我一份計畫，包含：

1. 要動哪些檔（列出來，標出新增／修改）
2. 新增的資料結構 / 端點 / 函式（名字 ＋ 一句話職責）
3. 跟現有機制的重疊（哪些地方可能該合併而不是新寫）
4. 風險與已知的坑
5. 估時
6. **你不確定、需要我裁示的地方**（這一項最重要，不要省略）

等我說「開始」再動手。
中途如果發現範圍要擴大，停下來問，不要順手做完。
```

---

## 常駐版（貼進記憶層）

```markdown
---
name: plan-before-code
description: 大改動一律先出計畫與估時，不直接寫 code
metadata:
  type: feedback
---

大改動先出【計畫＋估時】讓我裁示，不要直接產出 code。
範圍要延伸（「順手也改一下 X」）先報價，不要直接做。

**Why:** 計畫階段的錯誤改一行字，實作階段的錯誤改三個檔案。
   而且我對範圍的判斷比對實作細節的判斷準得多。
**How to apply:** 收到「做 X」時，先回一份「要動哪些檔／風險／估時／不確定的地方」，
   等我說「開始」再動手。已經在跑的工作中途發現要擴大範圍，停下來問。
```

---

## 我在這一步做什麼

```
採用    → 進排程表（一列一行），然後才動手
否決    → 🚨 理由寫進作廢紀錄，否則三週後會再提一次
改範圍  → 明確說砍掉哪些、為什麼
```

**我的時間幾乎只花在這一步。** 這是整套分工的核心：

> ①決策和③教訓是我的，②實作可以外包。

---

## 「不確定的地方」為什麼最重要

一份沒有「不確定的地方」的計畫，通常代表 AI 把它自己的假設當成了你的需求。

真實的例子：

```
不確定的地方：分享的權限是繼承相簿還是獨立？需要你裁示
```

這一行如果沒問，兩個選擇都寫得出可以動的 code，
而錯的那個要到使用者實際用起來才會發現 —— 那時候已經有資料了。

⇒ **判準：如果 AI 給的計畫沒有任何「不確定的地方」，要主動問一句「真的沒有嗎」。**

---

## 什麼時候可以跳過

改動小於 30 分鐘、而且只動一個檔的時候。

⚠️ 但注意「我以為只要 30 分鐘」本身就是最常見的誤判。
第二次評估超過三個檔，就退回來要計畫。