为什么“直接用代码解释器”并不能让 AI 在财务上安全可靠

每当有人指出大语言模型不擅长数学，总会有一位自信的工程师说出同样的话:“给它接上一个代码解释器就行了。”模型写 Python,Python 跑起来，算术精确无误，问题解决。

其实没有。

代码解释器解决的是一个真实但很狭窄的问题。它去掉了大家都能看见的那一个失误，却留下了没人截图记录的另外四个。你的 AI 不会再声称 8.4 乘以 12 等于 99.2 了，很好。但它拿来乘以 12 的那个数字，依然是从错误的列、错误的期间取出来的，而且没有你能追溯的来源。输出现在是精确地错了，而不是大致地错了，而 CFO 光靠看是分辨不出这两者区别的。

代码解释器真正修好了什么

当一个模型把计算工作转交给一个沙盒化的 Python(或任何函数调用工具)时，它就不再在脑子里做算术了。这很重要。LLM 把数字当作文本分词，再对结果做模式匹配，这正是为什么你会看到算术准确率随着位数增加而急剧下滑。把计算交给 numpy,你就能得到一个确定性的、可重复的答案。对 4,000 笔交易求和，每次结果都对得上。

所以如果问题是“AI 能不能正确地把一串数字加起来”,配备代码解释器之后答案是肯定的。这一点我们没有异议。我们自己也使用确定性执行，因为 LLM 永远不应该充当计算器。

问题在于,“把这些数字加起来”几乎从来都不是真正要做的事。真正要做的事是“Q3 的净收入留存率是多少，这和我们要展示给董事会的是不是同一个数字”。在任何乘法发生之前，这个问题至少有四种出错的方式。

解释器从未触及的四个失误

1. 错误的输入

代码解释器对任何喂给它的东西都能完美计算。喂给它总收入，而你本想要净收入;喂给它入账为已确认收入的递延收入;喂给它一条重复的发票行，它都会针对错误的问题给出精确的答案。垃圾进，精确计算出来的垃圾出。沙盒对输入是否正确没有任何判断，它没法判断，因为它根本不知道在你的科目表里“正确”意味着什么。

这正是在董事会材料里能要命的失误，因为数学是对得上的。没有人会去质疑一个能算得通的数字。

2. 未经核对的数据

大多数公司没有一套统一的数字。他们有 QuickBooks、一个计费系统、一个由人工更新 ARR 字段的 CRM,还有三份电子表格。从计费工具里取出“收入”,再从总账里取出“收入”,你会得到两个不同的数字，两个都说得通，却谁也没有和谁核对过。

配备了代码解释器的 AI 会很乐意对其中任何一个进行计算，它不会注意到两者不一致。它没有唯一真实来源、并与总账吻合的概念，因为核对是一个上游的数据问题，不是运行时的计算问题。这个缺口正是自主财务智能体需要先有一个可靠数字层的全部原因。这是团队最容易低估的部分。各类调查一再发现，数据质量和集成度才是财务领域从 AI 中获取价值的最大障碍，而不是模型准确性。模型从来都不是瓶颈。

3. 缺失的溯源信息

让 CFO 把一个数字摆到审计师、投资人或监管者面前，他们的第一个问题永远是“这个数字从哪来的”。代码解释器给你一个结果和生成它的那段 Python 记录，但它不会给你一条回到源文件、分录、期间、模型版本的链路。如果你不能点击一个数字并把它一路追溯回起点，不管算术有多干净，它都算不上审计就绪。这正是为什么审计轨迹比准确性本身更重要,尤其是在真金白银涉入其中之后。

4. 地区格式歧义

这是最容易被忽略的一点。12,345 是一万两千三百四十五，还是十二点三四五?在美国是前者，在德国大致是后者。如果文档里再混入东阿拉伯数字，解析就更麻烦了。代码解释器只会执行模型认定的那个数值。如果模型误读了分隔符，沙盒就会忠实地对一个偏差三个数量级的数值进行计算。不会报任何错误,Python 跑得好好的。

币种、财年边界、百分比与基点的区别、报表里千与百万的换算比例，每一项都是发生在计算之前的解读工作，而计算器无法捕捉一个它从未看见的误读。

规律:计算只是简单的那 20%

注意这四点的共同之处:它们都发生在算术之前或之后，而不是算术过程中。代码解释器是在错误的层面做修补。这就像雇了一位出色的会计，却给他一个装满未整理、标签错乱、可能重复的收据的鞋盒。他的算术会是完美的，财务报表依然会是错的。

在财务领域把数字弄对，主要是一个数据问题和一个溯源问题。数学是容易的那部分，而这也恰好是解释器唯一处理的部分。

真正让 AI 在财务上安全可靠的是什么

解决方案不是更聪明的模型或更快的沙盒。而是一个坐在原始数据和 AI 之间的已核对模型层，它必须做到解释器做不到的三件事。

• 先核对。 连接各个记账和财务数据源，解决其中的冲突，在 AI 提出任何问题之前建立一个与总账吻合的统一模型。AI 从已验证的数字中检索，而不是从哪个系统先响应就用哪个。我们在为什么已核对数据才是真正的解锁点里对此有更深入的讨论。
• 对正确的输入做确定性计算。 没错，用确定性引擎。但要让它作用在已核对、正确解析、期间对齐的数字上，地区格式和换算比例要事先解决好。引擎本身精确，只有在输入正确的前提下才有意义。
• 让每个数字都能追溯到源头。 AI 报出的每一个数字都应该携带自己的谱系:源记录、计算路径、期间、版本。这才是让一个答案变成可以站得住脚的东西的原因。

这才是真正做对了的神经符号拆分。LLM 做它擅长的事:理解问题、选择方法、用通俗语言解释结果。确定性引擎负责数学。而底层已核对、带有溯源追踪的模型确保这些数学是作用在真正属于你的数字上的。你可以了解确定性引擎是如何工作的,以及它如何在不需要你重新录入任何数据的情况下连接到你现有的系统。

代码解释器是必要的，但远远不够充分。真正被烧痛的公司，是那些看到算术被修好了，就以为信任问题也随之解决的公司。

如果你想让 AI 触碰到你真实的数字，请从解释器跳过的那一层开始。预约演示,我们会向你展示一个从董事会级输出一路追溯回源头分录的数字。