GPT-6 Astra vs Claude Fable 5.1 实测：同一份订单报表，差别在哪

同一份 596 行订单、同样的三份交付物要求，Fable 5.1 用了约 9 分 54 秒，Astra 用了约 10 分 53 秒，36 个数字字段两边都算对。差别出现在解释是否随筛选变化、CSV 列名和交付细节上。

一、这份订单为什么不能直接求和

同一份 596 行订单交给 GPT-6 Astra 和 Claude Fable 5.1，要回答一个很具体的问题：这家店少卖了多少钱，问题主要出在哪个渠道？

回答完还不算结束，它们还得做出一个能打开的中文报表，能切换渠道，能把当前看到的订单导出成 CSV。这比问一句「谁写代码更强」容易判断：数字对不上就是没算对，选了广告渠道却导出全店订单就是没做完。

数据是专门制作的教学样例，不涉及真实客户或任何站点的经营情况。两边拿到完全相同的订单表、渠道流量表和统计定义，分别在独立目录里工作。

比较区间固定为 8 月 1 日至 14 日、9 月 1 日至 14 日。净销售额按已付款订单原金额减退款计算，全额退款的订单仍计入已付款订单数。

原始文件里有三类干扰：8 行完全重复的导出记录，6 行不在比较区间内的订单，以及 12 行未付款或取消订单。正确处理后，参与计算的是 570 笔付款订单。这几类问题都很普通，自己从店铺后台、支付系统或 Excel 整理资料时经常会遇到。它们的作用是看看 AI 会不会认真读统计定义，而不是看见一列金额就开始加。

任务要求相同，包含三份交付物：一份文字分析、一份能逐项核对的数字汇总、一个不依赖网络也能打开的网页。网页还必须做到切换渠道后，卡片、图表、明细和导出使用同一范围。

最后的结果是：Fable 5.1 用了约 9 分 54 秒，Astra 用了约 10 分 53 秒。两边都算对了，也都交出了能操作的页面。

二、第一关：6000 元的下降，两边都找到了

独立复算的结果是：8 月净销售额 57000 元，9 月 51000 元，差额减 6000 元，变化率减 10.53%；已付款订单从 300 笔变成 270 笔；重复、区间外、未付款的排除数分别是 8、6、12 行。Astra 和 Fable 5.1 的结果与复算完全一致。

我还把各渠道的收入、单数、流量和转化率一起复算，总共核对了 36 个指定数字字段，两边都是 36 项通过。

这只是本次样例的计算检查，不能换算成模型对所有表格的正确率。但至少在这一步，没有谁需要靠「解释得好听」掩盖错账。

更有用的结果在渠道拆分里：自然搜索从 19000 元涨到 21000 元，增加 2000 元；短视频广告从 18000 元掉到 10000 元，减少 8000 元；老客回购 20000 元没有变化。

全店少 6000 元，广告渠道其实少了 8000 元，自然搜索多出的 2000 元抵消了一部分下降。如果只看总额，很容易给全店统一做促销；拆到这里，后续调查就可以先围绕广告访客展开。两边都找到了这个线索。

三、第二关：别急着写「广告不行了」

短视频广告的访问次数两期都是 5000，付款订单却从 100 笔降到了 60 笔，转化率从 2.00% 降到 1.20%，相差 0.80 个百分点。

这能说明付款转化下降了，但还不能断定是哪个具体环节出了问题。数据里没有广告素材、落地页、库存和支付错误记录。如果 AI 直接宣布「广告素材疲劳」或「支付系统故障」，就是把一个待查原因写成了事实。

这一步两边的分析都保持了区别，它们列出了应该继续核查的方向，没有声称从现有订单表里已经找到全部原因。

Astra 还把这段解释放进了报表。切到短视频广告时，页面会同步显示：访问量不变、少了 40 笔付款、具体业务原因待核查。打开页面的人不用再翻另一份分析文档，能直接看到数字对应的意思。

这也是 Astra 这版交付比较让人满意的地方：它把「数字」和「这组数字允许得出的结论」放在了一起。

四、第三关：页面上的按钮到底能不能用

Fable 5.1 做出的报表结构更紧凑。首屏同时放了前后两期收入、差额、变化率、成交单数和转化率，往下就是净销售额对比和各渠道贡献图。Astra 则把渠道变化的解释放在指标下方。

实际点击两边的全部、自然搜索、短视频广告和老客回购筛选，对应数字都能切换。其中最值得单独检查的是短视频广告：选中以后，前期收入应变成 18000 元，本期 10000 元，差额减 8000 元，订单总数变成两期合计 160 笔。

随后点击导出当前筛选订单的 CSV，从浏览器下载到本地，再读文件重新求和。两边的筛选切换都正确，下载得到的都是 160 条订单，文件只包含短视频广告，文件内 8 月净额合计 18000 元、9 月 10000 元。

唯一的区别在列标题：Astra 导出的列名是「订单号」「日期（北京时间）」「净销售额（元）」这类中文业务名称；Fable 5.1 用的是 order_id、order_date、net_yuan 一类英文字段名。

两份数据都正确。Astra 的中文列名能直接对应业务概念，Fable 5.1 保留的英文字段名便于程序识别。交付差距有时就出现在这些地方，它不一定改变算题成绩，却会改变你拿到结果以后还要做多少整理。

五、这一轮 Fable 5.1 早结束约 59 秒

Astra 使用的是 Codex CLI 0.154.0，Fable 5.1 使用的是 Claude Code 2.1.272，两边推理设置都是 high。交付三份文件并结束任务，Astra 用时 10 分 53 秒，Fable 5.1 用时 9 分 54 秒，人工补充需求或纠正答案都是 0 轮，指定数字字段核对都是 36 项通过。

这是单个任务的一轮运行，耗时包含模型响应、工具执行和客户端自身检查。不同工具的系统提示词和可用能力也不一样，所以它是实际工具组合的体验对比，不是实验室里剥离一切差异的纯模型测试。

另外，验证说明里 Astra 明确说自己没有做真实浏览器测试，Fable 5.1 也把自己的无头截图检查与实际点击下载区分开。它们没有用一句「全部验证通过」把没做过的事情带过去。

六、官方跑分怎样帮助理解这次结果

官方公布的对比是：AutomationBench 多步骤业务流程，Astra 41.4%、Fable 5.1 31.4%；Terminal-Bench 4.0 复杂命令行任务，57.9% 对 55.8%；DeepSWE v1.1 现有软件项目工程任务，74.1% 对 67.4%；GPQA Diamond 高难度科学问答，96.0% 对 93.7%；HLE 带工具跨学科难题，57.2% 对 65.0%。

Astra 在多步骤业务与软件工程项目上有优势信号，Fable 5.1 在 HLE 带工具项目中领先。这份订单任务难度有限，两边都通过并不奇怪；一次都能做对的任务，也不足以证明它们在更复杂工作中没有差距。

反过来，官方某项领先，也不能自动变成「今天这份经营报表一定完成得更快」。这轮计时就给出了不同结果。

七、API 价格

Astra 与 Fable 5.1 的标准 API 普通输入均为每百万 token 10 美元，输出均为 50 美元；缓存读取分别为 1 美元和 0.25 美元。Astra 超过 272K 输入涉及长上下文加价。

这是按用量调用模型的价格，与个人订阅是两套分开计算的计费方式。

八、常见问题

Q：两边都通过，是不是说明这两个模型没差别？

A：不是。这只是一份订单、一个任务。差别出现在交付细节上，比如解释是否随筛选同步变化、导出的列名用中文还是英文字段名。

Q：为什么强调 CSV 列名这种小事？

A：因为它直接决定你拿到结果后还要做多少整理。中文业务列名可以直接对应概念，英文字段名便于程序处理，两种都合理，但适用场景不同。

Q：耗时差 59 秒能说明推理速度差吗？

A：不能直接这么说。耗时包含模型响应、工具执行和客户端检查，两边的工具链和系统提示词都不一样。

Q：这些数字是真实经营数据吗？

A：不是。订单数据是专门制作的教学样例，不涉及真实客户或任何站点的经营情况。