同一個月，兩個 PR

今年春天，在同一個專案、同一個月，開了兩個 AI 產的 PR。

第一個動了 59 個檔案，附 165 個測試全綠，平安合併。第二個只動了 22 個檔案，被打回。

如果你只看檔案數，會猜反。59 個檔案聽起來像災難，22 個檔案聽起來還好。但打回的理由跟檔案數無關：那 22 個檔案沒有人看得完——包括我自己。reviewer 問我「這個 state 為什麼從這裡改到那裡」，我答不出來，因為那是 AI 的決定，我當時只確認了「能跑」。

59 個檔案那個為什麼沒事？因為動手前 spec 裡已經有狀態機、有流程圖、有每個 test case 的名稱。AI 是在一個框好的空間裡填東西，165 個測試是安全網。它不是「批量比較安全」，是「有安全網的批量才安全」。

那個月之後，我把這件事寫成一條原則：AI 是生產線的模組，不是黑盒。

原則：把 AI 放進 pipeline，不是放在你對面

你現在用 AI 的方式可能是這樣：開一個對話，描述任務，等它交卷，看一眼，用。這是把 AI 當「對面那個人」——給任務、收成品。

換一個心智模型：

輸入 → AI → 人類審查 → 輸出

AI 是中間那個高速處理節點，不是終點。它的產出永遠要經過「人類審查」才算輸出。這不是不信任它，是生產線的設計：每個高速節點後面都要有一道檢查，否則錯誤會以同樣的速度流到下游。

從這個模型往外推，正確的工作流是這樣，不可跳步：

需求分析 → 切 ticket → 規劃 PR 拆分 → AI 產出
        → 自動化掃描（lint / simplify / 第二個 AI 審）
        → 人工 review → merge

前三步是「給方向、控範圍」。跳過它們，等於讓 AI 在無邊界的空間裡產 code——它會產出局部最優、但不符合全局設計的東西，而且你要到 review 時才發現。這是 Day 6 的主題，今天先記住：前三步不是官僚，是安全網。

治癒者心態：稀缺的是「確保正確」

MMORPG 裡有一種角色叫治癒者。輸出不高，但沒有他整團會滅。

AI 讓「產 code」這件事變得便宜到接近免費。以前一個 feature 要寫三天，現在三十分鐘。但便宜的東西不會是你的價值所在——稀缺的是確保生成物正確的能力。審查、測試、判斷「這樣寫對不對」，這些沒有變便宜，反而因為產出變多而變得更稀缺。

所以：程式碼治理 > 程式碼生成。 把你的時間從「打字」搬到「審查和測試」。這不是被動的，是主動的角色轉換：你從輸出職變成治癒職。

具體一點，PR 的本質要重新定義。PR 不是「我寫完了」，是「團隊確認這段 code 可以進主線」。從這個定義推出兩條硬規則：

• 一個人看不完的 PR ＝ 把風險藏進主線。 不管是 AI 寫的還是人寫的。
• 每個 PR 控制在 5–8 個檔案。 超出就拆。這個數字不是科學，是「一個 reviewer 在一杯咖啡的時間內能真的看完」的經驗值。

什麼時候可以批量

回到開頭的問題：59 個檔案為什麼可以？

判斷準則只有一條：

spec 裡有沒有狀態機／流程圖／test case 名稱？
  有 → 可以批量（AI 在框好的空間裡填）
  沒有 → 先補 spec，再開 feature

安全網的優先順序也要說清楚：

• 治本：提高測試覆蓋率。讓 AI 的錯誤在 merge 前就被抓到。
• 治標：限制每次改的檔案數。有用，但不是根本解。

還有一條很多人忽略的：spec 要標出「AI 不得自行決定」的架構判斷。導航方式、跨層通訊機制、狀態放哪一層——這些如果沒標，AI 會自己選一個，而且通常選對它最方便的那個。

今天要做的一件事：自評一個 PR

拿你最近一個 AI 參與的 PR（沒有的話，拿昨天對照實驗第一輪的 diff），用下面八題自評。誠實一點，這張表不用給任何人看。

• [ ] 需求分析有做嗎？這個 PR 解決什麼明確問題？（一句話講得出來嗎）
• [ ] ticket 有切嗎？範圍有控制嗎？
• [ ] 檔案數 ≤ 8？
• [ ] 跑過 lint／simplify／自動化掃描？
• [ ] 測試有補？補的測試會失敗嗎？（把實作改壞，它會紅嗎）
• [ ] 我自己看得完，別人也看得完？
• [ ] AI 有沒有自行決定任何架構問題？（它選了什麼你沒叫它選的）
• [ ] 有沒有哪一行我答不出「為什麼這樣寫」？

如果超過三個沒勾，這個 PR 不該 merge——或者已經 merge 了，那你現在知道風險藏在哪裡。

第二件事，只要五分鐘：如果那個 PR 超過 8 個檔案，在紙上把它拆成兩到三個。不用真的拆，只要想一下拆分的線在哪裡——通常會發現有一條線是「這個 PR 其實混了兩個需求」。

新人最常在這一步犯的錯

AI 產出後直接 merge。 最常見，也最難改，因為它每次都「看起來沒事」。看起來沒事是統計上的：十次有九次真的沒事，第十次會讓你花三天。

PR 動輒 20+ 檔案。 理由通常是「AI 一次就做完了，拆開很麻煩」。麻煩是對的，但那個麻煩是 reviewer 的麻煩被你提前吃掉——現在不拆，reviewer 就會直接 approve（因為看不完），風險就進主線了。

把「測試全綠」當「做對」。 這一條會在 Day 20 用一個真實的假測試案例講透。今天先種一個懷疑：測試是 AI 寫的，實作也是 AI 寫的，它們兩個當然會互相同意。綠燈只證明它們一致，不證明它們對。

把 AI 當問答機。 「這樣寫對嗎？」「對。」——然後就相信了。問答機的回答沒有經過任何工具驗證。Agentic 的價值在它能跑測試、能讀 code，你要逼它用工具證明，不是用嘴回答。

本篇可帶走的檔案

pr-checklist.md——放進專案 docs/，或直接貼進 PR template 的最後一段。

## 開 PR 前自評（AI 參與的 PR 必填）

- [ ] 這個 PR 解決什麼明確問題：__________
- [ ] 範圍：ticket # ____，檔案數 ____（≤ 8）
- [ ] 自動化掃描：lint ☐  simplify ☐  第二個 AI 審 ☐
- [ ] 測試：有補 ☐  把實作改壞會紅 ☐
- [ ] AI 自行決定的架構問題（列出，沒有寫「無」）：__________
- [ ] 我答不出「為什麼這樣寫」的行數：____（不是 0 就回去問 AI，問到答得出來）

> 批量判斷：spec 有狀態機／流程圖／test case 名稱嗎？ 有 ☐ 沒有 ☐（沒有 → 先補 spec）

最後一項是整張表的核心。「我答不出為什麼」的行數不是 0，就代表 PR 裡有你無法負責的 code。回去問 AI，問到你能用自己的話解釋為止——這個動作本身就是 review。