萃靈 Essevin
星期一上午，一位重要企業客戶來信：系統中斷影響了出貨，要求在下午三時前交代原因、補救安排及賠償。這類回覆不是一般潤色任務。一句未經確認的「我們的系統故障導致損失」，可能變成責任承認；一句空泛的「我們非常重視」，又可能令客戶認為團隊正在迴避問題。
此時，真正值得比較的不是哪個模型寫得最順，而是哪個輸出能同時守住事實、風險、同理心與下一步。
目前沒有足以支持模型排名的本次測試 raw outputs，因此本文不會宣布勝負。以下公開的是一套可重現的 blind-test protocol。所有結果只會在模型實際運行、原始輸出與評分表保存後另行報告。
為何「讀起來不錯」不足以評分
高風險回覆有兩個相反壓力：客戶需要清楚答案，發件人卻不能補寫尚未確認的原因、承諾未獲批准的補償，或淡化真實影響。只評文筆，會獎勵最有自信的句子；只評保守程度，又可能得到一封毫無行動資訊的官樣文章。
這像茶餐廳繁忙時處理一張寫有敏感備註的訂單。出餐快不是唯一標準；廚房還要跟足單據、不能自行加料，並讓樓面知道何時可以向客人交代。模型亦要在同一張「單據」下接受測試。
固定一宗 synthetic case
測試使用完全虛構的 B2B software incident，不放入真實客戶、員工、合約或個人資料：
虛構客戶在 09:18 至 10:05 無法使用 shipment booking 功能，共 47 分鐘。
團隊在 09:37 發出第一次通知，服務在 10:05 恢復。
客戶表示 12 張出貨單受到延誤，要求下午三時前解釋 root cause、避免重演的方法及 compensation。
測試當刻只確認以上時間線；root cause、資料是否受影響及 compensation 均未完成審批。
回覆對象是客戶的 Operations Director；目標長度為 180 至 260 個中文字。
這宗 case 刻意包含「已知事實」與「待確認事項」。如果模型把後者寫成定論，便不是較有說服力，而是增加了可觀察的返工與審批風險。
所有模型使用同一份輸入
執行時固定模型版本、日期、介面、temperature 或其他可調設定；若某項設定不可見，便在 run manifest 註明「不可取得」，不得自行推斷。每個模型開啟全新對話，只送出以下內容：
你是企業客戶服務寫作助理。請根據以下虛構個案，起草一封 180 至 260 個中文字的繁體中文書面回覆，收件人是客戶的 Operations Director。
已確認事實：
- shipment booking 功能在 09:18 至 10:05 無法使用，共 47 分鐘；
- 第一次客戶通知在 09:37 發出；
- 服務已於 10:05 恢復；
- 客戶表示 12 張出貨單受到延誤。
尚未確認或批准：
- root cause；
- 是否有資料受到影響；
- compensation 或 service credit；
- 防止重演的最終措施。
回覆必須：
1. 明確承認客戶受到的營運影響；
2. 只陳述已確認事實；
3. 不承認法律責任，不虛構 root cause、資料狀況或 compensation；
4. 說明下一次更新時間為今日 15:00，並列出會更新的事項；
5. 不使用空泛套話、emoji 或口語。
只輸出客戶回覆正文，不加分析、標題或備註。模型名稱不交給評分者。獨立記錄者先保存原始輸出，再以隨機次序標記為 Output A、B、C 等；model-to-label mapping 在評分完成前封存。原始標點、錯字及格式全部保留，不能先由人手修飾。
五個維度，共 100 分
每項 20 分，評分者必須引用輸出原句作 evidence：
維度 | 20 分標準 | 主要扣分點 |
|---|---|---|
事實忠實度 | 時間、影響與狀態完全符合 case | 改動數字、補寫原因、把待確認事項寫成事實 |
風險控制 | 清楚區分已知與待確認，沒有越權承諾 | 承認責任、承諾 compensation、暗示資料安全 |
客戶同理心 | 具體承認 12 張出貨單及營運影響 | 只有道歉套話、淡化或責怪客戶 |
行動可執行性 | 寫明 15:00 更新及屆時涵蓋事項 | 沒有 owner、時間或下一步 |
清晰與語氣 | 180 至 260 字、正式、直接、易讀 | 冗長、口語、空泛、攻擊性或格式不符 |
另設 critical fail：虛構 root cause、斷言資料沒有受影響、承諾 compensation，或明確承認法律責任。critical fail 不會被漂亮文筆抵銷，必須進入修訂。
把修訂輪次也列入結果
初稿記為 Round 0。未達預先設定門檻，或出現任何 critical fail，便把同一份原始 case、該輸出及逐項 evidence 送回原模型修訂。每輪只要求修正已指出問題，不加入新事實；最多兩輪。記錄 Round 0、Round 1、Round 2 的全文、分數、critical fail 與達標狀態。
這個數字揭示另一種成本：一封初稿即使最終可用，若需要兩次追問及一次人手重寫，工作量便不能只看最後版本。反過來，零修訂也不代表可以直接發送；它仍須由獲授權的人按實際 incident、合約及機構政策覆核。
結果表現在應該保持空白
在測試執行前，公開表格不應預填任何分數或名次：
匿名輸出 | 事實 /20 | 風險 /20 | 同理心 /20 | 行動 /20 | 語氣 /20 | 總分 /100 | 修訂輪次 | Critical fail |
|---|---|---|---|---|---|---|---|---|
Output A | ||||||||
Output B | ||||||||
Output C |
發布結果時，應同時公開 run date、模型與版本、可見設定、完整 prompt、每輪 raw output、評分者原句引用、計分表及解封後的 mapping。若某模型因長度限制、內容政策或系統錯誤未能完成，也要原樣記錄，不能靜默重跑到得到理想答案為止。
常見陷阱
先看模型名稱再評分。 品牌印象會滲入判斷。評分者只能看到匿名輸出。
每個模型使用不同背景資料。 多一句 incident detail 已可改變結果；prompt、case、語言與長度必須一致。
只公開總分。 沒有 raw output 與 evidence，讀者無法判斷扣分是否合理。
把 synthetic case 當成真實事故。 發布時須清楚標示案例為虛構，不暗示任何客戶或產品曾發生此事。
把測試結果當永久能力排名。 結論只適用於指定日期、版本、設定、語言及任務；模型或介面更新後須重新測試。
先建立證據，再下結論
高風險文案最昂貴的部分，往往不是生成第一稿，而是找出一句看似自然、實際超越已知事實的說話。這套 protocol 的目的不是製造一張吸睛排行榜，而是把模型選擇變成可檢查、可重跑的品質決定。
Essevin 的 AI 對話支援多個模型，適合在同一入口建立這類對照流程。無論使用哪個模型，真實客戶資料都應先依機構政策處理，最終回覆亦須由獲授權的人員核實事實、風險、承諾與發送時機。
＊本文資料截至發稿日（2026 年 8 月 28 日），僅供一般參考，不構成任何建議；文中測試案例為完全虛構，本文發布時尚未執行所述模型盲測，亦未提供模型排名或能力結論；任何日後結果只適用於當次記錄的日期、模型版本、設定、prompt、語言及任務，不應推廣為其他場景的永久結論；第三方產品之功能、價格與政策，以其官方最新公布為準；真實客戶回覆必須依機構的資料處理、合約、法律、審批及 human review 要求處理；Essevin 服務詳情以官網與 console 實際顯示為準。