标准原子存储:一个经过核验的事实，一条记录

问一个典型的 FP&A 工具某个数字是从哪来的，你得到的往往是一句包装成答案的耸肩:“它就在模型里。”再问它是从哪个单元格汇总来的，最近一次被哪次导入触碰过，六个月前有人是从哪张表格里粘贴出来的，线索通常就断了。这与其说是数据问题，不如说是架构问题。大多数规划工具生来就是为了保存一个人手动输入的数字，它们从来不是为了保存一个必须能自证清白的事实而设计的。

Rexfin 的根基是反过来搭建的。每一个进入系统的数字，无论是营收、一条成本项，还是从年报里提取出的资产负债表总额，都被存储为一条单一的类型化记录，我们称之为原子(atom)。一个原子，一个事实，一个存放的地方。下游的一切，包括模型网格、AI 的回答、以及在导出前核验你数字的核验器，都读取同一条记录。不存在会偏离同步的第二份副本，也没有能让系统其他部分绕过去直接触碰数据的捷径。

究竟存储了什么

一个原子不只是一个数字。它携带着日后为这个数字辩护所需的一切:货币单位、报告规模(单位、千、百万，这个细节能让一个无辜的舍入差异，在你搞错的情况下变成一场假警报)、会计准则框架、这是母公司层面还是合并层面的数字、所属期间，以及它是从文档的哪一页被提取出来的。它还携带一个数字，记录有多少次独立的提取流程都得出了同一个值，低于这个门槛的数字会被标记为尚不足以支撑一项硬性检查。

最后这一点比听起来更重要。一个只有一次提取流程得出的数字，不会被悄悄当成和两次独立提取都确认过的数字一样对待。系统知道这个区别，之后读取该原子的任何环节也都知道。

这也正是点击溯源得以实现的原因:点击一个单元格，打开的抽屉会直接解析回该原子来自的具体文档和页码，而不是一个猜测。

为什么是一个存储库，而不是好几个

另一种做法是，让产品的不同部分各自走自己的私有路径来读写财务数据，这正是规划工具最终出现没人能对上账的重复数字的原因。Rexfin 的原子存储通过一个接口对外暴露，平台的其他每个部分，模型、AI 撰写器、导出门控，都通过这个接口来访问它。没有任何环节直接读取底层数据表。这听起来像是一个管道细节，但正因为如此，对存储库的一次修复不会在别处扩散成三份不一致的副本，围绕一家公司数据划定的安全边界也才能真正在各处都成立。

这个边界不是无意为之的。原子被限定在它所属的交易或项目范围内，而且这种限定是在查询本身层面强制执行的，而不是交给恰好在发起请求的那个界面自行判断。对一家公司数字的请求，在结构上就不可能返回另一家公司的数据，即使代码的某个其他部分忘了做二次检查。

这个存储库还会把原子归入不同的报表:利润表、资产负债表、现金流量表，并保留哪一行汇总进哪一个小计、带什么符号的信息。正是这种结构让一个总额能自动与其各组成部分对得上，也正是为什么要用确定性计算所依赖的同一种结构，任何计算都建立在它之上。

这不是什么

这不是 BI 意义上的数据仓库，它也不打算成为你的总账系统。它保存的是从源文档中提取出的事实，以及你的模型从这些事实推导出的数字，仅此而已。有些文档最终并未提取出任何财务数据，对应的记录仍然存在，只是不携带任何事实，这是一种合法的状态，不是错误。

它也不是魔法。一页扫描错误或一个提取错误的数字仍然可能进入这个存储库，这正是为什么核验是如何运作的作为一个独立的层存在，用来检查落地在这里的内容，然后才会有人信任它，也是为什么上游的数据摄取流水线要遵循自己的一套标准。

结论

大多数财务软件把“这个数字从哪来”当成一个可有可无的附加功能。Rexfin 把它当作其余一切的前提条件:模型、AI 和导出门控的可信度，都继承自同一个朴素的事实，即每个原子都清楚知道自己来自哪一页，平台里没有任何环节被允许忘记这一点。要了解这个根基如何支撑起整个平台的全貌，请参阅Rexfin 平台内部专题中心。