AI 答錯不可怕，可怕的是它看起來剛好可以交付

AI 回傳空白、逾時，或吐出一段無法解析的 JSON 時，產品反而比較容易處理。錯誤很明顯，流程會停，使用者也知道這次不能直接採用。

麻煩的是另一種輸出：標題像標題、摘要讀起來順、分類也在允許的選項裡。它看起來剛好可以放進資料庫，內容卻漏掉原文的限制、把別人的建議當成使用者的待辦，或用很肯定的語氣包住一個沒有根據的判斷。

我把這種東西叫做「看似可交付的錯誤」。它沒有破壞格式，也沒有觸發例外，所以最容易穿過產品原本用來擋錯的地方。

顯眼的錯誤反而容易處理

工程系統很會處理可辨認的失敗。HTTP 狀態不對、欄位缺失、型別不符或超過長度，都可以用確定的規則阻擋。

語意錯誤沒有這麼配合。下面這些輸出都可能通過格式驗證：

摘要很流暢，卻省略了原文的例外條件
分類符合 enum，語意上卻放錯位置
待辦句型完整，內容其實是來源作者的建議
回答附了記錄，結論卻超出記錄能支持的範圍
文案語氣很確定，原始資料仍然是不確定的

這些錯誤必須重新對照來源、理解語境，才知道哪裡不對。輸出越順，使用者越容易跳過這一步。

產品決定模型輸出跨過哪一條邊界

同一句 AI 回答，放在聊天視窗裡和寫進正式記錄裡，風險不同。聊天內容可以被忽略；一旦變成任務、決策、客戶回覆或長期知識，它就會進入後續流程，影響下一個人或下一次判斷。

模型只負責產生輸出。產品負責決定這段輸出現在是建議、草稿，還是已經可以交付。很多問題發生在這裡：介面看起來已經完成，資料狀態也直接被保存，使用者沒有看到中間其實少了一次確認。

原始來源：保留原文、網址與必要脈絡
AI 草稿：允許不確定，也允許被拒絕
已確認內容：人或確定規則核對過關鍵欄位
正式交付：才進入記錄、任務、回覆或決策流程

這四個狀態不一定要做成四個畫面，但產品不能假裝它們是同一件事。

Prompt 不能獨自守住交付邊界

把 prompt 寫清楚很重要。它可以要求保留不確定性、限制輸出格式、引用來源，也可以提醒模型不要把建議改寫成事實。

但 prompt 仍然是生成流程的一部分，不能同時當成最終驗證。系統可以用確定規則檢查必填欄位、允許值、長度與資料關聯；語意是否忠於來源，則需要把來源放在旁邊，讓人能夠核對。

讓同一個模型再回答一次「你確定嗎」，可以提供線索，不能把錯誤自動變成已驗證的結果。

KOFNote 已經保留了什麼，又還缺什麼

KOFNote 會把原始文字與來源網址和 AI 產生的內容分開保存。標題、摘要、分類與標籤也可以在記錄編輯器裡修正。這些設計讓使用者還有機會回到來源，不必只能接受 AI 的版本。

不過，保留來源只解決了可追查性，沒有保證使用者真的會核對。現在畫面上的「幫你讀完了 · 重點」很容易讓摘要看起來像完成品，而不是等待確認的草稿。

這是產品文案也必須承擔的責任。按鈕、標籤和版面會告訴使用者一段內容現在有多可信；如果介面比資料本身更有把握，錯誤就更容易被交付。

可靠性要分給不同角色

AI 適合整理、分類、提出摘要與候選答案。確定規則適合處理欄位、權限、狀態轉換與不能違反的限制。人則負責理解來源、情境與後果。

這不是要求每個 AI 動作都停下來等待人工審核。確認成本應該跟後果一起增加：推薦標籤可以直接建議；建立付費、刪除資料、發送公開內容或形成正式決策時，就需要更清楚的確認。

錯誤進去之後，還要有出去的路

AI 產品不能只設計「成功寫入」。錯誤被發現後，使用者要能找到原始來源、修改結果、知道哪些後續內容受影響，必要時撤回或刪除。

風險越高的交付，越需要留下產生時間、依據、確認者與修正紀錄。這些資訊不一定都要顯示在主畫面，卻應該在問題發生時找得到。

可逆不是失敗後才補的功能。它本來就是 AI 輸出能進入正式流程的條件之一。

真正要交付的是一條責任鏈

一段 AI 輸出能不能用，不能只看它讀起來像不像完成品。還要知道它根據什麼產生、目前處於哪個狀態、誰確認過，以及錯了要怎麼退回。

AI 答錯時，明確的錯誤至少會讓流程停下來。看似可交付的錯誤更危險，因為它讓每一層都以為前一層已經檢查過。

產品的工作，就是把那些沒有發生的確認重新顯示出來。輸出可以很快，交付仍然要有邊界。