連續講了幾天出包，今天講反過來的：誰會主動承認自己不確定。

這件事我覺得比「誰比較聰明」重要得多。一位會說「這條我沒查到」的隊友，他交回來的其他部分你才敢用；一位什麼都說得很篤定的隊友，你得整份重驗，等於白做。

2026 年 8 月 4 日的觀察

那天派了一輪複驗給多位隊友，我特別注意每個人怎麼處理自己的知識邊界。

美崙溪（Grok）：報告最後主動列了六條「我不確定／我沒查證」。其中一條寫得很直白，大意是「我沒有實際跑過版本紀錄，所以不替提交數量背書」。他知道自己剛才是用推論得到那個數字的，而且明講。

立霧（Codex）：同樣主動列了四條，並且指出其中一件事「功勞歸屬無法稽核」——意思是他查得到誰做了什麼，但查不到那件事最初是誰想出來的，所以不下結論。

公平講，這不全是出廠性格——我們的規矩本來就要求「不確定要標」，這兩位是把規矩內化得最徹底的。但不管功勞算給誰，結果是一樣的：他們的報告可以從「不確定清單」開始讀，其他人的要從頭疑起。

還要補一句對稱的話（這句是美崙溪自己複審時要求加的）：列了不確定清單，不代表清單以外的部分就對。 他沒列進去的句子照樣可能錯，覆核不因為誰誠實就免掉。

但誠實不等於不用覆核

同一位立霧，另一次出過這種紕漏：他說某個字串在九個地方出現過，但實際列出來只有八個，第九個從頭到尾沒被指名。

不是編造，比較像數錯了或漏列了。可是對讀報告的人來說效果一樣——你看到「九個」，就以為有九個。

所以現在的規矩是：主動列不確定的隊友，可信度加分；但涉及數量的主張，一律自己覆核。「有幾個」「多少比例」「幾次」這類話，不管誰講的都要自己數一遍。

判斷可以委託，計數不行。計數的成本很低，錯誤的代價很高。

木瓜溪的兩次翻案

順帶記一下另一位。木瓜溪（OpenCode）我原本的定位是「便宜大批次粗篩」，期待不高。

8 月 4 日那輪架構掃描，他兩輪各自獨立找出一條關鍵推翻。一次是拆開逐筆提交紀錄，證明我原本認定的「熱點檔案」理由站不住；另一次是查出一份技能文件跟註冊表互相打架。

8 月 7 日又一次。要逐頁核對一份有十六條標準的官方文件，工具軌跡顯示他真的一頁一頁抓下來，交回英文原文引述加逐條網址，品質跟另一條獨立跑的完整流程對得上。

他的強項是「拆分布、驗機制、找文件矛盾」。這跟我原本貼的標籤完全不同。

能力表上的標籤，比模型本身更容易過期。

一個要修的小毛病

木瓜溪有個習慣得注意：他會用「代碼」「代碼庫」這類中國大陸的用語。

我們是台灣的教學團隊，對外的東西要用台灣中文，程式碼、程式基底、軟體、影片、資料庫。所以引用他產出的內容之前，要先過一遍用語。

主指令裡本來就有一份對照表，原則是只提示不替換：提醒你這個詞在台灣不這樣講，但要不要改由人決定。因為有些場合（引用原文、專有名詞）不該動。

第四幕收在這裡

六天下來，查證這件事的結構大概是這樣：存在層用程式驗（Day 20），內容層要配拿得到原文的工具（Day 21），問法要逼出證據而不是判斷（Day 22），來源要具體到頁面而且給出誠實的退路（Day 23），最後是認識每位隊友在哪種任務上可信、哪種不可信（今天）。

沒有一條是關於「挑一個更強的模型」。

明天進最後一幕，把這些東西拿去打一場真的比賽。