讓每一則 AI 回饋都有證據狀態與責任所有者
AI 回饋要避免過度確定，因為流暢句子可能混合三種狀態：目前輸入直接支援的內容、僅在條件成立時才成立的推論，以及產品暫時無法解決的未知。它也要避免無法兌現的承諾，因為「我會處理好」沒有說明誰擁有動作、哪個外部服務必須回應、承諾何時失效，或失敗後介面顯示什麼。這是產品回饋文字與互動設計問題，不是教使用者核驗單一回答。七欄契約包括證據狀態、推論條件、未知項、可控動作、外部依賴、承諾所有者與時限及失敗終態、過期。確定語氣只能跟隨可觀察狀態。
先拆開證據、條件推論、未知和動作狀態
先標狀態，再寫順暢文案。「目前支援」要能對應具名輸入、系統紀錄或完成事件；「條件推論」必須顯示仍需成立的前提；「未知」指出缺少資料、不可用來源或衝突，不自行補齊；「動作狀態」只有系統觀察到轉換時才能寫已請求、排隊、送出、收到回執、完成或失敗。NIST 指出錯誤內容也可能以自信口吻呈現，所以語氣不能代替狀態。原子主張也要分開：日曆項目可能建立完成，但外部邀請仍未獲回應，不能合成「全部安排完成」。回饋卡應顯示支援來源類別及最近檢查時間。
把承諾拆成所有者、依賴和終態
承諾只有在所有者能執行並觀察完成時成立。寫清下一步屬於產品、使用者、具名外部服務，或系統外的人；再列前置條件、期限或估計、複查節點，以及完成、拒絕、過期、失敗、仍等待等終態。「我保證對方明天回覆」沒有可控所有者；「本應用已送出邀請，回覆由收件者決定，週二後可再查看」則分開控制與依賴。Microsoft HAX 支援清楚的能力與表現界線。第一人稱助手文案不能把外部人的義務悄悄轉給模型；無人能擁有結果時，把它寫成選項，不寫成承諾。
讓條件與過期時間貼近回饋
一般免責聲明不能修正無條件的完成徽章。把關鍵條件放在句子旁，例如「依據目前已連接日曆」「如果場館時間未改變」「尚未收到外部回執」。證據時間表示何時觀察到支援；承諾節點表示所有者何時行動或複查；過期時間表示文字何時不能繼續當成目前狀態。外部資料、權限、版本及使用者編輯會各自改變。依賴斷開或過期後，狀態應降級，不保留昨天的確定語氣。OECD 支援按情境說明輸入及限制。舊文字可留在有日期的歷史紀錄中，但不能繼續冒充現況。
提供可控下一步，不暗示結果
不確定回饋仍可給出有邊界的下一步。Google PAIR 建議說明缺少什麼，並提供複查後重試、重新連接來源、修改輸入、改走手動路徑、取消或保持未知等選項。按鈕名稱要描述動作：「送出申請」不是「取得批准」，「檢查空位」不是「預訂成功」，「請求釐清」不是「立即解決」。回饋控件也要說明真實影響。若修正只改本次畫面，就不能說系統已學會；若進入稍後審查隊列，應標明範圍與時間。單純感謝回饋也不能暗示底層模型即時更新。
以五個依賴中斷情境測試文案
用無害測試資料依序斷開外部來源、撤銷必要權限、讓回執超過複查節點、加入與原輸入衝突的新資料、在輸出過期後重新開啟。檢查標題、徽章、通知、摘要與後續生成文字是否一起降級。失敗後不能保留「已完成」「保證」「始終」或產品已不擁有的未來式。可用動作也要符合狀態：重新連接、編輯、重試、取消、手動路徑或未知。不要探查隱藏防護或使用危險內容。記錄輸入、依賴、時間、預期終態、實際文字及版本，使失敗可以重現。
以七欄契約作為發布門檻
逐項填寫證據狀態、條件、未知、可控動作、外部依賴、所有者/時限/失敗及過期。每句只對應一個狀態，每個承諾有真正能執行的所有者，依賴可見，過期會觸發降級，五種負向情境都抵達誠實終態，才可通過。若視覺自信超過證據、把已送出推成已完成、把估計寫成期限、把回饋描述成模型即時更新，或讓過期輸出維持有效，就不能通過。文案與事件狀態必須一起審查；後端只有成功布林值時，換形容詞也補不出等待、失敗與過期。此門檻審產品回饋，單一回答核驗仍由 170 承接。
常見問題
所有確定語氣都不適合嗎？
不是。範圍、來源及時間明確的可觀察完成狀態，可以使用確定文字。
可以顯示預估時間嗎？
可以，但要標為預估，說明依據與複查節點，也定義依賴未回應時的畫面。
所有未知都要顯示為錯誤嗎？
不用。有些事項只是尚未解決，應保留未知，並只提供確實能縮小缺口的動作。