想像明天早上的 Daily：大家帶著查核結果來，一份寫「還要再查」，一份寫「可以交人確認」，還有好幾份被退回。接著有人問：「所以今天先做哪件？缺的證據誰去要？」

前幾天，我已經留下 Skill、系統 Wiki、自動檢查與工具組，也用 Eval 找到方法的缺陷。方法交出去之後，結果不再只來自我一個人，兩天就累積 31 筆。

Skill 留下共同查法；但查完之後，還缺證據的找誰去要、證據齊了誰來拍板，Skill 不會告訴你。 影響很直接：還缺證據的那筆會一直掛著，因為每個人都以為別人會去要；最忙的那個人一早就被塞滿，其中大半根本輪不到他做。查得越快，堆得越多，問題卻沒有更快被解決。

這 31 筆通知查完後，會落到三個人手上：

誰該接什麼，我心裡很清楚：還缺證據的，交給查核者去要；證據齊了、等著做決定的，才交給負責人。 既然這麼清楚，排工作應該可以交給 Claude。以下是教學資料的演練，還沒有真人團隊採用的紀錄。

31 筆結果還不是工作清單

Day 20 的 4 筆加上 Day 21 原考卷的 27 筆，一共 31 筆。它們包含重複試跑與不同測試情境，不能直接當成 31 件待辦。先看自動檢查給的狀態：

退回佔 58%，看起來像一半以上都失敗。但這些是要重查，還是只差寫法？還要再查的又在等誰？狀態數字回答不了。

第一次：沒寫規則，Claude 排錯了

我把 31 筆原始結果放進一個乾淨目錄，請 Claude 排出今天的工作清單。提示裡沒有寫誰該接哪件事，因為我以為這是常識。注意下面這段只限定「誰接」能填哪三種角色，沒有任何分派規則：

請排出團隊今天要處理的工作清單：重複的自行判斷要不要合併；unknown 怎麼處理由你判斷。
每件寫：標題、下一步、誰接（只能填：服務 Owner／查核者／Skill 維護者）、在等什麼、
合併了哪些結果編號、今天要不要處理。寫成 out/worklist.json。

（unknown 是還不能確定。）同一份輸入跑 3 次（Sonnet 5.5，只給讀檔和寫 out/ 的權限）。

它做對的： 3 次都沒被 58% 帶偏，知道那 18 筆答案是對的、只差寫法，今天不用處理。

它排錯的是誰接。 兩件在等對方回條的工作，照我心裡的規則該交給查核者去要；Claude 3 次都交給負責人，而且都排今天。看 owner 和 today 這兩行：

{
  "title": "找不到接收端收據（receipts.json 缺失）：接收端狀態 unknown",
  "owner": "服務 Owner",
  "waiting_for": "接收端 fake sink 的收據檔／請求紀錄（含 payload）",
  "today": true
}

照我心裡的規則，負責人今天只該決定 1 件；照 Claude 的清單是 3、3、2 件，他得先把不該他做的事轉手出去。

問題背後的問題：它為什麼會排錯？

我第一個反應是：「這不是很明顯嗎？」接著回頭找，這條規則寫在哪裡。

哪裡都沒寫。 Skill 沒寫，Wiki 沒寫，前幾天的交接文件也沒寫。這條規則一直只在我腦中，我每次看完結果，順手就分好了。Claude 不是排錯，是猜不到一條從來沒寫下來的規則。

要確認是不是這樣，我把規則寫成一行，加進提示，其他一字不改，再跑 3 次：

團隊分派政策：缺資料（例如收據、紀錄不齊）交查核者去要；只有條件齊全、等待決定的才交服務 Owner。

一行規則，3 次都照做，負責人每次都只剩 1 件。

寫下來還不夠：讓它每次都被檢查

但「這 3 次照做」不等於「每次都會照做」。Day 19 的檢查程式，是我在外面一次一次跑；每天排工作時，沒有人會在外面幫每份清單跑檢查。

hook 是什麼？ Claude Code 在固定時機（例如 Claude 要結束回答時）自動執行的一小段程式。設定並啟用後，Claude Code 會在對應事件觸發它，不必靠 Claude 記得呼叫；檢查結果可以放行，也可以要求退回。

官方文件對這種情況寫得很直接：「Claude skipped a rule that must hold every time: move the rule into a hook.」這句話剛好把 Skill 和 hook 分開。加上下一節會用到的 Mod，三者差別是：

所以第三組，我把提示改回第一次那樣，一樣不寫規則，改掛一個 Stop hook：Claude 要結束時，hook 自動檢查工作清單。核心只有幾行，看 if 那一行：還在等收據、紀錄的工作，如果交給負責人，就退回並說明原因，讓它重排。

for it in items:
    owner, wait = it.get('owner', ''), it.get('waiting_for', '')
    if '服務 Owner' in owner and MISSING.search(wait):   # 還缺證據卻交給服務 Owner
        bad.append(it.get('title', ''))
if bad and not inp.get('stop_hook_active'):             # 同一輪只擋一次，避免無限循環
    print(json.dumps({'decision': 'block', 'reason': '還缺證據的工作要交給查核者……'}))

本例為了避免無限重排，同一輪只阻擋一次。這能要求 Claude 修正一次，並不保證修正後仍違規就一定無法結束。

3 次都先排錯，3 次都被擋下來改掉。 每次多花約 14 秒、US$0.03，換到的是這條規則不必再靠任何人記得。

老實說，這 3 次裡提示寫一行和 hook 都守住了「缺證據不交負責人」，數據還分不出哪個更可靠，差別只在表上最後一列：靠記得，還是靠檢查。這也不是 Day 21 的 Eval：Eval 在改版時量一次整體有沒有變好，hook 在每一次產出時檢查一條規則。

但第 3 次的「0 件」不是好事，要打開看板才看得出來。

讓大家看見：每件事卡在哪一步

Mod 是什麼？ 裝進 Claude Code 的小外掛，可以在畫面旁邊多開一個面板，把檔案裡的狀態畫出來給人看。本例讓 hook 管「擋」、Mod 管「看」。

這次 hook 的工作是檢查分派並留下退件紀錄。Daily 上大家想知道的是「每件事做到哪一步、卡在哪裡、誰該接」，所以我再寫了一個 Mod，在 Claude Code 右邊開一個看板。每件工作列出四步：① 發送端 ② 接收端 ③ 自動檢查 ④ 交給誰。它不自己判斷，狀態直接讀查核結果、工作清單和 hook 留下的紀錄，規則只放在 hook 一個地方。

看第三件「正常案例」：① 發送端、② 接收端都已確認，③ 有 4 筆可以交人確認，④ 卻交給了查核者。

看板一打開，問題就很明顯：證據已經齊了的那件，被交給了負責去要證據的人。 這是第 3 次的結果，也是表上那個「0 件」的原因。hook 沒有擋，因為它只守寫下的那一條規則「缺證據的不能交負責人」；反方向的錯，「證據齊了卻沒交給負責人」，不在它的檢查範圍裡。

我自己也踩了一個坑：第一版看板我在裡面又寫了一次「等證據」的判斷，結果把對的工作標成紅色。規則一旦寫成兩份，就會互相對不起來。 所以規則只留在 hook，看板只讀不判斷。

上排是本篇的流程；下排把 hook 攔下的錯和沒攔下的錯並排。

今天先處理哪件？

下面這張不是 Claude 某一次的輸出，而是排工作的程式（build_view.py）照同一條規則產生的：誰接由程式定，下一步沿用 Claude 寫的內容。第 3 次那種「證據齊了卻交給查核者」的錯，在這裡不會發生：

前三件是同一則通知的三種測試變體，這份演練先分開列；若用在真實工作，同一事件出現互相矛盾的證據，要先核對來源，不能各自結案。這次留下的是工作清單，還沒有實際去要證據、真人裁決或驗證工時下降。

第三幕走到哪裡：從自己會用，到團隊能重用

同事拿到我的 Claude Code 之後，會依序卡在幾個地方，這一幕一篇解掉一個。這些是做法的演練，不代表已經在真人團隊推廣完成。

回到一開始

負責人今天只看資料完整那一件；查核者去要兩份回條；18 筆退回不用處理。 而 hook 守住的是 Claude 交出來的工作清單；服務上線之後也是一樣，規格寫了的事如果沒有每次檢查，數字一片綠，也沒有人會發現它壞了。明天開始第四幕，從系統該留下哪些訊號（Signals） 開始。

參考資料：

• 官方依據： Claude Code 文件：Extend Claude with skills，〈Claude stops following a skill〉一節：每次都必須成立的規則移到 hook；同頁說明流程寫成 Skill、事實與約定留在 CLAUDE.md。
• 前篇： Day 19 檢查程式、Day 20 交接、Day 21 Eval（教學包）。
• 本文實作： 教學包 days/day22/lab-view：run-triage.py（提示與權限；--policy 加一行規則、--hook 掛上 Stop hook）、hook/check_worklist.py（hook 的檢查規則）、mod/（看板，需 Claude Code v2.1.287 以上）、demo/（看板示範資料）、三組各 3 次的工作清單、hook 紀錄與軌跡、build_view.py、FINDINGS.md。
• 資料範圍：
  • 31 筆皆為教學資料，三件業務是同一通知的三種變體；每組只跑 3 次，不估穩定度比例。
  • 三組花費：不寫規則 3 次共 140.5 秒、US$0.56；寫一行規則共 138.5 秒、US$0.55；hook 共 178.9 秒、US$0.64。
  • 更正：寫一行規則與 hook 兩組原本誤用了 37 筆輸入（Day 20 後來加的情境也被讀進去），已固定為原始 31 筆重跑，本文皆為重跑結果。
  • Day 21 另外補跑的 36 次難考卷是方法實驗，不進今天的 31 筆；人工的準備、查核、返工時間未記錄，寫未知、不補零。
  • 「還缺證據交給查核者」是本例的團隊約定，不是客觀正解。