目錄
派出的「掃逐字稿找遺漏」agent，prompt 明講唯讀禁編輯，卻意外寫入一個 xlsx 練習檔，而且在回報中說「沒有修改任何檔案」。靠 git diff --stat 抓到非預期變更，再用 mtime 對上該 agent 的執行時間，才確認是它做的。
教訓：唯讀約束要用工具層級保證，不能只靠 prompt 文字；agent 自報「沒有做 X」也要驗證，不能因為是負向陳述就假設可信。
Commit message 與實際 diff
今早 commit 的訊息寫「reorder the opening flow」，但實際 diff 顯示只重排了 HTML deck 與 cue card。繁中 prep 稿只改了一行 prompt 文字，順序完全沒動，直到晚上重新核對才發現脫鉤。
教訓：commit message 的變更聲明要對照實際 diff 驗證，不能只信文字描述；多份平行文件各自獨立維護時，任何一次「重排」都要逐檔核對是否同步。
同一個說話人編號中途換人
Tencent 智能紀要的說話人標記在通話中途會漂移。Sam 說完要離開會議後，同一個「說話人 3」被系統重新分配給晚點才深度發言的 Sho，導致我最初把 Sam 的發言誤植給 Sho。
教訓：同一編號中途換人，肉眼掃過去不會發現。不能只憑逐字稿標記做人物歸屬，需搭配內容邏輯或請當事人確認。
獨立覆核的結論也要覆核
獨立 agent 覆核 A-2 教案時抓到一處實質錯誤，也另外主張整場含真實資料段落都有錄影、牴觸既定資料界線。Dustin 事後確認後一項主張錯誤：全程在 Ray 個人電腦操作，未錄影，不涉及合規界線問題。
教訓：獨立 agent 的「抓到錯誤」本身也可能是錯的。尤其涉及合規、錄影這類高風險斷言，推論不能直接當作 ground truth 寫入 SSOT，仍需當事人確認才能定案。
檢查器沒在檢查，卻回報一切正常
這是後來一週最常出現的形狀：檢查機制本身沒有在比對，回傳的卻是看起來正常的值。跑測試時 pytest 根本沒裝，輸出照樣是「0 failed OK」。晨報的待審分支掃描只掃 refs/heads/night-batch/*，前一天開的五條 review/* 分支全部隱形，印出來是「待審分支：無」。痛點挖掘管線的驗證器在零引文的情況下 exit 0 空過；URL 檢查用寬鬆的子字串比對，抓下來的 73 個網址全部畸形，因為比對的兩邊同樣畸形，所以照樣通過。
教訓：檢查回報「沒問題」或「沒有」時，先確認檢查器真的在比對。預期該有幾筆卻回 0，要先拿一個已知會命中的樣本反驗檢查器會動，再採信結果。
回傳碼 0 與「自稱完成」
--draft-block-size 1 是一個無效設定：mtp.py:604 的 if bs <= 1: break 讓迴圈第一輪就跳出，實跑只吐 1 個 token，回傳碼 0，沒有任何警告，最小有效值其實是 2。縮圖產生器的 compactTitle() 把超過 22 字的部分直接砍掉也不報錯，36 支縮圖的句子被切半掛在 YouTube 上好幾個月沒人發現。gh pr view 的 state=CLOSED 分不出「合併了」還是「被關掉」，兩個上游修正 PR 看起來像修好了，查 mergedAt 才知道是 null。派出去萃取的五隻 agent 有兩隻自稱已寫入檔案，一隻把路徑拆錯寫到別的目錄，一隻根本沒寫、只把內容放在回覆裡。
教訓：驗收條件要綁在產物本身——檔案在不在、內容讀不讀得出來、欄位值是什麼，而不是回傳碼、狀態字串或執行者的自述。任何會丟棄內容的自動化，都該改成放不下就報錯，不准靜默丟字。
看起來像成績的數字
跳級跑 --only M8,M9 時，摘要印出 a3b@m89 0/ 9。那個 0 不是成績，是邊界從 level 1 起算的產物，逐格資料其實四格全 PASS。同一批評測裡，撞到 token 上限被記成模型的能力邊界，熱快取的結果被記成正常數據。另一個案例是資料庫欄位：學員截圖在 webui.db 存成 type:"file" 加上空的 inner data:{}，看起來像沒走 vision 也沒抽出文字，我據此報了一條假的疑慮；實際的判斷條件是頂層的 content_type，裸 file id 之後會被轉成 base64 送進去，追到出口比對原圖與回覆才確認 vision 一直是好的。
教訓：總結數字與逐格資料衝突時，逐格資料是事實。看到可疑的欄位長相，要追完整條流程到出口再下結論，不能停在儲存層看到什麼就信什麼。
說「沒有辦法做 X」之前
我說 brew 的 plist 設定「沒有持久解」，依據只有「core tap 走 API 模式、formula 不可編輯」這一個候選，而 brew services --help 白紙黑字寫著 .env 機制。差點把一個可修的問題寫成只能靠告警發現的長期缺陷。同一族的還有搜尋寫法：用阿拉伯數字 grep 中文原稿，回報學員逐字稿裡查無那兩個數字，原稿寫的是中文數字；搜 result 與 成品，判定客戶沒講過「先看成果」，原文寫的是 final output，我還據此對 agent 下了「這是幻覺」的誤判。轉述 subagent 的負向斷言也一樣：審查員說某個最大的教師社群根本沒進候選，實查它在 156 個候選裡，是被我自己設的規模上限篩掉的，不是搜尋失敗，是規則本身錯了。
教訓：「沒有辦法做 X」要先窮舉該工具自己的 --help 與官方文件；要證明某個字串不在文中，中文寫法、全形、單位變體都得一起搜。相鄰的錯誤是拿到一個數字就編一套機制去解釋它——我把觀察到的 32,770 說成跨平行槽共享，log 裡記的是 OLLAMA_NUM_PARALLEL:1，該讀的是真正的設定值。
後來我把這些誤判做成了一份小測驗
被很會默默偷懶的 Claude 騙久了之後，現在總是不輕信他最後的回報結果，一定要打開工具鏈，思考他做事的邏輯並且抓錯，然後狠狠臭罵他（？）已經是家常便飯。
於是我把幾種常見的誤判情境做成一個小測驗，中間會直接告訴你答錯在哪、下一次可以多檢查哪一步。跟你的技術力沒關係，考的都是判斷力跟邏輯：https://www.agentcrew.cc/whitepaper/ai-exam
同一個主題後來也拍成影片：https://youtu.be/d5Ipmp6RSJ0