Opus 5.5 做视频：从代码渲染原理到提示词和 Skill 工作流

本文整理自 xilo 的 X 帖子及其中的 X Article。原文发布于 2026 年 9 月 29 日，围绕 Opus 5.5 如何通过编写代码制作视频，拆解了 7 类代码路线、5 个作品案例、提示词框架和作者开源的 Skill。本文保留原文配图，并将经验重新编排为一份可执行的工作流。

文中的成片效果、渲染用时和作者的工具体验属于个案，不是模型能力、完成时间或商业结果保证。Claude、Opus 5.5、Skill、Playwright、FFmpeg 及相关框架的功能和版本，以各自当前文档与实际运行结果为准。

先说原理：模型写代码，代码逐帧画画

Opus 5.5 本身并不是视频生成模型。原文给出的制作路径是：模型根据提示词编写可运行的画面代码，代码在网页或动画框架中绘制某一时刻的画面，再由浏览器自动化工具逐帧截图，最后由 FFmpeg 等工具把图像帧和声音合成为视频。

可以把它想成一册自动翻动的动画书：每一页对应一帧，页面内容由时间决定。若视频是 30 帧/秒，渲染器需要为每秒生成 30 张画面，再按顺序合成。

一条可靠的生产链大致是：

主题与参考
  → 故事 / 分镜 / 画面规则
  → HTML、Canvas、WebGL、Three.js 或视频框架
  → 固定时间点渲染与抽帧检查
  → 配乐、配音、音效和字幕
  → FFmpeg 合成
  → 完整播放检查与修改

这个方法的优势是画面结构、运动、文字和节奏都能通过代码精确控制，适合动态图形、像素动画、界面动效、信息可视化和风格化短片。它的限制也很明确：模型需要写出可执行的程序，渲染链条可能耗时，写实人物和复杂动作不一定适合全程用代码生成。

一、7 类代码路线怎么选

原文把常见路线归纳为 7 类。实际制作时可以组合使用，选择依据是画面需求，而不是把技术栈越多越好。

路线	擅长内容	需要留意
JavaScript + Canvas 2D	像素画、平面插画、几何图形、粒子	逐帧绘制需要自己处理坐标、时间和动画状态
HTML + CSS + SVG	产品界面、排版、图标、网页元素变形	适合界面感画面；逐帧渲染前要等字体和资源加载完成
WebGL 着色器	扫描线、噪点、水面、光效、颗粒和像素后处理	GPU 效果强，但调试、跨设备表现和渲染成本更复杂
Three.js	3D 场景、镜头运动、空间文字、粒子云	程序化基础几何适合风格化表达；需要真实产品外形时可能要导入 3D 模型
p5.js / p5.brush	彩铅、水彩、蜡笔、手绘笔触	可做艺术化笔触，但仍需控制纹理密度和帧间一致性
HyperFrames / Remotion	时间线或帧驱动的视频合成与场景管理	复用已有视频结构更方便；要按团队熟悉的控制方式选择
Manim	公式、坐标轴、几何关系和教学动画	精确、结构清楚；若追求复杂质感，通常需要与其他路线组合

Playwright 可以驱动无头浏览器打开页面并截取指定时刻的画面；FFmpeg 可负责编码、混音和格式处理。声音也可以用程序生成，但它和画面一样需要听检，不能只依赖模型对结果的文字描述。

二、5 类案例：代码可以单独用，也可以混搭

原文比较了五种画面类型。配图来自原帖，帮助理解技术路线；它们是作者选取的作品案例，不代表每个工具都由原帖作者制作。

1. 像素巫师：Canvas 2D

这个例子把逻辑画布先设成较低分辨率，再按整数倍放大并关闭图像平滑，像素边缘因此保持清晰。角色由矩形和像素块绘制，姿势参数控制手臂、法杖和身体动作；蓄力、施法、收招则由循环状态组织。

原文强调的设计点不是“低分辨率就等于像素风”，而是分开处理角色姿势和特效：姿势可以较低帧率量化，火花等粒子仍保持流动，这样动作有复古感但画面不会整体发卡。

2. 界面变形：HTML / CSS / SVG、弹簧和节拍

按钮、播放器、滑块、开关、标签页、图表和命令面板都可以作为真实网页元素绘制。流畅感来自几项协同设计：用弹簧曲线控制变形，用音乐节拍安排状态切换，再通过多次取样叠加做运动模糊。

如果每个控件只是依次淡入，画面会像模板演示。更有连贯性的处理是让同一个形状改变尺寸、圆角和内部内容，转换成下一个界面状态。

3. 电子游戏史：Canvas + 着色器 + Three.js

不同年代可以使用不同的渲染方式：早期游戏用 Canvas 像素画，复古屏幕叠加 WebGL 着色器，后续年代切入 Three.js 的空间场景，音乐则通过程序合成或单独制作后再与镜头节奏对齐。

案例还提醒我们：视觉后处理可能显著增加渲染成本。原作者报告，某个 3 秒、90 帧片段只用 Canvas 渲染约 7 秒，加入着色器后约 48 秒。这是原文在其机器和项目中的单次记录，不能当作其他设备或项目的预估值。

4. 甜酷舞蹈：视频模型出人物，代码负责画面

写实人物和复杂舞蹈动作不是纯代码绘制的强项。原文展示的混合路线是先用视频模型生成绿幕人物，再由 Opus 5.5 编写代码完成抠像、背景、文字、胶带、分屏和空间文字等视觉设计，并按音乐节奏切换场景。

这类拆分把任务交给更适合的工具：人物运动交给视频生成模型，图形编排、信息层级和节奏控制交给代码。原文也提到作者自己的样片使用了外部角色动画服务；具体工具名和能力应以原文及服务现状为准。

5. AI 发展史：Remotion 讲完整故事

原文最后展示一条约 3 分钟的 AI 发展史短片：在 Claude Code 中使用 Remotion 管理场景，图形由 SVG、Canvas 和代码生成的粒子构成，配音与配乐分别制作。

这类长片最重要的是先写故事结构和场景表，再把场景拆成可独立渲染和检查的片段。不要一开始就要求模型一次生成完整影片，否则发生文字溢出、镜头重复或事实错误时，很难定位和返工。

三、提示词用结构控制，而不是堆形容词

原文观察到，复杂视频任务可以用 XML 标签分开写角色、输入、画面方向、结构、制作和检查要求。这个格式的价值在于让模型容易区分“需要用户提供什么”“最终画面想要什么”以及“执行时不能违反什么”；它不是保证一次成功的特殊语法。

一个精简结构如下：

<role>你是动态设计师和创意程序员。</role>
<inputs>
  主题、时长、画幅、帧率、参考素材、配色、字体、声音来源。
  缺少的信息先询问，不要替用户编造。
</inputs>
<direction>
  画面风格、主体一致性、镜头和动效原则，以及明确的禁止项。
</direction>
<structure>
  按时间列出镜头、构图、动作、屏幕文字、声音和转场。
</structure>
<build>
  指定渲染路线、输出分辨率、帧率、时间驱动画面方式和合成格式。
</build>
<gotchas>
  列出字体加载、资源缺失、文字重叠、WebGL、音量等常见问题。
</gotchas>
<start>
  先提交分镜和关键帧预览，确认后再渲染全片。
</start>

其中 <direction> 的禁止项很重要。只写“高级、电影感、精致”，模型容易回到熟悉的默认方案，例如居中大字、渐变背景、所有元素一起淡入。更有用的限制是写清楚不要什么：不要满屏小字、不要无理由发光、不要所有元素同步进场、不要重复使用同一种转场。

分镜表至少要回答 6 个问题

项目	说明
时间	镜头开始和结束时间，或帧范围
画面	主体、构图、背景和屏幕文字
动作	主体与镜头分别怎样变化
声音	旁白、音乐、音效或留白
转场	镜头如何自然过渡到下一段
技术	Canvas、CSS、WebGL、3D 或视频素材的分工

四、作者开源的 xilo-opus-video Skill

原文提到的 xilo-opus-video Skill 把视频制作步骤组织成对话工作流。按作者的介绍，它会先询问主题和输入，再给出不同风格方案、对应技术路线和镜头概括；用户选定方案后生成 brief，再逐镜头制作、检查关键帧并评审成片。

这类 Skill 的价值是把重复流程变成可复用的操作说明，不等于自动保证内容准确或成片达标。安装前应阅读仓库说明和权限需求；运行时确认它读写的文件范围、调用的外部工具以及渲染产物的位置。

五、把视频任务拆成可验收的 7 步

1. 确定目标和约束：明确观众、核心信息、时长、画幅、帧率、平台和素材来源。
2. 写故事和分镜：先校正事实与叙事，再决定镜头和转场。
3. 选最少的技术路线：平面画面优先 Canvas 或 SVG；界面动效优先 HTML/CSS；复杂空间运动再考虑 Three.js；需要成熟的帧管理时选 Remotion 或 HyperFrames。
4. 先做关键帧：检查风格、排版、主体比例和对比度，确认后再投入全片渲染。
5. 逐镜头实现：每完成一个镜头就渲染几张代表帧，避免问题累积到最后。
6. 合成声音和画面：声音按节拍或旁白时间轴安排；需要字幕时检查断句、阅读速度和画面对齐。
7. 完整观看并返修：查看开头是否抓人、画面是否清楚、动作是否自然、镜头是否重复、文字是否溢出、声音是否过响，以及结尾和循环是否完整。

对于可重复渲染的代码动画，最好让画面只由时间 t 决定：同一个时间点重复运行得到同一帧。固定随机种子、等待字体和图片加载、记录输出帧率，可以减少浏览器逐帧渲染时的不确定性。

六、视频自查：把“我觉得不错”变成具体问题

原文给出的自查方向可以整理为六项：

• 前 2 秒是否让人明白主题并愿意继续看？
• 缩小到手机屏幕后，文字和主体是否仍然清楚？
• 动作是否自然，是否有匀速滑动、卡顿或空拍？
• 每隔几秒是否有新的信息或视觉变化？
• 构图是否拥挤、空洞或被装饰元素分散注意力？
• 声音、字幕和画面是否对齐，音量是否稳定？

先找出最严重的三处问题，记录时间点并逐项修复，比要求模型笼统地“再优化一下”更有效。模型可以帮忙出抽帧、列问题和修改代码，最终仍要由人完整观看视频并确认。

最短试做路径

如果你还没有跑过完整流程，可以从 10 到 15 秒的单场景片段开始：选一种视觉风格，写清楚画幅和动作，要求模型生成一个 render(t) 函数或固定帧时间的网页；用浏览器截取少量关键时刻，检查一致性后再扩展到整段。先跑通一条能重复渲染、能听检、能修改的短片，比一开始追求三分钟成片更容易发现技术和提示词的问题。

来源与补充阅读

• xilo 的原始 X 帖子
• X Article：零基础入门 Opus 5.5 做视频
• xilo-opus-video Skill
• awesome-opus-5-5-videos
• awesome-ai-motion
• ClaudeAnimationBase
• PDoomVideo

配图来源：X Article 的封面和文内公开图片，按文章叙述顺序保存于本站静态资源目录。案例描述、渲染耗时和工具体验均为原作者或相应作品作者的分享；本文不据此推断 Opus 5.5 一定具备直接输出视频文件的能力。原文重点是通过代码绘制并渲染画面，再由其他工具完成视频合成。