I3.11.4conflict provenance设计
冲突合并界面需要清楚呈现差异来源而不只是最终合并结果
别名: 差异来源 · 谁改的 · merge provenance · 不只看结果
概念解释
合并界面若只抛出一份「建议结果」，人无法判断该不该接受。差异来源（provenance）要能看见：哪一段来自哪一侧、何时、在哪台设备或哪个身份下写下。结果可以在、甚至可以预填，但它不能是唯一可见物。没有来源的结果是一份匿名拼贴，接受它等于在没对照的情况下签字。
这条是展示义务。字段能不能自动并、文本该不该自动并，决定的是哪些格子进入这张界面；一旦进入，就要把来源说清。
机制
人解决冲突靠的是归因：「这句是我上周在飞机上写的，那句是同事今天改的」。归因需要三元组：谁、何时、哪一侧的原文。只给结果，工作记忆里没有对照物，决策退化成「看起来通顺就接受」——通顺便成了唯一标准，而通顺的假合成恰恰最像可接受。来源把对照外化：左右或上下并排，加上身份与时间，比较从回忆变成感知。
来源还有审计作用。事后「为什么最终版是这样」必须能回答到某一侧的某一版本，而不是「算法当时的输出」。界面如果把中间产物当成唯一文档，审计链在人眼里从这里断掉。即使底层日志还在，人找不到入口，等于没有来源。
边界
自动合并且双方补丁都进入结果、又无语义风险的字段，可以只在历史上保留来源，不必每次打开都并排——但历史必须达得到。匿名协作、笔名、或隐私要求隐藏身份时，「谁」可以降级为「左侧 / 本机 / 另一台」，时间仍应在。来源展示本身会泄露另一侧在离线期间的劳动，这有时是功能（看见同事写了），有时是风险（不该看见的草稿）；权限要切在来源层，不要靠不画来源来保密。极大 diff（整章对整章）并排会打爆小屏，来源可以先按章节索引，再进入段落对照，但不能因此只留一版结果。
怎么落地
- 冲突界面默认同时展示两侧原文，并标注身份与相对时间；建议结果若存在，放在对照之后，而不是替代对照。
- 每一块差异可追溯到一侧的一个版本，点开能看见该版本的上下文，不只是一行红字。
- 接受结果之后，来源进入该次合并的历史，而不是从对象上抹掉。
- 验证：一次标题冲突，界面若只有一个预填标题、没有「这是手机上的 / 这是电脑上的」，来源失败。加上身份与时间后再请一个不在场的人选择——他们应能说出自己在选谁的字。再在接受后打开历史，两侧原文应仍在。把同一场景做成只高亮最终句的 diff、不标侧别，同样不合格。