1. 当模型开始"画"视频：一个反直觉的实测发现

第一次看到"Claude Opus 5.5 直出视频"这个说法，我的反应和大多数人一样——不信。大语言模型输出的是文本 token，视频是像素帧序列，这两者之间隔着一整套渲染管线，怎么可能"直出"？但把提示词丢进去跑了一遍之后，我盯着屏幕上那个会动的画面愣了几秒：它确实没有生成 mp4 文件，但它用 HTML、CSS 和 JavaScript 在浏览器里"演"出了一段动画，视觉上就是一段可以播放的视频。

这件事的价值不在于"AI 能生成视频了"这种标题党式的结论，而在于它揭示了一个被很多人忽略的事实：当模型的代码能力足够强时，视频可以退化成一种"用代码描述的时间序列"。你不需要视频生成模型，不需要显卡渲染农场，只需要一段能被浏览器解析的 HTML 文件，就能得到一段可交互、可循环、可嵌入网页的动态画面。

这篇文章适合三类人看：一是想搞清楚"直出视频"到底是怎么回事的技术好奇者；二是手里有 Claude Code 或类似工具、想把它用出花来的开发者；三是做前端、做内容、做演示，需要快速产出动态视觉素材的人。我会把提示词怎么写、代码为什么这么组织、实测中哪些地方会翻车、怎么调参让动画更顺，全部拆开讲清楚。核心关键词围绕Claude Opus、Claude Code、提示词、HTML、CSS展开，但重点永远落在"你拿到手能怎么用"。

先说结论，免得你带着错误预期往下读：所谓"直出视频"，本质是模型生成一段自包含的 HTML 文件，用 CSS 动画和 JS 时间轴驱动画面变化，浏览器负责逐帧渲染。它不是视频编码，是"代码即动画"。理解这一点，后面所有的技巧才有落脚点。

2. "直出视频"的真相：代码即动画的底层逻辑

2.1 为什么是 HTML 而不是 mp4

视频文件本质上是"一帧一帧的图片 + 时间戳 + 编码压缩"。要让模型直接产出 mp4，它得输出二进制流或者 base64 编码的庞大数据块，这对 token 输出是灾难——一段 5 秒的视频轻松几十兆，模型根本吐不出来。但如果换成 HTML，模型只需要输出几百行结构化的文本，浏览器拿到之后自己去做渲染循环，每一帧都是实时算出来的。

打个比方：mp4 像是把一整部电影刻成光盘寄给你，而 HTML 动画像是给你一份菜谱加一口锅，你自己现炒。前者传输成本高、改不了，后者传输成本极低、随时能调。模型擅长的是写"菜谱"，不是"刻光盘"。

所以当你看到"Claude Opus 5.5 直出视频"，正确的理解是：它生成了一份能自动播放的动画代码，你在浏览器里打开，看到的就是一段视频效果。这个认知差是后面所有实操的基础。

2.2 CSS 动画与 JS 时间轴的分工

实测下来，一段"视频感"强的 HTML 动画，通常由两层驱动：

• CSS 层负责循环、缓动、渐变、位移、旋转这类"声明式"的持续动画。它的优势是浏览器原生优化，性能好，代码短。比如@keyframes定义一个呼吸效果，一行animation属性就能让它无限循环。
• JS 层负责时间轴控制、状态切换、随机性、交互响应。比如让画面在第 3 秒切换到下一个场景，或者根据鼠标位置改变粒子方向，这些 CSS 做起来别扭，JS 几行就搞定。

两者配合的典型结构是：CSS 定义"每个元素长什么样、怎么动"，JS 定义"什么时候动、动到什么程度"。模型在生成时，往往会先铺一层 CSS 关键帧，再用一个requestAnimationFrame循环或者setTimeout序列来编排节奏。

2.3 一个最小可跑的"视频"骨架

下面这段是我实测时用的最小骨架，你可以直接复制到本地.html文件里打开，能看到一个持续旋转并变色的方块——这就是最朴素的"直出视频"：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>最小动画骨架</title> <style> body { margin: 0; height: 100vh; display: flex; align-items: center; justify-content: center; background: #0b0b12; } .stage { width: 1440px; height: 810px; position: relative; overflow: hidden; } .box { width: 120px; height: 120px; position: absolute; top: 50%; left: 50%; margin: -60px 0 0 -60px; border-radius: 16px; background: linear-gradient(135deg, #6a5cff, #00d4ff); animation: spin 4s linear infinite, hue 6s ease-in-out infinite; } @keyframes spin { to { transform: rotate(360deg); } } @keyframes hue { 0%,100% { filter: hue-rotate(0deg); } 50% { filter: hue-rotate(120deg); } } </style> </head> <body> <div class="stage"><div class="box"></div></div> </body> </html>

注意1440px × 810px这个尺寸——它对应 16:9 的常见视频比例，是热词里反复出现的规格。把舞台固定成这个尺寸，动画看起来才像"视频"而不是"网页特效"。这个细节很多人第一次做会忽略，导致画面比例乱掉。

3. 提示词怎么写：从"鹈鹕骑自行车"看指令设计

3.1 为什么"鹈鹕骑自行车"成了经典测试

热词里反复出现"鹈鹕骑自行车提示词""鹈鹕测试提示词"，这不是偶然。鹈鹕骑自行车是一个同时考验造型能力、物理合理性、动态连贯性的复合任务：鹈鹕有大嘴、有翅膀、有细腿，自行车有轮子、有车架、有踏板，两者还要"骑"在一起并且动起来。模型如果只会画静态图形，这个任务立刻露馅；只有真正理解"结构 + 运动"的模型，才能把它做成一段能看的动画。

所以这个提示词本质上是一个能力探针。你用它测任何模型，都能快速判断对方在"代码生成动画"这件事上的水位。

3.2 提示词的四段式结构

实测下来，能稳定产出高质量动画的提示词，基本都遵循这个结构：

1. 场景与主体：明确画什么、几个元素、什么风格。比如"一只鹈鹕骑着一辆复古自行车，扁平插画风格，配色以橙蓝为主"。
2. 动态描述：说清楚什么在动、怎么动、节奏如何。比如"自行车轮持续旋转，鹈鹕身体随踏板上下起伏，背景云朵缓慢横向漂移"。
3. 技术约束：指定输出格式和尺寸。比如"输出单个 HTML 文件，内联 CSS 和 JS，舞台尺寸 1440×810，无外部依赖"。
4. 质量要求：补充细节期望。比如"动画循环无缝衔接，帧率流畅，不使用任何图片资源，全部用 CSS 或 SVG 绘制"。

这四段缺一不可。我试过只写第一段，模型会给你一张静态图；只写前两段，它可能用外部图片链接，结果你本地打开一片空白；加上技术约束之后，产出的稳定性明显提升。

3.3 一份可直接复用的提示词模板

把上面的结构固化下来，就是这份模板，你可以按需替换方括号里的内容：

请生成一个单文件 HTML 动画，要求如下： - 场景：[描述画面主体与风格] - 动态：[描述各元素的运动方式与节奏] - 技术：单个 HTML 文件，内联 CSS 与 JS，舞台 1440×810，居中显示，深色背景 - 约束：不使用任何外部图片、字体、库；所有图形用 CSS 或内联 SVG 绘制 - 质量：动画无缝循环，运动带缓动，整体观感流畅自然

这份模板我用了十几次，产出合格率大概在八成以上。剩下两成翻车的情况，多半是动态描述太模糊，比如只写"让它动起来"，模型就随便给你加个旋转，效果很敷衍。动态描述越具体，产出越可控，这是提示词工程里最朴素也最有效的规律。

3.4 迭代式追问比一次性长提示更有效

很多人喜欢把提示词写得又臭又长，指望一次到位。实测下来，分步迭代的效果反而更好。第一轮先让它出骨架，跑起来看效果；第二轮针对具体问题追问，比如"轮子转得太快，改成 3 秒一圈""背景太单调，加一层缓慢移动的渐变光晕"；第三轮再打磨细节。

这种方式的优势在于，每一轮你都能看到实际画面，反馈精准，模型也更容易理解你要什么。一次性长提示的问题是你没法预判它理解成了什么样，等看到结果往往已经跑偏很远，改起来反而更费劲。

4. 从提示词到成品的完整实操链路

4.1 环境准备：Claude Code 的接入方式

如果你只是想在网页版里试，直接开对话窗口贴提示词就行。但要做成可复用的工作流，用Claude Code这类命令行工具会顺手很多。它的价值在于：能直接在你的项目目录里生成文件、能读取本地上下文、能连续多轮修改同一个文件，不用来回复制粘贴。

安装和配置的通用思路是：先装好运行时环境，再通过包管理器拉取工具本体，然后用你的账号完成授权。具体命令各平台略有差异，但核心就三步——装环境、装工具、登录。装完之后在项目目录里启动，它就能感知当前文件夹，你让它生成animation.html，它就直接写进目录，浏览器刷新即可预览。

提示：如果你在配置过程中遇到授权相关的报错，先确认账号状态和网络环境是否正常，多数问题出在这一步，而不是工具本身。

4.2 生成、预览、微调的循环

真正高效的节奏是这样的：

1. 在项目目录里让 Claude Code 生成初版 HTML。
2. 浏览器打开，看动画效果。
3. 把不满意的地方用一句话描述清楚，让它改。
4. 重复 2 到 3，直到满意。

这个循环里，"描述清楚"是唯一的难点。别说"不好看"，要说"第三个元素的入场太突兀，加 0.5 秒的淡入和上移"。模型对具体的、可量化的修改指令响应最好，对模糊的审美评价基本无能为力。

4.3 尺寸与性能的取舍

热词里反复出现1440px × 810px，这个尺寸不是随便定的。它是 16:9 比例下比较常见的展示规格，既能保证清晰度，又不会让浏览器渲染压力过大。如果你要做更长的动画或者更复杂的粒子效果，可以考虑降到1280×720，性能会明显更稳。

性能这块有个经验：CSS 动画优先，JS 动画兜底。能用transform和opacity做的动画，尽量别用 JS 逐帧改样式，因为前者走的是 GPU 合成层，后者走主线程，元素一多就卡。模型有时候会图省事全用 JS 写，你看到卡顿就让它"改用 CSS 关键帧实现"，通常立竿见影。

4.4 常见产出问题与对应改法

这张表是我踩坑踩出来的，基本覆盖了九成以上的翻车场景。遇到问题先对照查一遍，比盲目重生成效率高得多。

5. 让动画"像视频"的几个关键技巧

5.1 缓动曲线决定质感

线性运动看起来最"假"，因为现实里没有东西是匀速启动匀速停止的。给动画加上缓动，质感立刻上一个台阶。CSS 里用cubic-bezier或者现成的ease-in-out、ease-out都能明显改善观感。比如一个元素入场，用ease-out会比linear自然得多——快速进入、缓慢停下，符合直觉。

模型默认经常用linear，你可以在提示词里直接要求"所有运动使用缓动，避免线性"。这一句话的收益极高，几乎零成本。

5.2 层次感来自速度差

一段好的动画，画面里的元素不会以同样的速度运动。前景快、背景慢，主体清晰、陪衬模糊，这种速度差和景深差会制造出强烈的空间感。做法很简单：给背景元素设置更长的动画周期，给前景元素设置更短的周期，再配合轻微的透明度和缩放差异。

比如鹈鹕骑车那个场景，云朵用 20 秒漂移一轮，自行车轮用 1 秒转一圈，鹈鹕身体用 0.5 秒起伏一次。三个速度层级叠在一起，画面立刻"活"了。

5.3 循环无缝的秘诀

视频要循环播放，首尾必须衔接。CSS 动画天然支持infinite，但前提是关键帧的首尾状态一致。如果你用 JS 控制时间轴，就要手动把最后一帧的状态设回初始状态。一个稳妥的做法是：所有周期性动画都用 CSS 关键帧，JS 只负责非周期性的场景切换。这样循环的可靠性最高。

5.4 用 CSS 做"涟漪光圈扩散"这类特效

热词里提到"CSS 涟漪光圈扩散"，这是个很实用的效果，做加载动画、点击反馈、氛围渲染都好用。核心思路是用一个圆环元素，通过scale放大配合opacity淡出，形成扩散感：

.ripple { position: absolute; border-radius: 50%; border: 2px solid rgba(120, 180, 255, 0.8); animation: ripple 2s ease-out infinite; } @keyframes ripple { 0% { transform: scale(0.2); opacity: 1; } 100% { transform: scale(2.5); opacity: 0; } }

多个这样的圆环错开延迟启动，就能形成一圈圈扩散的光晕。这个效果纯 CSS 实现，性能好，视觉冲击力强，非常适合放在动画背景里当氛围层。

6. 实测踩坑记录：那些文档不会告诉你的事

6.1 模型会"偷懒"用外部资源

第一次实测时，我让它画一个带纹理的背景，结果它直接写了个background-image: url(...)指向一个不存在的图片。本地打开当然是一片空白。后来我在提示词里加了硬约束"禁止任何外部资源引用"，这个问题才消失。模型倾向于用最省 token 的方式解决问题，引用外部资源就是它的偷懒路径之一，你得主动堵上。

6.2 中文字体渲染的坑

如果动画里有中文文字，不同系统默认字体差异很大，可能导致排版错位。稳妥的做法是显式指定字体栈，比如font-family: "PingFang SC", "Microsoft YaHei", sans-serif，并且给文字容器留足空间，别让它贴边。我吃过一次亏，本地看着好好的，换台机器文字就溢出了。

6.3 时间轴错乱的排查思路

有一次动画跑着跑着突然所有元素挤在一起，排查了半天发现是 JS 里用了多个setTimeout嵌套，延迟累加导致时序错乱。后来改成用一个统一的时间轴变量驱动，问题解决。多个独立计时器是动画错乱的头号元凶，能用单一时间源就别用多个。

6.4 别指望一次生成就完美

这是心态问题。模型生成的是"初稿"，不是"成品"。把它当成一个手很快但审美一般的实习生，你的角色是导演，负责提要求和把关。接受这个定位之后，整个工作流会顺畅很多。我现在的习惯是：第一轮只求跑起来，第二轮调节奏，第三轮抠细节，三轮下来基本能到可用的程度。

7. 这套玩法还能怎么扩展

把"代码即动画"这个思路打开，能做的事情比想象中多。比如做产品演示时，用一段自动播放的 HTML 动画代替录屏，体积小、可交互、随时改；做数据可视化时，用 CSS 动画让图表"生长"出来，比静态图生动得多；做教学材料时，把抽象概念做成循环动画，理解成本直线下降。

再往深了走，可以结合requestAnimationFrame做基于物理的运动，让动画更真实；可以接入鼠标和键盘事件，把"视频"变成"可玩的交互"；甚至可以用 Canvas 做粒子系统，性能上限比纯 DOM 高得多。这些方向模型都能帮你写，关键还是那句话——把需求描述清楚，把约束定死，剩下的交给它迭代。

我个人在实际操作中的体会是，这套工作流最大的价值不是"省了做视频的功夫"，而是"把动态视觉的门槛拉到了会写提示词就能上手"。以前做一段动画得会 AE、会代码、会调参，现在你只要能说清楚想要什么，剩下的模型帮你填。当然，审美和判断力还是你自己的，模型替代不了这部分——它负责实现，你负责决定什么值得实现。