您的 AI 助理應該回傳一個地址,並附上其用途、所依據的紀錄與核准狀態;否則就回傳一個例外,交給指定的審閱者。這就是我們建議的工作流程:不是「挑一個看起來最合理的地址」,而是「套用這張訂單的權威來源規則」。
我們的立場很簡單:共享語意,保留所有權。企業本體(ontology)應該定義客戶、訂單與地址,但不能在不知不覺中變成取代原有記錄系統(system of record)的新系統。這延續了 Global Advisors 導入報告中所描述的區分:語意定義、營運事實與請求當下的脈絡,三者各自分開。
導入實例證明了什麼
Global Advisors 在 2026 年 9 月 13 日發表的個案研究中指出,其本體與脈絡架構已在內部實際使用,而來源涵蓋範圍與部分整合仍在持續完善中。營運系統保有事實的所有權;在沒有權威性的聲明或經審閱的對照表之前,尚未確認的身分會維持分開。模稜兩可的比對會觸發「暫不判定」,而不是悄悄合併。這些都是該公司自行申報的導入細節,並非經獨立驗證的商業成果。資料來源
最重要的但書在於架構:其一般的請求路徑使用的是預先編譯、不可變更的讀取模型,不會呼叫來源系統。這是實用的脈絡架構,但不應被當成目前出貨指示的證明。因此,我們建議的試點會把「回答問題」與「授權採取行動」分開,並要求在執行會產生實際影響的步驟之前,重新向權威來源進行即時檢查。其公布的架構
1. 先定義地址,再選擇來源
我們會從一組經遮蔽處理的客戶紀錄配對,以及它所影響的交貨決策開始。對應各系統之間的客戶識別碼,連結訂單及其明細行,並區分帳戶通訊地址、預設送貨地址與訂單專屬送貨地址。記錄每一項對應的負責人與核准依據;不確定的身分比對則維持未解決。
這種區分在實際產品中也有具體的對應。Microsoft 的文件將「客戶為訂單選擇出貨地址」與「儲存主要地址」分開說明;在啟用相關設定後,也支援依明細行指定出貨地址。因此,對這個試點來說,「客戶地址」這個定義太過籠統。Microsoft 出貨地址說明文件
對每一個已對應的地址,我們會記錄其用途、來源紀錄、適用的訂單狀態、生效期間、核准證明,以及約定的資料時效上限。這些是我們建議的試點需求,並非該個案研究所報告的功能。
2. 議定權威來源對照表
以下是建議的決策表,需要與您的營運團隊共同核准;它並不是「ERP 一律優先於 CRM」的通用規則。每一列都假設身分已經確認,且相關來源可以查核。
| 情境 | 助理可以呈現的內容 | 人工檢查點 |
|---|---|---|
| CRM 的通訊地址與 ERP 中已核准的訂單明細送貨地址不同;您的政策規定該訂單狀態以 ERP 為準 | 訂單明細上的地址,並標示為該訂單專用;另外分開顯示不同的通訊地址 | 不提出變更;照常進行出貨核准 |
| CRM 中有一筆較新的送貨地址更新,但是否適用於這張未結訂單尚未核准 | 兩筆紀錄都呈現,並標示為尚未解決的送貨衝突;不選定出貨地址 | 經授權的訂單負責人確認是否適用及生效期間 |
| 沒有訂單專屬地址 | 僅將預設地址列為候選,且須來自政策指定的來源 | 經授權的訂單負責人核准後,才成為訂單指示 |
| 客戶對應、核准證明或權威來源的時效檢查未通過 | 不提供可用的出貨選擇;回傳未通過的檢查項目及相關參照 | 指定的例外審閱者負責解決證據缺漏 |
在這項提案下,較晚的時間戳記只證明有人編輯過紀錄,並不代表可以更改出貨目的地。用途不同的地址不一定構成衝突;同一次交貨出現互相牴觸的指示,才是衝突。
3. 讓解決過程明確,並將寫入作業分開
我們會提供審閱者互相牴觸的紀錄、受影響的訂單明細行、適用的權威來源規則,以及暫不判定的原因。審閱者應能選擇維持現有指示、透過負責的系統核准變更,或要求進一步釐清。同時記錄決定內容、核准人與生效範圍。
地址變更與對客戶的承諾,都必須經過人員核准。在執行任何已核准的下游動作之前,要重新檢查權威紀錄;若時效或核准檢查未通過,就停止執行。
要實際測試變更會連動到哪些地方,而不是假設變更只影響單一處。Microsoft 的文件指出,在其直接交貨工作流程中,無論修改採購單明細行或原始銷售訂單明細行上的送貨地址,都會自動更新對應的另一行。正因為有這種特定行為,下游整合測試也必須納入此試點的範圍。Microsoft 直接交貨說明文件
4. 衡量決策,而不是草稿
我們會先以唯讀模式,針對已審閱過的紀錄配對執行這個工作流程。衡量從發現衝突到獲得授權解決所經過的時間、對照審閱者核准的決定所出現的錯誤地址選擇,以及未解決的案例。用同樣的指標與您現行的流程比較;在開放寫入之前,先議定驗收標準。
不要依據假設的節省效益編列預算。文中引用的導入說明證明的是架構,而非經獨立驗證的地址錯誤減少幅度或衝突解決時間。這些成果仍有待在您的工作流程中實際衡量。導入實例
我們建議的取捨是刻意的:寧可接受一個明確的審閱佇列,也不要悄悄處理不確定的送貨指示。從一組有衝突的紀錄配對開始,核准它的權威來源規則,再測試助理是否選對地址,或是基於正確的理由暫不判定。
資料來源
營運團隊常見問題
權威來源規則是一項事先議定的政策,說明在特定用途與訂單狀態下,某項事實(例如訂單的送貨地址)應以哪個系統的紀錄為準。當套用該規則所需的證據不足時,AI 不做任何選擇,而是呈報給審閱者。
CRM 與 ERP 不一致時,AI 應該採用最新的地址嗎?
不應自動採用。在這種做法下,較晚的時間戳記只表示有人編輯過紀錄,並不代表可以更改出貨目的地。如果 CRM 中較新的更新尚未核准適用於某張未結訂單,就應同時呈現兩筆紀錄,並將衝突交給經授權的訂單負責人。
在讓 AI 修改紀錄之前,企業要如何安全地測試?
先以唯讀模式,用已審閱過的紀錄配對開始測試。衡量從發現衝突到獲得授權解決所需的時間、與審閱者決定相比所出現的錯誤地址選擇,以及未解決的案例。將這些指標與現行流程比較,並在開放寫入之前議定驗收標準。