裝工具很容易，結案才是工作：我的 AI 工具試用回顧制度

評估是入口，結案是出口。兩件事，回答的是不同的問題。

我在引進新工具、新 skill 之前也會做一堆功課，看架構、比功能、做各種推演，但那些評估最多只回答了「這東西值不值得試」。等真的裝進 workflow 之後，當初那個「值得試」的判斷到底對不對，往往就再也沒有任何環節回頭驗收了。

我建立這套試用回顧制度的動機非常單純：我很清楚自己的惰性，預判自己裝了新東西之後一定會忘記回頭確認。如果沒有一個獨立的機制在固定時間點把你叫醒，試用就永遠不會有結案的一天。

裝之前寫好判死條件，時間到讓機制叫醒你

我最後把這套做法壓成一條固定的工序，六個步驟：

1. 開案：引入的當下就把驗收指標與判死條件寫下來，並訂好回顧日期，全部記進帳本，進行中的一份、結案的另一份。判死條件必須在裝的那天決定，不能等到期了才邊看邊想，那樣只會變成事後找理由保留。
2. 提醒：到了回顧日，機制會在我日常做研究的那個目錄裡主動跳出來，每次開新 session 時提醒一次，完全不依賴我「有沒有想起來」。
3. 看行為：看它這段期間實際被呼叫、被觸發、產出過什麼的紀錄，而不是看它是不是還安靜躺在進行中的帳本上。
4. 裁決：三選一。KILL 是判死，KEEP 是留著，DEFER 是證據本身有問題、重新觀察一輪。
5. 執行：判 KILL 就把它從 workflow 裡拆掉；判 KEEP 就決定它接下來怎麼放，最常見的是升為常備，也就是不再列管、當成日常設備的一部分。
6. 沉澱：把可以跨專案複用的結論寫進我的長期筆記。

觀察期都交了白卷，六個案子走出三種結局

為了說明裁決怎麼進行，我挑一組表面現象相同的案例出來。這六個是為了示範挑的一組，不是帳本上所有同類案例的全部。

這六個工具在回顧時都沒有留下可以算數的成效，但裁決主要探究零進展背後的原因，因而分岔出 KILL、KEEP、DEFER 三種不同的結論。

• grok-build（xAI 的 CLI）：拿它當判官的呼叫全數失敗。用了，但沒有一次成功，判 KILL。
• codex2api：探測本身是成功的，但這個代理需求隔天就被既有路徑接手，不再需要第二套，判 KILL。
• recursive-research：整個觀察期內，它負責的那類場景一次都沒發生，所以從頭到尾沒被觸發過，判 KILL。
• agnix（設定檢查工具）：每天都有跑、每次都有回報，只是比對後確認回報的全部不是真問題。機制本身運作正常、只是那段期間確實沒有真問題，判 KEEP。
• compact-guard（我自己寫的 context 保護 skill）：整個觀察期內沒有發生過任何一次內容遺失，判 KEEP 並升為常備。
• Trail of Bits skills：回頭檢驗才發現，當初用來評估它的那組對照實驗設計有瑕疵、結論不能採信。這種情況不能判死也不能留，判 DEFER，重新設計觀察再看一次。

recursive-research 和 agnix 剛好是一組對照：前者是連題目都沒出現過，後者是題目有出現、只是答案全是虛驚。同樣沒有戰功，一個判死一個留下。

留下來的佔了近六成，不是不敢殺而是當初有挑過

翻開全部 152 筆結案紀錄，KEEP 89 筆、KILL 24 筆，留下來的佔了全部結案的近六成。這裡的分母是全部 152 筆，其中有一批早期格式的條目沒有回填裁決欄，所以剩下那些不是第三種結論，是當年沒記。

表面上看 KILL 是少數，但這不能解讀成回顧時下不了手。能進到試用階段的東西，前面本來就先過了一輪引入評估；每一次判 KILL，本質上都是在推翻自己當初「這值得一試」的判斷。

引入評估回答不了「當初判斷對不對」，但它確實過濾掉了一批一開始就不該裝的東西。所以引入端把關越準，走到結案時留下來的自然越多。判死的比例應該被當成引入品質的回饋訊號，而不是拿來衡量制度有多敢砍的分數。

這不是說近六成一定健康。同一個數字也可以解釋成結案標準太鬆。要分辨是哪一種，得回去翻每一筆 KEEP：當初寫的判死條件，到期有沒有真的拿出來對過。看比例本身分不出來。

不砍也不常備：退到手動呼叫的第三條路

裁決只有三種，但 KEEP 之後怎麼處置不只一種。除了升為常備，還有第三條路：降級。

以 explain-diff 這個我自己寫的 skill 為例，整段觀察期內完全沒有自然採用，也就是說我從來沒有在任何一次工作中自然而然用到它，唯一一次執行是安裝當天的測試。零採用照理說就是判死。

但我當時的處置是把它退出自動觸發，降級成只在我明確叫它時才跑。判準是看留著它還要不要付成本。掛在自動觸發上，它就一直佔著 context 裡的位置，這是成本；退出之後這個位置空出來，日常不再有任何負擔，需要時打一個 command 就回來。

跟直接刪掉的差別在這裡：刪掉是推翻當初「這值得一試」的判斷，降級不是。我認為那個判斷還算數，只是它適合的位置從常駐改成待命。這種處置也因此不計入判死的比例。

驗收機制自己也會出包

這套制度自己也踩過兩次雷。

第一個失誤在暫停狀態的設計。有些試用沒有固定週期，要等某件事自然發生才有東西可看，所以我設計了一種「等事件發生再回來看」的標記。本意是事件驅動，實作出來卻是永不提醒：沒有任何東西負責監聽那個事件，標記只是寫在檔案裡的願望。這等於又退回靠人腦想起來，違背整套制度的前提。

廢除那天我先數了一下，帳本上掛著這種標記的條目是 0 個，從設計出來到那一刻沒有任何一筆真的用它。所以我沒有修它，直接廢除，改成把回顧日期拉遠當最後防線，時間到了照樣提醒，只是那次回顧改成回頭對帳、確認這段期間那件事到底有沒有發生過。

第二個失誤是手動搬檔。整理帳本時，我把一筆還沒走完結案流程的觀察誤搬進結案帳本，後來跟另一份紀錄比對才發現不對、移回進行中。同一個名字在結案紀錄上留有兩行，這是帳本上抹不掉的疤。

驗收工具的機制，本身同樣需要被驗收。

先寫下一行判死條件，不用急著建整套系統

如果你也常在 workflow 裡加各種新工具、新 skill，不用急著明天就寫腳本、掛 hook 搞一整套帳本。上面那六道工序是累積出來的結果，不是起點。

起點只有一個動作：在裝下任何東西的那一天，順手寫下它到期怎麼判死。要看什麼才算它有用、什麼情況直接判死、哪一天回來看，三句話寫在你自己看得到的地方就好。

評估是入口，結案是出口。出口先挖好，引入才算做完。