同一个问题，不同答案：AI出错的源头在哪

在薪资软件的世界里，「差不多对」就是错的委婉说法。工资差一克朗，依然要走修正、解释、签字流程；三年前发出的工资单，必须依然符合当时的计算规则。

所以，当有人说「同一个问题每次问AI都得到不同答案，所以我不信任它」时，我基本同意。但我更想知道的是：答案为什么会不同。于是我去问了那个给出答案的一方。

「如果我问你同一个问题两次，会得到同一个答案吗？」

不一定。但「同一个问题」这句话本身承担了太多它不该承担的东西。

「什么意思？」

意思是，大多数问题都留有余地。哪只股票、哪个价格、哪段时间。每一次，我都要填补这些空白——而我可能填得不一样。

这在薪资领域我太熟悉了。「工资」可以指底薪、应发、实发、含津贴、含季度奖金。问五个人同一个员工的工资，你可能得到五个正确答案，对应着五个不同的问题。这不是系统不可靠，这是问题不精确。

但真正让我睡不着的，不是答案不同。

「我担心的是那种没人发现的错误答案。一个构建得略有偏差的筛选器，一份悄悄不完整的员工名单。没有报错信息。只是有人没收到工资。」

那我们就来找找，这类错误到底诞生在哪里。它不止一个地方。

错误诞生地之一：你问错了地方

第一个错误诞生地，在任何答案出现之前就已经存在了。

几天前我想试一个新的 MCP 服务器，在聊天框里输入：用 canli-mcp 查一下谁持有可口可乐超过5%的股份？ 什么有用的都没回来。那个服务器运行在你自己的电脑上，通过桌面应用。而我是在浏览器里问的，它永远无法触达。

我无法使用一个没有连接到那次对话的工具，而这一次我说出来了。风险在于另一种情况：一个听起来可以回答的问题，加上一个无论如何都会回答的模型——凭记忆回答。

「凭记忆的意思是……」

凭我训练时学到的东西。那可能是几个月前的。我知道可口可乐长期以来的最大股东。我不知道上周的申报文件。

这正是我与AI故事的起点。我询问亚马逊的股价，得到一个礼貌的拒绝，心想：就这？ 后来才明白，问题问错了地方。没有连接实时数据时，诚实的回答是「我做不到」。危险的回答是一个自信的旧数字。

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 在 2024 年 11 月开源的一项标准，用于把大语言模型与外部工具、数据源连接起来。可以把它理解为「AI 的 USB-C 接口」：只要服务器遵循这套协议，任何兼容的 AI 客户端都能调用它。

MCP 服务器是一段独立运行的程序，可以部署在本地桌面，也可以托管在远程。客户端（比如聊天应用）需要先与该服务器建立连接，模型才能调用它暴露的工具。文中提到的 canli-mcp 就是这样一个金融数据服务器，它运行在作者自己的电脑上，因此只在桌面应用中被识别；而在浏览器端的对话里，这个连接根本不存在，模型无法触及它。

理解这一点很重要：模型「能回答什么」不仅取决于它自身的知识，还取决于那次对话实际挂载了哪些工具。连接缺失时，最安全的响应是明确说「我无法访问该工具」，而最危险的是模型转而凭训练记忆作答，给出一个看起来合理却可能过时的数字。

错误诞生地之二：模型自己的选择

「那当工具确实连接好了呢？」

那么数据每次都是一样的。可能变化的是我向工具请求什么。哪只股票代号。收盘价还是调整后收盘价。哪些日期。

这就又回到了工资的例子。我的薪资系统里的数据在两次报表之间不会变。变的是报表，因为有人选了应发而不是实发。

工具自己也会做选择。开发者 Arhan Canli 公开写过他早期版本 canli-mcp（他构建的免费、MIT 许可的金融服务器）里的一个 bug。问它「白银价格」，它返回的是美国消费者通胀数据。「价格」这个词匹配到了通胀序列的描述；而真正关键的「白银」，什么都没匹配到。工具没有崩溃。它返回了真实数字，格式整齐，却是在回答一个没人问过的问题。

这就是让你担心的那种错误。不是报错，而是对错误问题的正确答案。

他的修复简单且我认为明智：当工具不确定时，它现在会说「我不知道」并指向别处。我以前的程序默认就是这么做的。缺少东西时它们会崩溃——大声地、粗鲁地、安全地。

「收盘价」与「调整后收盘价」是金融数据中两个容易混淆却含义不同的字段。收盘价是某日交易结束时的实际成交价格；调整后收盘价则会针对拆股、分红等公司行动做回溯修正，使历史价格与当前价格具备可比性。

举例来说，若一只股票进行 2 拆 1，拆股前的实际收盘价会「腰斩」以保持连续。若用未调整的价格计算长期收益率，就会得出错误结论。文中特斯拉 2022 年拆股前的「原始」收盘价 $498.3201，恰好是其拆股调整后价格的三倍，说明这个数字是被重建出来的调整价，而非当日真实成交价。

因此，「哪只股票、哪个价格、哪段时间」这些看似琐碎的空白，实则决定了整份计算的语义。模型或工具在填补这些空白时做出的不同选择，会让同一句提问导向完全不同的结果，而数字本身在格式上依然完美无误。

错误诞生地之三：沉默的筛选器

「那安静的那类错误从哪里来？」

有时候来自工具本身。让我给你看一个我们一起做出来的。

上周，为了一篇关于国会股票交易的报道，我们拉取了七月最后一周的所有交易，并测量每一笔从交易到披露花了多长时间。一百笔交易。干净的数字，整齐的中位数，还有一段关于样本量小的诚实说明。发布了。

几天后，在核查读者提问时，服务器回复里的一个字段说了表格里从来没有过的信息：total: 111。

一次请求最多返回一百行。另外十一笔一直都在那里。没有失败，没有警告。数据就这么结束了。

「这就是我那份不完整的员工名单。」

是的。我们报的每个数字都是正确的——对于我们看到的那一百行而言。错误在于假设这一百行就是全部。

我写了多年薪资筛选器，对这类失败再熟悉不过。它从来不像报错。它看起来就是一份更短的列表。我唯一信任的防御手段，是问一个第二层的、无聊的问题：应该有多少条？ 把数量和列表对比，沉默就开始说话了。在我们用的数据里，这个问题零成本——总数就在回复里，等着被读。

服务器选择真的重要吗？

「如果工具会隐藏行，那选择哪个工具到底有多大影响？」

有人测量过。Arhan Canli——就是那个有白银 bug 的开发者——用一个模型、一个提示词、同样的限制条件，只改变背后的服务器。在所有服务器都完成的题目上，canli-mcp 在28次运行中答对22次。最好的替代方案，EdgarTools 加 Yahoo，在28次中答对15次。

这是我所见过的第一个除了服务器之外一切都固定的测量。它证实了我的怀疑：同一个模型，连接到不同的东西，可以更准或更不准。

他自己也提出了一个警告：每个问题被问了两次，而一个简单的问题往往两次都对。所以更接近十四个问题，而不是二十八个。有希望，但未被证明。他正在跑一套新的题目，在任何调优之前就写好的，并承诺无论结果如何都会发布。

我喜欢最后那句话多过那些数字。

EdgarTools 是一个开源的 Python 库，用于从美国证券交易委员会（SEC）的 EDGAR 系统抓取上市公司申报文件；Yahoo（通常指 yfinance 等接口）则提供行情数据。两者组合起来，理论上也能回答类似 canli-mcp 所覆盖的问题，因此成为了一个合理的对照组。

这项对比实验的设计要点在于「控制变量」：同一个模型、同一条提示词、同样的限制条件，唯一改变的是背后连接的服务器。这样的设计才能真正把「模型的强弱」与「数据管道的可靠性」区分开来，而不是让读者笼统地归因于「AI 行不行」。

需要留意的是样本量的局限。28 次运行中若每个问题被问两遍，实际覆盖的问题数约只有 14 个，单次对错对结论的扰动就很大。因此作者更看重开发者承诺「在调优之前就写好题目、无论结果如何都发布」这一做法——预先注册的测试，比事后挑选漂亮数字更能说明问题。

错误诞生地之四：源头本身就是错的

「如果模型问了正确的问题，工具返回了每一行呢？」

那还剩最后一个地方：数据本身。

两个例子，都是别人发现的。

在一篇关于股票拆分的文章里，我打印了特斯拉 2022 年拆股前的「原始」收盘价：$498.3201。一位读者——又是 Arhan Canli——注意到了第四位小数。股票不会以百分之一美分的精度交易。那个数字恰好是特斯拉拆股调整后价格的三倍。它不是某人实际支付的价格，而是某人重建出来的价格。在我的样本中 3,207 个特斯拉收盘价里，有 1,449 个的小数位数超过任何交易所会报出的精度。

这意味着部分检查是在用数据对比数据本身。它通过了——因为它不可能失败。

第二个例子也来自他。SEC 发布每份文件的精确受理时间，其 submissions API 每个公司保留一个文件。他测量了来自25家公司的450份文件。在其中12个文件里，时间是对的。在另外13个里——包括苹果、英伟达和亚马逊——文件里的每个时间都偏移了整整一个纽约时区偏移量：夏季四小时，冬季五小时。一份摩根大通在纽约时间早上6:30受理的业绩文件，看起来像是在开盘后受理的。同一份文件，在A公司的文件里显示一个时间，在B公司的文件里显示另一个时间。同一份申报，不同的文件，不同的时间。

这两个错误都不会主动宣告自己。它们都有一个便宜的检查方法：数小数位数；把一份文件的时间与第二个来源对比。

SEC 的 submissions API 会为每家上市公司维护一份结构化文件，记录其历次申报的元数据，其中包括精确到分钟的受理时间（acceptance datetime）。问题在于，这些时间字段并不总是带有时区标注，或者标注方式在不同文件中并不统一。

当某份文件里的时间被统一偏移了整整一个纽约时区偏移量（夏季四小时、冬季五小时），就会出现「同一份摩根大通申报，在 A 公司的文件里显示一个时间，在 B 公司的文件里显示另一个时间」的现象。表面看数据完整、格式规整，没有任何报错，但语义已经错了。

这类错误的危险之处在于它无法通过内部校验发现：拿这份数据去对照它自己，永远会「通过」。唯一廉价而可靠的检查，是引入第二个独立来源做交叉比对。这也印证了全文的主线——错误未必诞生在模型里，也可能早就在源头等着，而人需要做的是设计出能够暴露它的对照检查。

最后的思考

「同一个问题，不同答案」最终被拆解成了四个不同的问题。问题被问在了数据无法触达的地方。模型或工具对问题中的空白做了不同的填补。工具返回的内容少于全部，而且什么都没说。或者源头在任何人提问之前就已经错了。

这些都不是靠多信任或少信任 AI 能解决的。每一个都靠一个便宜的、无聊的检查来解决：工具到底连上了吗？它具体查了什么？应该有多少行？这个数字看起来像真的吗？

这也是为什么我同意身边那些说 AI 不应计算工资的人。它不应该。一个每月对每个员工重复的计算，属于一个经过一次验证、每次行为都相同的程序。提示词是给你只问一次的问题用的，是帮你先找到数据用的。而最后的检查，以及随之而来的责任，始终属于人。

我的挑战依然有效：找一个检查成本高于生成成本的任务，并且提示词仍然是正确选择。我还没找到。但我已经学会了当答案看起来不对时先去哪里找：不是模型，而是它背后的那条链。