卡帕西暴露 Opus 5 新边界 

过去，人们喜欢用一道颇具喜感的题目测试大模型：“请生成一张鹈鹕骑自行车的可缩放矢量图。”

下面这张图是 ChatGPT 为我生成的：

这道题看似简单，实际上需要模型理解自行车的结构、鹈鹕的身体组成，以及两者之间的空间关系，再用一系列坐标、路径和图形元素把它们组合起来。

模型画出的鹈鹕究竟是坐在车上、悬浮在空中，还是与自行车融成一团，往往能直观暴露其空间推理能力。

但现在，Andrej Karpathy 认为，评价前沿模型的方式可能需要再次升级。

8 月 2 日，Karpathy 在 X 上公布了一项实验。他把《指环王》第一章开头的一段文字交给 Claude Opus 5，给出 100 万 Token 的推理预算——按他的估算约为 10 美元——并要求模型用 Three.js 把这段故事渲染成一个三维场景。

这条帖子的浏览量已经超过 280 万。

Opus 5 运行了约两小时，最终写出大约 5500 行代码。

成品并不精致，Karpathy 称它“有些粗糙，但很好玩”，但真正让他感到不可思议的是：一个语言模型需要自行决定场景中应该出现哪些角色、房屋、道路和植被，把各种多边形资产放进三维坐标系，再编写动画、镜头和时间轴逻辑，让这些对象按照故事发展运动起来，而它最终确实完成了一个能够在浏览器中运行的结果。

这不是简单地把文本交给图像或视频生成模型，再得到一段像素画面。

Opus 5 采取的是一条更接近传统游戏开发的路线：通过代码创建几何体、材质、灯光、摄像机和动画，搭建一个显式存在的三维场景。

在这样的系统中，一棵树不只是画面中的一团绿色像素，而是场景树中的一个对象；道路、房屋和角色都有对应坐标；镜头何时靠近、角色从哪里走到哪里、字幕在什么时间出现，也需要被写进程序。

Anthropic 在 7 月 24 日的 Opus 5 发布公告中也将视觉输出列为这一代模型的主要提升之一，并展示了模型生成的交互式风洞和细胞结构。官方将 Opus 5 定位为适合长时间、多步骤任务的模型，强调其能够反复检查结果、建立测试工具，并在复杂任务中持续迭代。

Karpathy 的实验则把这种能力推到了一个更开放的场景：没有明确的功能列表，没有现成的美术资源，也没有逐个给出对象坐标，模型必须自己判断“一段小说应该怎样变成一个可以运行的 3D 叙事”。

Karpathy 尤其关注的，并不是这段《指环王》动画本身，是它背后的经济性变化。

按照传统流程，为一段小说开头单独制作一个 3D 动画，需要编剧拆分场景、美术制作资产、程序员搭建交互与动画。即便最终只供一个人观看，这套成本也不会明显降低。由于需求过于定制，绝大多数类似想法根本不会进入制作阶段。

LLM 改变的首先不是作品质量，而是“是否值得开始”。

模型不在乎任务是否琐碎，也不在乎 5500 行代码最终只被播放一次。只要推理成本足够低，过去因为过于个性化、投入产出比太低而无人制作的内容，都可能被临时生成出来。

Karpathy 将其描述为一种“按需生成的临时版 GTA”：用户可以指定任何小说、历史事件或虚构设定，让模型临时搭出一个世界；玩家既可以作为旁观 NPC 进入故事，也可以成为其中一个角色，甚至改变原本的叙事走向。

这意味着，生成式 AI 正在把内容定制从“更换角色名字、调整几张图片”，推进到结构层面：场景、交互规则、角色关系和故事进程都可以根据单个用户即时生成。

用游戏测试模型，网友早就玩嗨了 

Karpathy 的实验并非孤例。

Opus 5 发布后，X 上的开发者迅速把三维游戏和物理模拟变成了一种非正式压力测试。

开发者 Matt Shumer 展示了一款由 Opus 5 生成的第一人称射击游戏“Claude of Duty”。据他介绍，项目从场景到贴图均由代码生成，没有使用任何外部美术资产。

Alex Ermolov 则让 Opus 5 制作了一段滑雪板体验。他评价称，在自己测试过的模型中，Opus 5 处于领先位置，第一次生成的版本就没有明显视觉故障，滑行的物理反馈也相对自然。

另一位用户 ChrisGPT 把一年前 Claude 4 Opus 的输出与 Opus 5 进行对比。

同样是生成一辆行驶在泥路上的汽车，旧版本主要由简单色块组成，而 Opus 5 已经开始自动加入车辙、植被、阴影和分层光照。

更极端的测试来自 Pankaj Kumar。

他让 Opus 5 重建《我的世界》，最终得到一个包含 15 种生物群系、创造与生存模式的程序化世界，图形、纹理和声音都在运行时生成。不过，这次任务使用了约 2500 万 Token，也说明随着世界规模扩大，成本和代码复杂度仍会快速增长。

atomic.chat 还让多款模型分别生成龙卷风、摆锤撞击建筑等物理场景。

按照该团队自己的测试结论，Opus 5 是少数能够同时处理多个场景的模型之一。需要说明的是，这类演示通常没有统一的提示词控制、运行次数和评分标准，因此更适合被视为开发者实验，而不是严格的模型基准。

这些作品的共同之处是，都告别了依赖传统游戏资产库，让模型直接把几何体、纹理、物理和交互写成代码。相比单张图片，测试对象开始变成长时间运行的系统：角色能否移动、对象会不会穿模、碰撞是否正确、几十秒后场景状态是否仍然一致。

很强，但不是真正意义上的“世界模型” 

尽管看起来像一个生成式世界，Karpathy 的实验与 谷歌 DeepMind 的 Genie 等世界模型仍有明显区别。

Opus 5 生成的是一套显式程序。场景中的对象、坐标和行为由 Three.js 代码决定，开发者可以阅读、修改和复用代码。其优势是结构清晰、控制性较强，但模型只能生成自己能够用程序表达出来的对象和规则。

Genie 3 采取的则是生成式视频路线。根据谷歌 DeepMind 的介绍，它可以根据文本实时生成 720p、每秒 24 帧的可交互环境，并在几分钟内保持一定视觉一致性。它不需要显式创建每一个三维模型，而是直接根据玩家操作预测下一帧画面。

两条路线解决的是不同问题。

代码生成世界更像“AI 自动编写一个小型游戏引擎和关卡”，结果可编辑、可调试，但视觉上容易粗糙；神经世界模型更像“实时生成一个可以进入的视频”，画面表现可能更丰富，却缺少传统游戏引擎中明确的对象、状态和规则。

未来的产品也可能融合两者：LLM 负责规划任务、设计规则和生成代码，世界模型负责画面、物理直觉与环境反馈。

这次实验最值得注意的部分，是 Opus 5 检查这些代码的方式。

Karpathy 指出，模型不能高效、原生地观看连续视频，也不能像真人测试员一样进入游戏，持续移动、碰撞、回头观察，再判断哪里出现问题。

它只能运行程序，在若干时间节点截取静态画面，然后根据截图修改代码。这个循环既缓慢，又很容易漏掉只在运动过程中出现的问题。例如，角色可能在某一帧看起来位置正确，却在几秒后穿过地面；摄像机在单张截图中没有问题，运动时却可能突然转向；碰撞、速度和操作手感更难通过几张图片判断。

因此，画面中仍然留下了不少错位和粗糙之处。

Karpathy 由此认为，视频理解、连续状态感知以及真正“玩游戏”的能力，仍是当前大模型明显不足的原始能力。

这暴露出一个正在变得越来越重要的矛盾：模型生成内容的能力，正在快于它验证内容的能力。

对于普通代码，模型可以运行单元测试、查看错误日志、比较文本输出；但面对动画、游戏、机器人和复杂用户界面，正确性不再只存在于文字和数值中，而是分布在连续时间、视觉状态和交互反馈里。

如果模型无法亲自体验自己生成的系统，就很难形成完整的“生成—执行—观察—修正”闭环。

从鹈鹕骑自行车，到《指环王》三维世界，大模型评测正在发生一个微妙变化。

过去的问题是：模型能不能写出代码、画出图片、生成一个可以运行的页面。现在的问题逐渐变成：它能不能连续工作两小时甚至更长时间，组织数千行代码，保持对象、任务和目标的一致性；完成之后，它能不能主动进入系统，发现那些没有出现在错误日志中的问题。

Opus 5 生成的还不是一款真正的《指环王》游戏，约 10 美元也只是 Karpathy 给出的 Token 预算估算，并不包含人工设计、运行环境、验收、修改和正式制作成本。

但这个实验依然意味着一个重要变化：以前因为“太麻烦、太小众、没有人愿意做”而不存在的软件和内容，现在可能只需要一句描述和一笔很小的推理预算。

模型已经开始具备建造临时世界的耐力。接下来的关键，是它什么时候能够真正看见、进入并理解自己建造的世界。

参考链接：

https://simonwillison.net/2025/Jun/6/six-months-in-llms/

https://x.com/ChrisGPT/status/2082265122949542149

https://karpathy.ai/lotr-movie/