Fable 5.2 自主开发演示：短提示词背后的运行成本与验证工作

一、主讲人与议题背景

这集节目由 Matthew Berman 主持，围绕 Fable 5.2 展开模型演示和个人评测。元数据将节目列为 Matthew Berman / Forward Future，时长1458秒，约24分钟。标题中的“最好模型”与他的开场评价一致，表达的是主持人的判断，并非已经独立确立的行业排名。

Berman 是主要发言者。他一边操作生成的软件和场景，一边介绍提示词、运行投入及使用感受。Alex 和 Brian 以团队成员身份参与演示和项目制作，其中包括多人游戏试玩。他们的参与不构成访谈嘉宾背景，这集节目的内容也并非围绕嘉宾经历展开。

Berman 说，自己大概已经投入超过一千亿 tokens 测试模型，并称这是他用过的最好模型。这一自述说明，他的鲜明偏好来自大量个人试用，但完整测试记录并未因此成为公开证据。节目可供判断的材料，是他选出的演示、报告的资源数字，以及个人评价和基准讨论如何支持他的结论。

二、本期主要内容

最醒目的演示，是 Unreal Engine 中一款《战争机器》风格的单关卡游戏。Berman 操作了掩体战斗、限时换弹和队友倒地后的救援，也承认翻越障碍物的动作有些别扭。据他介绍，初始提示词只有三行，要求关卡的观感和玩法尽量贴近目标作品，随后便由 UltraCode 持续执行。简短输入之后，是数天的运行：演示时任务仍未结束，已经消耗85亿 tokens，按 API 定价估算约1.5万美元。这里的“基本一次生成”描述的是输入和干预方式，并不意味着任务完成得快，或成本低。

生产力软件的展示更接近日常工作。Berman 说，浏览器版 Excel 仿作用了接近50小时，并声称它具备完整功能。他用虚构销售数据演示了公式和数据透视表。在随后的赞助环节之后，他报告了约80亿缓存读取输入 tokens、1500万输出 tokens，以及约1.17万美元的 API 成本估算。这组资源数据出现在表格展示之后，但其中的缓存读取和输出属于不同用量类别，不能将两者相加，再按同一个单价计算。

在 Windows 本地运行的视频编辑器 Kestrel 展示了波形、片段切割、移动、吸附、快捷键、缩放和关键帧。Berman 还说，Alex 正在使用自己另外生成的编辑器剪辑视频。这是团队内部使用情况的自述；要确认软件是否具备主持人所称的完整功能，仍需要进一步验收。

Tumble Beans 展示了多人交互。Berman 与团队成员一起试玩，演示中可以看到碰撞、弹跳、闯门和掉落地板等玩法。他说，最初要求的是十个各不相同、有趣且复杂的关卡，多人模式后来才追加。整个项目消耗超过90亿 tokens，运行约71小时，估算成本1.3万美元。这个过程也说明，最终成果包含后续提出的要求，并非全部由最初的指令一次确定。

较小项目的资源投入则低得多。水气球穿透模拟的提示词要求使用单个 HTML 文件、WebGL 2，且不依赖外部库。演示支持回放、移动视角，以及调整弹速、重力和光照；Berman 报告，它用了4100万 tokens、约两个半小时，估算成本91美元。一段软件反编译解释动画长1分52秒，据称消耗950万 tokens，用时45分钟，成本约25美元；另一段 LLM 动画则展示了嵌入、Transformer 层、训练和下一 token 预测。这些项目将展示范围扩展到交互表达和教学素材，也说明不同任务的成本不能按同一量级估计。

三、核心观点：推理、例子与边界

Berman 对自主执行能力最具体的描述，是模型替他作出的决定，十次中有九次甚至更多符合他的偏好。他因此少了一件需要操心的事。如果系统能够自行拆解任务、选择实现路线并持续推进，简短提示词就可能支撑更复杂的成果。不过，符合主持人的偏好，并不等于决定客观正确。这个比例是他的个人估计，节目没有呈现决策总数、错误类型或纠正代价。UltraCode 还会将工作分配给多个子代理，因此，最终表现也取决于执行配置和资源投入，不能全部归因于模型本身。Berman 也因费用高昂而不建议使用 UltraCode。

他对速度的判断，着眼于完成任务需要多久。Berman 说，代码审查找出了错误、安全问题和细微的界面不一致；一些他过去预计需要60至120分钟的工作，如今最多约十分钟就能完成。他明确区分了任务完成速度与 token 生成速度：少走弯路、更直接地得到结果，同样可以缩短总耗时。但这里的旧耗时包含他的预期判断，节目没有在相同代码库、相同缺陷集合和相同验收标准下进行成对比较。这是一项值得测试的效率判断，尚不足以推导出普遍适用的提速倍数。

相比之下，“软件已被解决”的结论，超出了这些演示能够支持的范围。表格中的公式和透视表、编辑器中的剪切与关键帧，证明生成的软件具备可操作的功能，但录制片段只展示了选定的使用路径。Berman 所说的“完整”“完美”，仍是他的评价，不能代替兼容性、异常处理和持续维护方面的证据。演示支持的判断是：复杂原型可能越来越少需要人工逐步指挥。它们能否达到交付标准，仍须另行验证；生成所需的劳动减少，验收工作并不会随之消失。

视觉演示也有类似的证据边界。水气球模拟允许调整参数，Berman 说物理过程会实时重新计算，但提示词中的“物理准确”只是任务要求。节目没有提供数值误差比较或实验验证，水体变形的视觉效果因此不能直接证明物理模型准确。东京场景中的列车、行人、车流和反射展示了场景的复杂程度；Berman 报告，它消耗了67.2亿 tokens，运行约70小时，估算成本1.1万美元。画面和投入本身，仍不足以说明城市复原有多完整。

节目中的瑕疵进一步说明了这种区别：Blender 住宅的车道中间有一棵树，欧洲小镇里有人穿过其他人的身体，一段活动现场复刻则被 Berman 自己评为很差。这些问题不足以否定所有项目，却说明整体画面可信与局部逻辑正确可以同时出现偏差。场景一旦用于导航、交互或设计判断，局部错误就可能比画面的精致程度更影响实际用途。

基准成绩同样需要逐项看待。节目报告 Fable 的 Frontier SWE 成绩为69.9，OS World 2.1为89.3，Humanity’s Last Exam 为74.2；同时也列出 Carbon 在 Automation Bench 上以53领先51，Mythos 5.2在 Terminal Bench Science 上以75.3领先74.6。这些都是节目引用的成绩，未经本文独立核验。节目给出的反例已经表明，Berman 综合判断中的“最好”，不代表每项任务都排名第一。个人偏好、具体任务表现与可复核测量，需要分别判断。

四、学习与应用

要将这些演示用于实际工作，需求和资源都需要留下记录。需求记录应包括最初指令、追加要求和完成标准；资源记录则应包括运行时间、人工介入、执行模式，以及普通输入、缓存读取和输出各自的用量。表格项目区分了缓存读取输入与输出，其他演示报告的则是 token 总量和按 API 价格估算的费用。总 tokens 因此不能直接乘以单一价格得到准确账单。大型游戏与较小模拟之间的投入差异，也说明预算应建立在边界明确的试运行上，再据此决定是否扩大任务规模，而不能只凭画面的复杂程度猜测费用。

模型选择还要结合任务价值与成本。Berman 更偏爱 Fable 的能力，同时认为 Opus 5.5 速度快、效率高，而且便宜得多。实际比较时，可以让候选模型完成同一项真实工作，将生成、等待、人工修正和验收全部计入总耗时，再判断增加的质量是否值得额外支出。节目所报常规价格为每百万输入 tokens 8美元、输出 tokens 40美元；快速模式分别为16美元和80美元。这些数字应视为本期引用的报价。Berman 还转述了快速模式达到2.5倍速度的说法，但明确表示自己没有快速模式的使用权限，因此这一速度未经他亲测，不宜直接用于承诺项目交付时间。

可交互软件的验收，应明确到具体操作和运行条件。表格软件可以先规定需要支持的公式、数据规模和文件交换路径，再逐项检查；视频编辑器可以围绕导入、切割、关键帧、保存和最终输出设置可重复操作。多人游戏则需要明确参与人数、断线后的行为和连续运行条件。Tumble Beans 的团队试玩证明了所展示的多人互动，但没有提供大规模多人验证。Berman 称它已经可以销售，并提出了变现设想，节目却没有销售结果。若据此制定商业计划，仍应将稳定性测试和用户反馈列为后续工作。

实体设计还必须经过测量。打印塔任务规定了0.4毫米喷嘴、PLA 材料、低于10克的重量目标，以及适配打印机尺寸的要求。Berman 报告，任务用了约1000万 tokens，运行一个多小时，成本37美元；随后，他在打印塔上逐步堆放设备和一把电钻。如果要据此比较结构方案，就需要称量成品和各项载荷，记录加载位置、失效方式，并重复测试。节目没有报告最终实测塔重，也没有给出完整的实测载荷，因此无法据此计算可靠的承重比，更不能直接作为承重用途的依据。它展示的是从需求走向实体试验的过程，性能结论仍待测量。

节目中的商业内容与未来推测也应分别看待。Eight Sleep 是明确标注的赞助商，赞助内容不能作为模型表现的旁证；结尾关于递归自我改进和内部模型的讨论，则属于 Berman 对未来的推测，无法补足当前项目的验收证据。这些演示对实际工作的启发，是在给予代理更完整任务空间的同时，明确预算、检查点和最终验收条件。只有把这些环节一起计入，才能判断减少人工指挥是否带来了可用成果，以及后续返工需要付出多少。

来源

• 原始节目：Anthropic just dropped the best model ever... (Fable 5.2)