# 06 — 日常循環：從一句需求到交付登記

上一層：[05 四層防線](05-guards.md)　下一層：[07 怎麼採用](07-adopt.md)　prompt：[prompts/](prompts/)

---

這一章把前面五章串成**一次真實的工作**。每一步都標出「誰做」與「產出落在哪」。

---

## 步驟 0 — 對話開場：AI 先報現況，不是先動手

每個對話開始，AI 要先回答三件事（可以用 hook 在我送出第一則訊息時自動送上）：

```
今天是 YYYY-MM-DD，距離下一個硬錨點還有 N 天
排程表 §三 現有 11 個工作包 · 剩餘 XX 小時
上次對話結束時停在：<一行>
```

**為什麼要這一步**：AI 會拿幾小時前的快照當現況。
曾經發生過：它把**兩件已經做完的事報成待辦**，而我照著說「現在全做」。

> 🚨 **判準：動手前先對現況跑一次指令，不要用「我剛才讀到的」。**

---

## 步驟 1 — 我給一句需求

```
「我想讓使用者可以在相簿裡把照片分享給特定的人」
```

就這樣。**不描述怎麼做** —— 那是步驟 2 的事，而且我在這個階段的判斷力不如查過索引之後的 AI。

---

## 步驟 2 — AI 先查，而且必須把查詢結果印出來

這是整套流程裡**最違反 AI 預設行為**的一步，所以它是 HARD RULE：

```markdown
## 🔁 實作前強制流程（HARD RULE）

任何新增功能／新檔案／新函式之前，必須依序做完：

1. 讀擴充點索引（現有 115 個，含「新增時怎麼接」）
2. grep 既有實作 —— **至少 3 個同義詞**（中英文都試：
   `提醒`/`remind`/`notify`；`分類`/`category`/`kind`）
3. **在回覆開頭輸出查詢結果**，二選一，不可省略：
   · `既有可複用項：EXT-06 syncFinanceEntityCreate（加 kind 即可）` → 接上去，不新寫
   · `查無可複用項。已查：<關鍵字>。新寫理由：<為什麼既有機制接不上>`

跳過 1–3 直接寫 code 視為錯誤，需重做。
```

### 為什麼是「印出來」而不是「請你查一下」

> **重點是把「有沒有查」從不可觀測的內部行為，變成使用者一眼能驗收的產出。**
> **沒印出來就是沒查。**

這一條解決的是一個很具體的問題：那個專案的兩個主要前端檔案是 26,000 行和 31,000 行 ——
**沒有人（包含 AI）能整檔讀進上下文**。
而對模型來說，**沒寫進檔案的預留鉤子＝不存在** ⇒ 同一個能力會被重寫第二遍，然後兩邊開始漂移。

⇒ 配套：維護一份**擴充點索引**（一列一個鉤子：在哪、做什麼、已經接了誰、新增時怎麼接），
並且有一支守衛從 code 端反查它有沒有說謊。**腐爛的索引比沒有索引更糟，因為它會誤導。**

---

## 步驟 3 — AI 出計畫，不出 code

```
要動的檔：3 個（前端 2、後端 1）
新增：1 張表、2 支端點
風險：跟現有的分享連結機制有重疊，可能要合併
估時：6h
不確定的地方：分享的權限是繼承相簿還是獨立？需要你裁示
```

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

我在這一步做的事：採用 / 否決 / 改範圍。**我的時間幾乎只花在這裡。**

⚠️ **否決的話，理由要寫進作廢紀錄**（見 [03](03-memory.md)），否則三週後會再提一次。

---

## 步驟 4 — 定案的東西進排程表，然後才動手

```
§三 未完成工作包（一列一行）
  PS  照片逐人分享   6h   1 張表 ＋ 2 支端點 ＋ 兩平台 UI
```

**還沒進排程表的東西不准動手。** 這條防的是「做了一堆事但沒有人知道還剩多少」。

---

## 步驟 5 — 實作：先改規格，再改 code

```
規格（openspec/**）  ←── 先改這裡
      ↓
     code
```

而且有一條**反直覺但必要**的例外：

> **規格與 code 衝突 → 以 code 為準**，然後回頭更新規格。
> 因為使用者看到的是 code 跑出來的畫面，不是散文。

---

## 步驟 6 — 四道閘門（見 [05](05-guards.md)）

```
L1 hook     自動，我不用記得
L2 守衛     「改到什麼就跑什麼」對照表
L3 演練     改過守衛邏輯才要跑
L4 端到端   要部署才跑（約 35 分鐘）
```

⚠️ **任一道紅燈都把工作推回步驟 5，不算做完。**

---

## 步驟 7 — 交付登記（同一個工作階段內，不是可選收尾）

```
1. 排程表 §三 整列移出，〈已完成〉補一行
2. 當季日誌補一則敘事
3. 證據帳本補一列：結論 ＋ 當下實測的數字 ＋ 指回日誌
4. 擴充點索引：新增的鉤子加一列，code 定義處加 // EXT-NN: 標記
```

> **判準：沒寫進檔案的進度＝不存在的進度；寫錯的進度＝存在的假進度，更毒。**

---

## 步驟 8 — 出事的時候：教訓迴圈

症狀通常長這樣：**畫面全對、console 乾淨、測試全綠，但東西是錯的。**

```
1. 第一句不可以是「我下次會小心」 → 問「結構原因是什麼」
2. 寫進事故記錄：症狀 / 結構性根因 / **現在誰接住它**
3. 分流：
     指令樣式、檔案事件、時間    → hook（＋正反向演練）
     做完了也不會知道出錯        → 守衛（＋故障演練）
     只能靠判斷                  → 才留在規則正文裡
4. 如果是「同一條規則第二次被違反」→ 不要再改規則的寫法，去加機器檢查
```

---

## 一頁版流程圖

```
  對話開場：AI 報現況（日期／剩餘工時／上次停在哪）
        │
  ①  我給一句需求
        │
  ②  AI 查索引 ＋ grep 3 個同義詞 → **在回覆開頭印出查詢結果**
        │                             （沒印出來就是沒查）
  ③  AI 出【計畫＋估時】，不出 code
        │  ← 我的時間幾乎只花在這裡
        │     我裁示：採用／否決（理由進作廢紀錄）／改範圍
  ④  定案 → 進排程表（一列一行）
        │
  ⑤  先改規格 → 再改 code
        │
  ⑥  L1 hook ▸ L2 守衛 ▸ L3 演練 ▸ L4 端到端
        │        任一紅 ⇒ 回 ⑤
  ⑦  交付登記（排程表移出／日誌／證據帳本／索引）
        │
  ⑧  出事 → 問結構原因 → 分流成 hook／守衛／規則
        └──────────────► 回到記憶層，下次自動生效
```

---

## 三個讓這套流程真的跑得動的小習慣

1. **要計畫、不要直接要 code。** 幾乎所有的返工都來自跳過這一步。
2. **交付後回頭更新索引。** 索引一旦腐爛，比沒有索引更糟。
3. **看到過時的狀態行就當場改。** 不要留給「之後整理」——
   因為過時的狀態行會讓下一次排程整包重做。

---

## 接下來

- 怎麼在自己的專案採用 → [07-adopt.md](07-adopt.md)
- 每一步對應的 prompt → [prompts/](prompts/)