自由文本等非结构化内容通常无法被系统自动合并
别名: 自由文本合并 · 段落冲突 · three-way merge prose · 不能自动并
概念解释
一段散文、一封邮件正文、一条备注，两边各改了意思，系统没有可靠的办法拼成「双方都承认的那一句」。非结构化内容通常无法自动合并。字符级的三方合并有时能把互不重叠的补丁叠进去，一旦补丁在语义上打架——同一句被改成两种语气、同一论据被删和被加强——叠进去的是一句谁也不想要的话。这时应停成冲突，而不是交一份假的合成。
这条对着字段级合并的另一面：格子可以并，段落往往不能。不要用「我们会自动合并文档」把散文也算进成功率。
机制
自动合并依赖可交换的补丁。结构化字段的补丁是「把 due date 写成 D」，两个不同键的赋值可交换。自由文本的补丁是「在偏移 40 插入三个字 / 删掉第 2 句」。偏移在另一边的编辑下会失效；即便用操作变换（OT）或 CRDT 让字符不丢，变换保证的是字符不丢，不是句子还像人写的。两边各改同一句的主语，变换的结果可能是两个主语连着，语法合法、意思毁了。
语义冲突检测比字符冲突贵，而且没有稳定的真值。所以诚实的系统在文本字段上用保守规则：补丁不重叠才自动并，重叠就标冲突，把两份原文留下。激进规则（总是变换到出一份文本）会提高「无冲突率」，代价是静默造句。造句比冲突更难发现，因为界面上只有一份流畅的假正文。
边界
同一段上的正交格式（一人加粗、一人改标点之外的空格）有时可并，前提是格式与字符分开存。代码、表格、Markdown 标题有时比散文更结构化，可以按块并，但围在块里的散文仍走这条。极短字段（一个词的标签、一个数字的字符串形式）按字段赋值并，不要当散文。机器翻译、拼写校正产生的文本看起来像散文，合并时仍是文本，不能因为来源是机器就自动取一侧。法律合同、对外发布的文案，自动合并的风险高于内部草稿：对外那一版必须经人眼，即使补丁看起来不重叠。
怎么落地
- 对散文、备注、邮件正文默认：不重叠的补丁可并，重叠则冲突并保留双方原文。不要为了绿点去跑激进变换。
- 冲突时展示两段原文，而不是展示一份「合并过」的句子再让人猜哪几个字是机器拼的。
- 把「文档已自动合并」的成功统计拆开：字段成功与文本成功分开报，避免用字段的高成功率掩盖文本。
- 验证：两人改同一句的不同意思（一句改成肯定、一句改成否定）。同步后若出现一句语法通顺但谁都没写过的话，自动合并已经越权。再改相邻但不重叠的两句：可以自动并。对照一张只有日期和标题被改的卡片：那不在这条的文本范围，不应用来宣称「文本也会并」。