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，检查输入、规则和停止条件。正式连接与排期另行配置；第一步是让每次不同都有可解释的出处，而不是让所有表格尽快看起来一样。