IL 201 的原型只需要證明價值假設，IL 301 的 Pilot 版本則必須要能被觀察：出了問題時，團隊要能知道發生了什麼、影響多大、要不要啟動停止權。監測設計的挑戰在於「記錄夠用的資訊」和「不過度蒐集敏感資料」之間取得平衡。
| 項目 | 說明 |
|---|---|
| 執行版本與時間 | 每次執行對應的程式／設定版本、時間戳記 |
| 輸入摘要（不含完整個資） | 輸入的類型與長度等中繼資訊，避免直接記錄完整敏感內容 |
| 信心程度與決策 | AI 是否判斷自己有足夠信心處理，或觸發了人工接手 |
| 處理結果與人工覆核 | 最終輸出、是否經過人工修改、修改幅度 |
| 例外與錯誤代碼 | 對應 Module 4 錯誤分類表的錯誤類型 |
注意
「AI 出錯了」不是一個可以處理的描述，必須先分類才能設計對應的處理策略。同一套重試機制不可能適用所有錯誤類型。
| 類型 | 範例（SYN-CS-001） | 處理策略 |
|---|---|---|
| 工具／系統失效 | 知識庫查詢逾時或服務中斷 | 重試一次，仍失敗則轉人工，不可靜默略過 |
| 資料缺漏 | missing_context 類案件，找不到足夠資訊回答 | 明確標示資訊不足，附上已知的部分資訊，轉人工補充 |
| 資料矛盾 | conflicting_sources 類案件，多份文件互相矛盾 | 不擅自選邊，列出矛盾點並轉人工判斷 |
| 低信心輸出 | AI 自評信心低於門檻 | 不直接送出，附上信心分數轉人工核可 |
| 越權要求 | 使用者要求超出核准範圍的資料或動作 | 拒絕執行並記錄，不得因為使用者堅持而放寬範圍 |
資訊
人工接手不是「AI 做不到就丟給人」的模糊概念，而是要有明確的觸發條件、清楚的介面設計，以及可被追蹤的回應時效，否則接手常常變成沒人真的處理的黑洞。
| 項目 | 說明 |
|---|---|
| 觸發條件 | 對應 Module 4 錯誤分類表的每一種類型，明確列出何時觸發接手 |
| 接手介面 | 人工看到的畫面要包含 AI 的判斷理由、信心程度、引用來源，而不是只有「請人工處理」四個字 |
| 回應時效 | 不同類型的接手案件，各自的預期回應時間（例如越權要求需即時處理，資料缺漏可排入一般佇列） |
| 責任歸屬 | 接手後由誰負責最終決定，以及若接手後仍無法解決，下一步升級給誰 |
系統顯示「此案件無法自動處理，請人工協助」，沒有任何 AI 判斷的脈絡或緊急程度標示。
為什麼人工接手介面只顯示「此案件無法自動處理，請人工協助」是不合格的設計？
