# 模型构建比拼需要失败率，而非奖杯

**Summary:** TryAI 的 12 模型构建比拼之所以有用，是因为它展示了每次运行的失败情况和原始产物，但我的看法是，四个熟悉的 App 提示仅能生成一份候选清单，而非生产级编码的最终结论。

- Canonical: https://markhuang.ai/zh/news/model-build-offs-need-failure-rates
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-11
- Section: News
- Tags: AI, 代码模型, 模型评估, 基准测试, 开发者工具
- Source: [TryAI](https://www.tryai.dev/blog/gpt-5.6-build-off-12-models)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一位卡通评审员正在检查多个由 AI 构建的装置，机器人建造者们在激烈竞争，而奖杯则被冷落在一旁](https://cdn.markhuang.ai/news/model-build-offs-need-failure-rates/hero.webp)

*一场有用的模型比拼，会让失败无处藏。满屋子最没看头的，偏偏是那个奖杯。*

[TryAI 的 GPT-5.6 构建比拼](https://www.tryai.dev/blog/gpt-5.6-build-off-12-models)让 12 个模型分别完成四个小型应用，每个模型对每项任务尝试五次，并公开了成本、平均耗时、通过次数和原始产物的链接。参赛阵容包括 GPT-5.6 Sol、Terra 和 Luna；其他几款前沿模型；Meta 新发布的 Muse Spark 1.1；以及 TryAI 所称的四款开源权重对比模型。

我的看法是，冠军标签远没有失败率来得有用。一次精美演示只能告诉我模型"能做出什么"，跑五次才能看出我实际拿到可用结果的概率。所以这次对比更适合拿来快速筛选原型阶段的候选模型，远不足以判定哪个模型能接管现有代码库或跑通一条长工程链路。

## 答案速览

| 问题       | 我的看法                                                         |
| -------- | ------------------------------------------------------------ |
| 发生了什么？   | TryAI 让 12 个模型分别尝试构建光线投射器、3D 魔方、计算器和康威生命游戏，每个模型对每项任务进行五次尝试。  |
| 解决了什么问题？ | 发布时的排行榜和精心挑选的截图掩盖了每次运行的差异；这次比拼把多次产物、实测成本、延迟和基本通过率都摊开给你看。     |
| 谁会受益？    | 需要选择原型模型的独立开发者，以及决定哪些低成本或高端模型值得进行特定工作负载评估的团队。                |
| 我的核心观点   | 公开的失败数据比单一赢家更有价值，因为可靠性是一种分布，而非高光集锦。                          |
| 局限性      | 四个常见的从零搭建小项目、人工评判标准，加上测试框架细节不完整，无法证明生产级编码质量，也给不出不偏向任何供应商的排名。 |

## 五次尝试才是正确的升级

TryAI 说这次跟进是为了回应之前单次尝试对比的批评。这确实是最重要的改进。文章没有把这次测试包装成科学定论，而是让读者直接查看生成的产物，而不是只给一张截图或一个汇总分数让你信。

我认同这个方向，因为模型差异不是评测中该剔除的噪音，它就是产品本身。一次惊艳、四次跑崩，惊艳的那次说明模型有这个能力，但跑崩的四次才是我真正要接手的工作流。

原文的通过规则也写得清楚。光线投射器：评审员能在迷宫里移动、转向，就算可玩。魔方：打乱和还原动画都得流畅跑完，不能出现卡顿或颜色错误。计算器：只测基础功能，不做穷尽测试。这些标准不高，但比一个说不清怎么算出来的总分有用得多。

![一位卡通评审员正在比较同一装置的五个版本，从完整到破损不等](https://cdn.markhuang.ai/news/model-build-offs-need-failure-rates/why-it-matters.webp)

*真正该看的不是最漂亮的那次，而是所有尝试呈现出的规律。*

## 排名随任务而变

结果很难排出一个干净的领奖台。光线投射器：GPT-5.6 Sol 和 Luna 五次全部可玩，Terra 只做到三次。魔方：Sol 和 Terra 各完成四次干净还原，Luna 一次没过，Claude Fable 5 是唯一五次全过的。计算器：Sol 和 Luna 又回到五次全过，Grok 4.5、Claude Opus 4.8、Claude Fable 5 和 Muse Spark 1.1 也同样全过。

这种起伏才是重点。它说明选模型应该先看任务长什么样，而不是先看品牌排名。一个能稳定跑通可漫游 3D 场景的模型，换个动画状态问题就可能翻车；一个在某项任务上又贵又慢的模型，碰到简单常见的界面可能根本用不上。

而且这次对比甚至没给生命游戏的五次尝试打分。TryAI 只公布了成本、平均时间和总体印象。我欣赏这种坦诚，但也意味着四项任务提供的证据并不对等——任何整体结论都得把这种不对称算进去。

> **Info:**
>
> 我会用这次比拼来决定哪些模型值得我下一步测试，但不会用它来跳过测试本身。

## 成本得放在测试框架里看才有意义

成本差异大到足以影响决策。五次光线投射器跑下来，TryAI 报告 GPT-5.6 Sol 花了 1.35 美元，平均耗时 120 秒；Luna 只花了 0.15 美元，平均 23 秒。如果便宜的模型能通过实际验收测试，这种价格和延迟差距足以改变路由选择。

但这些数字只适用于这套特定环境。文章提到四款开源权重对比模型用的是 Fireworks，但没有公布一套覆盖所有提供商、模型快照、推理努力程度、采样设置、系统指令和工具权限的完整通用配方。短答案吞吐量是在单独的延迟测试框架里报告的，原文也提醒好几个缓冲响应撞上了 400 Token 的上限。

[OpenAI 的 GPT-5.6 发布页面](https://openai.com/index/gpt-5-6/)从另一个角度揭示了配置问题：Sol、Terra 和 Luna 官方定价不同，用户可选择努力程度，部分产品还提供额外的 Max 和 Ultra 模式。推理努力和测试配置都没公开，拿一次对比就拔高成对整个产品线的永久定论，站不住脚。

![一位卡通工程师将相同任务分配给三个具有不同时长、成本和失败模式的机器人车间](https://cdn.markhuang.ai/news/model-build-offs-need-failure-rates/tradeoff.webp)

*价格、时间、成功率得一起算。跑崩了就是跑崩了，便宜也还是白花钱。*

## 公众反应反而划清了边界

[Hacker News 的讨论](https://news.ycombinator.com/item?id=48865093)之所以有价值，恰恰因为观点混杂。有人觉得单次构建能看出模型怎么处理未指定的决策；也有人指出，计算器、魔方、光线投射器、生命游戏都是常见模式，网上示例一大堆，这个测试可能更奖励检索能力和视觉打磨，而不是真正的工程创新。

帖子里的开发者还要求更完整的提示词和测试框架细节，质疑以视觉为主的任务组合，并把从零搭建的演示和在复杂现有代码库里干活做了对比。我觉得这种批评有道理。它没有让产物变得毫无价值，而是划定了它们能支持的范围。这次比拼展示了这些配置怎么处理这些任务，但没展示它们怎么应对迁移、维护成熟架构、诊断不稳定测试，或者在多轮审查里维护功能。

正面的解读同样重要。独立开发者可能很在意第一版输出的审美品味，以及模型怎么处理缺失的细节；做路由的团队可能更关心一个能用的原型要花多少钱。同一批证据可以帮到不同的人，不必假装每个买家都在做同一件事。

## 其他评测会产生不同的赢家

[Artificial Analysis 的 GPT-5.6 评测](https://artificialanalysis.ai/articles/gpt-5-6-has-landed)用了智能体编码套件，报告 Sol 在最大推理模式下以 80 分领跑编码智能体指数。但它的 AA-Briefcase 结果把呈现效果和分析质量分开了：Sol 的呈现评分最高，Claude Fable 5 却在更宽的基准上领先，任务评分也更高。这提醒我们，界面好看≠分析正确。

[METR 的 GPT-5.6 Sol 预部署评测](https://metr.org/blog/2026-06-26-gpt-5-6-sol/)给出了更尖锐的方法论教训。METR 表示，他们的软件任务时间跨度测量不够稳健，因为结果会因为怎么处理检测到的违规尝试而发生巨大变化。他们还指出，脚手架设计和任务措辞的细节都会影响观察到的行为。

这些来源不是因为规模更大或更正式就更好，而是回答了不同的问题。它们共同强化了我关心的观点：模型能力和任务设计、评估规则、脚手架、工具、验收标准密不可分。

![一幅卡通图对比了一个微小精致的 AI 演示与一个充满依赖关系和维护工作的大型生产系统](https://cdn.markhuang.ai/news/model-build-offs-need-failure-rates/workflow-risk.webp)

*一次干净的单次演示与生产代码库虽有关联，但中间还隔着很长一段路要修。*

## 下一次构建比拼应衡量修复能力

如果我来扩展这个实验，会保留五次尝试和原始产物，然后加第二阶段。把每个模型放进一个小型现有代码库，给它一个失败的测试、一个模糊的功能需求、一个隐藏的回归 bug，还有一轮评审反馈。不只记录第一次输出好不好看，还要记录达到可接受补丁需要多少轮交互、多少次工具调用、多少次人工修正。

我还会冻结模型标识符、提供商、推理努力程度、系统提示、工具访问权限和 Token 预算，然后按每个被接受的任务报成本，而不是按每次回复报。这同样造不出一个通用排行榜，但会让证据更贴近团队真正花钱买的工程产出。

Meta 的 [Muse Spark 1.1 公告](https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/?_fb_noscript=1)正好说明了第二阶段为什么重要。Meta 把这个模型定位在多轮编码、工具调用、上下文管理、以及检查渲染输出来修复失败。单次做一个小应用只能看看模型的第一步怎么走，测不了厂商真正在宣传的那套工作流。

## 我的最终结论

TryAI 的构建比拼之所以有用，是因为它给了读者发布排行榜常缺的东西：多次尝试、简单的通过标准、实测成本和时间，以及可以检查的产物。最有价值的结果不是 Sol 赢了某项任务或 Fable 赢了另一项，而是同一个模型在一项任务里看起来可靠，下一项任务里却显得脆弱。

这就是为什么我想要更多失败率，更少奖杯。用这次对比生成候选清单，留意差异在哪里出现，然后为你真正关心的工作设计更精准的评估。值得部署的模型，不是五次尝试里最漂亮的那个，而是它的失败能被你的工作流检测、承受并修复的那个。