如何追踪流程中的变更
如何追踪流程变更：QueryChart 的变更日志会写明是谁改了一条判断规则或一个阈值、这个字段原来的值，以及现在的值，谁都不用凭记忆重建一次编辑。
追踪流程变更，是指准确记录哪个字段变了、谁改的、它取代了什么值，而不只是记录“存在一个新版本”这件事。
简而言之
- 对某个判断行门槛的一次编辑——第二审批人门槛从 5,000 美元以上提高到 10,000 美元以上——会成为一条变更日志条目，写明谁改的、取代了什么值。
- 每一次编辑都被归属到具体的人：经办人、字段、原值、现值和时间戳，而不只是“图表已更新”。
- 当两个版本之间改动的不止一处、超出单条变更日志条目能覆盖的范围时，比较版本能给出更完整的差异。
- 还原到旧版本会彻底撤销那次编辑，而不需要有人凭记忆重新输入旧规则。
- 追踪变更不同于控制变更：这是一次编辑留下的记录，不是决定它该不该发生的审批关口。
谁挪动了那道门槛，什么时候挪的
一位流程负责人把某个判断行上的金额从 5,000 美元提高到 10,000 美元——一个字段，一次编辑，几秒钟内保存完成。三周后，一张 7,000 美元的发票在没有第二位审批人的情况下就通过了，问题不是这条规则有没有变，而是谁改的、什么时候改的、原来那个数字到底是多少。这件事从没有被记录在图表本身以外的任何地方，因为这条规则本来就活在图表里。
QueryChart 会自动保留这份记录。对图表的每一次编辑——改了一个判断的标签、挪动了一个分支、改了一个阈值——都会写下一条条目，写明是谁改的、动了哪个字段、原来的值、现在的值。打开上面那次编辑的变更日志，看到的正是这样一条记录：门槛由某位具名人员从 5,000 美元改成 10,000 美元，附带记录的时间。不需要任何人手工维护一份平行的变更记录，也不需要任何人去相信某段关于旧规则说了什么的记忆。完整机制见 /features/version-control。
追踪变更和控制变更不是一回事。本文讲的是流程被编辑之后 QueryChart 保留的那份记录——一个事后的事实。变更控制是决定一次编辑是否应该发生的判断流程，通常带有一次申请和一个评审步骤；这套机制的搭建方法见 /zh/guides/如何创建变更控制流程。而如果讨论的对象是一份书面程序而不是一棵判断树，同样的变更日志依然适用，只是图表演示会不一样——见 /zh/guides/如何追踪SOP变更。
被编辑、也被追踪的审批树
一棵二十行的文件审批判断树，从受理一路铺陈到发布，中心是第二审批人门槛——上面那个示例正是编辑了这条确切规则。
一次编辑从哪里开始
图表从“文件提交审批”开始，接着问“是新文件还是改版？”，如果是改版，再问“是编辑性修改还是实质性修改？”，然后才分流进“登记这次编辑性更正”，或者一次完整的“是否属于受监管的文件类型？”检查——这个分支决定了一次变更在被任何人评审之前要经受多大程度的审视。
让分歧浮出水面的评审回路
第六到第九行运行的是评审本身：“加入质量与法规评审人”“收集评审意见”，然后是“所有评审意见是否都已处理？”——如果没有，会问“作者能否当下解决？”，再决定回到循环还是退出去返工。每一轮走过这个回路都会各自保存为一个版本。
本文示例编辑的那道门槛
“审批人审阅最终稿”通向“是否批准发布？”，再到本文示例编辑的那一行：“是否需要第二位审批人？”——答案是“需要”时，会导向“取得第二位审批”。提高这一行的门槛，变更日志就会准确记下这次编辑。
发布，以及它留下的记录
发布泳道用三种方式收尾——“作为小幅编辑性更新发布”“经完整审批后发布”，或者经过“是否需要“已阅读并理解”确认？”之后的“发布并已指派培训”——再加上“退回作者返工”和“已否决并关闭”。每一条把文件送到这些结果之一的规则，都存在于一个比较版本能打开的版本里。
运作方式
编辑之后打开变更日志
每一次保存都会写入一个新版本，变更日志按顺序列出这些版本。从图表的历史面板打开它，看哪个版本变了、谁保存的——你不需要事先知道是某个门槛动了。
读懂这条条目：经办人、字段、原值、现值
点进一个版本，它的条目会写明是谁编辑的、动了哪个字段——一行的标签、一个分支的条件、一条泳道的归属——以及它改动前的值对照现在的值。这就是“谁改了第二审批人门槛、原来写的是什么”的完整答案，不用打开任何一封邮件。
当单条条目讲不完整个故事时，用比较版本
单次编辑的条目很精确，但很窄。当你信任的版本和眼前的版本之间，动过的不止一行时，改用比较版本，把两者并排看——同样的机制，扩大到每一个有差异的字段。
如果这次编辑需要撤销，就还原到之前的版本
如果一次提高后的门槛结果证明是错误而非有意为之，就还原到它之前的版本。还原会直接用那个历史版本替换当前图表，而不需要有人凭记忆重新输入旧规则。
给规则命名，而不只是给分支命名，让差异保持可读
围绕真正的触发条件来写一个判断行的标签和它的分支标签——比如“是否需要第二位审批人？”答“需要”或“不需要”——而不是一个光秃秃的是或否。一条点名了具体字段的变更日志条目，比一条只说“某个未命名方框动了”的条目有用得多。
应避免的错误
靠聊天记录和记忆去追一条改过的规则
没有变更日志的话，一个提高过的门槛只能靠 Slack 消息和某人对旧数字的回忆拼凑出来，而两者很少一致。每一次字段级编辑其实都已经被归属和标注了时间——这正是 QueryChart 存在的意义：让这种拼凑变得没有必要。
把一条被记录的编辑误当成一条已获批的编辑
一条变更日志条目能证明门槛变了、也能证明是谁改的——但不能证明任何人对新数字点过头。如果这样一条规则理应在生效前经过评审，那道关口应该建在流程本身里，比如 /zh/templates/变更控制流程 那样搭建的流程，而不只是存在于版本历史里。
以为审计轨迹已经默认开启
QueryChart 内置的版本历史——变更日志、比较版本、还原——是免费的，在每张图表上默认激活，无需设置。而一条映射到 ISO 27001、SOC 2 或 HIPAA 控制项的哈希链审计轨迹，是一项需要组织主动开启的独立付费能力；它不是因为编辑被追踪了，就默认每张图表都自带的东西。
追踪你自己流程中的变更
从文件审批示例开始，编辑一个判断行的门槛，看着变更日志准确写出改了什么。
相关指南
常见问题
流程变更时，变更日志到底会记录什么？
对每一次编辑，都有一条条目写明是谁改的、动了哪个字段——一行的标签、一个分支条件、一条泳道归属——以及这个字段改动前的值对照改动后的值。把第二审批人门槛从 5,000 美元提高到 10,000 美元，会产生一条准确说明这一点的条目，带归属和时间戳，不需要任何人维护一份单独的日志。完整机制见 /features/version-control。
追踪流程变更和变更控制是一回事吗？
不是。追踪变更是 QueryChart 在一次编辑发生之后自动保留的记录——谁、哪个字段、原值、新值。变更控制是决定一次编辑是否应该发生的判断流程，通常带有一次申请、一个评审步骤和一条回滚路径。两者都重要，但回答的是不同问题；后者的机制见 /zh/guides/如何创建变更控制流程。
这和追踪 SOP 里的变更有什么不同？
变更日志本身是一样的——同样的经办人、字段、改动前后的值——因为一棵判断树和一份书面程序，都是同一套版本历史下的图表。真正不同的是通常会被编辑的内容：像本文这样的流程改的是分支条件和路由，而 SOP 更多改的是步骤文字和职责。同一功能的另一个版本，见 /zh/guides/如何追踪SOP变更。
能不能看到两个版本之间的全部改动，而不只是一次编辑？
可以——打开比较版本而不是单条变更日志条目，它会把两个版本并排展示，标出每一个有差异的字段。这正是用来处理一条规则经过好几次小编辑逐渐漂移、而不是一次明显改动的工具。
还原到旧版本，会删掉改过门槛的那次编辑吗？
不会。还原会让一个更旧的版本重新成为当前版本，但门槛改动发生的那个版本仍然存在于图表历史里——它的变更日志条目不会被抹去，所以是谁在什么时候提高了门槛的记录，会在还原之后依然保留。
