公司知識 · 觀點評論
兩份政策互相矛盾時，不應讓模型決定哪份有效
政策衝突應由業務負責人處理，不能靠更有自信的答案掩蓋。
把文件權威寫清楚
假設一家代理公司最近的簡報寫明費用由經理批准，較舊的手冊卻要求財務覆核。日期較新不代表一定有權修改政策，簡報可能只是培訓內容。文件應記錄負責人、批准狀態、生效期間及適用範圍。檢索標籤可以幫忙篩選，但不能代替公司決定哪個部門有權制定規則，也不能把版本排序當成正式的授權程序。
設計衝突的處理路徑
助手遇到衝突時，應列出相應段落，再交由指定政策負責人處理。不要把兩套指示混成從未有人批准的第三種做法。試點期間建立衝突紀錄，保留問題、來源版本、審核者與最後決定。這樣可以把難堪的答案轉成有流程的編輯任務，也讓企業看見真正缺少一致規則的地方，而不是一直要求技術團隊修改提示詞。
流程一覽
同時檢查範圍與日期
同樣的說法出現在不同客戶合約、團隊或生效日期的文件中，未必代表錯誤。有些客戶規則可以合法地覆蓋一般流程。測試題應包含這些接近但不同的情境。只儲存應用能可靠維護的標籤，因為沒有人更新的複雜層級會製造另一種假確定性。先處理會實際改變答案的少數範圍差異，再逐步擴充分類。
讓正式決定回到來源
作出決定後，應更新或撤回正式文件，並刷新檢索索引，不能只把結果留在聊天紀錄。重新測試原本的衝突問題，再加一道相近情境，確認新規則的邊界。來源資料支持可追溯檢索的設計，但批准企業政策的責任始終在組織本身，不在向量模型或軟件供應商。若仍無人願意確認規則，應明確保留人工處理。
一次政策衝突演練
建立兩份刻意互相矛盾的合成程序，先請同事不靠助手解決權威問題。他們確認的步驟，就是應用需要支援的升級規則。若連人員都不知道誰能拍板，系統便不應假裝有唯一答案。把演練結果記入內容管理程序，並指定有人追蹤修改是否已傳回正式文件，避免相同衝突下次重新出現。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。