非 Opus 模型也能做的科普可视化代码视频：从类型清单到工程兜底

Opus 5.5 之所以让人惊艳，不是因为它特殊，而是因为它把"写代码 → 浏览器渲染 → 录制成片"这条工作流做到了可复现。把 Opus 拿掉、换成别的 LLM，这条工作流仍然跑得通——这是一系列新证据共同指向的事实。本文先摆出六类代码视频的取向清单让你自己挑，挑中数据可视化/动态图表一类后用一个完整案例走通这条链路，再用 Code2Video Bench 的实测差距说明"换模型"并不等于"成片崩坏"，最后给出分步生成 + 渲染器闭环自纠这套工程兜底。

一、先看清 Opus 5.5 到底做了什么：写代码，不是吐视频

Opus 5.5 是文本模型，不输出视频帧。它的工作方式是写 HTML / CSS / JavaScript 代码，由浏览器渲染后录制成 MP4。这一件事是理解后面所有内容的前提，写代码 → 浏览器渲染 → 编码成片，而不是用通用视频生成模型直接吐像素。 HyperFrames

Opus 5.5 的事实坐标由 Anthropic 自家平台文档锚定：发布于 2026 年 9 月 22 日，model id 是 claude-opus-5-5，context 1M tokens、max output 128K tokens（Batch API 可到 300K），input/output 形态是 "Text and images → text"，定价 $4 / M input、$20 / M output tokens。Anthropic — Introducing Claude Opus 5.5 的产品页与平台文档在 Coding / Knowledge work / Communication / Safety / Availability 五节里完全不出现 "video / render / MP4 / animation" 这一类词，社区站点 claudevideo.org /how-it-works 也用一句话把这件事讲得很直白："Claude Opus 5.5 doesn't output video. It writes code that draws a video." DURATION

这条工作流已经被 Anthropic 自家产品化。2026 年 10 月 8 日 Claude Motion 进入 beta，运行方式是在 Team / Enterprise 计划的 Chat 里输入 /motion，Motion 作为一个内置 artifact 出现，由 Claude 写代码、内置渲染器产出 MP4，本质和外面社区搭出来的"代码驱动 + 浏览器渲染 + ffmpeg"链路完全相同。

图注：Claude Chat 输入框里输入 /motion 弹出的 Motion 命令面板与底部状态栏。这个截图直接证明 Claude Motion 是 Anthropic 自家产品里嵌入的代码驱动 artifact，而不是临时方案。

后面所有章节都默认你已经知道 Opus 5.5 的工作方式。如果用一句话给非 Opus 模型门道留个入口：同一份管线能跑通的关键不是某个模型的"特殊能力"，而是 prompt 里那条确定性渲染契约——window.DURATION（秒数）和 async window.seek(t)（把任意时刻画上屏的函数）。后面走完整案例那一章会把它展开。 BeatAPI

二、类型清单：六类 AI 生成的代码视频，你想要哪一种

先把类型摆全。这一节的任务是让你自己挑，不要先替你做决定。claudevideo.org 的 /videos 索引按视觉风格把当时已收录的 1276 条 Opus 5.5 代码视频分成 8 个分桶：Motion Graphics 357 / Explainers 201 / Product & Ads 186 / Interactive 176 / Stories 130 / 3D Scenes 91 / Art 81 / Production 54。这套分桶是"按输出风格"切的。WPS Blog 的 5 use-case × Why code works × Watch for 切法跟它不一样：按使用场景切（Product launch / Educational / Data stories / Kinetic typography / UI demos），每条都告诉读者为什么代码在该场景下能跑通、有什么常见踩坑点。两条切法互补，下面这张对照表把它们对齐：

类型（面向用户的提法）	claudevideo 8 桶同位	适合讲什么	视觉追求	对模型能力的要求
科普讲解动画	Explainers（201）	概念讲解、流程拆解	清晰字幕 + 节奏稳定 + 画面留白够	中：图字对齐 + 时间轴对位
数据可视化	Explainers + Motion Graphics 重叠	真实数据驱动的图表与变化	数值精确、可追溯的口径	低-中：图表来自数据而非凭空想象
动态图表（kinetic 风格）	Motion Graphics（357，最大桶）	趋势、流程、抽象概念（地图、网络、立方体等）	节奏感强、留白合理	中：图字对齐 + 风格连贯
白板手绘	Art（81）	抒情短片、概念图解、歌词视频	水彩/钢笔/手绘质感	中-高：风格连贯性是难点
3D 演示	3D Scenes（91）	三维结构、空间关系、产品 3D 渲染	几何精度	高：Three.js / Blender scripting
UI 交互演示	Interactive（176）+ Product & Ads（186）	App / Web 流程截图、产品 demo	像素精确、真实 UI 截图	中：UI 元素复用 + 干净截图

每行对应 WPS Blog 文章里那列"Watch for"——negative-case 列表是 talking heads / nuanced acting / wildlife / documentary / complex fluid motion，这些不是代码驱动视频的菜，是专门视频模型的活，选型时先把它们剔掉。

类型清单的下一步是选框架。下面这张 HyperFrames vs Remotion 对比表来自 claudevideo.org 的 PIPELINE 2: RENDER FRAMEWORKS 小节，是你锁定一类后立刻要回答的问题："用什么框架写代码"。 HyperFrames

图注：claudevideo.org 给的 HyperFrames vs Remotion 对比。两边都能产出 deterministic MP4，区别在 authoring：你写 HTML/CSS/JS 还是 React 组件；以及 licensing（HyperFrames Apache 2.0，Remotion 在 4 人以上公司需要购买 Company License）。

重要边界：Code2Video Bench 的 168 条 brief 实际上偏向 launch-narrative（Hook / Problem / Product Intro / Key Feature / Benefits / Social Proof / CTA / Brand Outro 这 8 个 launch beat），Key_Feature 和 Product_Intro 两类加起来超过一半。下面这张分布图来自 HeyGen Research 的 Code2Video Benchmark 报告 Figure 4。

图注：Code2Video Bench 的 168 条 brief 在 8 个 launch beat 上的分布，Key_Feature 和 Product_Intro 占比超 50%。

这张图意味着：当你判断一个模型"在这条工作流上跑得好不好"时，benchmark 的优势集中在 launch / product 类，你的具体类型不一定直接被它覆盖——benchmark 数字要参考但不能照搬。

三、挑一类走到底：数据可视化/动态图表一条完整案例

为什么挑数据可视化/动态图表走到底？三句话理由：第一，模型在 coordinate-defined 的图字世界里反而比角色表演世界干净（WPS Blog：every object can be positioned by coordinates and every frame can be calculated from time）；第二，这条线和 Code2Video Bench 的 Prompt-Intent + Composition 两个评分轴最强项重合——"遵循 brief"几乎被解决、"排版与构图"在图字场景里是模型已经擅长的一块；第三，HyperFrames / Remotion / render.mjs 这一套在 chart / launch clip 这条路径上已经被多个独立来源多次走通（BeatAPI、LaoZhang AI Blog、claudevideo.org 都给过完整 worked example）。

下面这条主线把整条管线一次性压成 4 步。

图注：LaoZhang AI Blog 给的 4 步流程图——Write the scene（写 scene.html）→ Seek a frame（按 i/fps 调 window.seek(t)）→ Screenshot it（page.screenshot）→ Encode the MP4（spawn ffmpeg image2pipe → libx264）。底部小字 "No video model involved"。

3.1 提示词里强制写 window.DURATION + seek(t)

模型产出的 HTML 必须满足这条契约才能被确定性截图——window.DURATION = {LENGTH} 写视频总秒数，async window.seek(t) 把任意时刻 t 画到屏幕上，每个像素只依赖 t、输入数据和固定资源，禁止 Date.now / requestAnimationFrame 循环 / 计时器 / CSS transitions / 未 seed 的 Math.random。这条契约由 BeatAPI 的 prompt 模板给出模板原文（包含 Contract 行和"Every pixel is a pure function of t"行），LaoZhang AI Blog给出实测动机。

为什么必须 seek(t) 而不能读时钟？这不是仪式感，是物理约束：LaoZhang AI Blog 在 Apple M4 上测出一帧 PNG 截图平均约 72 ms，而 30 fps 视频的相邻两帧播放间隔是 33.3 ms。如果场景读 performance.now() 推进，画面在每帧之间真实向前走 72 ms，但播放器只放 33.3 ms，等同跑出 2.2 倍速，整段就废了。 PNG

图注：同一篇博客的 72 ms 截图时间 vs 33.3 ms 播放时间对比图，以及读时钟场景跑飞 2.2× vs seek(t) 驱动场景前后帧字节一致的对照。数字来自 Apple M4 单机单场景实测（PNG，360 帧 @ 30fps，12 秒 1080p 测试），不是普适值。

3.2 render.mjs 把 HTML 录成 MP4

参考 BeatAPI 的 render.mjs 和 LaoZhang AI Blog 的实现，最简形态：Playwright 启动 headless Chromium，page.goto scene.html，await page.waitForFunction(() => typeof window.seek === "function")，循环 page.evaluate((t) => window.seek(t), i / fps) + page.screenshot({type:"png"}) 把每帧 pipe 给 ffmpeg -y -f image2pipe -framerate {fps} -i - -c:v libx264 -pix_fmt yuv420p -crf 18 out.mp4。-crf 18 是 quality/压缩比的一个折中点（数字越小质量越高），-pix_fmt yuv420p 是视频播放器普遍兼容的像素格式。同一份 scene.html 重跑两次，LaoZhang AI 的测试得到字节级一致的 MP4——这就是 deterministic render 的工程实质。

3.3 本地先跑一次 sanity check 再让模型接管

把一份 hand-written 的 6 秒、1080×1080、30fps 场景（比如 4 根亮绿柱状图的 fake chart）先跑通一次完整的 render.mjs。确认 Node.js / Playwright Chromium / ffmpeg 都装好、PNG pipe 进 ffmpeg 不堵，确认输出 MP4 用 ffprobe 读得到正确时长和帧数。这一步是 BeatAPI 的"先跑通一次"建议：场景准备好了再让模型换你的 scene.html。下面是本机 sanity check 跑完后产出的样片帧。

图注：hand-written 6 秒 1080×1080 30fps 场景的输出帧，黑底 4 根亮绿柱 W1–W4 数值 800/1,300/2,100/3,900。标题 "TikTok followers (sample)"——数字是合成的，不是真账号数据；保留 "sample" 字样，避免被误读。

把上面的 sanity check 换成模型生成的 scene.html 之前，先把整份提示词的最后一行固定成 "First reply with a beat sheet and 4 keyframes only; write the file after I approve"——这一句让模型先出节奏表和 4 个关键帧让你过一遍，再动手写完整文件，避免你直接拿到一份很贵但跑偏的 HTML。

四、换模型之后到底差在哪：Code2Video Bench 摊牌

数据可视化/动态图表这条线走通了，但换一个不是 Opus 的模型会不会马上崩？HeyGen Research 在 2026-09-18 发布的 Code2Video Benchmark 是当前唯一公开维护、可以一站式回答这个问题的工作。它给出 168 条人工撰写的 launch brief × 8 beats × 5 轴两两对比打分（pairwise Elo）+ 95% 置信区间 + 一个人类一致性 82% 的判分模型。 HeyGen HeyGen

下面这张是 top-10 Elo 排行榜：

图注：Code2Video Benchmark top-10 Elo 排行榜（168 brief × 5 轴两两对比），具体数字以 Kaggle leaderboard 为准。

头条数字是：top 4 模型差距 12 Elo 以内、置信区间互相重叠（说明没有一个真正拉开身位），open-weight 集群（HeyGen 报告里列出的 qwen3.8-max / deepseek-v4.1-flash / kimi-k3 / glm-5.3）与第一名差距在 50 Elo 以内，几乎所有模型与 human reference 的差距都接近 0。这三条信息合起来讲一件事：换模型不会让成片质量崩坏到"完全不能用"。

5 轴评估是独立评分，不加权不合成总分。下图解释这 5 轴是什么。

图注：Code2Video Bench 的 5 轴评估框架——Engagement / Prompt-Intent / Composition / Temporal / Craft。每轴独立评分，意味着排名靠前的模型在不同轴上各有强弱，不存在单一"全能 SOTA"。

AlphaSignal 的读后小结把"哪里会翻车"讲得很具体，3 条失败模式：(1) broken timing——新元素开始动的时候前一段动画还没停；(2) mid-flight collisions——文字只按终态排版，没检查运动中间帧会撞；(3) defensive styling——模型不确定就缩小字体、变细线条，世界地图退化成居中小图形。HeyGen Research 报告里直接写了一句结论："Following the brief is nearly solved; craft is not."——Prompt-Intent 最强（已被"遵循指引"解决），Composition / Craft / Temporal 拉开差距。AlphaSignal 自己转述为「Prompt intent is the strongest and most tightly clustered axis, indicating that leading models usually include the requested scenes and elements. Composition, temporal rhythm, craft, and motion create more separation.」。这条结论就是真正会翻车的地方，也是下一章工程兜底要补的缝。

另外值得注意的：bench 里出现 regression——AlphaSignal 文章里直接写明 "GPT-5.5 和 Claude Opus 4.8 偶尔胜过它们的下一版"，新旧版本换上去未必更好。如果你现在用的模型跑得稳，老版本掉队之前不必追新。

五、工程兜底：分步生成 + 渲染器闭环自纠

如果换模型带来的是 motion 撞版 / text 不到位 / 安全选择而不是直接崩，那工程兜底的正确角度不是"换更大的模型"而是"把模型包进一个会看错误并自纠的循环"。这一步靠的是 arXiv:2604.18364 提出的 RITL / RITL-DOC（Renderer-in-the-Loop / RITL + Rule-based API Doc 注入）。 GRPO

学术 arXiv:2604.18364 把这件事在 Manim 数学教学动画上量化测出来。先看训练侧：

图注：ManimTrainer 训练管线——Quantised Base LLM → SFT → GRPO，使用外部 Manim 渲染结果计算 code reward 和 visual reward 回灌 policy。模型天然就被训练成"期待看到渲染错误信息"的状态。

再看推理侧（务必配对出现，否则等于把动机丢掉）：

图注：ManimAgent 推理管线——LLM → render box → 成功则退出 / 失败则抽 API 调用符号 → 检索 Manim 官方文档 → 重建 prompt → 重新生成。K 步循环，每次把渲染器的报错回喂。

把 AlphaSignal 引用的 HeyGen 5 条 production guardrails（验证 timeline 依赖 / 测试中间帧碰撞 / 断言 reveal 后的精确文字 / 设置最小画布覆盖率 / 轴级 critique + 人工 review）和 RITL/RITL-DOC 一一对上：(1) 验证 timeline 依赖 ↔ RITL 把渲染错误回喂给模型；(2) 测试中间帧碰撞 ↔ RITL 每步重渲染整个时间轴的中间帧；(3) 断言 reveal 后的精确文字 ↔ K 步循环里的 regenerate 把文字对齐。AlphaSignal 文章里给出过例子，GPT-6-Astra 渲出 "Make it your owr" 缺字母 R——但要注意：这条 guardrail 在原论文里 RITL 并没有专门覆盖。RITL 主要回喂的是 renderer error log（编译 / 运行时异常），"Make it your owr" 这种视觉缺字不会触发错误日志；要做这种对齐需要在 RITL 之外再加一道渲染后文字 OCR / 视觉 diff 检查（这超出了 arXiv:2604.18364 已实现的机制）。第 4 条和第 5 条是工程层面的事（防御性设计 + 人工 review），靠 RITL 不能完全自动解决，需要写在 prompt 或者外层脚本里。

arXiv:2604.18364 在 ManimBench 100-sample 测试集上的 headline 数字：Qwen 3 Coder 30B（A3B，约 30B 总参 / 3B 激活）+ GRPO + RITL-DOC@3 → VS 85.7% / RSR 94% / CBB 54.2%，超过 GPT-4.1 的 RITL-DOC@3 baseline（VS 82.8% / RSR 94%）。17 个模型的均值在 Vanilla → RITL → RITL-DOC 上单调上升，Vanilla-Block 到 RITL-Block 均值提升约 7 pp（大于 Vanilla-Block 内部 Base→GRPO 的约 3 pp），说明推理时增强比训练时增强更划算。这条主线给弱模型 + 渲染器闭环做出成片效果给了一份学术论证。

工程提示：arXiv:2604.18364 明确 RITL-DOC 在 ≥7B 模型上稳定增益，在 <4B 模型上可能拖后腿（稠密 API 文档撑爆上下文）。所以小模型用纯 RITL + 更小 K，大模型才上 RITL-DOC。这条经验在 motion graphics / product launch（非数学教学）上的泛化在论文里没有独立验证，但机制一致，可以先 K=1 试。

六、仓库地图：谁解决哪一环，哪些直接能用、哪些只能参考

这一层是把上面所有概念落到"我下一步去 GitHub 拉什么"的具体清单。这一节按"渲染框架"和"style skill"两层分开——前者解决"用什么语言写时间轴"，后者解决"写出来像什么风格"。两层严格不混。 SKILL STYLE

6.1 渲染框架层

四个框架是 React / HTML / TypeScript-generator / Python-native 四条正交路线，按你的语言栈挑：

Remotion（remotion-dev/remotion，Source-available Remotion License）——React + JSX 组件，把 composition 当作一组 React 元素 + 时间维度。CLI 是 npx create-video@latest。3 人以下免费商用，4 人以上要买 Company License，Lambda 走 server-side render。
HyperFrames（heygen-com/hyperframes，Apache 2.0）——HTML + CSS + data-* 时间属性 + 任一 seekable animation runtime（GSAP / Lottie / Three.js / Anime.js / WAAPI 等）。npx hyperframes init my-video，对 agent 友好，CLI 默认非交互。
motion-canvas（motion-canvas/motion-canvas，MIT）——TypeScript + generator functions 写动画（yield* 决定帧时机），npm init @motion-canvas@latest 起手。适合"会写 TypeScript、想要编辑器实时预览"的视频图/解说长片。

图注：motion-canvas 编辑器在第 35 帧处的快照——顶部 transport 按钮、时间标尺、scene 块、event 胶囊（高亮态）、音频波形、playhead。它和上面两个的最大区别是"代码本身就是时间轴"，没有 seek(t) 契约。

Manim Community（ManimCommunity/manim，MIT 双许可）——Python 原生，manim -p -ql example.py SceneName 一行出 MP4，专门做数学/教学/3D Axes。

图注：HyperFrames vs Remotion 7 维对比表（Authoring / Build step / Agent handoff / 库时序动画 / 分布式渲染 / License / 一句话）。其中 License 是最关键的硬性差异——Apache 2.0 vs Source-available，与你的商业约束直接相关。

6.2 Style skill 层

style skill 是上层封装：一个目录里装 SKILL.md + 可跑的 template/ + 一个 worked example + marketplace.json。底层要么自己写 render.mjs（opus-video-skills），要么挂到上面某个框架上。挑 style skill 的依据是"我想要什么视觉"，不是"哪个模型最强"。

opus-video-skills（tuzhechen2005/opus-video-skills，MIT）——两个完全不同的风格共享同一份 render 架构：painted-animation 是 p5.js + p5.brush 水墨手绘，这里是 31 秒 lyric video 陶喆《小镇姑娘》的 6 帧 contact sheet：

图注：painted-animation 的 6 帧水墨 contact sheet，时间戳 1.20s / 7.30s / 10.30s / 18.25s / 21.20s / 27.90s，含卡拉 OK 字幕。

kinetic-reel 是动态字体（kinetic typography） + Three.js 层 + WebGL post pass，Work Reel '26 84 秒作品的 12 帧 contact sheet：

图注：kinetic-reel 的 12 帧 kinetic typography + three.js slide，TC 时间码 01.x / 02.x 等标签。

lemo-opuscar（lemomo-ai/lemo-opuscar，MIT）——43 种 film style，每种一份 STYLE.md + 一支 code-made 短片，这里是 4 行 × ~11 列 ≈ 44 格的全风格拼贴：

图注：43 种 film style 索引拼贴——水墨、水彩、浮世绘、像素 UI、等距 3D、卡通、霓虹并行排列。右下角 LEMO / OPUSCAR / 43 STYLES · MADE IN CODE。

huashu-art-motion（alchaincyf/huashu-art-motion，MIT，2026-10-13 最近 commit）——35 种艺术风格（公元前 40000 年的岩洞一路穿到 2026 flat vector）+ 9 种解说语法（Kurzgesagt / Vox / whiteboard / 3Blue1Brown / kinetic type / finance charts 等），35 种艺术风格的 6×6 网格同主题渲染：

图注：35 种艺术风格按同主题（少女 + 橘白猫 + 桌子）渲染的 6×6 网格总览——同一构图在 35000 年艺术史中重画 35 次，覆盖岩洞 / 埃及 / 哥特 / 文艺复兴 / 梵高 / 蒙克 / 立体派 / 8-bit / 吉卜力 / 新海诚 / 2026 flat vector。

PDoomVideo + ClaudeAnimationBase（JohnHeibel/PDoomVideo，ISC + JohnHeibel/ClaudeAnimationBase，MIT）——历史节点，2026-09-22 与 Opus 5.5 同日创建，156.6 秒音乐视频 for I'm Upping My P(doom)，全部 JavaScript + p5.js + p5.brush。README 推荐 fork ClaudeAnimationBase 而不是 PDoomVideo，opus-video-skills 显式承认它的方法来自这一支。这里是 README 里的 recursion_loop 帧：

图注：PDoomVideo 的 recursion_loop 一帧——橙色皇冠角色站在木舞台上、同心玫红光环、黄色小星。水墨线条 + 平涂风格，p5.js + p5.brush 渲染（不是 WebGL / Three.js）。

lemo-opuscar 与 huashu 的关系：前者偏电影风格密度（43 种各一支短片），后者偏艺术史 + 解说语法（35 种 × 同一主题 1 帧）。两个仓库都在公开 READMEs 里没显式 cite PDoomVideo，所以同源是概念性的不是仓库 attribution 上的。lemo-opuscar README 有一句明确的边界声明："The styles are tuned for Opus 5.5; other models may not reproduce them"——非 Opus 模型复用时要回到前一章的 RITL/RITL-DOC 兜底。

七、未选类型的入口 + 少踩坑收束

这一节给的是一句话级别的快速索引，不展开，每条都对应 GitHub 上现成的仓库或方案。

未选类型的入口：

科普讲解动画 → Manim Community + ManimTrainer/ManimAgent（arXiv:2604.18364）的分步兜底；起步用 manim -p -ql example.py SceneName。
白板手绘 → p5.js + p5.brush；直接看 opus-video-skills / painted-animation 或 PDoomVideo 的方法谱系。
3D 演示 → Three.js / Blender scripting。
UI 交互演示 → Remotion + 真 UI 截图，谨记 WPS "Watch for" 那条（mock UI 必须标注）。
产品 launch → HyperFrames，让模型读真 UI 组件而非用 plausible imitation 凑 demo；claudevideo.org 的 8 桶计数里这是一条代表路径。
dynamic kinetic typography → opus-video-skills / kinetic-reel（84 秒 Work Reel 的 worked example 在那）。

code-to-video 不擅长的事（"negative cases"，由 WPS Blog 总结）：talking heads、nuanced acting、wildlife、documentary、complex fluid motion——这些用专门视频模型而不是代码驱动路径。

少踩坑的 4 个常见点：

视觉漂移：同一份 prompt 多跑几次结果不一致——这是 ManimTrainer / ManimAgent 论文里的 RITL 要兜底的结构性问题；不是 bug、是有意为之。
动画节奏失控：模型独自出完整成品时最容易撞 AlphaSignal 那 3 条失败模式；用第 3 章那份"先出 beat sheet + 4 keyframes"的强制条款挡一刀。
字体与排版：当类型取科普讲解/UI 演示时用系统字体 + 显式列在提示词的 Style 行，BeatAPI 那份 prompt 模板里的 Style 行（palette HEX、font 名称、motion 风格）就是这条。
录制成片质量：render.mjs 里 -crf 18、-pix_fmt yuv420p、-movflags +faststart 是常规三件套，crf 是质量系数（Constant Rate Factor），数字越小质量越高，18 是质量与文件大小的常用折中点。

参考文献

本专题引用过的核心资料如下，建议深入学习时阅读原文：

Anthropic — Introducing Claude Opus 5.5 — https://www.anthropic.com/claude-opus-5-5
claudevideo.org — How Claude Opus 5.5 makes video (it writes code, not pixels) — https://claudevideo.org/how-it-works
WPS Blog — How Claude Opus 5.5 Generates Videos with Code — https://www.wps.com/blog/how-claude-opus-5-5-generates-videos-with-code/
Claude Dashboards and Motion (Anthropic) — https://claude.com/resources/articles/dashboards-and-motion
BeatAPI — How to Make Videos with Claude Opus 5.5: A Deterministic Render Pipeline — https://beatapi.io/blog/how-to-make-videos-with-claude-opus-5-5
LaoZhang AI Blog — Claude Opus 5.5 Video Generation: Code In, Rendered MP4 Out — https://blog.laozhang.ai/en/posts/claude-opus-5-5-video-generation
opus-video-skills (tuzhechen2005) — https://github.com/tuzhechen2005/opus-video-skills
Training and Agentic Inference Strategies for LLM-based Manim Animation Generation (ManimTrainer / ManimAgent, RITL / RITL-DOC) — https://arxiv.org/abs/2604.18364
HeyGen Research — Code2Video Benchmark: Evaluating AI Agents on Motion Design — https://www.heygen.com/research/introducing-code2video-benchmark
AlphaSignal — HeyGen's Code2Video Bench Reveals AI Still Fails at Motion Graphics — https://alphasignal.ai/news/heygen-s-code2video-bench-reveals-ai-still-fails-at-motion-graphics
Code-to-video frameworks — Remotion / HyperFrames / motion-canvas / Manim（README + 官方站点 overview） — https://www.remotion.dev/ / https://github.com/heygen-com/hyperframes / https://motioncanvas.io/ / https://docs.manim.community/en/stable/
motion-canvas/motion-canvas — Visualize Your Ideas With Code — https://motioncanvas.io/
lemomo-ai/lemo-opuscar — Claude Code skill for short films with no video model (43 film styles) — https://github.com/lemomo-ai/lemo-opuscar
alchaincyf/huashu-art-motion — 35 art styles + 9 explainer grammars — https://github.com/alchaincyf/huashu-art-motion
JohnHeibel/PDoomVideo + JohnHeibel/ClaudeAnimationBase — Code-rendered music video for I'm Upping My P(doom) — https://github.com/JohnHeibel/PDoomVideo / https://github.com/JohnHeibel/ClaudeAnimationBase