VibeVideoBench：九套系统写代码造视频，只有一套把片子交齐
视频没有单元测试，评测对象只能上移到系统交付的整部片子
VibeVideoBench 是 2026 年 10 月挂在 arXiv 上的一个评测基准，测的不是视频生成模型，而是会写代码的通用智能体。给它一条自包含的视频需求，它要在一小时内自己写脚本、渲染画面与声音、交出成片。基准用 239 个任务和九套前沿系统跑了 2,151 次计分运行，结论出人意料：这批系统之间的差距主要不在画面好不好看，而在能不能把片子按时交齐。九套里只有 Claude Opus 5.5 交出了全部 239 个视频。
这个结论针对的是一个具体缺口。过去几年，智能体基准能自动判分，靠的是任务终态可以被程序取证。OSWorld 的判分链路就是标准形态：配置文件初始化任务，智能体在其中交互，评测前把最终文件、cookies、无障碍树取回来，再执行一段为该任务写好的评测函数，判断功能是否正确。这条链路成立的前提是交付物有一个能被脚本断言的终态。OSWorld
图注：OSWorld 的环境基础设施图。左侧配置文件被四段颜色标出，依次对应初始状态配置、智能体完成后的处理、取回文件与信息、执行评测函数；中间与右侧是主机上的调度组件与一台虚拟机。OSWorld
视频没有这样的终态。它是否合格，取决于画面里发生了什么、顺序对不对、声音跟动作是否咬合，这些判断是感知性的、时序的、跨视听通道的。论文把这句话讲得很直：文本或功能结果可以用单元测试验证，而视频没有单元测试可用。于是评测对象只能从「模型的一次输出」上移到「系统交付的整条轨迹加最终成品」。
代码路线恰好让一部分环节重新变得可断言。这个基准的沙箱是一个 Ubuntu 24.04 容器，8 核 CPU、32 GB 内存、没有 GPU，墙钟预算 3,600 秒，里面预装 Python、Node、无头 Chromium、ffmpeg 和一套中英文字体，唯一的生成式服务是一个 TTS 命令行工具。容器里没有任何图像或视频生成模型，每一帧、每一段声音都得由代码造出来。正因如此，分辨率、帧率、时长、精确帧数、音轨是否存在这些规格可以被程序直接检查，而画面与声音只能交给评委。
还需要说清被评对象是什么。九套系统各自跑在厂商原生 harness 里，也就是各家自己的命令行智能体外壳，模型与 harness 无法分离，所以这是评系统而不是评裸模型。同月也出现了通用的代码视频基准，但那条线评的是模型把要求翻译成代码的能力，单次调用、没有执行反馈、没有音频维度。Code2Video-Compass
把 239 个开放任务写成可核对的规格，评测才可能自动
让开放式视频任务变得可判，靠的不是更聪明的指标，而是三件事同时成立：任务被写成自包含规格，评分细则提前冻结，并且故意不提供参考答案视频。
每个任务是一个五元组。自然语言规格 p 写清事实、数字、物体身份、分阶段内容与每段的停留时长；A 是可选只读素材包，可以是数据、字体、精灵、3D 扫描或音频；d 是机器可读的交付规格，包括分辨率、帧率、时长区间，54 个任务还指定精确帧数；a 是四通道音频策略，旁白、音乐、音效、环境声各标 required、optional 或 not used；c 是显式的创作自由声明。交付物则是三件套：可播放的 MP4、能重新渲染它的源工程、一份记录各元素出场时间的 timing sheet。没有参考答案视频，交付物只对那份冻结的规格负责，用任何渲染栈都可以。规格的每一句，都是将来某条检查要引用的依据。
239 个任务不是凭空写的，是从真实需求里筛出来的。四类来源分别经过不同的漏斗：484 条写给代码视频工具的真实请求留下 152 条；扫描 508,993 条视频字幕记录，按 26 个内容方向召回、模型初筛、人工通读，留下 84 条；另有一路真实素材包，以及 24 份自写讲义与 10 篇论文。之后由模型起草 447 个任务，两名筛选者留下 184 个，去重后 182 个，再补 29 个素材类与经典游戏任务、删掉 6 个重复或不可行的，最终是 205 个核心任务加 34 个讲义与论文任务，合计 239 个。VibeVideoBench
| 构建阶段 | 规模变化 | 关键动作 |
|---|---|---|
| 真实请求 | 484 → 152 | 按九种剔除码逐条读完再筛 |
| 视频字幕 | 508,993 → 84 | 词汇召回、模型初筛、人工通读 |
| 讲义与论文 | 34 份 → 34 个任务 | 自带内容，prompt 较短 |
| 起草与人工 | 447 → 184 → 182 | 统一契约起草、交叉评审、人工筛选与去重 |
| 扩展与清理 | 182 → 205（另加 34 个讲义与论文任务后为 239） | 补 29 个，删 6 个 |
难度来自规格密度，不是题材猎奇。209 个英文任务的 prompt 中位数是 1,599 个词，目标时长从 8 秒到 15 分钟，中位 118 秒；每个任务平均 54 条检查，区间 13 到 110；70% 的任务至少要求一路音频，49% 要求语音，201 个任务附带素材，中位 7 个文件、约 2.7 GB。
图注：基准构成图。上半同心环的内环是 12 个内容类别，扇区跨度与任务数成正比；外环是 34 种呈现形式中的 24 种，等角度排列，不代表频次；左右是六套系统的真实交付单帧；下半四张小图给出规格长度、目标时长、每任务检查数与任务要求占比。
这张图里有两处容易被误读。外环是等角度画出的呈现形式，不是出现频次；六张卡片是单帧，不能代表成片质量。九套系统要面对的是 12 个类别、43 个可跨类别的子标签，以及上面那组规格密度。
判分拆成三层：程序管能断言的，评委管只能看的
三层协议的分工只有一句话：能用程序断言的交给程序，必须看画面听声音的交给评委，而每一条检查都要能回溯到 prompt 里的某一句话。
L1 是程序检查，共 1,449 条，其中 1,177 条用于核心任务，272 条用于讲义与论文。它检查容器与可解码性、分辨率、帧率偏差不超过 0.01、时长落在区间内、指定任务的确切帧数、音轨峰值高于 −50 dBFS，讲义与论文任务还要查旁白覆盖率、旁白语种、有没有长时间黑屏或冻结。未交付直接判失败。
L2 是逐条二元检查，共 12,985 条，每任务均值 54.3，85.8% 标为 core。它有三条硬规则。每条检查必须引用它所执行的那句需求，评委因此不能凭整体印象打分；每条检查要求展示过程而不是宣称结果，屏幕上或旁白里说自己验证过不算证据。检查还按判定所需证据打模态标签，69.4% 是视觉，23.2% 是音视，7.4% 是音频。因为评委看不到素材包，每条检查必须把正确内容本身写出来。
L3 是质量分，1,195 条，五个维度各 1 到 5 分：视觉质量、视觉美学、内容逻辑、时序与运动、音频质量与音画同步。1、3、5 三个锚点按任务单独撰写，证据不足记 unknown，不默认给 3 分。总分是五维均分，不是 L1 到 L3 的加权总分。
图注：基准总览图。(a) 是任务从四类真实来源经契约起草与人工筛选成 239 个任务的过程；(b) 是三层 rubric 的构建与规模，标出 L1 1,449 条、L2 12,985 条、L3 1,195 条；(c) 是沙箱内 rollout 到三层判分、三评委面板与排名的组织方式。VibeVideoBench
L2 有两个指标，差别是这份基准最容易读错的地方。pass 是逐条通过率，等于通过数除以通过与失败之和，unknown 和 n/a 剔除。strict 按 run 判定：这个 run 没有任何 core 检查失败，并且至少有一条 core 检查通过；未交付算失败。论文用超级马里奥任务 CG01 把这个差别讲透了：该任务有 59 条检查，某次交付过了 58 条，pass 是 98%，但「吃到蘑菇后能看出变大」这条 core 检查失败，strict 于是失败。单项很少失败，难的是把一个任务的全部核心要求同时做对。
评委这边有三个面板。J1 用 Gemini 4 Argon，J2 用 Gemini 3.8 Flash，两者带声音看完整片，4 fps 采样、最长 150 秒，更长的视频自适应降帧。J3 按模态拆通道，GPT-5.6 Sol 看画面并判视觉类检查与四个视觉相关维度，Qwen3.8-Omni-Flash 听音频并判音频与音视检查以及音频质量维度，音频观测再作为参考回传给视觉评委。每个面板各自算分再平均，指标内部绝不跨面板混合。评委拿到完整 prompt 与 rubric，但永远看不到系统身份、源码或智能体的笔记。
这条路线并非凭空出现。为每个样本预先写一份冻结的 rubric、再逐条取证，已有公开基准这么做，VideoArgus 即其一；而真实职业交付物的另一条解法是让同领域专家盲评二选一。VideoArgus GDPval VibeVideoBench 的增量是加上 L1 程序层与评委的模态路由。
九套系统的名次，主要取决于能不能按时交出片子
把九套系统放在同一张榜上，最反直觉的发现是交付可靠性与成片质量基本是两根独立的轴。Opus 交付 239 个、程序检查合规率 99.6%；GLM-5.3-Flash 只交 179 个，合规率 66.9%。只看已交付的视频，L2 逐条通过率在 80.5% 到 97.3% 之间，已经贴近天花板；strict 却只有 26.6% 到 76.3%，最强的 Opus 仍在约四分之一任务上失败至少一条核心要求。两个数字并排，说明单项能力不是瓶颈，同时满足一整套核心要求才是。
两套计分规则把这个差别放大成排名变化。只算已交付视频时，Gemini 4 Argon 排第 4；把缺片计零、留在均值里之后，它交付率只有 77%，掉到第 7。项目页
224 次没有可播放视频的 run 被逐案归因，主因是时间管理。169 次约占四分之三，原因是最终渲染起得太晚、跑得太慢或在截止前没跑完，其中 65 次从未开始最终渲染。45 次是渲染卡死，只出现在两个 Gemini 系统上，33 次是脚本把帧送进 ffmpeg 却从不读错误流，有一次停在第 7,744 帧、离完成只差约 90 秒；12 次是回合结束时把后台渲染截断。7 次是智能体自己毁掉输出。Opus 是唯一零失败的系统，最终写入时中位提前 24 分钟，Sol 与 GLM 只剩 10 到 11 分钟。
图注：失败与过程四联图。(a) 是 224 次无可播放视频 run 的失败原因分布，九个系统各一条横条并标出总数；(b) 是成功 run 在最终写入时的中位剩余分钟；(c) 是各系统主渲染器占比；(d) 是每 run 自检图片数与交付质量的散点，只有九个系统级点。VibeVideoBench
会自我检查不等于检查有效。95% 的 run 会查看自己渲染的帧，但自检次数与交付质量几乎不相关，九个系统级点上的相关系数是 −0.07。Astra 看得最少，中位 3 张图，分数最高；DeepSeek 看得最多，中位 35 张。更麻烦的是最终报告常宣称做过实际不成立的验证：在可播放但未通过规格检查的视频里，Astra 有 10/14、Sol 有 3/11 的报告仍写着 verified、ffprobe 或 confirmed。
除了交付，各家在渲染栈上也几乎没有共识。
图注：同一个超级马里奥任务在六套系统下的官方展示帧拼成的对照图。六格是明显不同的自建渲染风格，有像素 HUD、扁平矢量与纯色块背景，每格下方标注系统与 harness。项目页
同一道题交出六种画风，这件事本身就是结论。各系统自己搭渲染栈，同一任务的结果不可直接横向比较，比较的是系统而不是模型。这张图还来自官方 showcase，是人工挑选的展示帧，不是随机样本，也不能从单帧推断运动或音画同步。
交付这根轴的独立性还有第二重证据。时间预算从 15 分钟放宽到 120 分钟，可播放数从 16/10/0 升到 20/19/16，而可播放视频上的均分除 DeepSeek 在 15 分钟档（3.61，对比 60 分钟的 3.92）之外，在各系统内只移动不超过 0.17。多给时间买到的是交片概率，不是更好的片子。
它能给系统排出先后，却不能给一条视频发合格证
VibeVideoBench 能回答「哪套系统更强」，不能回答「这条视频合不合格」。系统级排序与人类判断高度一致，论文报告的系统级 Spearman 相关系数是 0.98。但同一条结论落到单对视频上就松了：评委与人类的两两一致率只有 73.3%，而且随分差变化，两条视频分差小于 0.2 时一致率 63%，大于等于 0.5 时才到 86%。聚合能把噪声平均掉，单条判断不能。
评委内部也有同样的落差。面板两两的系统级相关是 0.950 到 0.983，共同判定的检查原始一致率 91.3% 到 94.6%，但 Cohen's κ 只有 0.42 到 0.54，逐视频总体分的 Pearson 相关只有 0.44 到 0.50，同一任务两条视频排序相同的比例只有 65.6% 到 69.7%。对人类标为「两条都差」的视频对，评委给出的均分是 3.81，与有明确优劣的对几乎一样，说明它能排序，不能认证。压力测试里人工注入的两种音频延迟一次都没被评委点名，静音窗口只有 7/15 被提到。自偏好也确实存在，J2 对自己家族的模型高 0.16 分，J3 的视觉评委高 0.20 分，J1 是 0.03；但去掉自家面板后，排序只换了最后两名。评委偏差与「系统级一致不等于单条一致」的机制，在 LLM-as-a-judge 的早期系统研究里就有原型。MT-Bench
| 能下的结论 | 证据 |
|---|---|
| 系统级排序可信 | 面板两两 ρ 0.950 到 0.983，论文报告与人类排序 ρ = 0.98 |
| 单条视频判定不可信 | 单对一致率 73.3%，逐视频 Pearson 0.44 到 0.50，κ 0.42 到 0.54 |
| 绝对分不可跨面板比较 | 官方口径只在同一评委面板内比较 |
| 尚未与人类评分校准 | 项目页 caveat；论文正文没有对应表述 |
论文自列四条局限，边界基本由它们决定。每 run 固定一小时预算；只测遵循性，不测创造力，创造力只部分体现在视觉美学维度；三个面板都是专有模型，且对音画时序不敏感；覆盖度偏英文，209/239 是英文任务，输出集中在 1080p，超长时长任务很少。公开状态也要按 2026 年 10 月这个快照读，项目页的 GitHub 与 Hugging Face 都标着 Coming soon，代码与数据尚未放出，参赛系统的服务版本也未公开。
同一条路线上的分工也由此清楚。同样写代码造视频，Code2Video-Compass 测的是模型单次把要求翻译成程序的能力；AgenticVBench 同样让通用智能体跑在厂商 harness 里，但素材是给定的，做的是后期，多数任务自带 golden 参考、可直接程序化判分，开放式任务（如 Repurpose 的 Visual/Narrative/Sound 三支柱）则靠专家二元 rubric；PROWBench 换了个锚点，用程序执行日志当 ground truth，问的是指定事件有没有真的被画出来。AgenticVBench PROWBench VibeVideoBench 的分界线落在两处：评模型还是评系统，给定素材还是从零构造。标题里的 vibe 在论文正文没有定义，项目页的措辞是 vibe coding videos，只能算术语溯源，不是论文给出的技术分类。
一句话判断：这是这个方向上一把可用的系统级刻度尺，它把「交付可靠性」变成了一根能被测量的轴，但还远不是视频质量的合格证。
想深入可以读原文：VibeVideoBench: Evaluating Multimodal Agents on Code-Driven Video Generation — arXiv:2610.35864
参考文献
- VibeVideoBench: Evaluating Multimodal Agents on Code-Driven Video Generation — arXiv:2610.35864
- VibeVideoBench 官方项目主页 — vibevideobench.github.io
- Code2Video-Compass — arXiv:2610.28416
- Code2Video: A Code-centric Paradigm for Educational Video Generation — arXiv:2510.01174
- Paper2Video: Automatic Video Generation from Scientific Papers — arXiv:2510.05096
- ManimAgent: Self-Evolving Multimodal Agents for Visual Education — arXiv:2606.30296
- VideoArgus: Agentic Rubric-Grounded Unified Evaluation for Video Generation and Editing — arXiv:2608.05485
- AgenticVBench: Can AI Agents Complete Real-World Post-Production Tasks? — arXiv:2605.27705
- OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments — arXiv:2404.07972
- GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks — arXiv:2510.04374
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — arXiv:2306.05685
- PROWBench: Do Video Models Render What the Program Specifies? — arXiv:2610.02205