如何追踪 SOP 中的变更
如何追踪 SOP 中的变更：一条修订历史条目必须记录什么——改了什么、谁改的、什么时候、为什么，以及它取代了哪个版本——外加安全关键的加急分流。
运作方式
在每条条目上记录这五个字段
写下受影响的 SOP 和步骤、改了什么及原因、生效日期、作者，以及这条条目确切取代的版本号。一条漏掉被取代版本的条目，会在日志里留下一个事后无法弥补的空白。
把安全关键变更导入加急通道
在送去评审之前，先问这次变更是否涉及安全关键步骤。如果是，标记为加急评审，不要让它排在常规变更后面；如果不是，送入标准评审周期。
起草之前先检查是否有待处理条目
在开始一条新条目之前，先在日志里搜索针对同一份 SOP 是否已经有条目在流转。同一份程序有两条开放条目，会产生两个候选版本号——去和另一位作者协调，或者给这些变更排定先后顺序，而不是各自并行起草。
条目一旦获批就锁定
把已获批的条目记录为最终版，然后更新 SOP 的版本号和生效日期，并撤回它取代的那个版本。一条获批之后仍可被编辑的条目算不上一条记录，只是一份签了审批人名字的草稿。
让基于图表的 SOP 由变更日志代劳记录
如果 SOP 本身就是一张 QueryChart 流程图，图表上已经捕捉到的内容就不需要再手工记日志：每一次编辑都已经逐字段被追踪。打开版本历史，用比较版本查看两个已保存版本之间改了什么，一键还原到更早的版本——见 /features/version-control。
常见问题
“追踪更改”和 SOP 的版本控制是一回事吗？
不完全是。“追踪更改”是文档编辑器的说法，指的是一份文件内部的批注修订和评论。SOP 的版本控制，是给程序的每一个获批状态分配一个明确版本、并保留两者之间改了什么的记录这种做法；而一条修订历史条目，就是这份记录被写下来的方式。更完整的区分见 /zh/guides/如何对SOP进行版本控制。
一条修订历史条目需要记录什么？
无论谁写，都要记录五样东西：受影响的 SOP 和步骤，用平实语言写的变更说明和原因，生效日期，作者，以及这条条目确切取代的版本号。漏记被取代的版本，是修订历史日志里最常见的一处缺口。
所有 SOP 变更都走同一套评审吗？
不是。涉及安全关键步骤的变更走加急评审通道，不用排在常规变更后面；其余的都走标准评审周期。两条路径在起草之前，都会汇合到同一个重复检查：这份 SOP 是否已经有一条待处理条目在流转？
这和管理 SOP 修订整体有什么不同？
本文讲的是单独一条条目的机制——它需要的字段、评审分流、重复检查。而编号方案、审查周期，以及谁对所有 SOP 的这套时间表负责，属于治理层面，见 /zh/guides/如何管理SOP修订。
QueryChart 能取代手工日志吗？
对基于图表的 SOP 来说，图表上能捕捉到的内容，能——每一次字段级编辑都会自动记录在版本历史里，带比较版本视图和一键还原——见 /features/version-control。但当 SOP 的内容存在于图表之外，或者某项标准把修订历史日志本身当作一项独立的证据文件（比如受控 SOP 模板 /zh/templates/受控标准作业程序模板 描述的更完整生命周期）时，手工日志仍然值得保留。