流暢不等於可靠：先定義不可遺失的資訊
大型語言模型擅長壓縮語意，卻不天然擅長保存每一個精確細節。它可能把「新台幣五十萬元，未稅」縮成「約五十萬元」，把「應於驗收後十個工作日內付款」改寫成「驗收後付款」，或在濃縮多方對話時省略真正負責核准的人。文字仍然通順，但金額基準、期限與責任鏈已經改變，這類摘要不能直接支援採購、法務、財務或專案決策。
因此，第一步不是調整提示詞，而是定義摘要中的受保護事實。通常包括金額、幣別、稅別、數量、比例、日期、時區、版本、門檻、例外條件、義務、禁止事項、交付物、負責人、核准者與升級窗口。同一個數字還必須保留語境：「三十日」可能是付款期限、保固通知期或合約終止預告期，只有數字而沒有名稱、起算事件與單位，仍然無法執行。
風險也應分級。一般會議近況可以容許較多改寫；合約、報價、SLA、事故紀錄與稽核文件則應優先保真。高風險內容若來源互相衝突，系統應標示差異並要求人工確認，而不是自行選出看似合理的答案。
把文件轉成「主張、證據、責任」資料
可靠摘要不宜只有一段生成文字。實務上可先建立中介資料層，把文件中的重要主張抽取成結構化欄位，再由模型撰寫摘要。每筆資料都要連回原始證據，例如文件名稱、頁碼、段落、表格列或訊息時間戳。這使後續驗證可以比較欄位，而不必只靠另一個模型判斷整段文字是否正確。
- 數字：保存原始字串、正規化數值、單位、幣別、含稅狀態、適用期間與比較關係，例如「不得超過」不能只剩數值。
- 條款：拆出義務主體、行為、前提、期限、例外、違約結果及文件版本，並保留「必須」「得」「不得」等強度差異。
- 責任：記錄誰負責執行、誰核准、誰提供意見、誰需要被通知，以及責任是否已被當事人確認。
- 證據：為每項主張保存來源定位與原文短句；若同一主張來自多處，應保留全部來源及其優先順序。
- 狀態：區分提案、已同意、待確認、已完成與已撤回，避免把討論中的選項寫成最終決議。
這個模型也揭露常見取捨。逐句擷取最接近原文，但閱讀負擔較高；自由改寫更容易理解，卻增加條件遺失的風險。較穩健的做法是讓正文保持簡潔，同時以固定格式呈現關鍵數字、條款與責任清單，並提供可開啟的證據定位。
用抽取、生成、驗證三階段降低錯誤
處理流程可以分成三階段。第一階段先以規則與模型共同抽取候選事實。日期、金額、百分比、版本號與編號適合使用確定性解析器找出；條件、否定、例外與責任關係則由模型協助辨識。規則能降低漏掉格式化數字的機會，模型則能理解跨句語境，兩者不應互相取代。
第二階段才生成摘要，而且輸入不只是原始文件，還要包含受保護事實清單。提示規則應要求模型不得合併不同單位、不得擅自換算、不得移除否定或例外，並在責任不明時明確寫出「待確認」。若原文出現兩個不同期限，摘要應並列差異和來源，而不是推測哪一個更新。
第三階段執行生成後驗證。系統可重新抽取摘要中的數字與責任陳述，和中介資料逐項比對；檢查幣別、單位、日期、條款強度及主體是否一致。模型可以補充語意檢查，但金額、日期與識別碼等精確欄位宜使用程式化比較。驗證失敗時，應阻擋自動發布、保留錯誤原因，並把相關原文交給審核者。
評估的是可執行性，不只是文字相似度
摘要品質測試應涵蓋真實文件常見的難題：表格與正文數字不一致、附件更新主文件、同名人員分屬不同部門、相對日期沒有明確基準、條款含有多重例外，以及會議中先提出後撤回的行動項目。評估問題要具體，例如「每個金額是否保留幣別與稅別」「每個期限是否有起算事件」「每項行動是否有唯一責任人與狀態」，而不是只問摘要是否看起來完整。
上線後還需要版本與稽核紀錄。保存原始文件雜湊、抽取結果、模型與提示版本、驗證結果及人工修正，可以在爭議發生時重現摘要形成過程。權限也必須沿用來源系統；使用者不能因為摘要彙整了多份文件，就看到原本無權存取的合約或人事內容。
最重要的設計原則是：無法確認時，不要補完。一份明確標示缺口、衝突與待確認責任的摘要，遠比一份看似完整但改變商業條件的摘要可靠。若要把這套方法接進企業 RAG、LINE、ERP 或 CRM，整合團隊應同時設計資料結構、驗證閘門與人工審核介面，而不是只調整生成模型。