示範案例：安裝教材的交叉審查紀錄

產出內容： Windows／macOS 開發環境安裝教材（README.md、AGENTS.md、windows/install-quick.md、macos/install-quick.md）。
註： 本紀錄保留審查當時的內容。之後教材又有修改：檔名改為 01-install/windows.md、01-install/macos.md，內容也持續調整，與現行安裝指南不一定相同。
產出者： Claude Code（Claude Opus）。
審查者： 5 位 AI 專家，共 3 輪。
結果： 第 3 輪兩位審查者都判定「可以發布」，沒有 🔴 項目。但依現行的停止條件，這個案例還不算完成：macOS 版尚未實機測試，最後一輪的修改也沒有再審查一次（見第 3 輪判斷）。審查者說「可以發布」，不等於流程完成。

---

每一輪概況

輪次	審查者	建議數	接受	部分接受	否決	已處理	紀錄
1	專家 A	9	4	3	2	0	prompt・審查・判斷
2	專家 B、專家 C	36	20	4	5	7	審查・判斷
3	專家 D、專家 E	3	1	1	1	0	prompt・審查・判斷

第 2 輪沒有新的 prompt：教師直接把第 1 輪的 prompt 交給另外兩位專家，而他們看到的是修改前的版本，所以有 7 項是「已經處理過」。

第 0 輪（在審查之前）： 產出者自己先檢查原始內容，實際查詢 PyPI 後發現 faster-whisper-cli 套件安裝後的指令名稱其實是 faster-whisper，文件中的指令與參數都跑不起來。這說明實際驗證比讀文件可靠。

---

帶讀重點：審查者說錯的地方

這是本案例最有教學價值的部分。每一則都是審查者很有自信、但實際上有問題的建議：

輪次	審查者的說法	問題在哪裡
1	PingFang 字型在 xelatex 失敗，是因為 TTC 字型集合檔無法解析	結論對、理由錯。Songti TC 與微軟正黑體也是 TTC 檔卻能正常使用，所以不能斷定是 TTC 的問題。真正原因本紀錄無法確定（產出者一度寫成「字型位置」，同樣沒有根據，後來更正）
1	Intel Mac 需要額外設定 brew 的 PATH	/usr/local/bin 本來就在 macOS 預設的 PATH 中，加了只會讓腳本更複雜
1	把 hash -r 改回 rehash	rehash 在 bash 中不存在，學生的 Mac 若使用 bash 會出錯
1	審查過程中在使用者電腦上執行了 uv tool update-shell	審查者擅自修改設定。之後的 prompt 都加上「只讀不執行」
2	macOS 26 已移除 PingFang 字型	Apple 官方的 macOS Tahoe 字型清單仍列有 PingFang TC
2	腳本失敗時用 throw 或 return 1 停止	學生是把腳本「貼進終端機」執行，這些寫法不一定能停下整段腳本
2	macOS 找不到 brew 時用 exit 1 停止	在終端機直接貼上執行時，exit 1 會把整個終端機視窗關掉
2	用 "中文" | pandoc ... 測試中文 PDF	在 Windows PowerShell 5.1 中，管線傳給外部程式的中文會變成「?」
2	刪除 Set-ExecutionPolicy	另一位專家同一輪的意見正好相反。刪掉後學生執行 npm 會直接報錯
2	MacTeX 約 2.8 GB／超過 6 GB	兩位專家給的數字不同，產出者也無法確認，最後只寫「數 GB」
3	MiKTeX 備援路徑要補 Program Files，因為「環境變數索引延遲」	不存在這種延遲；腳本已重新讀取 PATH

---

從這個案例學到的事

1. 專家會說錯，而且語氣很肯定。 「100% 開箱即用」「保證失敗」這類說法不代表正確。
2. 結論和理由要分開判斷。 可以接受結論、但修正理由；而且產出者自己的理由也可能沒有根據，查不到證據時就寫「無法確定」。
3. 具體指令要放回實際情境檢查。 exit 1、管線編碼這些問題，只有想到「學生是貼進終端機執行」才看得出來。
4. 兩位專家意見相反時，不要多數決。 回到事實判斷。
5. prompt 要列出已決定事項。 第 3 輪的 prompt 加入後，審查者就沒有再重複提出已否決的建議。
6. 要求審查者只讀不執行。
7. 查證用官方文件。 例如 MiKTeX 的設定值，查官方知識庫後確認是 AutoInstall=yes，不是原本寫的 1。
8. 停止條件要明確。 第 3 輪兩位審查者都說可以發布、沒有 🔴，才停止；但 macOS 版仍需實機測試才算完成。