80 分鐘
開發與驗收分離
正式測試開始前，先確認 Module 2 定義的開發集／驗收集切分規則沒有被破壞：Prototype 的版本必須在看到任何驗收集案例之前就已凍結（version freeze）。
- 1第一步
凍結 Prototype 版本，記錄凍結時的 run_id，此後不得再依驗收結果調整此版本。 - 2第二步
在驗收集的每一筆案例上執行凍結版本，依 Module 3 的 run log 欄位完整記錄。 - 3第三步
若必須修改 Prototype，一律視為新版本，重新走一次凍結與驗收流程，不能沿用舊版本的驗收分數。
注意
常見錯誤：驗收測試進行到一半發現某類案例表現不佳，臨時「修一下」提示詞後繼續用同一批驗收集跑完。這樣得到的分數已經被驗收資料污染，不能代表真正的驗收結果。
重點: 版本凍結是驗收測試可信的前提；凍結後若修改原型，就必須視為新版本重新驗收。
80 分鐘
練習：找出 Failure Log 中的錯誤
以下是一份 failure log 摘要的第一版草稿（v1）。請先自己找出至少一個問題，再往下看修訂後的版本（v2）與修訂說明。這是本課程「一個逐步完成的範例，包含至少一處錯誤及修訂說明」的練習。
Failure log 摘要 v1（有問題的草稿）
整體正確率：92%（37/40 案例正確）
結論：表現良好，建議進入下一階段。
Failure log 摘要 v2（修訂後，逐類別揭露）
- 一般案例（24 筆）
- 正確率 96%（23/24），無重大錯誤。
- 缺漏資訊案例（8 筆）
- 正確率 88%（7/8），1 筆將「無法回答」誤判為可回答並給出臆測答案（重大錯誤）。
- 來源矛盾案例（4 筆）
- 正確率 75%（3/4），1 筆未偵測到文件矛盾，直接引用較舊版本（重大錯誤）。
- 無答案案例（4 筆）
- 樣本數過少（4 筆），本次結果僅供參考，不足以下結論，需擴大樣本後重測。
- 重大錯誤總計
- 2 筆重大錯誤（缺漏資訊 1 筆、來源矛盾 1 筆），佔全體 5%，但均屬「AI 自信給出錯誤答案」類型，風險高於一般錯誤，即使整體正確率達 92% 也不能忽略。
注意
修訂說明：v1 只給一個整體正確率 92%，把「AI 自信給出錯誤答案」這種高風險重大錯誤，跟其他輕微錯誤混在一起平均掉，也沒有依案例類別拆分，更沒有揭露「無答案案例」樣本數過少的問題。v2 依類別分開報告、明確標出重大錯誤與其風險屬性，並誠實揭露樣本不足的類別，才是 IL 201 要求的失敗分析。
重點: 一個 92% 的整體正確率可能藏著兩筆「AI 自信給出錯誤答案」的重大錯誤；沒有拆分類別與標出重大錯誤的分析，無法讓 Sponsor 做出正確判斷。
80 分鐘
寫出你自己的 Failure Log
Failure log 最低欄位（沿用 SYN-CS-001 failure_log.csv 格式）| 欄位 | 說明 |
|---|
| case_id | 對應驗收集的案例識別碼 |
|---|
| case_category | 案例類別 |
|---|
| is_critical_error | 是否為重大錯誤（例如自信給出錯誤資訊、違反權限限制） |
|---|
| error_description | 錯誤的具體描述，而非「不太準確」這類籠統說法 |
|---|
| rework_needed | 人工需要修正的程度（無／小幅／大幅重做） |
|---|
資訊
SYN-CS-001 的 failure_log.csv 與 experiment_results.csv 提供合成範例，可作為你撰寫自己 failure log 前的格式與詳細程度參考，不可直接複製套用到你自己的專案結論。
- 1練習
針對你在 Module 3 的原型，至少完成 10 筆驗收集案例的測試與 failure log 記錄，依案例類別分別報告正確率，並單獨列出所有重大錯誤。 - 2自我檢核
確認你的 failure log 沒有用整體平均掩蓋任何重大錯誤，也沒有把樣本不足的類別當作已有定論。
重點: Failure log 的價值不在於算出一個好看的整體分數，而在於誠實揭露哪裡會出錯、錯得多嚴重，以及有多少證據支持這個結論。
