昨天結尾說，這些工具的失敗有一種共同形狀：安靜地失敗。今天講最極端的那個版本。

先講一個很蠢但很難查的狀況

2026 年 8 月 5 日，我照慣例派一件活給負責大批次粗篩的那位。

他跑完了。讀了檔案，正常結束，回傳成功。

然後什麼都沒有。零輸出。

我以為是我的指令有問題，把工單縮短再試一次，一樣。再縮短成一句最簡單的問答，還是一樣：讀檔、正常結束、零輸出。

那顆模型當下就是壞的。而它在模型清單裡好端端地列著，看起來完全可用。

換一顆模型，同一題，秒答，而且會主動去搜尋和讀檔。

教訓寫進了能力表：他沒回話，先換模型，再懷疑他。

這件事之所以難查，是因為所有訊號都是綠燈。沒有錯誤碼、沒有例外、結束狀態正常。你唯一能依據的是「應該要有東西，但沒有」。

四個工具，四種輸出行為

更麻煩的是，「零輸出」對不同工具的意義不一樣。

有一位在無人互動模式下，本來就讀不到輸出。這是它的正常行為，不是故障。我一開始不知道，看到空白就以為它死了，重派了好幾次，其實每一次它都做完了。

有一位輸出很乾淨，直接讀就好，中文也不會出問題。

有一位輸出會有編碼問題。

有一位輸出乾淨但速度差距很大，短問句十幾秒，長指令一兩分鐘。

同一個空白畫面，可能代表正常行為、模型故障、還在跑、或輸出編碼壞掉——你光看畫面分不出來，也別急著對號入座。

順帶一提這條的變形：負責廣搜的那位常在成品寫完之後才收尾逾時，回你 exit 1 加一句「timeout waiting for response」。看到逾時先去成品資料夾讀檔——檔在而且完整，就是成功，別急著重派。重派會白跑一輪，還可能把成品蓋掉。exit code 說失敗但其實成功了，跟 exit 0 但其實沒做，是同一個病的兩面。

所以驗收改成看檔案

我後來把驗收方式統一了：不管派給誰、不管它說什麼，只看一件事——要它產出的那個檔案，落地了沒有？

指令裡一定寫清楚：把結果寫到哪個路徑、檔名叫什麼。然後我自己去讀那個檔。

這個做法把所有工具拉到同一個標準上。它有沒有回話、回得漂不漂亮、用什麼語氣說自己完成了，全部不重要。檔案在，就是做完了；檔案不在，就是沒做完。

一個 8 月 7 日的例子，說明為什麼不能鬆手

那天我觀察到，原本「讀不到輸出」的那位，突然讀得到了，而且吐出 2,697 個位元組，內容是完整的完成回報。

看起來是好消息。我在能力表上加了一列，然後補了一句：做法不變。

為什麼不變？因為那是單次觀察，還沒複驗。更重要的是，「有輸出」跟「做成了」是兩件事。它完全可以吐給你一段漂亮的完成回報，而檔案根本沒寫出去。輸出是它對自己的描述，檔案是事實。

一個能力變好了，不代表你可以把已經證明有效的那道關卡拆掉。

這條規矩後來變成主指令的第一鐵律

寫在最前面，凌駕其他所有條款：

不准把「未驗證」寫成「已完成」。工具回 error 就停下驗證，不腦補成功，沒驗證標「待確認」。

會寫得這麼重，是因為這個錯誤的代價不對稱。一個沒做完卻被記成做完的任務，會安靜地待在那裡，直到某天你依賴它的時候才爆炸。而那時候你已經想不起來當初是哪裡出的問題了。

明天講一個更基礎、但在 Windows 上會反覆咬人的東西：中文亂碼。它其實是三種不同的病，得先分流才治得好。