需要能回到任意历史版本，只能撤销上一步不足以支撑迭代
别名: 任意版本恢复 · 线性撤销不够 · history restore not undo
概念解释
用户在第 3 版喜欢结构，在第 7 版喜欢结尾，在第 8 版把结构改坏了。Ctrl+Z 只能退到第 7 版，退不到第 3 版，除非把 4 到 7 的全部收获一起丢掉。任意版本恢复（any-version restore）和「撤销上一步」不是同一档能力。迭代修改是在版本树上走动，线性撤销把它压成一条只能后退一格的栈。栈撑不住这种走法。
有历史列表可以浏览，也不等于能恢复。能看见第 3 版但只能整段复制粘贴，仍会丢掉第 7 版里已经对的那一段。
机制
生成式迭代的价值经常不在最新态，而在路径上的局部峰值：某一版的提纲对、另一版的例子对。人需要的是随机访问，不是栈。线性撤销的实现假设每一步都是对当前态的改进，回退等于取消最近的错误。这个假设在探索里不成立——第 8 步可以是一次失败的实验，第 3 步仍是要保留的骨架。
还有分支：从第 3 版另开一条「换受众」的路径，不应覆盖原路径。只能撤销上一步的界面强迫人在覆盖和放弃之间选，于是人开始在编辑器外另存，迭代被搬出产品。
怎么研究
给一个必须「取路径上两版之长」的任务：指定第 A 版的结构加第 B 版的一段必须同时出现在终点。只提供线性撤销的界面 vs 提供可点选恢复任意版的界面。因变量：任务完成率、是否把文本拷出产品、恢复操作的目标版本距当前的距离分布。
记录人们实际想回到的不是 n-1，而是更早的峰值。若距离分布的众数大于 1，线性撤销在设计上就选错了模型。实验室若禁止使用外部文档，会低估「拷出去当版本库」的真实发生率。
边界
两步就结束的流程用线性撤销足够，做任意版本恢复是过载。协同文档若已有完整版本历史，产品应接到那套历史上，而不是再做一套只能看不能回的生成快照。存储与隐私会限制保留时长；不能无限保留时，必须标明「第 3 版已过期不可恢复」，让人在过期前决定是否钉住。
怎么落地
- 每次生成落一个不可变快照，历史里每一项可以一键成为当前工作副本，不必先撤销中间各步。
- 允许从某一快照开分支，而不是覆盖。当前路径在历史上要能看出来。
- 撤销上一步可以保留为快捷键，但它不能是回到旧结果的唯一入口。
- 验证：做一次至少八版的修改，要求回到第 3 版且不丢失第 7 版另存的片段。若必须连按撤销并重做第 7 版的工作，功能不合格。再看日志：若「复制全文」在修改中后期陡增，人正在用剪贴板补版本库。