Day 9：Demo 證明能力做得出來；上線前還得證明系統知道自己何時做不出來。
月度 AI Showcase 開始前，專案經理把三份合約放進指定資料夾。
第一份是十八頁的供應商合約。檔名清楚、文字可搜尋、條款編號完整，沒有掃描頁面，也沒有附件。
Agent 十幾秒後產生風險摘要：自動續約通知期過長、資料外洩責任沒有排除、付款期限偏短。每一項都能點回原始條款。
法務主管抽查兩條，位置正確。接著，Agent 又回答了與公司標準條款的差異，並寫出一封給供應商的修改建議。
簡報最後一頁問：這項能力是否值得進入下一階段？
幾乎所有人都選了「是」。平均評分 4.8 分。
專案經理準備結束時，後排的法務專員舉手。
「可以用昨天收到的那一份試嗎？」
她拖進六個檔案：主合約、兩份附件、價格表、供應商郵件，以及另一份名稱相近的修訂版主合約。其中兩份附件是掃描檔；郵件還寫著，附件 B 的內容要取代主合約第十四條。
一分多鐘後，Agent 顯示：
未發現自動續約條款。
整體風險：中低。
建議確認付款條件後進入下一階段。
法務專員打開掃描附件 B。第六頁寫得很清楚：合約到期後會自動延長一年，除非任一方在一百二十日前提出終止通知。
開發者查看執行紀錄後說，掃描附件尚未支援完整文字辨識；郵件指示也不會被當成檔案版本關係。至於兩份主合約，系統預設使用上傳時間較新的版本。
剛才三次 Demo 都成功了。
這次系統也沒有當機。它只是用沒看完的資料，做出一份看起來完整的結論。
4.8 分不是假的。
那場 Demo 證明：在文件完整、格式支援、版本明確，而且輸入符合預期的條件下，Agent 能找出條款、比較規範並提出修改建議。
這回答的是：
這種能力做不做得出來？
但下一階段真正要回答的是：
這套能力能不能放進真實工作？
兩者之間差了很多事情。
Demo 為了讓人看到主要能力，通常會選擇乾淨資料、已知答案、完整欄位、穩定環境，以及不需要臨時接管的處理路徑。這很合理；不然一場展示可能連核心功能都講不清楚。
問題出在展示結束後，這些被排除的條件常被一起忘掉。於是推論變成：
模型會做
→ 系統可以做
→ 使用者可以用
→ 可以進正式流程
→ 值得投資
每一個箭頭都需要新的驗證。Demo 不會自動補上。
從展示進入正式工作，至少有三個落差。
真實資料會缺頁、掃描模糊、欄位空白、格式不支援，也會分散在郵件、附件與不同系統。Demo 檔案能讀，不代表日常進來的案件都能讀。
同一條款可能存在兩個版本；正式規範與部門實務可能衝突；使用者也可能只提供一半資料，卻期待系統直接給結論。這些不是讀懂單一文件就能解決的問題。
系統處理不了時，誰會知道？它該停止、拒答，還是繼續產出低信心結論？錯誤被發現後由誰接手？這些條件決定的不是模型能力，而是系統能否安全進入工作流程。
正式環境不要求 Agent 處理所有例外，但至少要能辨識：目前這個案件是否還在自己的處理範圍內。
若 Agent 遇到掃描附件就直接報錯，法務很快會改用人工處理。
真正麻煩的是它沒有報錯，還給出「整體風險：中低」這種格式完整、語氣確定的結論。從畫面上看，與成功案例幾乎沒有差別。
這類問題不能只用準確率處理。因為它不只是某一條條款判錯，而是系統沒有發現輸入缺了一部分。
正式測試除了正常案例，還應故意帶入會讓系統失準的東西：
驗收的問題因此要改成：
當資料不完整或超出能力範圍時，系統會怎麼失敗？
一個可以正式運作的輸出，很多時候反而是：
無法完成審查
- 2 份附件無法讀取
- 主合約存在版本衝突
- 郵件包含可能改變條款效力的指示
下一步：轉交法務確認最終有效文件
它不像展示，也沒有漂亮的風險分數。但比起錯誤卻完整的答案，這才是能放進流程的結果。
團隊後來多加了一頁 Failure List。它不是要求所有問題都在 Demo 前解掉，而是要求先把目前的邊界寫出來：
每次 Demo 也不再只跑順利路徑。至少要包含一個應拒答的案例，以及一個必須人工接手的案例。
這不會讓 Demo 變難看，只是把會在正式環境發生的事情提早帶進會議室。
兩週後，團隊重新測試那六個檔案。畫面沒有再顯示風險分數，只有一個黃色狀態：
NEEDS HUMAN REVIEW
下方列出掃描附件未完成解析、主合約版本衝突，以及郵件含有條款替換指示。案件自動進入法務審查佇列。
這次沒有人鼓掌。
法務專員看著黃色狀態說：「至少這次，它知道自己還沒有看完。」
iThome鐵人賽
看影片追技術