Anthropic发布Opus 5.5，主打高质量插值型软件生成

围绕 AI 编程的许多兴奋点，归根结底源于一个事实：大量软件本质上是插值式的。这一点在近来尤为明显——随着 Opus 5.5 的发布，我敢说它在生成大量高质量插值式软件方面已经达到了超人水准。¹ 这篇文章主要是为我过去几个月几乎每天都会提及的一个想法做一份参考记录。 在 2026 年，软件落在一条光谱上，一端是插值式软件，另一端是新颖软件。 绝大多数软件工程师² 大部分时间所写的软件，都属于插值式软件。所谓插值式软件，是指稳稳落在模型训练分布之内的代码。有时这意味着，agent 们（很可能）确实是在构建各类软件的示例上训练过的（比如“做一个 todo 应用”“做一个 xyz.com 的克隆”），或者是在特定 API 内构建的（比如 React）。另一些时候，软件与足够多的现有软件“押韵”，或者处于两块软件之间一个定义明确的位置，使得模型能够在它见过的相似示例之间进行插值。 插值式软件往往只需要几句话的 prompt 就能描述清楚。判断软件是否属于插值式，要问的问题是：你需要在 prompt 里包含多少比特的信息，才能得到你想要的东西？³ 如果答案很小，那它就是插值式的。⁴ 诸如 issue tracker、Web 表单、训练流水线、CI 系统、工作流引擎，以及几乎所有在开源文献中有标准参考设计的东西，或多或少都落在这个插值式的范畴内。 光谱的另一端，是新颖软件。当你在做某种从根本上未曾存在过的东西时，你就是在开发新颖软件。这通常是因为，要么构成它的组件不在 agent 的训练分布中，要么它们以如此新颖的方式被组合在一起，以至于 agent 对如何组装这些组件的直觉不足以在缺乏大量人工引导的情况下解决问题。 用 agent 编写新颖软件，感觉像是“逆水行舟”，因为其中有足够多的新颖组件并非来自训练语料，模型在努力领会你想要什么。真正新颖的软件并不多。这也没问题；插值式的东西本身就有巨大的价值。 在工作中，我们一直在重新开发一个大规模分布式系统，它有一组复杂的特定需求。我确信，满足这组特定标准的系统此前在任何公司都不曾存在过。（即便存在过，也肯定不是公开的，也不在任何公开训练集中。）看着同事们用大量的 agent 和 token 在这个系统上推进了大半年，实在令人着迷。尽管这是我迄今见过的最“agent 化”的项目之一，它仍然需要大量细致的人工引导，以确保系统真正按设计运行。 另一方面，你可以给 agent 下达本质上是“做一个 Anki”或“做一个 Linear”的指令，它就会端到端地做出来。这两件事我都做过——我让 agent 把 Anki 的大块功能重建成了我个人的一套工具。只花了几条 prompt，就完全无差别地替代了我所关心的 Anki 全部功能。Linear 同理。⁵ 随着 RL 环境日益多样化，属于插值式软件的范畴会随时间不断扩大。 AI 行业有时用任务时间跨度来衡量这一点（例如 METR 时间跨度图）。这是个有用的指标，但它大致是一个代理指标，衡量的是“你能给 agent 多大技术难度的任务，而它最终仍能产出有用的东西”。agent 所能进行的创造性插值的量在增长——而在极限处，足够通用、富有创造性、外推式的现有组件组合，开始看起来像新颖的发明。 在 AI 之前，人们就已在一定程度上认识到，大量软件工程工作花在插值式工作上。“我们想要一个满足 $OUR_REQUIREMENTS 的 CI 系统。我们想要一个针对 X、能做 Y 的工作流引擎。”诸如此类。每个项目都包含一点新颖性，但大量工作是把现有部件以略带新颖的配置重新组装。我把 2010–2020 年代开源运动的成功视为这一点的证据。既然大量软件开发是在组合某种程度上的标准模式，而这些模式本身要胜任地实现又很复杂，那么统一到 OSS 上并共享标准化带来的好处，就是理性的。 需要明确的是：软件是新颖还是插值，并不是一种价值判断。如果要说的话，你反倒应该努力把更多问题推到可以用插值解决的领域，因为插值式的子问题可以轻松地用充裕的 token 解决。现代软件工程师的许多工作，就是投入所需的那些比特，把一个问题从新颖变为纯插值式，从而让最大量的动手交互式实现工作可以外包给 agent。 GPT Sol 6.1⁶ —— 显而易见的对比对象 —— 并不是一个糟糕的编程 agent。只是很明显，Opus 5.5 在输出插值式软件方面有某种特殊的“劲头”，而 GPT 系列模型目前略逊一筹。↩︎ 好吧，到这个阶段得说 agent 了。↩︎ 这里与 Gwern 的《Adding Bits Beats AI Slop》有相通之处。↩︎ 注意，这是前沿模型训练分布的函数，而非软件实际复杂度的函数。“给我造一个内存分配器”是一条很短的 prompt，产出的东西虽然多半不是你在任何真实场景中会想用的，但仍然相当复杂。↩︎ 诚然，我不是 Linear 的重度用户。但我想要一个可改造的 issue ↩︎

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）