如何追踪 SOP 中的变更
如何追踪 SOP 中的变更：一条修订历史条目必须记录什么——改了什么、谁改的、什么时候、为什么，以及它取代了哪个版本——外加安全关键的加急分流。
追踪 SOP 变更，是指记录一条带日期的修订历史条目——改了什么、谁改的、什么时候、为什么，以及它取代了哪个版本——而不是依赖文档内的批注修订。
简而言之
- 一条修订历史条目需要五个字段：受影响的 SOP/步骤，改了什么及原因，生效日期，作者，以及它取代的版本。
- 安全关键步骤走加急评审通道；其余的走标准评审周期。
- 起草新条目之前，先检查日志里是否已有针对同一份 SOP 的待处理条目——两条开放条目会产生两个互相竞争的版本号。
- 把一条条目定稿会锁定它的日期、审批人和版本号，让这条记录以后不能被悄悄改写。
- 对基于图表的 SOP，QueryChart 的变更日志会自动记录每一次字段级编辑——见 /features/version-control。
记录是一条条目，不是一处批注
“追踪更改”是 Word 和 Google 文档的说法：一个批注气泡和一道删除线，都活在文件本身里面。一份借用了这个说法、却没有借用这套机制的 SOP，最后会落得变更历史散落在各个邮件串和一堆没人合并过的修订副本里，而程序负责人根本说不清上一版到底改了什么、什么时候改的、为什么改。追踪一次 SOP 变更，指的是更窄、也更持久的东西——在修订历史日志里写下一条带日期的条目，记录改了什么、谁改的、什么时候、为什么，以及它取代了哪个版本。
无论谁来写、无论改的是什么，每条条目都需要同样的字段：受影响的 SOP 和步骤、用平实语言写的变更说明和原因、生效日期、作者，以及——大多数日志都会漏掉的那个字段——这条条目取代的确切版本号。涉及安全关键步骤的变更，走的是加急评审通道，不用排在常规队列后面等；而在起草开始之前，要先检查日志本身：这份 SOP 是否已经有一条待处理的条目在流转？同一份程序有两条开放中的条目，会产生两个候选版本号，这个问题必须在日志值得被信任之前先解决。
在 QueryChart 里搭建的基于图表的 SOP，不需要靠手工维护日志来捕捉修订历史本该记录的那些字段。对图表的每一次编辑都已经自动、逐字段地记录在它的版本历史面板里——打开它，比较版本视图会准确显示任意两个已保存版本之间改了什么、谁改的，一次点击就能还原到更早的版本，且不会丢失之后的工作。当 SOP 的内容存在于图表之外，或者某项标准把修订历史日志本身当作一项独立的证据文件时，下面的手工条目做法仍然重要；内置版本背后到底在自动做什么、不需要任何人手工维护，见 /features/version-control。
一次拟议变更，追踪到一条定稿的条目
一次针对 SOP 的拟议变更，从被识别的那一刻起，逐行追踪到一条写明它取代了哪个版本的定稿日志条目。
在任何事情之前，先记录下来的东西
图表从“识别到 SOP 变更”开始，然后是“描述拟议变更及其原因”——哪份 SOP、哪个步骤、改什么、为什么改、生效日期——之后“变更是否涉及安全关键步骤？”才决定这条条目走哪条评审路径。
加急分流和重复检查
安全关键变更会“将该条目标记为加急评审”，其余的都“将该条目送入标准评审流程”；两条路径都会先经过“修订历史登记册中是否已有该 SOP 的待处理条目？”，然后才把“起草修订历史条目：日期、变更摘要、起草人、被取代的版本”写成一个文件形状的行。
一条条目被信任之前要经过两次检查
“评审人对照现行 SOP 内容核对条目”先来；“审批前是否有待处理的意见？”会把未解决的条目循环送回 SOP 起草人重新评审，然后审批人才会对照“SOP 母本及其所取代的版本”核对它。
定稿之后，旧版本才被结清
“在修订历史登记册中将已批准的条目记录为最终版”锁定了日期、审批人和版本号，然后 SOP 自身的版本号和生效日期才更新，“撤回或归档被标记为已取代的版本”结清了被这次新版本取代的那个版本。
运作方式
在每条条目上记录这五个字段
写下受影响的 SOP 和步骤、改了什么及原因、生效日期、作者，以及这条条目确切取代的版本号。一条漏掉被取代版本的条目，会在日志里留下一个事后无法弥补的空白。
把安全关键变更导入加急通道
在送去评审之前，先问这次变更是否涉及安全关键步骤。如果是，标记为加急评审，不要让它排在常规变更后面；如果不是，送入标准评审周期。
起草之前先检查是否有待处理条目
在开始一条新条目之前，先在日志里搜索针对同一份 SOP 是否已经有条目在流转。同一份程序有两条开放条目，会产生两个候选版本号——去和另一位作者协调，或者给这些变更排定先后顺序，而不是各自并行起草。
条目一旦获批就锁定
把已获批的条目记录为最终版，然后更新 SOP 的版本号和生效日期，并撤回它取代的那个版本。一条获批之后仍可被编辑的条目算不上一条记录，只是一份签了审批人名字的草稿。
让基于图表的 SOP 由变更日志代劳记录
如果 SOP 本身就是一张 QueryChart 流程图，图表上已经捕捉到的内容就不需要再手工记日志：每一次编辑都已经逐字段被追踪。打开版本历史，用比较版本查看两个已保存版本之间改了什么，一键还原到更早的版本——见 /features/version-control。
应避免的错误
没有写明被取代版本的条目
一条记录了改了什么、却没记录取代了哪个版本的修订历史条目，日后没法被重新拼成一条时间线。在起草开始之前，就把被取代版本设为必填字段，而不是一条可选的备注。
一份 SOP 有两条开放条目
两位作者在同一周为同一份 SOP 分别开立修订历史条目，会产生两个互相竞争的版本号。起草之前先检查是否有待处理条目，去协调，而不是等两条都获批之后再去调和这次冲突。
用批注修订代替日志
靠邮件传来传去的批注修订文件，会把“谁在什么时候改了什么”这条真实序列散落在各个收件箱里。一条带日期的日志条目，或者一张图表自带的变更日志，才是记录；留在某人收件箱里的一份批注附件不是。
把一条条目和整套体系混为一谈
把单独一条条目做对，并不能修复一套逐渐漂移的编号方案，或者一个没人追踪的审查周期——那属于治理层面，见 /zh/guides/如何管理SOP修订。本文讲的是单独一条条目；那一篇讲的是所有条目共同的节奏。
搭建你的 SOP 修订历史日志
把这份修订历史日志变成你自己的图表，设定你的条目要记录哪些字段，之后让版本历史自动追踪每一次编辑。
相关指南
常见问题
“追踪更改”和 SOP 的版本控制是一回事吗？
不完全是。“追踪更改”是文档编辑器的说法，指的是一份文件内部的批注修订和评论。SOP 的版本控制，是给程序的每一个获批状态分配一个明确版本、并保留两者之间改了什么的记录这种做法；而一条修订历史条目，就是这份记录被写下来的方式。更完整的区分见 /zh/guides/如何对SOP进行版本控制。
一条修订历史条目需要记录什么？
无论谁写，都要记录五样东西：受影响的 SOP 和步骤，用平实语言写的变更说明和原因，生效日期，作者，以及这条条目确切取代的版本号。漏记被取代的版本，是修订历史日志里最常见的一处缺口。
所有 SOP 变更都走同一套评审吗？
不是。涉及安全关键步骤的变更走加急评审通道，不用排在常规变更后面；其余的都走标准评审周期。两条路径在起草之前，都会汇合到同一个重复检查：这份 SOP 是否已经有一条待处理条目在流转？
这和管理 SOP 修订整体有什么不同？
本文讲的是单独一条条目的机制——它需要的字段、评审分流、重复检查。而编号方案、审查周期，以及谁对所有 SOP 的这套时间表负责，属于治理层面，见 /zh/guides/如何管理SOP修订。
QueryChart 能取代手工日志吗？
对基于图表的 SOP 来说，图表上能捕捉到的内容，能——每一次字段级编辑都会自动记录在版本历史里，带比较版本视图和一键还原——见 /features/version-control。但当 SOP 的内容存在于图表之外，或者某项标准把修订历史日志本身当作一项独立的证据文件（比如受控 SOP 模板 /zh/templates/受控标准作业程序模板 描述的更完整生命周期）时，手工日志仍然值得保留。
