如何创建文件修订历史
如何搭建一份文件修订历史：它需要哪些列，为什么这份日志应该是独立于文件本身、只增不改的记录，以及大多数手工表格完全漏掉的那个核实步骤。
运作方式
把日志和文件分开
把修订历史放进它自己的载体——封面页上的一张表格，或者一份独立的登记册——绝不要写成正文里埋藏的一段话。文件会变；日志是两者之中唯一被允许只增不减的那一个。
在第一条条目之前先定好列
版本号、日期、作者、一句说明改了什么及原因的平实文字、一个指向它取代的版本的引用，以及谁核实过这条条目。漏掉后两者中的任何一列，就没有办法分辨一条经过核对的记录和一份作者的自我陈述。
在改动之前先开条目，而不是改动之后
在一次变更获批的那一刻，就登记一条待处理条目——编号、文件链接、指派的作者——早于任何人打开那个文件。事后才写的条目是靠记忆重建出来的，而这正是日志本该防止出现的那种失败模式。
写下改了什么，而不只是“有改动”
“更新了第 4 节”不算一句说明；“把第 4 节的审批门槛从 500 美元改成了 2,000 美元”才算。用平实的语言记录改动前后、作者姓名和日期，让读者不用打开文件自身的历史就能重建这次改动。
把条目和真正的改动核对一致
在条目结案之前，让作者以外的人把记录下来的说明和文件里真正改动的内容做对比。如果两者不一致，就去弄清楚是文件错了还是条目错了——修正条目对作者来说，并不总是意味着倒退。
抽查已结案条目，而不是逐条复核
搭建一个定期审计，按属于审计方案本身、而不是临时起意的排期，抽查一批已结案条目对照它们的文件。这正是让这份日志变得可以信任、而不需要你自己重新核实一遍的原因。
常见问题
修订历史和版本控制有什么区别？
修订历史是那个具体产物——版本、日期、作者、说明和核实人的表格。版本控制是让这张表格保持诚实的那套做法：没有条目不得编辑、条目事后绝不改写、由作者以外的人去核对两者的规则。你可以有一份修订历史，背后的版本控制却很薄弱——表格是存在的，但从没有人把哪一行和真正的改动核对过。
修订历史表需要哪些列？
版本号、日期、作者、一句说明改了什么及原因的平实文字、一个指向它取代的版本的引用，以及——大多数手工搭建的表格会漏掉的那一列——谁核实过这条条目对照真正的改动。漏掉最后一列的一行，是作者的自我陈述，不是一条经过核对的记录。
为了修正一条旧条目里的错误，应该去编辑修订历史吗？
不应该。用一条新行去修正记录，而不是重写旧的那条；日志的可信度，正来自它这套只增不改的历史保持完整。如果出错的是文件本身而不是那条条目，修复应该体现在一次新的文件修订里，而不是一行被重写的日志。
一张手工维护的电子表格，够用来做修订历史吗，还是需要专门的软件？
电子表格在没人去编辑一行而不是追加一行之前是够用的，而这件事很难防住，也很容易被漏掉。QueryChart 的版本历史会自动写出等效的日志——每一次修订都带逐字段改动前后值和编辑者姓名的变更日志，可以在比较版本界面查看，任意一点都能还原，见 /features/version-control。上面的图表展示的是同一套纪律的手工版本——一次申请、一份归档的说明、一个核实步骤——不管是哪种工具在运行它。