스크립트
00:00:00Fable 5.1 和 GPT-6 Astra 发布仅相隔几天，两者的基准测试
00:00:05分数都非常高。Astra 在 AGI 测试中甚至取得了近 100% 的高分，这是以往没有任何模型
00:00:11能接近的成绩。因此看这些数字，你会期望它在处理你自己的实际工作时
00:00:16也能表现得极为出色。但在这些测试中的优异表现并不能说明模型在处理
00:00:20具体工作时究竟能发挥多大作用，我们想看看这两个模型在我们的
00:00:25实际工作中是否同样表现优秀。由于我们是一家软件公司，手头本来就有项目可以用来测试，于是我们将
00:00:30这些项目中的工作交给了这两个模型，并检查了它们的完成情况。我们在多个
00:00:35项目中运行了每个模型，并对其在不同领域的表现进行了评分。我们使用了 GPT-5.6 来协助
00:00:41评判和打分结果。这位裁判模型并不知道哪些结果来自 Fable，哪些来自
00:00:45Astra。其中一个模型的总分为 100 分中的 86 分，而另一个则是 84 分。这看起来
00:00:52可能差距很小，但总分领先的模型并没有在测试的每一个环节都获胜，
00:00:57而另一个模型在其中某些方面表现得令人惊讶地好。因此，我们将详细回顾每个
00:01:02模型在测试中的表现，以及它们在各个类别中是谁胜出，好让你了解这些差异
00:01:07会如何影响你交给它们的工作。在我们探讨每个模型的具体表现之前，先来简单了解一下
00:01:12这些模型本身。本节仅针对那些对它们还不太了解的人，如果你已经知道了
00:01:17这些细节，大可跳过这一节，直接看下一部分。Anthropic 发布了
00:01:22Fable 5.1 在 9 月 1 日发布，甚至还没等 Anthropic 充分享受发布带来的热度，
00:01:27OpenAI 就在 Fable 推出几天后推出了 GPT-6 Astra，人们一直在用这些模型开发非常有趣
00:01:33的产品，将这些模型推向能力的极限，并取得了令人惊讶的
00:01:37成果。在定价方面，这两个模型的定价实际上是相同的，均为每百万输入 Token 10 美元
00:01:43以及每百万输出 Token 50 美元。但 Fable 5.1 有一点
00:01:49不同，那就是 Anthropic 将缓存读取（cached reads）的价格降低了 75%。对于不了解
00:01:54缓存读取的人来说，模型已经阅读过的一部分对话其实会被保存起来
00:02:00以便重复使用。当你发送新的提示词时，这些保存的部分会被重新利用，而不需要模型从头开始
00:02:05再次阅读，这个过程就叫做缓存读取。这些读取本来就已经让重复使用
00:02:10对话变得更便宜，而随着价格的下调，费用变得更加低廉。但这并不意味着 Fable
00:02:14在总体上是一个更便宜的模型，因为总费用还取决于许多其他因素，我们
00:02:19稍后会谈到。目前 Fable 模型已经在 Claude Code 中使用了一段时间，但 Fable 5.1 仍然没有
00:02:25包含在 Claude Pro 计划中，所以在 Pro 版本中你必须通过使用额度（credits）来单独付费。在
00:02:30Max 计划中，Fable 5.1 是包含在内的，但 Fable 模型的使用上限比其他模型要低。
00:02:36另一方面，OpenAI 并没有把 Astra 视为一个单独的模型来对待，因为 Astra 是
00:02:41ChatGPT+ 和 Pro 上常规 Codex 额度的一部分，你可以把所有的使用量都花在 Astra 上。现在这些
00:02:47模型确实具备处理长任务的能力，这意味着你可以直接要求它们构建一个大型
00:02:52功能，然后放手让它们自行完成各个步骤。但当你让这些模型去处理
00:02:57长任务时，它们所能容纳的上下文大小也很重要。Fable 在 Claude Code 中为你提供一百万个 Token 的上下文，
00:03:02而 Astra 在 Codex 中的默认上下文窗口仅为 272,000 个 Token，尽管 Astra 通过其 API
00:03:09拥有大得多的窗口，甚至比 Fable 的一百万还要高。但目前你在 Codex 中是无法获得
00:03:14这一点的，因为 Codex 默认的上下文窗口就是 272,000 个 Token，即使对 Astra 来说也是如此。
00:03:21现在这些模型已经达到了能够进行高级研究的水平，因此 OpenAI 和
00:03:26Anthropic 都增加了安全护栏，限制了它们被允许执行的部分工作。
00:03:31但这些限制也会以不同的方式影响你的工作，因为当安全系统判定你的请求不被允许时，
00:03:36每个模型的反应都不一样。当 Astra 碰到任务中违反其规则的部分时，
00:03:41它会直接拒绝该任务并向你说明情况。另一方面，
00:03:45当请求违反规则时，Claude Code 会从 Fable 切换到一个较弱的模型。许多
00:03:51人发现 Claude Code 在他们不知情的情况下悄悄切换了模型。因此，如果 Claude Code 在
00:03:56切换后继续工作，你得到的结果可能就不再来自 Fable 了。
00:04:01我们测量的第一个指标是质量，它考察的是模型的工作实际有多好。
00:04:06为了这次测试，我们使用了多个客户项目，因此我们不能透露这些项目的细节，
00:04:11但我们可以解释我们是如何评判这些工作以及模型之间的差异体现在哪里。关于代码
00:04:16的编写和组织情况，Fable 获得了 90 分，而 Astra 是 78 分，因为它将应用程序不同部分的
00:04:22代码保持了更清晰的分离。这使得模型在以后进行更改时更容易理解应用程序，
00:04:27并且在我们测试的所有项目中，Fable 在这一点上都领先于 Astra。而在
00:04:32要求的各项工作完成了多少方面，Fable 得到了 91 分，相比之下 Astra 是 84 分，因为 Fable 还顺便修复了
00:04:39我们没有专门要求它去修复的问题。但我们也检查了已完成的功能是否在无需我们要求修复的情况下
00:04:44正常工作，在这方面 Astra 获得了 87 分，Fable 为 85 分。
00:04:50Astra 的部分领先优势来自于对应用程序进行了更彻底的检查并修复了更多已知的问题。
00:04:55当 Fable 测试其应用程序时，它漏掉了一些可能出错的情形，因此完成的功能
00:05:00仍然存在一些问题。在应用的使用体验方面，Astra 获得了 89 分，Fable 为 88 分，
00:05:08因为它将页面上的不同部分安排在了更容易找到和使用的位置。
00:05:13因此基于我们刚刚提到的所有测试，Fable 的总体质量得分为 88 分，而 Astra 得到了 84 分，
00:05:19因为 Fable 构建的功能更完整，且其工作在后续更容易进行修改。所以在质量方面，
00:05:25Fable 是毫无疑问的赢家。但在我们进入下一个测试之前，先听一下我们的赞助商
00:05:30Zapier 的介绍。当你用 Vibe 编程写出一个应用并且它运行良好时，一旦你想让它真正连接到
00:05:35Gmail、Slack 和 Notion 等工具，你就得手动搭建每一个集成和 OAuth 流程。不知不觉中，
00:05:41你就会陷入繁琐的身份验证代码中，突然间集成工作成了整个项目的全部。这就是
00:05:46Zapier SDK 派上用场的地方。它是一个你可以直接放入项目的代码库，就在 Claude Code 或 Cursor 中，
00:05:52让你能够以编程方式访问 Zapier 拥有 9000 多个应用的生态系统。因此，与其手动构建每一个集成，
00:05:58我们只需调用需要的那些并继续前进。只需几行代码，我们的应用就能发送电子邮件
00:06:04并创建 Notion 页面，无需查看 API 文档，也不用苦心应付身份验证。当我们需要更新
00:06:10Notion 中没有预建操作的自定义属性时，我们可以通过 SDK 直接对其进行调用。
00:06:15它真正做到了在你的工作流中无缝契合。如果你厌倦了手动搭建集成，
00:06:20不妨试试 Zapier SDK。链接就在下方的说明栏中。我们测量的下一个指标是模型如何处理
00:06:26长运行任务，也就是它们在工作时靠自己完成了多少工作，而不需要我们给予太多
00:06:31指导。我们还检查了它们如何处理过程中出现的各种问题。
00:06:36为此，我们给每个模型一个要构建的应用创意，并根据其提示指南来措辞请求，
00:06:42以便让它有最大机会把工作做好。我们没有提及想要的具体细节，
00:06:47而只是描述了应用需要做什么。Astra 工作了大约 32 分钟，Fable 工作了
00:06:53大约 44 分钟。Astra 在构建和检查其应用时遇到了错误，但它自己克服了这些问题，
00:06:58并在不需要我们指导它解决每个问题的情况下继续修复应用。Fable 也完成了
00:07:03它的应用，没有提前停止也没有问我们接下来该做什么，并且它对其构建的内容运行了检查。
00:07:09所以两者都把工作坚持到了最后，但我们也仔细检查了完成的应用，看看它们给我们留下了
00:07:13什么样的成果。Astra 的应用直接打开登录页面，没有单独的着陆页。一旦我们
00:07:18登录进去，布局组织得很好，应用也能正常工作，尽管它依然带着许多 AI 生成应用中
00:07:24常见的熟悉布局。但我们在侧边栏遇到了一些问题，因为它无法滚动得
00:07:30足够远以让我们够到登出按钮。我们不得不缩小页面才能按到那个按钮，而这是
00:07:35Astra 自身的检查没有发现的问题。Fable 的应用同样直接打开登录页面，但它的
00:07:40设计感觉要平庸得多。各项功能虽然能用，但所有东西都挤得太紧了，
00:07:45以至于应用很难使用，而重复的渐变色也加剧了那种熟悉的 AI 生成外观。它确实能适应
00:07:51更小的屏幕，但依然缺乏一个好用的布局，尽管功能做得比较深入。我们
00:07:56还规划并构建了其他几个应用和庞大的功能，同样是以这种让模型
00:08:01自行工作的方式完成的。因此在长任务方面，Astra 在 100 分中得到了 93 分，而 Fable 是 90 分。
00:08:08Fable 更专注于让功能运转起来，除非我们在提示词中明确说明它也应该
00:08:13关注视觉效果。而 Astra 既关注应用的运行逻辑，又关注它们的外观，
00:08:18因此 Astra 在长运行任务上胜出。我们看重的下一个指标是设计以及
00:08:23应用是否易于使用。我们确实让模型给设计打过分，但我们不想仅仅依赖
00:08:28它单一的设计品味。于是我们构建了一个查看器来展示 Fable 的结果，又做了一个给 Astra，这让我们能够
00:08:33亲自浏览设计并比较它们的使用体验。我们给两个模型分配了相同的设计
00:08:38任务，首先是为一个销售字体的企业制作着陆页。Fable 的版本看起来与
00:08:44Opus 通常产出的风格非常相似，从颜色、字体到布局。它甚至还有那种我们在最近 Opus 设计中
00:08:50经常看到的横跨页面的文字滚动条。但 Fable 与 Opus 不同的地方在于，
00:08:55它在整个设计中加入了更多互动元素，这让应用感觉更好用。
00:09:00Astra 的版本布局更宽敞，字号和色彩对比更清晰，
00:09:05让文字更容易阅读。但动态效果明显少得多，所以虽然看着更舒适，
00:09:10却没有 Fable 设计的那种体验。这就是为什么 Fable
00:09:14在交互得分上得了 94 分，而 Astra 得了 85 分。接下来，我们让每个模型设计一个恐怖游戏
00:09:20落地页。Fable 的设计使用了一个动画灯塔来营造氛围。
00:09:25它用 SVG 制作了美术图形，也就是用代码绘制的图像，但由于 Fable 选择的尺寸和颜色，
00:09:31文字在暗色背景下不够显眼。而在同样的设计任务中，Astra 使用了
00:09:36Codex 内置的图像生成模型来生成图片，而不是用代码创建美术素材。
00:09:42它还为游戏创建了一个预告片，尽管我们并没有要求。而 Astra 领先的地方
00:09:47在于它对字体和色彩的选择，这使得文字在暗色背景下更加突出。
00:09:52对于音乐节网站，Fable 的版本重复了很多我们在 Opus 制作的设计中
00:09:57看到的设计选择。但即使有这些熟悉的选择，Fable 似乎也花费了更多精力
00:10:03来赋予该网站独特的风格。Astra 使用了一张生成的演唱会照片，但整体设计感觉更通用。
00:10:08最后的对比是一个侧方停车游戏，其中 Fable 的版本制作得非常精良，
00:10:13而后视镜帮助我们更准确地判断移动汽车的位置。该游戏有两个
00:10:18相机视角，但都存在问题。因为一个显示了停车位的错误一侧，
00:10:23而另一个只显示了一侧，而没有给我们提供前方道路的全景。这使得
00:10:27我们更难看清汽车移动的位置，如果这些相机角度正确的话，游戏会
00:10:32感觉更逼真。Astra 提供了三个固定视角并在侧边栏添加了驾驶提示，
00:10:38这使得它的游戏更容易上手。相机视角也比 Fable 的好得多。这些都是
00:10:42常规测试，我们向模型提供极少关于所需设计的细节，因此在这里我们看到的是
00:10:48模型自己的品味。两者都重复了我们在它们其他作品中看到的设计选择，但也确实
00:10:53产生了很好的结果。只要再多一点关于我们对应用外观和体验的要求的细节，
00:10:58我们期望两者都能设计得很好。因此单从品味来看，Astra 在视觉和易用性上获胜，而 Fable 在
00:11:04动画和交互性上获胜。但在我们继续测试成本和速度之前，如果你能
00:11:09订阅频道并点击点赞按钮，那就太好了。这个小小的支持举动对我们意义重大。
00:11:15我们测量的下一个指标是效率，涵盖了工作成本、耗时，
00:11:20以及模型为完成工作而使用工具的次数。关于成本需要了解的一点是，
00:11:25我们没有使用 API，所以这些只是根据所用 Token 估算出的使用 API 工作的成本。
00:11:31我们在常规订阅上运行了测试。在所有测试运行中，Fable 的
00:11:37估计总成本为 49.18 美元，而 Astra 为 27.69 美元，因此 Astra 的总成本大约低了 44%。
00:11:47Fable 生成的输出 Token 数量几乎是 Astra 的 3 倍，正如 Fable 的提示词指南
00:11:52中提到的一样，它往往比其他模型写得更多。两个模型这些 Token 的成本是相同的，
00:11:57所以写得更多正是导致 Fable 成本增加的原因。使用工具也会增加 Token 的使用量，
00:12:03因为模型会决定使用哪个工具，然后在继续工作之前读取结果。在所有
00:12:09六次运行中，Fable 的主智能体使用工具的次数为 443 次，而 Astra 为 287 次，这也增加了
00:12:17成本。在成本方面，Astra 满分 100 分得了 80 分，而 Fable 得了 66 分。在速度方面，Astra 同样
00:12:23领先，得 70 分，Fable 为 67 分。Astra 的长时间运行任务总共耗时约 62 分钟，
00:12:30而 Fable 耗时 73 分钟。因此在成本、速度和工具效率的得分上，
00:12:35Astra 优于 Fable。我们测量的下一个指标是指令遵循能力，
00:12:40我们检查了模型在构建过程中遵循我们给出的指令的程度，
00:12:44以及随着工作的继续它们是否能持续遵循。当我们让 Fable 运行一个项目时，
00:12:49它最初添加了一条共同署名消息，称 Claude 协助编写了代码，
00:12:53尽管我们的指令明确禁止这样做。它还忽略了一条关于如何创建或修改文件的规则。
00:12:58我们告诉它使用 Claude 自己的文件编辑工具，这样这些更改就可以被追踪
00:13:04且易于撤销，但它却通过运行命令创建了两个文件。在指令遵循方面，
00:13:09Astra 满分 100 分得了 96 分，而 Fable 得了 88 分。所以论遵循指令，
00:13:16Astra 在这些运行中表现领先。我们测量的下一个指标是审查质量，我们给模型
00:13:21提供了一个包含问题的项目，并要求它们找出这些问题。我们首先给两个模型
00:13:27审查相同的代码，其中故意添加了四个问题，以便我们知道它们需要找出什么。Fable
00:13:33找出了全部四个，还找出了我们没有添加的另外五个问题，这些问题随后
00:13:37得到了检查和确认。Astra 找出了我们添加的四个问题中的两个，但它仍然告诉我们审查
00:13:42已完成。我们还包含三个看起来可疑但实际上正确的代码段，因为
00:13:47我们想看看模型是否会报告错误的问题。两者都没有将这些视为漏洞，所以这里的
00:13:52区别在于它们找出了多少，Fable 给出了更彻底的审查，
00:13:57但当我们在一个包含 9 个已确认问题的大型项目上测试它们时，Astra 修复了 5 个，而 Fable
00:14:03只找到并修复了 4 个。因此 Astra 完成了更多的修复，尽管两者都留下了几个问题
00:14:08未修复。对于审查质量（包括这些修复以及模型如何检查其其他工作），
00:14:13Fable 得了 84 分，而 Astra 得了 78 分。因此 Fable 在整体审查得分上胜出，
00:14:19因为 Fable 整体上给出了更出色的审查。所以根据这些结果，Astra 在我们测试的多个类别中明显胜出，
00:14:25但这并不意味着 Fable 是一个糟糕的模型，因为它在各项任务中确实表现良好，
00:14:30在其中几个任务中也只落后 Astra 一点点。所以你只需要根据你交办的任务
00:14:35来选择模型。现在，为了将这两个模型的性能推向极致，有一些
00:14:40特定的实践需要遵循。我们在测试中使用了其中很多方法，如果你也想获取
00:14:45这些方法，你可以在我们的社区 AI Labs Pro 中获取。所以如果你觉得我们的工作有价值
00:14:51并想支持本频道，这就是最好的方式。链接在简介中。
00:14:56这就到了本视频的尾声。如果你想支持本频道并帮助我们继续制作
00:15:01这样的视频，可以通过使用下方的超级感谢按钮来做到这一点。一如既往，
00:15:05感谢观看，我们下期再见。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기