版本管理与审计追踪:谁改了什么、何时改的、为什么改

一旦有不止一个人参与编辑同一个模型，两个不同的问题就会浮现。第一:自董事会上次看到这个模型以来，数字发生了什么变化?第二:是谁改动了工作区的设置、角色和邀请，何时改动的?Rexfin 为这两个问题分别维护一条专门设计的独立追踪路径，因为把“模型变了”和“某项管理员设置变了”混在一起，只会产生一份谁都用不上的日志。

模型版本:快照、链条、差异对比

模型的每一个有意义的状态都会被快照下来，而不仅仅是覆盖上一个版本，它会被捕获为一个不可变版本，并锚定进该笔交易或项目专属的哈希链条中。每个新版本都通过链式哈希回指上一个版本，因此任何人都可以独立于 Rexfin 本身来验证这个版本序列。你不必仅凭工具的一面之词就相信第六版确实是从第五版演变而来的，这条链条从结构上就证明了这一点。

真正有用的不是快照本身，而是差异对比。第 N 版与第 N-1 版对比，会精确显示哪些行、哪些驱动因子或哪些假设发生了变化，变化了多少，以及归因于谁。这份差异对比正是董事会材料中“自上次董事会以来发生了什么变化”那一行内容的来源。它不是某人对自己编辑内容的回忆，而是两个链式锚定、不可变状态之间的一次计算式比较。

从草稿模型晋升为董事会或审计师将看到的正式发布版本，同样遵循这套纪律:晋升发生前会先经过差异审查，生成的发布版本会像其他每个快照一样被链式锚定，并且在需要时可以回滚。一个已发布的模型，永远不会是对草稿的一次悄无声息的覆盖，而是一个附带记录的、经过审查的步骤。

管理员操作:一份独立的、租户级的日志

与模型版本管理并行的，是一种更朴素的审计追踪:谁改动了工作区自身的设置。偏好设置的变更、司法管辖区或财年结束日等合规设置、团队角色变更、以及邀请的创建或撤销，一旦发生就会立即写入工作区审计日志。

让这份日志值得信赖而非只是摆设的关键细节在于:审计记录与变更本身写入的是同一个数据库事务。如果设置更新失败，对应的审计条目也不会被写入，不存在这样的情况:日志条目描述了一次实际上并未生效的变更，或者一次变更发生了却没有留下任何记录。每条记录中的“变更前”数值同样是在同一个事务内读取的，因此即便有两个人同时编辑设置，这个值也不会失真过时。

这份日志存放在一个仅工作区所有者可见的活动页面上，按最新变更在前排列，目的就是让工作区所有者能够回答“是谁把这个人加进团队的”或“是谁改了我们的财年设置”,而不必四处询问。

为什么要分开保存

模型版本差异对比和设置审计日志，回答的是面向不同受众的不同问题。董事会成员关心的是驱动因子假设自上季度以来是否发生了变化。工作区所有者关心的是有没有出现意料之外、却获得了编辑权限的人。如果把两者合并成一条信息流，模型层面的信号会被日常管理噪音淹没，而管理层面的问责又会被外部财务团队根本不关心的模型细节掩盖。把它们保持为两条各自严谨、都不可篡改、都可归因的独立追踪路径，才能让每一条对真正会去查阅它的受众保持有用。

与其他部分的关系

版本管理支撑着董事会材料中的版本差异对比这一行，也为导出关口提供了具体的检查依据:如果一个模型自身的版本历史无法支撑“这是最终版”这一说法，它就无法作为最终版导出。结合基于角色的访问控制,审计追踪正是把“我们认为知道是谁做的”变成“这里有记录为证”的那个环节。

完整的信任链条，请参阅 Rexfin 产品导览。