驗證心法與 Plan 大師級

15.1　四階段工作法：先探索、再規劃、後動手

達人寫程式很少劈頭就叫 Claude「動手做」。官方建議的標準節奏是四個階段：探索（Explore）→ 規劃（Plan）→ 實作（Implement）→ 提交（Commit）。把「研究跟規劃」跟「實際改動」分開，最大的好處是：避免 Claude 還沒搞懂你要什麼，就一頭栽進去解錯問題——等它寫完一大堆你才發現方向不對，那才是真的浪費時間。

✅官方 四階段工作法出自 Anthropic 官方最佳實踐。

動手看一次：一輪真實的四階段對話會長什麼樣子

上面的表格是骨架，實際打字會是什麼樣子？舉個例子：你想幫一個舊專案的「匯出報表」功能，加上依欄位篩選再匯出 CSV 的能力。四個階段實際下指令，大概會像這樣：

# ① 探索（先進 Plan 模式，Shift+Tab 切過去）
去讀 src/reports/ 底下匯出報表的程式碼，
搞懂現在的匯出流程跟資料怎麼組出來的，
也看一下有沒有現成的「欄位篩選」邏輯可以參考。

# ② 規劃（還在 Plan 模式）
我想讓匯出報表支援勾選要匯出哪些欄位。
哪些檔案要動？資料流程會怎麼變？
把計畫寫出來。

# ③ 實作（切出 Plan 模式後）
照你的計畫做，欄位篩選的邏輯要寫測試，
全部跑過一次、把失敗的都修好再回報。

# ④ 提交
用清楚的訊息 commit，開一個 PR。

留意第②句：規劃階段的重點不是「叫它動手」，是逼它先講出「哪些檔案會動、資料流程怎麼變」——這兩句話它答得出來，代表是真的想過一輪，不是複製貼上你的需求就開始改。

核准計畫時，其實有 5 個選擇，不是只有「同意」

Plan 模式寫完計畫後，你不是只能「按 Enter 同意」。核准畫面通常會給你五條路，挑哪一條看你對這份計畫的信任程度：

1. 直接轉 Auto mode 執行：信任計畫、想少被打斷，讓它自己跑（見 15.4）。
2. 轉 acceptEdits 執行：檔案編輯自動過，但敏感操作還是會問你。
3. 逐一審查每個編輯：最保守，每個檔案改動都要你點頭。
4. 回頭再修計畫：看完覺得哪裡不對，直接打字要它改計畫，還沒開始動手。
5. 轉 Ultraplan 到瀏覽器複審：把計畫丟上雲端介面，用滑鼠留言、反應 emoji 慢慢審（見下方）。

有個小細節可以省事：核准計畫之後，Claude Code 通常會直接拿計畫內容幫這個 session 命名，不用你自己再想一個 session 名字。

研究預覽：把規劃搬上雲端瀏覽器複審 — Ultraplan

🧪實驗性 Ultraplan 是核准計畫的第 5 條路：把規劃任務丟給雲端版的 Claude Code on the web，一樣用 Plan 模式跑，但複審介面搬到瀏覽器上，多了三種本機終端機沒有的複審工具——行內留言（對計畫裡某一句話直接註解）、emoji 反應（快速標記同意／有疑慮）、大綱側欄（整份計畫的章節縮圖，方便跳讀）。複審完可以選擇留在雲端繼續執行，或是瞬移回本機終端機接手實作。

要用它，你得先有 Claude Code on the web 的帳號、專案要連 GitHub repo，版本也有下限（官方標的是 v2.1.91 以上）。它目前標的是研究預覽，介面與需求都可能還在變動，用之前建議先看官方 Ultraplan 文件頁確認現況。

✅官方 核准計畫的 5 個選項與自動命名出自官方文件；🧪實驗性 Ultraplan 為 research preview，需求與介面可能持續變動；🌐社群 Plan 模式非硬沙盒一事，出自 GitHub issue tracker 上的重複回報，實際修復狀態請自行核實。

15.2　驗證閉迴圈：四級升級閘門

這一節是整章的核心，也是達人心法裡最值錢的一段。要治「假裝做完」這個病，靠的不是一直叮嚀它「請確實完成」——那種純嘴上的提醒，它七成時候照樣偷工。真正有效的做法只有一個原則：給 Claude 一個會回傳「通過／失敗」的東西，逼它拿證據說話。

這個「會回傳通過／失敗的東西」可以是：測試套件（test suite）、build 的結束碼（exit code）、linter、固定的對照檔（fixture diff），或截圖跟設計稿比對。重點在於——它是機器能客觀判定真假的事實，不是 Claude 自己說了算。給了這種檢查，Claude 就能自己反覆跑、自己迭代到真的過，而不是跑一次就跟你說「好了」。一句話記住整套心法：不要問它「做完了嗎」，要問它「證據呢」——人類工程師交付前會自己跑一次測試，你只是把這個習慣，變成 Claude 跑不掉的硬規矩而已。

✅官方 驗證閉迴圈與四級升級閘門出自 Anthropic 官方最佳實踐。

先寫一個會失敗的測試，直接 commit 起來當檢查點

有個做法特別適合搭配「機器可驗證」這套心法：先叫它寫測試，不急著寫功能。順序是先寫測試 → 跑一次確認它真的會失敗（紅燈）→ 把這個「會失敗的測試」先 commit 下來當檢查點 → 才開始實作，做到全部轉綠為止。

中間那個「先 commit 失敗的測試」常被跳過，但它其實是這招最關鍵的一步：它把「驗證標準」釘死在版控歷史裡，之後不管改幾輪、換幾個 session，你都能用 git diff 對照這顆檢查點，確認 Claude 沒有偷偷把測試改鬆來讓它通過——這正是防止「表面過關」最直接的辦法。

兩句話乍看差不多，差別在後者把「做對」的定義寫死成機器可以判定的案例，而且明講「跑測試給我看」——Claude 沒辦法用「應該可以吧」蒙混過去，因為你已經先講好怎麼算數。

Stop hook 怎麼寫：兩種回覆格式

第③級的 Stop hook 是一段你自己寫的腳本，Claude 想收工時會先過一遍。它讀你腳本的輸出決定要不要真的停下來，常見兩種寫法：

💡 寫法一：擋下來，附理由（Claude 會看理由繼續做）

{ "decision": "block", "reason": "測試覆蓋率不到 80%，請補測試再回報。" }

💡 寫法二：不擋，但補一段背景資訊讓它自己判斷

{ "hookSpecificOutput": { "hookEventName": "Stop", "additionalContext": "效能回歸：API 回應時間增加了 15%。" } }

寫 Stop hook 前有個地方一定要處理：它本身也會觸發一輪新的對話，新的一輪結束時又會再觸發一次 Stop hook——沒處理好會變成關不掉的無限迴圈。你的腳本要去檢查傳進來的 stop_hook_active 旗標，已經是 hook 觸發的這一輪就別再擋。另外別忘了前面提過的保險絲：連續擋滿 8 次，Claude Code 會直接強制放行，這是系統內建、不是你能調的參數。長時間無人值守的任務，Stop hook 適合當第一層攔截，別指望它能無限期擋下去，真要保險就再疊一層對抗式 subagent（下一段）。

第④級對抗式 subagent 的一個提醒：它幾乎總會挑出東西

派一個全新 subagent 去對抗式覆核，官方給的範例大致是這樣的指令：

# 派一個 subagent 拿計畫當標準，覆核剛剛的變更
派一個 subagent 對照 PLAN.md 檢查這次改動的 diff：
確認計畫裡列的每一項都做到了、
提到的邊界情況都有對應測試、
而且沒有動到範圍外的東西。
只回報會影響正確性或需求的漏洞，其他當參考就好。

最後那句「只回報會影響正確性或需求的漏洞」不是客套話，是必要的煞車。一個被交付任務就是「去挑毛病」的 reviewer，就算東西真的沒問題，也幾乎總會硬擠出幾條意見來交差——這是它被賦予的角色使然。如果你把它列的每一條都照單全收去修，很容易滾出一堆不必要的抽象層、防禦性程式碼，甚至為了根本不會發生的情境寫測試，結果是過度工程化，比原本沒審查還糟。做法是把它的意見分兩桶：真的會讓功能壞掉或需求沒做到的，處理；純粹是「風格比較好」「可以更保險」的，看情況、不追殺每一條。

✅官方 TDD 紅燈檢查點、Stop hook 兩種回覆格式與 stop_hook_active 旗標、對抗式 subagent 範例與「別追殺每一條」的提醒，均出自 Anthropic 官方最佳實踐與官方 subagent 範例文件。

15.3　/goal：給它一個「達成才算完」的條件

上一節的第二級閘門是 /goal，這節單獨講它，因為它是「讓 Claude 無人值守跑很久」的基礎。/goal 的用法是設一個可被機器驗證的完成條件，然後 Claude 會在每一個回合都重新檢查：這個條件成立了嗎？沒成立就繼續做，成立了才停。

💡 用法示意：設定一個確定性的完成條件

# 設一個可驗證的目標：所有測試檔通過、且分支乾淨可開 PR
/goal "all test files pass and branch is clean for PR"

這條件的關鍵在於它不是模糊的「把功能做好」，而是「測試全過」「分支乾淨」這種機器能客觀判定的事實。Claude 沒辦法靠嘴砲說自己達標——它得真的讓測試綠燈，/goal 才會認帳。

✅官方 /goal 為官方功能；👤達人 搭 /loop + worktree 做無人值守的用法，出自 Boris Cherny 的個人實踐。

💡 查看目前的 goal 狀態、清掉 goal、非互動模式下使用

# 不加參數直接打，列出條件、已跑時長、跑了幾回合、目前 token 花費、評審模型最新一次的判斷理由
/goal

# 清掉目前設定的 goal（stop／off／reset／none／cancel 都是同義字）
/goal clear

# 非互動模式一次跑到完成，適合排程或 CI；想中途喊停就按 Ctrl+C
claude -p "/goal CHANGELOG.md 裡本週合併的每個 PR 都要有一行紀錄"

/goal、/loop、Stop hook：三個「自動繼續」的機制，誰管什麼

這三個常被搞混，因為都會讓 Claude 在一輪結束後「自己決定要不要繼續」。差別在誰來判斷、什麼時候判斷：

三者可以疊在一起用：比如用 /goal 設好機器可驗證的完成條件當主要判準，同時掛一個 Stop hook 當保底閘門，兩層都要過才真的收工。resume 一個已經設過 goal 的 session，條件本身會保留，但已跑的回合數、計時、token 花費會重新計算。

✅官方 評審模型機制、字元上限、狀態查詢與非互動用法、以及 /goal／/loop／Stop hook 的機制對照，均出自官方 /goal 文件。

15.4　Auto mode：用分類器取代「逐次問你」

講到「讓 Claude 自己跑」，2026 年隨 Opus 4.8 來了一個關鍵的新東西：Auto mode。它常被誤會，所以這節要把它講清楚。先記住一句話定調：Auto mode 是「研究預覽」，不是安全保證——它能大幅減少打斷，但官方坦承它會漏放危險動作，別把它當成「有它就不用管」。

它是第 6 個權限模式

你在 第 7 章 學過權限模式（預設、接受編輯、計畫）。Auto mode 是 Claude Code 的第 6 個權限模式，不是新產品。把六個模式從「最保守」排到「最自主」會更好懂：

它的本質：不是權限更大，是換一種審查方式

這是最容易搞錯的地方，務必看懂：Auto mode 不是「權限層級更高」——那是第 6 順位的 bypassPermissions。Auto mode 做的是把權限檢查從「事前逐次問你」換成「事後由 AI 分類器自動判斷」。防護沒有被拿掉，只是從「打斷你」變成「背景機器幫你看」。

這個背景分類器是獨立的 Sonnet 4.6 模型，跟你用 /model 選的模型無關——你拿 Opus 跑任務，分類器仍是 Sonnet 4.6 在背後把關。它會先用單一 token 快速過濾，只對被標記的可疑動作才做更深的推理。讀檔、在本地工作目錄編輯這類安全動作會跳過分類器（不送審）；開銷主要來自 shell 指令和網路操作。

分類器盯的是這幾類高風險動作，命中就擋下並要 Claude 改做法：

• 下載並執行外部程式碼（典型的 curl … | bash）。
• 把敏感資料往外部端點送。
• 生產環境部署、資料庫遷移。
• 雲端儲存的批量刪除。
• IAM／repo 權限授予、共享基礎設施的修改。
• git 破壞性操作：force push、reset --hard、stash drop、直接推 main。
• 會話邊界違反：你在對話裡說過「別 push」，它卻想 push——擋。

常見誤解：允許清單救不了 .claude/ 和 .git/ 這批「受保護路徑」

不少人以為只要在允許清單裡寫一條 Edit(.claude/**)，Auto mode 就會放行對 .claude/ 設定的編輯——實際上不是這樣。.claude/、.git/、shell 啟動檔（.zshrc 之類）這批「受保護路徑」，在除了 bypassPermissions 以外的所有模式都不會被允許規則自動放行：Auto mode 下會被強制送去給分類器覆核，dontAsk 模式下則是直接拒絕。這是刻意設計——不然一份寫死在 repo 裡的允許清單，等於任何 clone 這個 repo 的人都能自己幫自己開後門動 Claude Code 的設定本身。

Plan 模式 vs Auto mode：不是誰取代誰

這兩個常被講成「新的取代舊的」，其實不互斥、可以隨時切，是兩種不同的工作流：

你可以在 session 裡用 Shift+Tab 在這幾個模式間循環切換。Plan 模式批准後可以轉進 Auto 執行；Auto 跑到一半想改策略，也能切回 Plan 重新摸。要設成預設只能寫在 ~/.claude/settings.json 的 { "permissions": { "defaultMode": "auto" } }，不能放進專案 repo 的設定。

這條「只能設在使用者層」的規則背後是刻意設計：defaultMode: "auto" 若寫在專案層的 .claude/settings.json 或 .claude/settings.local.json，新版 Claude Code 會直接忽略它——不然一個 repo 只要偷偷簽入這行設定，任何人 clone 下來就等於被自動開了 Auto mode，這不該由 repo 作者代替使用者決定。相對地，Plan 模式的預設值可以合法寫在專案層，因為它只會讓行為更保守：

💡 兩種作用域的實際寫法對照

~/.claude/settings.json（使用者層，Auto mode 只能寫在這）
{ "permissions": { "defaultMode": "auto" } }

.claude/settings.json（專案層，Plan 模式可以合法寫在這）
{ "permissions": { "defaultMode": "plan" } }

團隊想幫協作者設一個「保守起步」的預設值，寫進專案層的 plan 就是合法又不踩雷的做法；反過來想讓自己的機器全域偏好 Auto mode，才需要動使用者層設定。

值得一提的是 Opus 4.8 把工作流訊息也改了：以前官方建議「先 Plan、再執行，而且常常要另開一個全新 session 來執行」——那其實是當年 context 容量有限時的權宜做法。現在官方訊息轉成「Plan 模式留給真的不確定的設計，多數的規劃—實作—驗證交給 Auto mode」，所以「另開 fresh session 執行」變成可選、不再強制。

達人觀察也呼應這個轉向：Boris Cherny 提過，隨著模型能力往上（他提到 Opus 4.6 之後那幾代），他反而減少特地切進 Plan 模式的頻率——新一代模型在動手前某種程度已經「內建」會先想過一輪，Plan 模式這個顯式步驟對他來說變多餘，他改成直接從 Auto mode 開始。這是他個人隨模型世代調整的習慣，不是官方硬性建議；自己的專案該不該跳過 Plan 模式，還是取決於任務風險，別只因為「達人這樣做」照搬。

這個限制在非互動模式下特別要注意。互動 CLI 裡，同一個動作被連擋 3 次，Auto mode 會自動暫停、退回逐次詢問——這時候還有你在，可以回答。但 claude -p 這種非互動模式沒有人可以回答，遇到一樣的重複擋下情形，行為是直接中止整條 run，不會安靜等你回覆。用 /goal 搭 -p 跑無人值守的排程任務時要留意：如果分類器對你的內部基礎設施「不熟」（常見情境是內部服務網域被誤判成不明外部端點），整個排程可能就這樣提早結束，得靠 /permissions 的「最近被拒」紀錄才看得出發生過什麼事。真的要讓分類器更懂自家基礎設施，正解不是關掉 Auto mode，是請管理員把內部網域、bucket、服務白名單寫進 trusted infrastructure 設定。

近期動態：預設模式可能已經改回 Manual，請自行核實你手上的版本

Auto mode 官方工程部落格自己承認一個很說明問題的數字：對真實流量做匿名統計，使用者對權限提示的核准率高達約 93%——這代表「跳出視窗要你按確認」早就不等於「你真的有在審查」，跟這整章反覆強調的「看起來做完 ≠ 真的做完」是同一個病根，連 Anthropic 自家產品都踩過。多家科技媒體在 2026 年 7 月初回報，Claude Code 一次版本更新把預設權限模式從 Auto 改回 Manual，理由正是這個「核准疲勞」數字。這個「改回預設」的時間點是我從二手媒體報導轉述，不是直接讀到 Anthropic 官方公告頁面，寫這段當下無法保證仍是最新狀態——建議動手前自己跑一次 claude --version 對照官方 release notes，或打 /config 看目前生效的預設模式，別完全相信任何一篇文章（包括這篇）講的「現在預設是什麼」。

✅官方 權限模式階梯、分類器機制、兩模式關係、受保護路徑放行規則、defaultMode 作用域差異、非互動模式的中止行為，皆出自官方文件與工程部落格；🧪實驗性 Auto mode 為 research preview，誤擋約 0.4%／漏放約 17%、不保證安全；✅官方 核准率約 93% 的核准疲勞數字出自 Anthropic 官方 Auto mode 工程部落格；🌐社群「2026 年 7 月改回 Manual 預設」為科技媒體轉述，請自行核實現況；👤達人「多數任務改偏好 Auto mode」與「模型變強後減少用 Plan 模式」屬 Boris Cherny 的個人傾向，非官方硬規範。

15.5　雙模型與雙 Claude：規劃用強的、審查找新的

達人有兩個省力又抓得準的搭配技巧，都圍繞「別讓同一個 Claude 既當球員又當裁判」。

技巧一：雙模型——深規劃用 Opus、快執行用 Sonnet

把需要深度思考的規劃路由到比較強的 Opus，把照計畫快速執行交給比較快的 Sonnet。可以透過 /model 切換，或在 .claude/settings.json 做條件路由。好處是：燒最貴模型的時間花在最需要腦力的地方，執行階段用便宜快的就夠。

技巧二：雙 Claude——讓一個全新的它來挑另一個的毛病

這招對「安全敏感的變更」特別值得。重點是：審查的那個 Claude 要零先前 context——因為它對前一個計畫沒有任何感情投入，反而更容易挖出盲點。一個寫計畫的 Claude 看自己的計畫總覺得很完美；換一個全新的、立場像「資深工程師審稿」的 Claude 來看，常常一眼就點出漏洞。

官方最近把這個做法背後的道理講得更完整，值得放在這裡當理論骨架：長 context 的單一 session 容易踩三種官方點名的失效模式——agentic laziness（做到一半就自認收工，例如 50 項任務只做完 35 項就宣告完成）、self-preferential bias（自己審自己的產出，手會不自覺放鬆）、goal drift（對話輪數一多、幾輪 compaction 下來，你早先講的「不要做 X」邊界條件被壓縮消失）。雙 Claude 互審能治的正是前兩種：把「做」跟「判斷做完了沒」拆進兩個完全獨立的 context，審查者沒有自己的產出要護航，也沒有一路做下來的疲勞感。第三種 goal drift 則要靠拆更多獨立目標的 subagent 來對治——這正是第 17 章動態工作流要處理的規模化問題，這裡先知道有這三種病名就好。

1. 1
   ✋動手做

   Session A 在 Plan 模式草一份計畫

   開一個 session，進 Plan 模式（Shift+Tab 切到 plan），讓它把實作計畫寫出來，但先別動手。

2. 2
   ✋動手做

   Session B（全新、零 context）來批判這份計畫

   另開一個全新 session，把計畫貼給它，要求它當「資深工程師 reviewer」，專門挑這份計畫漏了什麼、哪裡有風險。因為它沒參與規劃，看得比較冷靜。大約 2–5 分鐘，換來的盲點清單很值。

3. 3
   ✋動手做

   把審查意見併回去，修好再執行

   把 B 挑出的問題交回 A 修正計畫，確認都處理完，再切出 Plan 模式開始實作（可搭 auto-accept）。

   ✅ 你會發現

   全新 context 的審查者，常會點出原作者「想當然耳」而跳過的邊界情況——這正是 dual-Claude 比自己審自己更可靠的原因。

實際文字大概長怎樣？延續前面「幫報表加匯出欄位篩選」的例子，Session B 收到的指令可以是：

# 貼給 Session B（全新、零 context）的指令
用「資深工程師 code reviewer」的角度看
@src/reports/exportFilter.ts 這份實作，
挑出邊界情況、競速條件（race condition）、
以及跟現有匯出邏輯風格不一致的地方。

拿到意見後，貼回 Session A：「這是另一個 reviewer 的意見：〔貼上 Session B 的回覆〕，處理掉這些問題。」——整個循環大約多花 2–5 分鐘，換到的盲點清單通常很值得。

max 與 ultracode：一個加深推理，一個改變做事方式

max 和 ultracode 看起來都在 /effort 選單裡，卻不是同一個維度：前者是單次模型呼叫投入多少推理，後者是 Claude Code 是否要把有份量的工作自動編排成動態工作流。可用的 effort 等級仍取決於你正在用的模型；完整支援時由低到高是 low → medium → high → xhigh → max。

官方把 max 定位為「不以 token 支出為限制、追求最高能力」的選項；不過 effort 是行為訊號，不是一個解除所有輸出限制的固定 token 預算。它讓模型在同一任務上更願意投入推理，而不是替你移除模型、方案或 max_tokens 的其他限制。

所以若只比較單一模型呼叫想得多深，max 的層級確實高於 xhigh；但 ultracode 的價值不在多想一級，而在於不必每次都下「use a workflow」這類指令，Claude 會把一個請求拆成理解程式碼、修改、驗證等多個工作流。這也不保證每一項任務都平行展開——是否值得用工作流，仍由 Claude 依任務規模判斷。

官方規則之外：達人實測看見的成本與品質取捨

這裡不能把「max 比較省 token、只是比較慢」當成定律。✅官方 Anthropic 的說法是：max 不限制 token spending，可能帶來更深推理，但也可能出現 diminishing returns 或 overthinking；Dynamic Workflows 則可能比一般 Claude Code session 消耗顯著更多 token。也就是說，兩個旋鈕改變的是不同成本來源，官方沒有保證哪一個在所有任務都更便宜。

🌐社群 雙模型規劃與 dual-Claude 獨立審查為社群最佳實踐（Jules Boiteux／Vibe Coding Academy），非官方文件模式；👤達人 plan-then-one-shot ＋ reviewer ＋ /effort 出自 Boris Cherny 個人實踐；✅官方 effort、max、ultracode 與 ultrathink 的機制，出自官方 Model configuration 與 Dynamic Workflows 文件；👤公開使用者實測 成本與品質觀察取自上方 Alicicek03 與 coolreddy 的公開回報，皆為非受控、不可保證的個案；實際可選等級請以你目前版本的 /effort 選單為準。

15.6　80/20 規劃法：八成力氣花在計畫上

有個社群裡很受用的比例原則：把約 80% 的力氣花在規劃，只留 20% 監督執行。聽起來反直覺——不是該趕快動手嗎？但實務上正好相反：計畫想得越透，執行就越不會歪、你要回頭糾正的次數就越少。規劃時要把需求、依賴關係、邊界情況都想清楚，剩下的執行交給 Claude，你只要盯著別讓它跑偏。

🌐社群 80/20 規劃法與退出 Plan 模式 checklist 為社群最佳實踐（Jules Boiteux）。

15.7　/simplify 與 /code-review：改完之後，找人自己再審一遍

寫完、改完程式之後，別急著收工，跑一個收尾審查。這裡有兩支相關但職責分開的指令，不少流傳的教學會把它們講成同一件事，這裡先把差別講清楚，免得你以為跑了 /simplify 就等於做過程式碼審查。

💡 /simplify 用法：在一輪變更之後跑，可以加聚焦範圍

# 對整輪變更跑一次收尾審查
/simplify

# 只聚焦某個面向
/simplify focus on error handling

# 只審某個路徑
/simplify src/reports/

💡 /code-review 用法：抓正確性 bug，強度與輸出方式可調

# 中等強度，找到問題直接在本機修好
/code-review medium --fix

# 對第 1234 號 PR 跑雲端多代理深度審查（ultra 專屬）
/code-review ultra 1234

# 找到的問題直接貼成 PR 行內留言，不動你的檔案
/code-review high --comment

強度怎麼選：日常小改動 low／medium 夠用；要合併進主分支前的把關用 high 起跳；ultra 是唯一會把任務丟上雲端、派多個代理平行深度審查的等級，適合真的要動刀的大改動或別人提的 PR，跑起來比較久也比較貴，別當日常習慣用。

兩支指令跟前面 15.2 的「驗證閉迴圈」是三件互補的事：閉迴圈確認功能對不對（測試過沒過）、/code-review 抓藏著的 bug、/simplify 收寫得乾不乾淨（重複邏輯、能不能用現成的、dead code）。三個都跑過，交出去的東西才是真的又對、又沒有藏雷、又整齊。

✅官方 /simplify 與 /code-review 的分工、強度分級與 --fix／--comment／ultra 用法出自官方指令文件，實際版本行為請以 --help 為準；👤達人 收工儀式與自訂 /go skill 出自 Boris Cherny 個人實踐。

15.8　五個最常見的失敗反模式，以及怎麼破

最後收一份官方整理的「踩雷地圖」。這五個是大家最常掉進去的坑，每個都附上修法。對照看看，你最近是不是中了哪一條：

✅官方 五大失敗反模式與「提供具體 context」皆出自 Anthropic 官方最佳實踐。

這五個坑背後其實有個更底層的共通點，跟本章開頭的「拿證據說話」互相呼應：Boris Cherny 提過他處理 Claude 犯錯的方式——不是每次都口頭糾正就算了，而是把糾正寫進 CLAUDE.md 或某個 skill 裡，讓同一個錯不會在下一個 session 重演。這跟反模式③（CLAUDE.md 過度指定）看似矛盾，其實是一體兩面：CLAUDE.md 該做的是「把踩過的雷變成規則」，不是「把你能想到的規則都先寫一遍」——前者是精煉、越改越薄；後者是堆積、越改越厚。連 15.4 提到的 93% 核准疲勞數字都是同一個道理：不管是「跳出視窗要你按確認」還是「Claude 說已完成」，只要你沒有真的停下來查，這個訊號就只是安慰劑。

👤達人「把糾正寫進 CLAUDE.md」出自 Boris Cherny 個人實踐。

小結

走完這章，你掌握了大師篇「驗證與規劃」的核心心法：

• 四階段工作法：探索 → 規劃 → 實作 → 提交，把「想清楚」跟「動手做」分開；一句話 diff 才跳過規劃。
• 驗證靠閘門不靠叮嚀：給它會回傳通過／失敗的客觀檢查，逼它拿證據說話。閘門四級——寫進 prompt → /goal → Stop hook → 對抗式 subagent——依風險往上加。驗不了的就別 ship。
• 別讓同一個 Claude 球員兼裁判：規劃用強模型、執行用快模型；審查找一個零 context 的全新 Claude，盲點挖得更乾淨。
• Auto mode 是研究預覽，不是安全保證：它用分類器取代逐次審核，但約六分之一的危險動作可能漏放，受保護路徑與非互動模式各有各的眉角；近期甚至傳出因 93% 核准疲勞改回 Manual 預設，版本行為請自行核實。
• 收尾分兩支指令：/code-review 抓正確性 bug，/simplify 收重用性與乾淨度，兩者職責不同、別只跑一個；對照五大反模式自我體檢，多數坑的解藥都是「一開始就給足具體 context」。

動手試試

1. 挑一個你最近交給 Claude 的任務，不要只說「做好它」，改成用 /goal 設一個機器可驗證的完成條件（例如 /goal "lint passes and all tests are green"），看它每一回合怎麼自己重新檢查到達標。
2. 找一份你覺得「應該沒問題」的計畫或一段剛改完的 code，另開一個全新 session，把它貼進去、要求對方當「資深工程師 reviewer」專挑毛病。比較看看：全新 context 的它，是不是點出了原作者漏掉的東西？
3. 把你最近一輪改動跑一次 /simplify，看它在 reuse／quality／efficiency 上抓出哪些可以收乾淨的地方。
4. 同一輪變更分別跑 /code-review medium 和 /simplify，比較兩份報告抓出的東西有什麼不同——這能幫你確認自己真的分得清兩者的分工，不是背口訣。
5. 設過 /goal 之後，中途打一次不加參數的 /goal，看它現在回報的已跑回合數、token 花費，和評審模型最新一次判斷「還沒達成」的理由是什麼。
6. （進階、謹慎）在一個無風險的玩具專案裡用 Shift+Tab 切到 Auto mode 跑一個小任務，感受「背景分類器」的節奏——但切記，正式專案的破壞性操作別只靠它把關。