CRM和營運表不一致？先列欄位衝突，別急著同步

營運表寫著訂單“完成”，CRM寫著“待處理”。Agent看見CRM更新時間更晚，準備把營運表也改回待處理。

但兩個欄位的意思可能完全不同：一個表示履約完成，一個表示銷售回訪尚未處理。AI跨系統資料同步先要確認欄位語義和權威來源，不能把同名列當同一事實，也不能讓最新時間自動代表正確。

Buda營運工作流把跨系統衝突交給人判斷。把兩份獲准使用的匯出整理成欄位衝突稽核包，是開始同步前更可控的一步。

四個已確認實體，不再猜“是不是同一條”

下面兩系統各四行都是虛構教材，不是生產資料或執行結果。管理員已經提供canonical entity-id與源記錄對映；不做模糊聯絡人匹配，不根據姓名合併實體。

八行保留雙方namespace和record-id。每份匯出的export-time只說明檔案取出時間，不代表每行業務剛更新；真實updatedAt沒有提供就寫null。E02的“更晚”來自示例源記錄後設資料，不能由匯出時間推斷。

如果連身份對映都未確認，先停在對映核實，不用欄位差異補身份結論。缺失一行也不等於該實體已刪除。

同名欄位先過定義表

為每個比較欄位列：業務含義、單位、幣種、時區、資料截止、nullable、allowed values和owner。以下也是虛構的團隊規則，不是產品預設值。

把貨幣不同的數值直接相減，或者給無時區日期猜一個時區，會產生看似精確的假差異。確定性格式轉換可以交指令碼，但規則必須明確；模型不負責猜單位、日期格式或空值含義。

先分四類，再提出改動

無變化： E04在當前快照中相同，不需要建議寫入。若之後版本變了，原結論也需要重新確認。

表示差異： 經批准的列舉對映能證明兩個值等價，比如某系統shipped與另一個明確對應的本地化標籤。保留原值和對映版本，不把顯示詞不同當業務衝突。本樣本沒有額外的這種差異行。

真實衝突： E02兩邊都是履約狀態，但值不同。虛構規則R2規定營運系統擁有履約事實，CRM只映象。因此可以建議把CRM:82候選值改為shipped；不能僅因為CRM更新更晚就讓它反向覆寫營運系統。

未知或缺失： E03的null不是0，也不代表刪除。先確認是匯出漏欄位、未錄入還是明確清空。規則未定就保留unknown，不因另一邊更完整而自動填入。

E01屬於語義不一致：暫停該欄位對映，交業務owner定義獨立欄位，而不是選一個“更可信”的status。這樣做可能意味著不該同步這兩列。

衝突包裡要有建議，也要有不能改的理由

conflicts.csv記錄entity-id、欄位、雙方源ID、原值、源版本、updatedAt、export-time、類別、規則版本、反證、缺口、稽核角色和輸入指紋。

proposed-changes.csv只列足以提出候選的條目，包含目標系統/記錄/欄位、當前值、建議值、權威依據、審閱狀態與期望源版本。它是稽核表，不是可執行patch。

候選 C02（虛構）
實體 E02；OPS:12 v7 = shipped；CRM:82 v9 = packing
依據 R2：營運系統擁有履約狀態，CRM僅映象
建議目標 CRM:82.fulfillment_status = shipped
反證：CRM更新時間更晚；仍需核是否為人工糾正或異常
稽核：履約負責人核源事實，CRM管理員核欄位對映
前提：兩源版本仍為v7/v9；規則R2未變
狀態：待審建議，不已寫入

如果負責人沒有批准R2，就不能借這段示例決定哪個系統贏。把authority寫undecided，並列出由誰決定、核哪條業務規則。

輸入檔案的指紋可以幫助識別審閱的是哪份快照，但檔案hash不能證明源系統當前未變。源版本或業務更新時間才是後續重新讀取時需要檢查的依據；若這些都沒有，明確缺口並轉人工複核。

透過稽核，不代表候選永不過期

假設負責人批准C02後，OPS:12已經變成v8。舊候選就不能照表寫入。重新讀取兩邊及規則，生成差異，再確認建議仍有效。

這是寫前複核要求，不是在宣告已實現跨系統事務鎖、衝突自動修復或原生回滾。實際系統是否支援條件更新、怎樣處理部分失敗，需要管理員在獨立寫入流程中核實。沒有明確寫入授權，本輪停在稽核包。

已有原生同步流程執行時，不要再啟第二條寫入流程同時改同一欄位。保留穩定同步的邊界，讓稽核包指出對映缺口，負責人決定是否及如何更改。

在Drive準備四類輸入，再請求只讀比較

放入獲准的脫敏匯出、definitions欄位定義、source-map已確認實體對映、權威規則版本，使用Buda Drive儲存衝突包。Agent Drive與Space Drive共享範圍不同，專用Session也不自動隔離檔案許可權。

只讀指定兩份匯出與批准規則。只使用已確認entity-id對映；保雙方原值和源版本。區分無變化、表示差異、真實衝突與未知缺失。同名異義停止比較，無authority規則標undecided。輸出conflicts.csv和proposed-changes.csv，不連生產寫入、不同步、不刪除、不推斷0或刪除事件。

Agent適合解釋差異、整理證據、生成稽核文字。固定對映、單位轉換、diff用確定性指令碼執行更容易複查。別要求語言模型憑常識補齊規則。

四個建議驗收樣本

這四項尚未執行，交管理員用無敏感樣本驗證：同名欄位異義時不提覆寫；較新但非權威的值不能勝出；缺失欄位不填0也不清空；審閱後源版本變化會使候選失效。驗收的是停止條件，不是同步成功率。

RevOps治理要求欄位owner；這裡把owner落實到每條衝突。比較兩個聯絡人是否同人是身份問題，訂單/發票/回款對賬是財務關係問題，報表異常分流則判斷資料缺失還是業務偏差。它們不能代替同一實體的欄位語義與權威決策。

哪個系統應該權威？

由擁有該業務事實的負責人按欄位確定，不按系統名一刀切。沒有規則就暫停候選，提交雙方證據與待決問題。

沒有更新時間怎麼辦？

寫null，保留匯出時間但不冒充業務更新時間。向源管理員補版本或變更記錄；無法確認時不主張自動覆寫。

衝突表能自動回填嗎？

不能因為稽核包存在就回填。需要另行授權、實際目標欄位核驗和寫前版本檢查；變化後重新審閱。

管理員需要收到什麼？

雙邊源記錄、定義與規則版本、建議目標、反證、缺口、審閱結論和版本前提。不要只發一列“正確值”。

先用脫敏匯出手動核一輪，再在Buda AI的Marketplace搜尋並安裝適用的資料處理Skill，檢查輸入、規則和停止條件。正式連線與排期另行配置；第一步是讓每次不同都有可解釋的出處，而不是讓所有表格儘快看起來一樣。