Block 如何用 Claude Fable 编排数千个 pull request 的代码迁移

Block 打造帮助企业和个人参与经济的工具，包括面向卖家的 Square 和面向消费者的 Cash App。Bradley Axen 在 Block 领导 AI 能力团队，他的团队构建端到端 AI 产品，包括 Buzz——一个面向人机团队的开源工作空间（在新标签页中打开），并与 Square 和 Cash App 团队合作打造面向客户的 AI 功能。Brad 与 Anthropic 探讨了 Claude Opus 5 和 Claude Fable 5 等前沿模型如何改变了工程师的含义、Block 如何用 Fable 应用智能体编排模式，以及当每位员工都能使用前沿模型时保障措施所扮演的角色。

前沿模型在 2026 年取得了实质性进展。这项技术如何影响了你的工作方式？

AI 对我们在 Block 工作的最大影响在于我们构建事物的方式，其影响力怎么强调都不为过。我们在 2025 年通过 Claude Code 等工具看到了它的开端，当时它还需要大量人工干预。随着模型变得更智能，设计和工程工作已转向设计迁移本身、审查智能体行为，以及构建更多面向客户的功能——这一直是我们的目标。

下一阶段是通过 Block 的产品将这些变革性技术带给我们的客户。AI 在帮助小企业处理它们不愿花时间打理的后台运营，或帮助 Cash App 客户管理财务方面，能带来同样多的价值。借助 Claude，我们在技术上有了一个全新的杠杆，可以改变人们对软件能为他们做什么的期望。想象一下，如果 AI 能够响应客户需求并即时构建新界面会怎样？我越来越认为，我们的产品将越来越多地借助 AI 按需构建，以解决具体问题。

随着前沿智能的演进，你的团队现在能做哪些几个月前还做不到的事？

Claude 更新的前沿模型带来的最大变化是我们构建软件的规模。编写代码仍然是核心组成部分，但现在我们会用 AI 进行全公司范围的迁移。我们长期以来都怀有这一梦想，而在 2025 年它很少能实现。在 Claude Fable 5 之前，你必须有一个形态特别合适的问题，前沿模型才能真正大放异彩。

在 2026 年，AI 是我们运行所有大规模代码迁移的重要部分。对我们来说，一次迁移可能意味着跨多个代码库的数百或数千个独立拉取请求，以及数百万行代码。过去，人类必须协调这些工作，而模型一次只能处理一个或几个 PR。有了 Fable，我们看到它能够跨多个会话编排工作。人类工程师负责掌舵，Fable 专注于更高层次的设计工作：数据模型、API 规范、算法。然后它指挥多达数十个更小、更具成本效益的模型（如 Opus 或 Sonnet）来完成各项任务，例如进行实际的文件编辑和运行测试。

经济账算得过来。早期结果显示，编排器使用前沿 token 进行复杂的、前期规划，然后将更高比例的 token 交给更小的工作模型，而质量并未下降。我们在 Buzz 上运行整套设置，这是我们的开源协作工作空间，人类和 AI 智能体在共享频道和话题中并肩工作。它让我们能很好地了解团队的进展。

在任何一次迁移中，我们可能会合并由 Fable 编排的一千个拉取请求。这让工程师能够专注于困难的设计决策，而不是机械性的工作。

什么时候你会选择 Claude Fable 模型而不是其他选项？

自那以后，很多模型已经开始缩小差距，Opus 也非常出色，但 Fable 问世的那一刻，你能一次性处理的问题规模发生了巨大的飞跃。Block 的团队被这一点吸引，并开始思考再提升一个抽象层次、再提升一个规模层次意味着什么。

现在，我们的很多讨论都围绕模型效率。这就是模型编排发挥作用的地方：Fable 的前沿智能在你用它处理大问题时最有价值，然后我们依靠更小的模型来填充代码变更中的大量细节。这 literally 是我记忆中自我们开始将 LLM 用于代码以来，第一次答案不再是“100% 的时间都使用最前沿的模型”。

模型编排是我们今天构建方式的重要组成部分，这意味着我们需要新的工具。有些工具非常专注于单一对话，其界面无法跟上你同时有 45 个代理与你协作的情况。这就是 Buzz 的另一个用武之地。我们在 Buzz 中有多代理工作流，我们真的认为未来是多人对多代理，组织为常规任务选择高效模型，为更大的问题选择前沿模型。

你交给 Fable 的最难的问题是什么？

第一个是大规模迁移：数千个 PR 的迁移，Fable 编排了整个完成工作的系统。

第二个是拿一个大型代码库，大约一百万行代码，确保它不会每天增加技术债务。我们发布的 PR 比以往任何时候都多。人们发布了更多的功能和更多的变更，所以我们的系统积累技术债务的速度比以往任何时候都快，而我们一直缺少相应的东西来加速我们维护它们的能力。这终于发生了。我们有代理每天或每周对整个代码库进行扫描，询问：“这里进展如何？我们需要清理和整合什么？”

在广泛访问的情况下，你如何推动前沿模型的高效使用？

我们让任何技术角色的人都能完全访问最前沿的模型，因为我们战略的很大一部分就是始终在可能性的边缘工作。

用 Fable 修复 README 中的拼写错误是对资源的非常糟糕的使用。所以我们需要更好的系统来建议给定任务使用哪个模型。为了实现这一点，我们一直在构建一个自动选择器，帮助员工选择何时使用哪个模型。我们由大小前沿模型混合驱动的多代理系统也有帮助。

作为一家公司，我们的目标很大一部分是默认高效运营，这就是我们现在正在培养的技能。我们有很多优秀的模型可供选择。如果每个人都擅长为正确的任务选择正确的模型，我们的成本效益会大大提高，而不会拖慢我们的速度。

你是否建议特定的优化策略，比如努力级别？

即使作为一个整天与 LLM 打交道的人，我几乎觉得在 xhigh 努力级别下的模型与同一模型在 medium 级别下是不同的模型。我不认为努力级别是你沿着走的一条光谱。Fable 在 low 级别下可能就比另一个模型在 xhigh 级别下更好。所以我认为它是一个更大的网格，我们需要针对它进行优化。我们基准测试的每一个用例，我们不仅检查每个模型，还检查每个模型的每个努力级别。

作为核心负责我们如何做 AI 的人，我想要非常明确的建议，比如：“对于这类任务，默认使用这个模型的高级别。”我们必须让工具尽可能自动地做到这一点，然后让专家在需要时自行探索。

你如何考虑将保障措施与当今的前沿模型结合起来？

有些事情如此关键，以至于你需要保证，而我们还没有准备好让 LLM 在我们的代码库上自由行动。我们始终将合并到主分支和部署到生产环境留给人类，以及相关的更改，如功能标志。代理可以进行代码更改，但这些更改必须通过我们的安全检查，然后需要两个人批准部署。这种双重批准层使得 LLM 不可能自行推送这类更改。

在更低的层面上，令人惊讶的是，如果员工不注意，他们可以在笔记本电脑上做多少事情，那些你假设人类不会做的事情，因为他们知道不该做。这推动我们走向有趣的方向。我认为未来的工作很多是远程工作站，因为它们更容易保护（并且它们有助于解决 LLM 的其他问题，比如填满磁盘空间）。我们安全故事的一大部分是构建默认安全的系统：使用网络允许列表而不是拒绝列表，以及类似的东西，这样可以阻止最糟糕的问题。

我们还尽可能多地从模型循环中获取。我们的许多安全护栏是非常廉价、高效的检查，无需模型参与即可运行。我们将这些构建到人们用来工作的界面中。有时甚至是一个正则表达式。越来越多的，更小的分类器也成为其中的一部分。

然后在日常中，有一整类你想启用的事情，以使人们高效，而阻止它们不值得。我们有意让模型打开 PR、审查代码，并查询我们的日志系统和分析数据库，所有这些都为了帮助人们更快地行动。

这就是模型内置保障措施真正关键的地方。我指的是 Fable 和其他前沿模型被调整以避免参与危险活动的方式，加上 Anthropic 自己的安全分类器（在新标签页中打开）。在我们的测试中，即使有人要求 Claude “绕过”我们的双重批准系统，它也拒绝尝试绕过它。这也是我们进行基准测试的内容。

对其他使用前沿模型的工程团队有什么建议吗？

我们有成千上万的人在使用 AI，他们正在推动其能力的边界。他们作为个人在学习什么有效，并且他们正在改进周围的系统。例如，我的笔记本电脑上有一堆本地技能，使我能够在我们的 Square 网页前端中工作，尽管我并不是专业的前端开发人员。当所有这些上下文和组织知识在系统层面而不是个人层面被记住时，组织成熟度就来了。

我们的目标是把从一线实践者那里学到的一切记录下来，并纳入一个让所有人受益的系统，这样每次你运行 agent 时，都知道它拥有最佳的上下文来为你的工作做出贡献。

立即开始使用 Claude Fable 5.1（在新标签页中打开）。