🎯 什麼情境該想到我
當你想讓一部分變更「不用人看就合併」，但又怕哪天合進一個不該合的東西，需要一套規則決定「這個變更要幾個人核准」的時候。
⚙️ 怎麼用（步驟 / 公式）
1. 先寫下風險分級
原文 Claude Code 團隊的分法（2026-10-15）：
| 風險 | 例子 | 需要幾個人核准 |
|---|---|---|
| 低 | 文件、文案、只給內部用的功能、藏在功能開關後面的新增 | 0 人（自動審查與資安檢查都過了才行） |
| 中 | 一般產品變更；敏感區域如快取、自動更新、系統提示詞 | 1 人 |
| 高 | 風險最高的程式碼，以及少數固定要兩個人的路徑 | 2 人 |
2. 讓「變更」決定層級，不是讓「作者」決定
- 分類器讀變更內容來判斷層級。
- 第二個分類器再問一次：這個變更就算層級說不需要，是不是也該多一個人看？
- 有些路徑永遠要人：owner 列為敏感的路徑，以及任何 CI workflow 檔。實作上用
CODEOWNERS加分支保護。
3. 用四條規則堵住漏洞
- 只有受信任的作者能走較輕的路徑：名單上多半是負責這個 repo 的團隊，其他人一律要第二個人核准。
- agent 的核准永遠不算人的核准：自動審查可以放行低風險變更，但不能填補「需要一個人」的那個位置。
- 下指令的人就是負責人：agent 寫的 PR，指揮 agent 的那個人算一位必要的審查者，就像他自己打的 code 一樣。
- 核准綁在特定 commit 上：之後又進來系統無法擔保的 commit（agent 的 push、某人手動解的 merge），就要重新核准。
4. 先嚴再鬆，用證據放寬
一開始從嚴，靠回滾率與事故率當證據，一步步把更多類型移到較低的層級。原文的方向是讓 owner 自己決定哪些低風險變更可以只靠自動檢查合併，而這條線還在持續移動。
🧪 我實際套用的紀錄
- 2026-10-31：（待填）
⚠️ 注意 / 什麼時候不適用
- 0 人核准的前提是事後能快速發現並復原：功能開關、分階段發布、一步回滾、值班與回滾儀表板。沒有這些，低風險的定義要收得更窄。
- 分類器會分錯，所以才需要「永遠要人的路徑」當底線，以及第二個分類器做反向檢查。不要讓分類器成為唯一的一道判斷。
- Anthropic 對外的產品比內部更保守：Code Review 產品只張貼發現、不給核准，核准仍然是人的事。內部 repo 才讓 owner 決定哪些變更可以只靠自動檢查合併。
- 自動化程度和團隊信任度綁在一起：跨團隊、外部貢獻者的變更，不適用較輕的路徑。
🔗 相關工具
- 工具-分層把關取代單一審查關卡 —— 這張是其中第 ⑤ 層
- 同儕審查取代變更審批 —— 同樣反對「一律送高層簽核」，改成依風險決定誰看
- 把變更重歸類為標準變更 —— DevOps 手冊的做法：低風險、可重複的變更預先核准，不必每次送審