Claude Opus 5.5 一次生成音乐视频：“Plan a Video”究竟能产出什么

2026年9月23日发布在X上的一条帖子写道：“Claude's Plan——由 opus 5.5 一次成型的视频”，并附有对 @jeffgwoah 的致意。这只是演示层面的说法，并非发布层面的声明——而它恰恰落在了通常最要紧的那件事的错误一边。Claude Opus 5.5并不是一个需要从泄露消息里嗅探出来的未发布模型。Anthropic 已于 2026 年 9 月 22 日发布它，价格为每百万输入 token 4 美元、每百万输出 token 20 美元。它才面世一天，已正式开放可用，并且已经列在价目表上。所以，真正有趣的问题不是 Opus 5.5 是否存在，而是这些“一次成型做出一段视频”的帖子究竟展示了什么——因为这个说法比它听起来要窄得多，而这一差别决定了你能不能拿它来用。

简短版本如下，而这正是大多数转发所略去的部分：在那些经得起检验的演示中，Claude Opus 5.5 并不生成像素，它编写的是绘制像素的代码。输出的是一个程序，而不是视频文件。

流传中的那两个演示实际做了什么

这类主张背后存在两个公开的产物，而且两者都可核查，因为两者都公开了各自的来源。

第一件作品是一段时长156.6秒的音乐视频，歌曲名为“I'm Upping My P(doom)”，对应的仓库名为 PDoomVideo，于2026年9月22日发布在 GitHub 上——也就是 Opus 5.5 上线的同一天。其 README 称，这段视频“经历了两代生成，均在 Claude Code 中完成”，第一次归功于 Claude Opus 5.5 (Medium)，第二次归功于默认 effort 下的 Claude Opus 5.5。它还称，“这个仓库中的一切都是由模型生成的”，并且“没有指定任何场景创意”——唯一给出的指示是使用某个特定的角色设计，并为每句歌词配上有趣的视觉效果和转场。

第二个是2026年9月23日发布的一个包含三款游戏的演示仓库，与其说是展示，不如说更接近一次受控实验：三款可玩的3D浏览器游戏，每款只有一个单句提示词，在单次会话中生成——据该仓库所述，代码未经任何人工修改——随后便完成部署。这些游戏是单文件HTML，不含任何外部资源——模型、纹理、动画和音效全部由代码程序化生成。三者之中有一个要求模型先查证某款游戏地图的官方布局，并在写下任何代码之前，依据这项调研重建其几何结构。

两个代码仓库都不是厂商发布物。两者都是第三方产物，属于自述，而且“零人工编辑”这一说法尤其只是在陈述一段 git 历史，并不是外部方已经审计过的事实。把流程描述视为作者的自述，把产物本身视为证据。

故事板才是真正的产出

决定“one-shotted”这一说法是否公允的细节，是第一个仓库里一个名为 STORYBOARD.md 的文件。它不是人类写的镜头清单。它是模型在第一次生成之后为自己写的一份文档，而且具体得确凿：一条规则，要求每个镜头里“屏幕上都要有事情发生”；一项指示，要求画面中不出现文字；一组有名字、有固定设计的角色阵容；一套调色板，从温暖的奶油色，经过太空紫，到警报红，再回到原处；一条规则，要求角色表情渐变过渡，而非瞬间切换；以及一项要求：每一次剪辑都要由动作来驱动——一口咬下转黑、一次坠落、一次穿过眼睛的变焦。

那份文档就是信号文本所指向的计划。模型生成了一份导演简报，然后针对它并行运行子代理，每个章节一个，各自编写一个 JavaScript 文件来绘制时间线上属于自己的片段。

渲染管线平平无奇，也值得直说，因为正是在这里，“AI 制作了一段视频”的说法站不住脚：帧是在一个页面里用 p5.js 和水彩画笔库绘制的，一个 Node 脚本在无头 Chrome 中驱动该页面并截取每一帧，再由 ffmpeg 把这些帧与音轨合成到一起。以每秒 24 帧、持续 156.6 秒计算，那就是大约 3,760 帧被逐帧渲染出来。

因此，准确的表述不是“Claude Opus 5.5 生成了一段视频”，而是“Claude Opus 5.5 编写了一个能渲染视频的程序，随后又执导了它”。这种区别并非吹毛求疵——对于任何不制作音乐视频的人来说，这正是该技术有用的根本原因。

为什么“两代人”这一说法比“一次性”这一说法更重要

同一份 README 反而削弱了它自己的标题。这段视频经历了两代制作，而不是一代。第一遍产出的结果，作者随后又把它推进得更远；而分镜脚本和动画指南——正是让第二遍得以连贯的文档——是在那第一遍之后才写成的，而不是之前。

这就是每一项严肃的长时程生成任务的真实面貌，而这一点值得说明，因为“一次性完成”的框架设定了一种产出物无法满足的预期。提示词只是一条消息。工作却并非一遍就能完成。模型所做的，是让一个大型、多文件、耗时数小时的构建保持足够好的整体性，以至于第二遍是修订而不是重新开始——这是一种真实、且远不如“一条提示词，一个视频”那样炫目的能力。

有一个独立的数字比这些演示更能说明问题。Artificial Analysis 在其 Intelligence Index 上测得 Claude Opus 5.5 在最大努力下达到 58 分——这是它记录到的最高分，领先紧随其后的模型数分——并报告称，该模型每个 Index 任务消耗约 119,000 个输出 token，而 Claude Opus 5 约为 73,000 个，Claude Fable 5.1 约为 78,000 个。它使用的输出 token 约为 1.6 倍，并且在每 token 价格低 20% 的情况下，每任务成本仍大致相当（约 5.98 美元对约 5.86 美元）。长时程生成从外部看就是这种 token 画像：模型把预算花在了自己身上。

工件在哪里变得不可用

这类工作中的失效模式是一致的，而两个仓库从不同的方向指向了同一个。

• 输出的是一个程序，而不是一个文件。如果你需要一个能直接交给别人的 MP4，你仍然需要 Node、浏览器和 ffmpeg。模型产出的是渲染器，而不是渲染结果。这是你将永远背负的构建依赖。

• 它随帧数扩展，而非随提示词扩展。 3,760 帧在作者自己的硬件上完成了一次脚本化的通宵运行。Opus 5.5 的任何特性都不会改变绘制第 2,000 帧的成本。

• 确定性是一项硬性要求，而非可有可无的讲究。帧是并行且乱序渲染的，因此每一帧都必须是其时间戳的纯函数——不能有跨帧携带的状态，也不能有无种子的随机性。模型若没有把这一点内化，生成的视频就会闪烁。两个仓库都处理了这个问题；但提示词中没有任何内容强制要求这样做。

• 一次性并不意味着未经审核。最明显的证据来自第二个仓库的游戏相关工作：模型在动手构建之前，必须先研究一张现有地图的布局——这说明模型自己认定，它最初的答案会是错的。

• 没有人计算过失败的代价。这两个仓库都没有说明它尝试了多少次、烧掉了多少 token，也没有说明第二版生成中有多少是在修补第一版。而这恰恰是团队在真正投入之前所需要的数字。

这会给你带来什么改变，以及不会带来什么改变

如果你期待的是一个视频生成模型，Claude Opus 5.5 并不是，而且再多的演示片段也不能让它变成那样的模型。Anthropic 的发布材料中没有任何视频生成能力；该模型公布的评估是智能体编码、计算机使用和知识工作。这些演示所展示的是带创意简报的长时程代码生成——这与 Anthropic 在其自己的发布文章中提到的 68 万行迁移和 C-to-Rust 移植中体现出的能力相同，只不过被用在了你能亲眼观看的东西上。

如果这正是你想要的能力，那么实际问题就不再是“该用哪个模型”，而是“我该如何运行这样的东西，又不把生产路径押在它上面”。长时程生成很昂贵，而且它的失败方式是无声的——你会得到一个看似合理的程序，它渲染了四分钟，然后崩掉。合理的测试方式，是让这项工作走你已有的端点，而不是新签一份合约：Opus 5.5 已在 OrcaRouter 上以 Anthropic 的目录价提供，加价 0%，与同系列的其他模型并列，因此一次通宵的生成运行可以与其他所有调用共用同一个密钥和同一套故障转移规则。如果这次运行在第 3,000 帧挂掉，那是路由问题，而不是需要重新架构。

在你围绕这一点做规划之前，有两件事值得关注。Anthropic 表示 Sonnet 5.5 和 Haiku 5.5 将在“未来几周内”跟进，这会改变长时间渲染的成本账——一个更便宜、还能撑起多文件构建的模型，会让通宵跑一轮变成例行公事，而不是值得关注的事。而且分镜脚本模式本身是可移植的：那份文档里没有任何内容是 Opus 5.5 特有的，也没有什么能阻止一个更小的模型写出一份更差的。

目前，对“Claude's Plan a video by opus 5.5 one shotted”的诚实解读，比它听起来更狭窄，也比它看起来更有用。模型写了一份镜头清单，向自己的子代理做了简报，然后写了渲染器——而像这样的计划能在接触 3,760 帧后依然成立，这才是值得检验的主张，而不是那段视频。