DeepSeek 做视频输给 Codex 那场盲测，跟你用 huashu-motion 有关系吗？

2026-10-30silcano

我把那篇盲测从头读到尾，替你把结论定了：它比的是“同一套流程里塞哪个模型”，你干的是“流程本身”，所以它既证明不了也否不了 huashu-motion，但它翻出来的那个短板，正好是你改到第三版时会撞上的墙。

作者是 maverick高子权，10 月 27 日发的。三组 18 秒短片、1080p、30 帧，全程左 A 右 B，名字遮到最后才揭。看得出是有心想测，不是随手写篇软文。下面先说清他到底干了什么，再说你和他差在哪一层，最后回答“有没有必要了解”。

一、他到底干了什么事

设计很干净，三组，变量只换一个：

• 第一组裸跑：什么都不给，就让做一支 Kimi 宣传片，风格分镜自由发挥；
• 后两组给手册：发同一份“制作手册”（就是 Skill），给定文案和视觉材质——水彩笔刷、像素 MG 绿宝石风格——分镜、构图、动作仍交给模型自己排。

揭晓：A 是 Codex（GPT-6.1 sol high），B 是 DeepSeek（V4.1 Flash high）。他三票全投 A。耗时也报了：Codex 一轮 17 分钟，DeepSeek 一轮 32 分钟。

他给的理由，是这篇里唯一真正值钱的部分，值得逐字看：

• B 开局更抓人。大字“有些活，不是难。是太耗时间。”，浅底蓝底黑底一顿切，把“查资料、做 PPT、读文档”直接怼到眼前，很懂怎么让人停下来；
• 但看完记不住。几个功能之间靠文案硬切，彼此是散的；
• A 从头到尾守着“城市骑行”一个例子：先查骑行资料，再写活动稿，最后做成 PPT。18 秒里，一个想法真的往前走了几步；
• 第三组最见真章。讲缓存，“v1 换成 v2”这个关键动作，A 让读取路径从书架转到桌面、书本增加、容量提示变化、源头版本一变桌面旧内容跟着换，你能一路追到“哪里更新了、哪里还得换”。B 主要靠标题和物件变化带过，看完不知道换掉的是哪一本。

所以他的结论不是“谁画得好看”，是“谁能把一件事讲完”。这句判断，比三比零的比分有用得多。

二、你的活儿和他，差在哪一层

你的链路长这样：

huashu-motion（一套规则）+ DeepSeek（出代码）→ index.html + GSAP → Chromium 逐帧截图 → FFmpeg 拼 MP4

他那个链路长这样：

一份很薄的手册（文案 + 材质）→ 模型自己排分镜 → HyperFrames 合成 → 出片

看着都叫“HTML 转视频”，但两套东西的变量根本不是一个。

他那场测试里，被控制住的是提示词和素材，被换掉的只有模型。他要回答的问题是“哪个模型更会当导演”。

你这套里，模型是可插拔的零件，真正决定成片下限的是 huashu-motion 那份 24KB 的 SKILL.md 和它的 references。

这就是为什么那篇文章对你只有参考价值，没有结论价值——他测的是你系统里的一个零件，不是你的系统。

三、五个实打实的差别

拆开看，就这五处，不重不漏。

1）手册的厚度不在一个量级

他那份“制作手册”本质是“文案 + 视觉材质 + 你自己发挥”，分镜构图动作全放开，等于让模型裸考审美。

huashu-motion 那份是工程契约，不是形容词。硬约束随手举几条：

• 只许动 transform（x / y / scale / rotation），禁止动 left / top / width / height。理由不玄学：改布局触发重排，逐帧重排必掉帧；transform 走合成层，浏览器能保证不重排。om check 会直接拒绝 layout motion。
• 一个根目录只允许一个 composition，草稿塞进 tools 子目录，否则报“多个根 composition”。
• 一切都是时间的函数：不许 Date.now()，不许无种子随机，不许联网。随机走 OM.random(seed)，弹簧用闭式解 OM.spring(0.1) 而不是物理积分。换来的是同一秒在任何机器上渲染结果一致，随时能暂停、截帧、接着跑。
• 素材必须是真的：logo 用真文件不重画，界面在代码里重建再跟实拍截图逐帧对，禁止灰底占位块。

这几条跟“写得好不好”无关，跟“能不能验收”有关。反过来说，那篇盲测里 Codex 赢在“讲得连贯”，恰好就是这类约束在替模型兜底——手册薄，就只能靠模型自己的审美兜，兜不住就散。

2）改片的方式不一样

他那边是交卷式：给提示词，等出片，看完打分。不满意就重开一局。

huashu-motion 是 om studio 起在本机 127.0.0.1，你在浏览器里按 C 点中画面某个元素，写一句“太亮”，评论会自动带上四样东西：时间点、当前场景、被点中的元素、以及它在源码里的位置。Agent 那边 om inbox --wait 阻塞着等，拿到评论先用 om look 把那一帧放大看一眼，只改那一处，om done 回一句话，预览原地刷新。每次改动是独立版本，能撤回。

这条差别最实际：他那套是“改崩了重来”，你这套是“改一个字”。有支片改到第 9 版拿了 91 分，靠的就是这个回路。

3）有没有质量门

他那篇文章是人眼当裁判，自己看自己投票。主观，但真实——这也是它作为盲测成立的前提。

huashu-motion 有两道机器门：om check 抽样出帧，查三类事故——切出安全区、被遮挡、低对比文字；om qa 查动效本身——单帧跳变、死时间、循环接缝。再叠一道独立评审 agent 打分，90 分才算完成，专门防自评偏差——写片子的 agent 天然觉得自己写得好。

4）声音

他那三组动图是静音的。这不是挑刺，是那条链路里压根没有声音这一环。

huashu-motion 有作曲家模式：先用 ABC 记谱法写节奏单，小节跟场景一一对齐写死，再用三角钢琴、弦乐、鼓组采样演奏，画面每件事“落地”那一帧配一个音效，音效钉在动作上，不是背景音乐糊过去。全在本机跑，不调付费音乐 API，不按量计费，也不用把没发布的产品素材传出去。

5）成本和时间

他给的是耗时：Codex 17 分钟一轮，DeepSeek 32 分钟一轮，没给钱。

huashu-motion 作者给的是钱：22 秒片、改三轮、缓存命中 99.4%，约 1.95 元。99.4% 这个数字最值得注意——它说明改片时 99% 以上的输入是重复的（同一份 SKILL.md、同一份 references、同一份已有代码），模型只处理真变的那一小块。

代价也说清：浏览器逐帧渲染不是免费的，22 秒 1080p 就是几千帧一张张画，时长和分辨率线性涨。15 到 60 秒的产品片合适，别想拿它做十分钟长片。

四、所以你还有必要了解他吗

有，但只拿走三样，别照搬方法。

第一，拿走他对 DeepSeek 的那个判断。视觉冲击够，叙事连贯弱，“开局抓眼、全程散”。这不是玄学，是可预期的失败模式。你用 DeepSeek 跑 huashu-motion 时，最容易崩的就是“三个场景之间没有同一条线索”。所以你要主动把主线在节奏单里写死——像他那条“城市骑行”，一个例子贯穿到底——而不是指望模型自己串。

第二，拿走他那个“v1→v2”的检验点。一个片子能不能被复述，看它有没有一个具体的、可验证的状态变化。发片前问自己一句：这一版里，有哪个东西真的从 A 变成了 B？答不上来，就是散的。

第三，拿走他的方法。遮名字盲测、同一提示词、固定左右位、三组。你想知道自己那套到底稳不稳，就该这么测：把 Codex 和 DeepSeek 各跑一遍同一份 SKILL.md，遮住名字自己看。这比看别人投票有用得多——因为你的手册比他的厚，结论很可能反过来。他测的是“裸手谁强”，你测的是“戴着手套谁顺手”。

至于“要不要直接改用 Codex”，我的看法：如果你卡在“讲不连贯”，换模型是治标，把叙事主线写进节奏单是治本。他那个测试里 Codex 赢，是因为没人给它手册时它自带更多秩序感；而 huashu-motion 已经把秩序感写成了检查项。两个都上当然更稳，但那是钱的问题，不是方法的问题。

一句话收尾

他测的是“哪个模型更会当导演”，你干的是“给导演配一套能验收的剧组制度”。前者看个热闹就够，后者才是你的护城河。所以这篇文章，值得花十分钟看结论，不值得花十天改流程。