30 秒看懂
Theo 在 2026 年 6 月 Fable 5 发布后不久进行评测,比较基准结果并介绍使用模型构建的项目。他既报告迭代成功,也报告严重失败,讨论防护和数据保留,并主张在验证的前提下尝试更有雄心的工作。
- 1基准测试与防护Theo 区分模型测量表现和拒答、备用模型转交的影响。
- 2有条件的大型迁移旧应用经过多轮反馈后可运行,但后续迁移仍有严重回归。
- 3用量成本快速增长Theo 称一次密集工作流在按量计费下八分钟花掉 100 美元,任务仍未完成。
- 4一次错误审查模型误解预发布与生产环境,在澄清后仍坚持报告问题。
- 5分析 SkateBench模型找到了错误中的命名模式,尽管它自己也答错了同样的问题。
- 6探索并验证Theo 强调模糊测试和独立审查,并明确反对放弃代码审查。
要点建议
- 防护措施和拒答会影响基准分数和产品行为。
- Theo 报告了有前景的编程结果,但质疑部分基准的方法或波动。
- 大型现代化项目需要多轮反馈,而进一步迁移仍破坏了重要功能。
- 密集工作流可能快速消耗用量,也可能产生错误的审查结论。
- 即使模型能探索更大任务,人工审查和测试仍然必要。
按章节阅读整理后的全文
初步印象与基准测试
Theo 介绍模型,并区分基准测试结果与防护措施的影响。他讨论多项评估及其局限。
Fable 5 发布后,我一直在密集测试。Anthropic 将它描述为与 Mythos 5 使用相同的底层模型,但有额外防护。我对它的能力印象深刻,也遇到了拒答、成本和错误,这些在评估时同样重要。
有些基准测试表格把结果标为 Mythos 5/Fable 5,但防护措施可能改变结果。我报告的比较中,Fable 因拒绝部分任务,在 Terminal-Bench 上低了约 20 分。区分模型能力和产品的实际行为很重要。

展示的 SWE-bench Pro 分数约为 80%,但我对这项使用已有拉取请求的测试持怀疑态度。我担心模型可能在训练时接触过相关材料。这是方法上的担忧,不是某次测试发生数据污染的证据。
展示的 FrontierCode 最难档中,Mythos/Fable 得分约 29%,Opus 4.8 约 13%,GPT-5.5 为 5.7%。我也看到很强的视觉和空间测试结果,但一项基准衡量的是特定任务和配置,不是智能的所有方面。
我自己的 SkateBench 要求模型根据空间描述说出滑板动作名称。在展示的运行中,Fable 得分 79%,Gemini 3.1 Pro 得分 98%;之前一次高推理强度的 Fable 运行达到 83%。这是一项小众测试,适合探索差异,不是综合排名。

我还担心 FrontierCode 的波动:展示的 Opus 分数没有随着推理强度稳定上升。这让我谨慎解读结果,但这种模式本身并不能证明分数波动的原因。

DataCurve 与我分享了早期 Deep SWE 结果。在这项评估中,我认为 xhigh 强度的 Fable 与 GPT-5.5 大致相当,并以较低的单任务成本超过展示的 Opus 结果。这是特定评估,不保证其他工作负载也有同样价格或性能。
当时我引用的 API 价格是每百万输入 token 10 美元、每百万输出 token 50 美元,订阅访问也只有有限窗口。我预计条款会随容量变化。这里的价格、限额和可用性描述的是 2026 年 6 月的发布情况,并非当前条款。
真实项目、失败与成本
他测试现代化和迁移工作,例子包括迭代成功、功能回归和快速增长的用量成本。
实际使用中,我觉得模型特别细致。我让它现代化我以前的 ping.gg 流媒体应用。第一次构建没有成功,但经过大约四轮截图和错误反馈后,它完成了大规模变更并得到可运行版本;这不是一次成功。
我进一步要求它迁移到更新的技术栈。它取得了出乎意料的进展,但迁移结果破坏了核心功能,也引入了界面和认证问题。这说明进展与局限可以同时存在:结果仍需要大量工作。
那个工作流进行时我触及限额,转而使用按量计费。运行约八分钟花了 100 美元,第二个订阅也达到了会话限额;我最终停止,任务仍未完成。这些数字来自我运行的一次特别密集的工作流。
一次 Lakebed 审查暴露了另一个失败。我的 main 分支部署到预发布环境,生产环境使用另一分支,但模型比较错了环境,坚持认为存在严重不兼容。即使我解释配置后,它修改的报告仍建议修复我认为无需修复的问题。
防护措施与演示
Theo 讲述备用模型转交与拒答的经历,展示界面和游戏,并让模型分析自己的基准测试。
我在不同界面遇到的拒答情况不同。有一次,我询问自己网站的可发现性时,请求被转给 Opus,直到我澄清身份和意图。其他用户报告了更多拒答。Anthropic 的系统卡还描述过针对前沿模型开发的最初不可见干预;该政策后来发生了变化,本视频反映的是早期状态。
Artificial Analysis 报告,其智能指数评估中约 8% 的任务发生了备用模型转交,而 Anthropic 描述的是平均少于 5% 的会话。两项百分比的分母和工作负载不同,不能直接视为相互矛盾的估计。转交与拒答都会影响分数解读。
我比以前更喜欢许多生成的界面示例,但无法判断这是更好的设计判断,还是仅仅使用了更好的模板。有些例子仍然不好看。它们是起点,不代表可以省略视觉审查。
我的团队还构建了一些有趣的例子:终端冒险游戏、Rust 终端界面、方块建造游戏和多人赛车游戏。这些演示展示了人们借助模型做出的成果,但不能证明每个功能都无需人工参与,也不能证明项目已可用于生产。

我让模型分析 SkateBench 结果。它指出两道题区分了约定俗成的名称和对动作的字面描述:许多模型能描述动作,却说不出固定的滑板术语。尽管它自己也答错了这些题,它还是识别出了这一模式。

数据、代码质量与验证
他讨论公布的数据保留政策和对代码质量的定性印象,并鼓励在测试和人工审查下尝试更大项目。
Anthropic 宣布 Fable 流量需要保留数据 30 天,并表示不会将这些数据用于训练新 Claude 模型或非安全目的。我对模型改进的来源有所猜测,但关于使用用户历史进行训练的说法并不能由这项保留公告证明。
我还谈到另一位开发者使用它构建 Python 工具并改进数据库智能体的早期经历。我的个人印象是 Fable 的代码通常更易读、结构更好,但这是定性判断。它仍会犯错,需要审查。
我正在尝试更大范围的任务、独立审查,并让智能体测试自己的工作。在 Lakebed 的数据库重构中,模型编写的模糊测试找到了问题。这让我更愿意让它探索,但我并不是说可以不再阅读代码或跳过验证。
我的建议是测试边界:给智能体更难的问题,看看它在哪里失败,再提供工具或测试帮助它继续。我的经历令人鼓舞,但不保证模型可以安全重写任何系统。保留人工审查,保持好奇,并将结果与实际需求比较。
同频道的其他文章
38:47EN → 简体中文
36:07EN → 简体中文
30:37EN → 简体中文
0:43EN → 简体中文
29:22EN → 简体中文
31:13EN → 简体中文