Claude Opus 5.5 实例：8 个能看出变化的真实演示

核心要点

• Claude Opus 5.5 于 2026 年 9 月 22 日发布，是 Anthropic 5.5 系列的首个模型。Anthropic 表示，它在多数工作上接近 Claude Fable 5.1 的水平，而典型工作负载的成本比 Opus 5 低约 40%。
• 最有意思的 Opus 5.5 实例并不是短小的代码片段，而是长时间运行的智能体任务、用代码生成的视觉内容、多智能体研究、大规模迁移，以及跨仓库工程。
• 公开的 X 演示能说明熟练用户能把模型用到什么程度，但它们不是受控基准测试。提示词、迭代次数、脚手架、工具以及人工介入都可能不同。
• Anthropic 自己的早期试用结果，强化了长周期编程能力的说法：一次 68 万行的迁移据说在一天内完成，另一次 20 万行的审计与修复则在三小时内完成。
• 这些实例中反复出现的模式是：Opus 5.5 被当作能创建并核验产物的智能体来用，而不只是返回文本的聊天机器人。

Claude Opus 5.5 带着醒目的基准分数上线，但基准本身并不能解释开发者为什么在关注它。

更有用的问题是：人们到底在用它做什么？

第一波公开实例指向 Claude 角色的更大转变。Opus 5.5 被用来从代码生成动画、搭建视觉场景、用程序模拟绘画风格、协调其他智能体、迁移大型代码库，并在较少监督下完成持续数小时的工程工作。

这个区别很重要。能回答一道难编程题的模型很有用。能守住目标、编辑大量文件、调用工具、检查结果、从错误中恢复，并连续工作数小时的模型，有用的方式完全不同。

Claude Opus 5.5 速览

Anthropic 把 Opus 5.5 定位在智能体编程、计算机使用和专业知识工作上。标准 API 价格为每百万输入 token 4 美元、每百万输出 token 20 美元，缓存读取为每百万 token 0.20 美元。Anthropic 还表示，输出生成速度比 Opus 5 快 30% 以上。

Anthropic 公布的部分结果包括：

Anthropic 自己也提醒：在这一能力层级上，基准差距并不总能干净地转化成同等幅度的真实世界差异。

正因为如此，下面这些实例比排行榜本身更有说服力。

实例 1：用代码做出来的定格动画

开发者 DreW 分享了一件视觉作品，配文很简单：“Made with @claudeai Opus 5.5。”在相邻帖子和回复里，DreW 说这个项目用了 Claude Code，作品是用代码完成的，并提到声音设计和视觉节奏上有一些来回调整。

为什么重要： 模型被当成通过代码完成视觉制作的智能体。它给出的不是静态答案，而是参与一个循环：代码成为构图、运动、节奏和修改的媒介。

需要注意的是，这是一次展示，而不是一次性基准测试。作者明确提到做过迭代清理。这让这个实例更有参考价值，而不是更少：它更接近真实制作流程。

实例 2：把 Three.js 当成生成式视觉媒介

Addy Osmani 还提到另一个视觉编程测试：用 Opus 5.5 在 Three.js 里做出一只骑自行车的鹈鹕。重点不在鹈鹕本身。有意思的是，语言模型能借助可编程图形栈，把一个视觉概念转成几何、材质、镜头选择、布局和最终渲染构图。

对开发者来说，这是一个有用的模式，因为代码生成的视觉内容可编辑、可检查。生成式图片通常就是最终产物。Three.js 场景则可以继续改、做成动画、参数化、接到用户输入，或作为 Web 应用的一部分上线。

实际使用时，只要目标输出能用 HTML、CSS、SVG、Canvas、WebGL、Three.js 或其他可编程媒介表达，Opus 5.5 就不太像图像生成器，而更像一位视觉软件工程师。

实例 3：不用图像模型，逐像素作画

Anthropic 研究员 Jake Eaton 分享了一个技术上更少见的演示。Eaton 说，实验中的图像是由 Python 程序逐像素生成的，没有用图像模型，也没有用现成的绘画软件。这些程序使用标准库，大约 7500 行代码，来模拟不同的绘画风格。

相比普通文生图，这是对过程化表征更强的考验。

模型必须把笔触质感、调色、空间构图和风格线索，翻译成可执行规则。这同时要求多种能力：

• 把视觉风格拆成可编程的基本单元；
• 在生成局部细节时维持整体构图；
• 用代码作为视觉意图的压缩表示；
• 对渲染结果进行迭代，而不是只描述它。

对正在做设计工具、教育软件、生成艺术系统或浏览器原生创作应用的开发者来说，这项能力比单纯产出一张好看的图更可迁移。

实例 4：着色器生成与视觉推理

沃顿商学院教授 Ethan Mollick 也用着色器任务测试了 Opus 5.5，并发布了模型对同一视觉提示的版本，方便对照。他的初步印象整体偏正面，同时也提到 Claude 在某些语境下语言仍可能偏密。

着色器是很好的压力测试，因为视觉效果往往来自紧凑的数学代码。模型必须推理坐标、变换、颜色函数、重复、类似光照的效果，以及小改动与大视觉变化之间的关系。

这指向一个重要的实际用途：快速探索由确定性代码生成输出的视觉系统。

实例 5：10 个 Opus 5.5 智能体攻最短路径算法

Vals AI 做了一项完全不同的实验。它以最大努力启动了 10 个 Claude Opus 5.5 智能体，给它们一块共享留言板，要求寻找精确最短路径算法的理论改进，并给出完整的 Lean 证明。

Vals 称，15 小时内这些智能体产出了名为 C-HD 的结果，以及 Lean 源码、非正式论文和核验记录。智能体被要求分享发现、互相质疑、保留失败路径，并在宣布成功前必须有可复现的核验。

这个实例之所以重要，和聊天质量关系不大：它展示的是一种工作流，模型成为由其他模型实例组成的研究组织中的一员。

架构大致如下：

研究目标
      ↓
协调者 / 共享工作区
      ↓
多个 Opus 5.5 智能体
  ├─ 算法探索
  ├─ 文献对比
  ├─ 证明构建
  ├─ 对抗式审查
  └─ Lean 核验
      ↓
可复现产物

这套工作流最强的部分，不只是并行本身，而是用独立批评和机器可检查的核验，降低多个智能体共同强化同一个错误的概率。

这个结果仍应视为一项研究主张，而不是被广泛复现的基准；但已发布的证明包，比只有截图的演示更容易检查。

实例 6：把 HAProxy 从 C 改写成 Rust

Anthropic 做了一项内部测试，让 Opus 5.5 和 Claude Fable 5.1 把 HAProxy 从 C 翻译成 Rust。

据 Anthropic 称，两次改写几乎通过了 HAProxy 的全部回归测试。Opus 5.5 用了 9.5 小时，Fable 5.1 用了 12 小时，成本低 51%。

Boris Cherny 也公开提到了这次测试：

这类语言迁移与生成一个新的玩具项目本质不同。智能体必须在大型既有系统中保持行为不变，理解接口和测试，跟踪大量相互依赖的改动，并反复验证翻译后的实现仍然可用。

对考虑用 AI 辅助现代化成熟仓库的团队来说，这个信号更有意义。

实例 7：企业知识工作用更少 token

Box CEO Aaron Levie 分享了 Box 用 Opus 5.5 测试复杂企业知识工作任务的结果，这些任务涉及非结构化数据。他报告称，相对 Opus 5，token 用量明显更低，冗长度下降，执行更快。

这一点很重要，因为智能体的经济性并不只由定价页上的 API 价格决定。

更有用的模型是：

任务总成本
= token 单价
× 每轮 token 数
× 轮次数
+ 重试
+ 工具调用
+ 人工返工

一个名义 token 单价更高的模型，如果重试更少、工具调用更少、人工纠正更少，真实工作流反而可能更便宜。

Anthropic 在 Opus 5.5 发布材料里也持同样观点：模型的每 token 价格比 Opus 5 更低，但更大的节省来自用更少 token、更少步骤完成任务。

实例 8：一次 Claude 会话协调 40 个 PR 的 rebase

早期试用里最强的工程故事之一来自 Stripe。

Anthropic 引用 Stripe 工程师 Cristian Rivera 的描述：一次持续多日、涉及 40 个堆叠 pull request 的 rebase 中，一个 Opus 5.5 会话指挥了大约十几个额外会话。模型把冲突呈现得足够清楚，工程师离开数小时后再回来也能快速做决定；第二天下午，全部 40 个 pull request 都通过了 CI。

这个实例指向编码智能体的另一种未来。

基本模式不再是：

开发者 → 模型 → 代码

而越来越是：

开发者
   ↓
编排智能体
   ├─ 迁移智能体
   ├─ 测试智能体
   ├─ 调试智能体
   ├─ 审查智能体
   └─ 文档智能体

一旦模型开始协调其他智能体，委派质量、状态管理、简洁汇报和自我核验就会和原始编码能力同样重要。

这也是 Opus 5.5 沟通改进之所以重要的原因之一。如果模型叙述过多，或无法把真正需要人工介入的决策亮出来，长时间运行的系统就会很难监督。

最出色的 Opus 5.5 实例有何共同点

这些案例里，有几条模式反复出现。

1. 输出是产物，不是回答。

最强的实例最终都落到可检查的东西上：代码、动画、渲染场景、证明、已迁移的仓库、通过的测试套件，或结构化工作成果。

2. 核验是工作流的一部分。

回归测试、CI、Lean、视觉渲染，以及独立智能体审查，都能提供比一段有说服力的文字更难造假的反馈。

3. 长周期工作正在成为区分点。

Anthropic 称，一位早期测试者在一天内完成了 68 万行迁移；另一次 20 万行的审计与修复在三小时内完成。据称 Opus 5 完成后者需要 20 小时以上，token 用量是 2.5 倍。

4. 对模型来说，代码正在成为通用创作媒介。

若干最醒目的演示在技术上仍是编程任务，即使用户体验到的是艺术、动态图形、交互场景或游戏。

5. 更好的编排，可能比更好的一次性回答更重要。

多智能体研究实验和 Stripe 的 rebase，都指向会组织工作、委派、核验并汇报的模型，而不只是生成单次回复。

如何复现工作流，而不是照抄演示

从病毒式实例里复制精确提示词，很少是评估模型的最佳方式。

更好的测试是复现任务结构。

对大型代码库任务：

先检查仓库，再开始编辑。

目标：
在不改变用户可见行为的前提下，把 [子系统] 从 [旧架构] 迁移到 [新架构]。

要求：
- 先构建依赖图。
- 定义可衡量的验收标准。
- 以小而可测试的阶段推进改动。
- 每个阶段后运行相关测试套件。
- 调查失败原因，而不是绕过它们。
- 为含糊案例保留决策日志。
- 结束前跑完整回归，并总结剩余风险。

对创意编程任务：

用 [Three.js / SVG / Canvas / WebGL] 搭建一个交互视觉场景。

不要在产出代码后就停下来。
渲染结果，做视觉检查，找出最弱的三个方面，然后迭代。

要求：
- 项目保持自包含。
- 在可行处优先使用过程化资源。
- 让构图、运动、字体和交互都有明确意图。
- 在桌面和移动尺寸下测试。
- 只有在没有明显损坏状态时才结束。

对多智能体研究任务：

为这个问题创建多条独立工作流。

角色：
- 提出者
- 怀疑式审查者
- 文献核对者
- 实现 / 证明构建者
- 核验负责人

智能体必须分享发现，但不应只因为另一个智能体很有把握就趋同。
只有在具备可复现产物，并经过独立核验后，主张才算完成。
保留失败路径，并解释它们为何失败。

核心原则是给模型一个闭合反馈环。智能体应当能观察到自己的工作是否成功。

Opus 5.5 仍需谨慎的地方

发布日实例令人印象深刻，但不应当被解读成每次 Opus 5.5 会话都会达到同样水平。

原因有几个：

• 公开演示是被挑选过的例子。 失败尝试更不容易被发出去。
• 脚手架很重要。 Claude Code、自定义工具、浏览器访问、子智能体、测试和项目特定说明，都会实质改变结果。
• 迭代次数往往不清晰。 一份打磨过的产出，可能已经经过多轮反馈。
• 模型努力程度会改变成本和行为。 最大努力下的结果，不应自动被视为默认用法的代表。
• 核验仍然必不可少。 如果环境没有可靠的检查方式，模型仍可能产出看起来可信、实际错误的代码、分析或研究。

Anthropic 在自己的发布文章里也提到相关观点：前沿基准差距，作为实际差异的预测指标正在变得不那么可靠。

因此，严肃评估时，团队应在自己的工作负载上测量任务完成率、耗时、token 消耗、工具调用、重试、人工介入、回归失败和返工。

结语

最重要的 Claude Opus 5.5 实例之所以令人印象深刻，并不是因为模型能产出更多文字。它们令人印象深刻，是因为模型越来越能把意图，经过一长串动作，变成经过核验的产物。

早期证据主要集中在四个方向：

• 长时间运行的软件工程，包括迁移、审计和跨仓库工作；
• 创意编程，JavaScript、Python、着色器和 Three.js 成为视觉媒介；
• 多智能体编排，多个 Claude 实例分工并互相批评；
• 专业知识工作，效率取决于用更少轮次、更少返工正确完成任务。

因此，评估 Opus 5.5 的最佳方式很直接：不要只问它一道更难的题。给它一个带工具、约束和成功核验方式的真实任务。

当产出必须能编译、能渲染、能通过测试、能经得起审查，或能自我证明时，强聊天机器人和有用的自主智能体之间的差别，会容易看得多。