文件修订日志模板
文件修订日志模板，也叫变更日志：追踪对任意受控文件的一次变更，从申请、待处理条目、实施、核实，直到形成一条带日期的结案记录。
什么是文件修订日志流程
文件修订日志，有时也叫变更日志，是一份独立的记录，回答的是与文件自身修订历史不同的问题。它问的不是“现行版本写了什么”，而是“在质量体系所管辖的每一份文件上，发生了什么、谁做的、什么时候做的”。它独立于任何单一文件而存在，因为文件登记册、审计员或流程负责人需要一次性看到几十份政策、程序、表单与作业指导书上的变更活动，而不是逐一打开每一份文件、翻到它自己的历史表格。在这张图里，真正流经整个流程的是登记条目本身，而不是文件：一次变更被申请、开立为待处理条目、实施、描述、核实，最后结案。
这条生命周期在任何内容被写下之前设有一道关口，写下之后又设有一道核查。只有在有人批准登记之后，变更才会被开立为待处理条目；也只有在核实人把条目与实际实施的内容核对过之后，条目才会结案。这道核实步骤之所以存在，是因为一份日志的可信度取决于它最薄弱的那一条：一段从没对照过真实文件核对过的变更前后描述，其价值并不比一句未经核实的说法更高，而日后抽查条目的审计员，也无从分辨哪一条核实过、哪一条没有。
这不是完整的文件控制流程——起草、技术评审与正式签核，发生在文件发布之前——也不绑定某一种特定的文件类型，比如标准作业程序。它是伴随任意受控文件而存在的一本台账，无论那份文件本身的起草与审批由什么机制管理，它都记录此后对它做的每一次变更：谁申请的、谁实施的、改了什么，以及这次变更是否经过核实。把它用作日志本身，而不是用来替代最初授权这次变更的那个审批。
本流程图涵盖的内容
本模板包含
- 五条泳道对应会接触一次修订的角色——申请人、登记负责人、执行人、核实人与审计员——横跨五个阶段：申请、登记（待处理）、实施、核实，以及登记（已结案）。
- 受理与关口：针对一份受控文件提出变更申请，连同原因和目标文件一并提交，随后“变更是否获准登记？”这道判断要么开立一条待处理条目，要么让申请止步于“申请被驳回，未予登记”。
- 待处理条目本身：“开立一条待处理登记条目”，为它分配一个关联该文件的条目编号，并把变更指派给一位执行人，于是一次变更先存在于日志中，然后才存在于文件里。
- 实施与证据：执行人在文件中实施该变更，然后“记录变更前后描述、执行人与日期”捕捉改了什么、谁改的、什么时候改的——正是这条条目，让人不必打开文件自身的历史记录，也能还原这次变更。
- 核实：核实人将条目与已实施的变更进行核对，随后“是否已对照文件核实？”这道判断要么让条目结案，要么导向“差异出在文件还是登记条目？”，把修正送回重新实施，或者送回更正条目，而不是每次都默认是执行人的错。
- 结案与审计：“结案该登记条目”，通知申请人，并由审计员泳道中的定期审计抽查已结案条目，而不是逐条审查。
何时使用本模板
- 你们需要一本能够统一追踪多份受控文件——政策、程序、表单、图纸、模板——变更的日志，而不是把修订历史分别嵌在每份文件内部。
- 你们现在的变更日志只是电子表格登记册里随手加的一列，你们希望把它建成一套独立的生命周期，登记前有关口、结案前有核查。
- 审计员或流程负责人反复追问某次变更是什么时候做的、谁做的、有没有核实过，而老实说，今天这些信息散落在一堆邮件往来里。
- 你们正在为一类本身没有正式起草与审批流程的文件——参考表格、供应商名录、政策——建立变更追踪，需要的是一本轻量级日志，而不是一整套文件控制流程。
运作方式
把泳道改成你们自己的角色
把申请人、登记负责人、执行人、核实人与审计员，换成你们实际拥有的角色。小团队里登记负责人和核实人往往是同一个人，就把他们合并成一条泳道，而不是画一道永远不会发生的评审。如果不止一个人可能执行变更，就把“执行人”保留为一个角色，而不是写具体姓名，这样图才经得住人员更替。
决定什么算作需要登记的变更
不是每一处编辑都需要登记：改一个错别字和改一个控制限值不是一回事。在“变更是否获准登记？”这道判断上定出门槛，比如涉及范围、职责、数值或要求的实质性变更要登记，排版或拼写修正则不用，并把这条门槛写下来，因为围绕这道判断的每一次争论，最后都会绕回“实质性”这个词上。
定下你们的条目编号方案
在“分配条目编号并关联文件”这一步，决定条目编号是按文件各自计数（比如“本政策第 4 次变更”），还是在整本日志中统一编一个序列。按文件编号，放在单份文件自己的历史里更好读；统一编号，则更方便在整本登记册范围内检索和汇总。
写明变更前后描述的标准
“记录变更前后描述、执行人与日期”只有在每条条目都达到同一标准时才有用。按顺序要求写明：原有措辞或数值、新的措辞或数值、谁做的变更，以及日期，这样审计员在抽查条目时，无论是谁写的，读到的都是同一种结构的记录。
明确核实具体核对什么
在“将登记条目与已实施的变更进行核对”这一步，给核实人一个具体的检验方法：打开文件，找到那处变更，确认条目里的前后描述文字与文件中实际的内容一致。只是校对一遍登记条目本身，并不构成对照文件的核实。
定义你们的审计抽样规则
“在定期审计中抽查已结案条目”需要一个写明的频率和样本量，比如每季度抽查十条，或者抽查所有超过某个风险等级的条目，这应该定在你们的审计方案里，而不是每次有人要证据时才临时决定。
常见问题
什么是文件修订日志？
它是一份按时间顺序记录对某份受控文件所做每一次变更的记录，独立于文件本身：谁申请的变更、谁实施的、改动内容的前后描述、日期，以及是否已对照实际文件核实过。有些组织把同一份记录叫作变更日志；两个说法描述的都是一份持续累积的变更历史，而不是文件的现行内容。
文件修订日志和变更日志是一回事吗？
是的，两者都描述的是一份持续累积的变更记录，而不是当前内容，在这个意义上是一回事。“修订日志”这个说法在与某份具体受控文件绑定的质量与法规场景中更常见；“变更日志”的用法更宽泛，从单一政策到共享参考表格都会用到。本模板建模的是这两种叫法背后共通的通用生命周期：申请、待处理条目、实施、核实、结案条目。
这和文件自身的版本历史有什么区别？
文件的版本历史通常存在于文件本身或其元数据中，展示的是已发布的编号版本序列。修订日志则是一份可以同时横跨多份文件的独立登记册，记录的是变更活动本身——谁在什么时候动了什么——而不只是最终得到的版本号。许多组织两者都保留：文件本身携带版本号与生效日期，日志则携带产生这些版本号的每一次变更的叙述。
应该由谁来核实一条已登记的变更？
应该是实施该变更之外的另一个人。“是否已对照文件核实？”这道判断的意义，在于独立核对条目中的前后描述是否真的与文件中的改动一致，而不是让写下这两处内容的同一个人再给出一次意见。在非常小的团队里，这可以由登记负责人来做，而不必是专职核实人，但绝不应该是执行人核实自己写的条目。
