需能比较任意两个版本
别名: 跨版本差异 · 任意基线比较 · 版本差分
概念解释
任意版本比较（arbitrary version comparison）允许用户把历史上任意两个状态设为基线与目标，直接查看两者之间的净差异，而不局限于相邻两次保存之间的比较。它要回答的是"从评审稿到当前稿一共改了什么"这类问题——中间往往夹着几十次自动保存、格式化操作和多人交叉编辑，这些噪声需要被压缩掉，只留下净结果供人判断。
机制
相邻差异（adjacent diff）本质上是对编辑操作序列的原样记录：谁在哪一步加了什么、删了什么，顺序天然保真，因为它就是操作发生的顺序本身，系统不需要猜。任意端点之间的差异不是记录，而是一次算法反推——系统手上只有两张独立快照，必须从静态结果里倒推中间发生过哪些插入、删除、移动和属性变化。这是一个信号复原问题，不是记录问题，也是它比相邻差异脆弱得多的根本原因。
结构化文档（列表、表格、富文本树）的端点比较通常退化成树编辑距离问题的近似求解：精确解的计算代价随文档规模增大而陡增，工具普遍改用启发式——相似度阈值、锚点匹配、内容指纹——用速度换准确度。这带来两个具体后果。第一，移动检测的准确度完全取决于对象身份能不能被稳定追踪：如果系统给每个块、每个单元格分配持久 ID，移动能被精确识别为"同一对象换了位置"；如果对象只靠内容和位置定位，删除后在别处重新输入相近内容，算法大概率会把它误判成"删除加新增"而不是"移动"，呈现给人看的差异会比实际编辑动作夸张得多。第二，中途被撤销的操作在端点差异里完全不可见——这正是压缩带来的代价：一段内容中途被删掉又贴回来，端点比较只会显示"没有变化"，但对象内部的 ID、格式细节可能已经在这个过程里悄悄改变，留下一处端点比较发现不了的隐性风险。
怎么研究
构造包含移动、重命名、格式变化、"删除再重建"与并发合并的受控语料，把算法准确率和人类理解正确率分开测：一是算法能不能正确区分"移动"与"删除加新增"这两种客观操作路径不同但最终内容相同的情形；二是被试只读端点差异后，自己复述出的编辑历史与实际发生的操作序列偏差有多大。日志分析上，一个可用信号是用户在比较界面里从净差异跳回中间版本的点击频率——跳得越勤，说明端点差异不足以支撑当前的审阅任务，需要额外提供中间轨迹。算法匹配对了不代表用户读对了，两者常常不同步，必须分开报告。
边界
端点差异的可靠性随团队规模和历史时间尺度系统性下降。小团队、短历史（几十个版本以内、单一命名空间）里，对象身份链条通常没有发生漂移，端点比较基本可信。进入大规模、长期项目——成百上千次提交，文件被反复拆分、合并、改路径——对象身份链会在某个环节断裂：拆分出来的两个文件各自的"历史"从系统角度看是两个全新对象，端点比较会把真实的内容迁移误报成一次删除加一次新建。这类场景需要专门的迁移追踪算法（按内容相似度阈值做跨文件归属，并遍历中间历史而非只看两端），不能指望端点差异直接给出正确答案。此外，端点差异无法解释变化的顺序、动机和中间暴露过的风险；二进制媒体和结构剧变的场景，无论团队规模大小，都只能给出"变了"这样的粗粒度信号；涉及合规审计时，净差异更不能替代完整的事件记录，原始历史必须原样保留。
怎么落地
- 允许从历史列表、标签或里程碑中任选两个端点，并在界面上清楚标出比较方向（谁是基线、谁是目标）。
- 分别呈现新增、删除、移动、属性变化四类结果，对置信度低的匹配（例如疑似移动但相似度接近阈值）用明确的视觉标记提示不确定性，不要把猜测当结论直接呈现。
- 提供从净差异跳转到中间事件、评论和提交说明的入口，让被压缩掉的过程仍然可追溯。
- 用真实审阅任务（例如让评审者据此判断是否批准合并）测试差异是否被正确理解、决策是否正确，而不是只比较算法输出的差异行数或压缩率。