如何创建文件修订历史
如何搭建一份文件修订历史：它需要哪些列，为什么这份日志应该是独立于文件本身、只增不改的记录，以及大多数手工表格完全漏掉的那个核实步骤。
文件修订历史是一份具体产物——一张列出版本、日期、作者、说明和核实人的表格——由版本控制这套做法产生，并由它保持准确。
简而言之
- 修订历史是那个具体产物（一张表格）；版本控制是让它保持准确的那套做法。
- 最少要有这些列：版本、日期、作者、说明、上一版本引用、核实人。
- 只增不改：用一条新行去修正一条错误的条目，绝不去编辑旧的那条。
- 一条没人核对过真正改动的条目，只是一个说法，不是一条记录。
- QueryChart 通过它的变更日志自动生成这一切——见 /features/version-control。
表格是一份记录，不是那套纪律本身
修订历史是大多数读者一听就能想到的那张表格：版本号、日期、改动人姓名、一句改了什么的简短说明，往往还有核实人姓名。它是一个具体产物——通常就在文件自己的封面页上，是表格里的几行。而版本控制是产生这些行的那套不同的东西：从不在没有写条目的情况下编辑受控文件，从不事后改写一条条目，并且让编辑者以外的人去核对这条条目和这次编辑是否相符。一份文件可以有一张看起来很完整的修订历史，背后却没有真正的版本控制——只要从没有人把哪怕一行和真正的改动核对过。
把修订历史当作独立于它所描述的那份文件的另一个对象，而不是文件里的一个部分。文件会变，日志则只会增长。每条条目都需要一个版本号、一个日期、一位作者、一句说明改了什么及原因的平实文字、一个指向它取代的版本的引用，以及——大多数手工搭建的表格会漏掉的那一列——谁核实过这条条目和真正的改动一致。少了最后这一列，日志就是一堆未经核实的说法：作者对自己改动的自述，由改动的同一个人归档。
下面的图表演示了一个通用的修订日志条目流程——十六行，横跨五条泳道——在这个流程里流转的是日志条目本身，不是文件。一次申请开出一条待处理条目，一位作者实施变更并归档一份改动前后的说明，一位评审人在关闭任何东西之前把这份说明和真正的改动做对比，之后一位审计员再抽查已结案的条目。手工维护的电子表格几乎从来没有这个核对步骤，因为没有人明确负责去执行它。QueryChart 完全取代了这张手工搭建的表格：对图表的每一次编辑，都会被记入一份带逐字段改动前后值和编辑者姓名的变更日志，可以在比较版本界面里查看，见 /features/version-control——谁都不用去打这条条目，因为它就是真正被编辑过的记录，不是自我陈述。
十六行，五条泳道，一条日志条目
看一条单独的修订日志条目从申请走到一次核实过、经过审计抽查的结案——手工搭建的表格通常会漏掉的那几列，被铺展成了一个流程。
一次申请，还不是一条条目
起点行是“针对受控文件提出变更申请”——一个事件，不是一项任务——随后是“提交变更申请，注明原因与目标文件”，先点名具体的文件和原因，才谈得上登记任何东西。“变更是否获准登记？”决定一条待处理条目会不会真的被开出来。
条目在改动之前就先开出来
只有在获准之后，“开立一条待处理登记条目”才会出现，是一个文件形状的行，而不是某人收件箱里的一条便签。“分配条目编号并关联文件”和“将变更指派给执行人”都发生在登记负责人的泳道里，都在执行人泳道开始之前——条目在文件哪怕一个字改动之前，就已经作为一条记录存在了。
核实，而不只是一句说明
“在文件中实施该变更”把工作移进了执行人的泳道，“记录变更前后描述、执行人与日期”被单独归档成它自己的一行，而不是塞进那次编辑里。“将登记条目与已实施的变更进行核对”和“是否已对照文件核实？”要求评审人在任何人相信其中一方之前，把条目的说法和真正的改动核对一致。
不一致，然后是结案与审计
“差异出在文件还是登记条目？”会把没通过检查的情况送回“在文件中实施该变更”或“记录变更前后描述、执行人与日期”，看是哪一边出的错。核实通过的条目会到达“结案该登记条目”“通知申请人变更已完成”“在定期审计中抽查已结案条目”，最终到达终点“修订日志条目结案，随时可供审计”——另一个出口是“申请被驳回，未予登记”，回到最上面。
运作方式
把日志和文件分开
把修订历史放进它自己的载体——封面页上的一张表格，或者一份独立的登记册——绝不要写成正文里埋藏的一段话。文件会变；日志是两者之中唯一被允许只增不减的那一个。
在第一条条目之前先定好列
版本号、日期、作者、一句说明改了什么及原因的平实文字、一个指向它取代的版本的引用，以及谁核实过这条条目。漏掉后两者中的任何一列，就没有办法分辨一条经过核对的记录和一份作者的自我陈述。
在改动之前先开条目，而不是改动之后
在一次变更获批的那一刻，就登记一条待处理条目——编号、文件链接、指派的作者——早于任何人打开那个文件。事后才写的条目是靠记忆重建出来的，而这正是日志本该防止出现的那种失败模式。
写下改了什么，而不只是“有改动”
“更新了第 4 节”不算一句说明；“把第 4 节的审批门槛从 500 美元改成了 2,000 美元”才算。用平实的语言记录改动前后、作者姓名和日期，让读者不用打开文件自身的历史就能重建这次改动。
把条目和真正的改动核对一致
在条目结案之前，让作者以外的人把记录下来的说明和文件里真正改动的内容做对比。如果两者不一致，就去弄清楚是文件错了还是条目错了——修正条目对作者来说，并不总是意味着倒退。
抽查已结案条目，而不是逐条复核
搭建一个定期审计，按属于审计方案本身、而不是临时起意的排期，抽查一批已结案条目对照它们的文件。这正是让这份日志变得可以信任、而不需要你自己重新核实一遍的原因。
应避免的错误
把日志变成一场记忆考试
在改动完成好几天之后才写条目，会把一条记录变成一次事后重建。在变更获批时就开出待处理条目，并在改动落地的当天就归档那份改动前后说明，而不是靠几周之后某人的记忆。
原地修改历史
为了修正一句错误的说明，去改一张电子表格里的第三行，会摧毁修订历史存在的本意——证明当时记录下来的是什么。改用一条新行；/zh/guides/如何追踪SOP变更 和 /zh/guides/如何管理SOP修订 专门讲了 SOP 场景下这套只增不改的纪律。
一份没人拿去和文件核对的日志
一张有版本列和说明列、却没有核实步骤的表格，是一堆说法，不是一条记录。像上面图表里“将登记条目与已实施的变更进行核对”那样，给这个核对动作它自己的一行和自己的负责人，否则这份日志的可靠程度就只等于作者的记忆。
把日志和产生它的流程混为一谈
修订历史记录的是改了什么；它不决定谁可以批准一次变更，也不决定被取代的副本存在哪里——那属于文件控制，完整介绍见 /zh/templates/文件控制流程。两者都要搭建，但要作为独立的产物分开维护。
搭建你自己的修订日志
把这张修订日志条目图表打开成你自己的模板，把你自己的文件类型填进泳道，让 QueryChart 的变更日志来保留这份经过核实的历史，而不是一张电子表格。
相关指南
常见问题
修订历史和版本控制有什么区别？
修订历史是那个具体产物——版本、日期、作者、说明和核实人的表格。版本控制是让这张表格保持诚实的那套做法：没有条目不得编辑、条目事后绝不改写、由作者以外的人去核对两者的规则。你可以有一份修订历史，背后的版本控制却很薄弱——表格是存在的，但从没有人把哪一行和真正的改动核对过。
修订历史表需要哪些列？
版本号、日期、作者、一句说明改了什么及原因的平实文字、一个指向它取代的版本的引用，以及——大多数手工搭建的表格会漏掉的那一列——谁核实过这条条目对照真正的改动。漏掉最后一列的一行，是作者的自我陈述，不是一条经过核对的记录。
为了修正一条旧条目里的错误，应该去编辑修订历史吗？
不应该。用一条新行去修正记录，而不是重写旧的那条；日志的可信度，正来自它这套只增不改的历史保持完整。如果出错的是文件本身而不是那条条目，修复应该体现在一次新的文件修订里，而不是一行被重写的日志。
一张手工维护的电子表格，够用来做修订历史吗，还是需要专门的软件？
电子表格在没人去编辑一行而不是追加一行之前是够用的，而这件事很难防住，也很容易被漏掉。QueryChart 的版本历史会自动写出等效的日志——每一次修订都带逐字段改动前后值和编辑者姓名的变更日志，可以在比较版本界面查看，任意一点都能还原，见 /features/version-control。上面的图表展示的是同一套纪律的手工版本——一次申请、一份归档的说明、一个核实步骤——不管是哪种工具在运行它。
