为什么 Rexfin 的数字来自引擎，而从不是来自 AI 的猜测

让一个语言模型去计算明年的期末现金，它会给你一个数字。这个数字是一个统计上看似合理、外形像答案的猜测，而不是一次计算，模型从未真正拿走你的收入、减去成本、再把余额结转下去。有时候这个猜测很接近，有时候它偏差到足以造成影响的程度，而你光看是分辨不出是哪一种，因为一个自信的错误答案和一个自信的正确答案读起来一模一样。这正是 Rexfin 建模引擎要杜绝的那种特定失误:AI 从不计算任何财务数字，由一个引擎来计算。

两项工作，严格分开

Rexfin 把工作拆分为推理和执行两部分。理解一个问题，该调整哪个驱动因子、调整多少、覆盖哪些期间，是推理，而 AI 确实很擅长这个。针对一个真实模型计算出那个变化的结果，是执行，而这必须是确定性的。所以当有人问“如果这个客户流失了会怎样”,AI 会把它翻译成一次驱动因子变化;一个计算引擎会针对这个变化重新计算三张报表;AI 再叙述得出的结果。它从不亲自编造现金数字。

这个引擎依据一个依赖图来工作:每一行，收入、毛利、留存收益、期末现金，都是一个节点，其公式指向它所依赖的输入。改变一个驱动因子，只有它下游的单元格会按正确的顺序重新计算，每次都是如此。实际数(从一份申报文件中导入的数字)是只读的，引擎中没有任何东西能够覆盖它们，而任何标记为“建模得出”的数字也不能冒充为有实际数来源。正是这种区分，让 Rexfin 能够诚实地把每个单元格标注为实际数或计算数，这一点在规范化原子存储中有更深入的介绍。

恒等式必须真正成立

每次重新计算之后，引擎都会检查资产是否等于负债加所有者权益，现金流是否与资产负债表对得上，以及这些数字是否在一个随数值大小而变化的容差范围内核对一致，而不是用一个固定的美元容差，那样的话遇到经过四舍五入的 IFRS 报表就会误判失败。这项对账检查在每一次重新计算时都会运行，而不是抽查性质的，而这也是下游的验证步骤把它升级为导出时硬性阻断的依据，详见验证机制的工作原理。一个只是看起来平衡的模型是不够的，它必须真正核对得上。

相同输入，相同答案，每一次都一样

这个引擎的确定性承诺是明确的:给定相同的实际数和相同的驱动因子值，它在不同运行和不同机器上都会产生字节级完全一致的输出，计算路径中没有时钟、没有随机性，也没有任何网络请求或模型调用。这不是一个锦上添花的细节，而是下游一切工作的先决条件。一个验证者无法有意义地为一个重新运行可能得出不同结果的数字背书，一个董事会也无法信任一个无法从其所依据的假设中重现出来的情景。

这也是为什么 Rexfin 中的情景分析成本低、可信度高:一个“下行”情景是以对基础模型做稀疏驱动因子覆盖的方式存储的，每一个情景都通过同一个引擎运行，并各自获得自己的核对检查。在一次董事会会议上叠加三项假设，数字依然对得上，因为每一项都是用同一种方式、针对同一个基础计算出来的。

引擎选择拒绝回答，而不是去猜

估值输出，包括 NPV、企业价值、IRR,都是从模型自身的预测现金流中推导出来的，从不单独手工录入，因此董事会材料里的一个 EV 数字可以一路追溯到实际预测背后的 DCF 计算。而在数学上确实无解的地方，比如现金流没有符号变化的 IRR,或者目标搜索的目标值超出任何可达范围，引擎会返回一个带类型的“未定义”或“无解”,并受限于一个固定的迭代上限，而不是给出一个装扮成精确值的数字。这体现了贯穿始终的同一种自律:一个有边界的、诚实的失败，胜过一个自信的、编造出来的结果。

这在实践中意味着什么

一旦算术完全交由引擎承担，速度就不再是危险的事。你可以在会议中即时提出后续的假设问题，并相信答案是一次重新计算，而不是一次全新的猜测。确定性并不意味着底层逻辑自动就是正确的，一个错误的驱动因子关系依然会可靠地产生一个错误的数字。它意味着这个错误数字可以被找到、被追溯、被修正，而这是你对一个凭空冒出来的 AI 数字做不到的事。这也是平台的答案审计日志和置信度校准与信任调优所依赖的基础，你只有在底层数字确实是计算出来而非生成出来的前提下，才能校准对一个答案的信心。

关于 Rexfin 如何在方方面面做到端到端可站得住脚，请参见 Inside the Rexfin platform 专题页。