解决冲突需要足够的上下文
别名: 冲突界面上下文 · 三方对比 · 冲突理解成本
概念解释
冲突界面的职责不是尽快让人点「确认」，而是让人看懂撞了什么再决定。只给两个版本让用户二选一，是冲突处理的最低配；真正能支撑判断的是上下文：共同祖先版本（撞之前长什么样）、修改者与时间、修改周边的内容、以及修改的理由（提交说明、评论）。缺了这些，「采用我方还是对方」就成了盲选——用户不知道对方为什么改、改了多久、动了哪些看不见的关联。判定一个冲突界面够不够，标准是：一个不了解内情的人，能否只凭界面提供的信息做出与当事人相当的判断。
机制
冲突的本质是两个各自合理的意图撞在同一处，而解读者对其中至少一方的意图是缺位的——通常是对方那边。判断「留哪个」实际上是在重构两个意图再比优劣，这个重构需要的材料就是上下文：没有祖先版本，看不出各自动了什么，只能看到两个终态；没有周边内容，看不出这处修改牵连的上下文（一个词的改动可能对应三段外的结构调整）；没有修改者与时间，无法找人问或推断当时的情境；没有理由，只能从字面反推动机，而字面往往不足。三方对比（你的版本、对方的版本、共同祖先）之所以是代码合并界面的标配，正因为它把「各自动了什么」直接显影出来，把重构意图的成本从用户肩上卸下来一大部分。上下文不足时，人的默认策略是保自己——因为自己的意图是唯一在场的一方，这会让冲突系统性地偏向资历更深、在场更久的人。
怎么研究
- 范式：受控实验给被试呈现同一组冲突，操纵上下文完备度（仅双版本 / 加共同祖先 / 加修改者与理由 / 全量），测量决策正确率（与专家裁决的一致度）、决策时间与信心；眼动可以回答用户实际看了哪些信息块；对真实仓库的冲突解决做档案分析，统计上下文可得性与解决质量、返工率的关系。
- 变量：自变量为上下文成分（祖先版本、作者元数据、理由说明、周边范围）的有无；因变量为决策质量、决策时长、事后返工。
- 在界面研究里的用途：决定冲突界面该展示哪些信息块、周边展开到多大范围，避免信息不足与信息过载两个坑。
- 方法论注意点：实验用的冲突若是人造的短文本，被试对「意图」的依赖远低于真实场景（真实冲突常涉及数十行与多个关联文件）；「决策更快」不等于「决策更好」，两个指标必须同时报告，否则会得出砍上下文提速的错误结论。
边界
上下文的充分性随内容类型变化：散文冲突看两段文字加祖先基本够，代码冲突还需要类型与引用信息，设计文件的冲突甚至需要图层的语义。上下文也有成本上限——一次倾泻全部历史与所有关联，等于把考古工作转嫁给用户；工程实践是把高频需要的部分（祖先、作者、时间、理由）默认展示，深挖入口按需展开。另外，再全的上下文也替代不了直接沟通，冲突界面应保留「联系修改者」的出口，而不是假设信息自足。
怎么落地
- 冲突界面默认呈现三方：共同祖先、我方修改、对方修改，差异高亮。
- 每个版本标注作者、时间与修改理由（有提交说明或评论就带进来，没有就留空而不是编造占位符）。
- 周边内容可展开：默认显示冲突区域前后若干行/若干句，允许一键扩大范围。
- 提供「询问修改者」的入口（评论、@提及），把上下文不足的问题路由给人而不是硬选。
- 验证：让未参与编写的第三方用冲突界面裁决历史冲突，与实际解决结果比对；正确率低说明界面信息不够，全部靠「保自己」通过也说明上下文未起作用。