1. 这个标题到底在说什么先拆掉“直出视频”的滤镜先把结论摆在前面所谓“Claude Opus 5.5 直出视频”并不是模型真的吐出了一个 mp4 文件而是它一次性生成了一段能自己动起来的 HTML CSS JavaScript 代码你在浏览器里打开就看到了一段“视频”。这个区别非常关键因为一旦你误以为它真的在做视频编码后面所有的提示词设计、参数调整、效果优化都会跑偏。我最早看到这个说法的时候也愣了一下因为从技术路径上讲当前主流大模型的原生输出模态里视频生成和代码生成是两条完全不同的链路。视频生成走的是扩散模型那一套逐帧去噪、时序一致性、运动建模算力消耗巨大而“直出视频”这个说法本质上是模型把动画逻辑用代码表达了出来——它生成的是“播放视频的播放器”而不是“视频本身”。那为什么大家会觉得震撼因为过去你要做一个网页动画得自己写关键帧、调缓动曲线、算时间轴现在你只需要一段描述模型就把这一整套东西给你写好了。这背后真正被验证的能力是长上下文下的结构化代码生成能力以及对视觉运动规律的隐式理解。它得知道“鹈鹕骑自行车”这个画面里轮子要转、腿要蹬、身体要上下起伏还得让这些动作在时间轴上对齐这已经不是简单的“写个 div”了。所以这篇文章我想聊的不是“哇模型好厉害”而是把这套东西拆开它到底怎么实现的、提示词该怎么写、代码结构长什么样、哪些坑我踩过、怎么让它稳定输出而不是抽卡。适合谁看前端想偷懒做动效的、做 AI 应用想接这类能力的、以及单纯好奇“这玩意儿到底靠不靠谱”的人。哪怕你只会写div看完也能自己复现一个。我下面所有的拆解都基于一个核心判断模型输出的是可运行的网页动画代码而不是视频文件。抓住这一点后面的一切才立得住。2. 为什么是 HTML CSS JS 这条路线2.1 三条技术路线的取舍逻辑要让模型“生成动态画面”理论上至少有三种做法我把它们摆在一起对比一下你就能明白为什么 HTML 这条路胜出。路线实现方式优点致命缺点视频文件生成扩散模型逐帧生成画面真实、细节丰富算力贵、时序易崩、无法交互Canvas / WebGL 绘制JS 逐帧重绘性能强、可控性高代码复杂度高模型容易写错HTML CSS 动画DOM keyframes / transition代码短、可读、浏览器原生支持复杂物理运动表现力有限模型最终大量采用第三条路线原因很实在CSS 动画是声明式的。你告诉它“这个元素从 A 状态变到 B 状态用 2 秒缓动用 ease-in-out”浏览器自己会去算中间帧。模型不需要理解每一帧的像素只需要描述状态变化这大大降低了生成难度也提高了成功率。而 Canvas 那条路模型得自己写requestAnimationFrame循环、自己算坐标、自己处理重绘代码量翻好几倍出错概率也高。我实测过让它用 Canvas 画一个旋转的自行车轮十次里有三次坐标算错轮子会飘出画面。换成 CSS 的transform: rotate()基本一次就对。2.2 CSS 动画的“声明式”优势到底在哪打个比方。Canvas 逐帧绘制就像你拿笔一张一张画连环画每一张都得自己画CSS 动画就像你告诉放映员“这张画从左边滑到右边用两秒”中间的过程他帮你补。模型擅长的是“描述意图”不擅长“精确计算每一帧”所以声明式天然更契合它的能力边界。具体到代码层面一个旋转动画在 CSS 里就三行.wheel { animation: spin 1s linear infinite; } keyframes spin { from { transform: rotate(0deg); } to { transform: rotate(360deg); } }同样的效果用 Canvas你得维护一个角度变量每帧加一点再清屏重绘还要处理设备像素比。代码量差了一个数量级出错面也差了一个数量级。2.3 浏览器渲染管线为什么能扛住这种“伪视频”有人会担心DOM 动画性能不是很差吗这要看场景。如果是几百个元素同时动确实会卡但“鹈鹕骑自行车”这种画面元素数量通常在几十个以内而且大部分是transform和opacity变化——这两个属性恰好是浏览器合成层能直接处理的不触发重排重绘走的是 GPU 加速。我实测过一个 1440×810 的动画场景元素大概 40 个全程稳定 60fpsCPU 占用不到 15%。所以只要提示词里控制好元素规模性能完全不是问题。真正会拖垮性能的是width、top、left这类触发 layout 的属性这个后面讲提示词的时候会重点说。3. 提示词怎么写从“鹈鹕骑自行车”说起3.1 一个合格提示词的四个必备要素“鹈鹕骑自行车”这个测试题在网上很火因为它同时考验了模型的多个能力生物形态、机械结构、运动协调。但如果你只丢一句“画一个鹈鹕骑自行车”出来的结果大概率是静态的或者动得很诡异。我反复试下来一个能稳定出效果的提示词必须包含四块内容。第一块是画面主体与场景谁、在哪、什么风格。第二块是运动描述哪个部位怎么动、动多快、什么节奏。第三块是技术约束用什么技术实现、画布尺寸、性能要求。第四块是输出格式要完整可运行的单文件还是分文件。我常用的模板长这样用单个 HTML 文件实现一个动画场景 画面一只鹈鹕骑着一辆自行车从右向左穿过画面背景是简单的城市剪影。 运动自行车两个轮子持续旋转鹈鹕的双腿做踩踏板的循环动作身体随踩踏轻微上下起伏背景云朵缓慢左移。 技术使用 HTML CSS 动画实现画布 1440x810只用 transform 和 opacity 做动画保证 60fps。 输出完整可运行的单文件代码不要省略任何部分。3.2 为什么必须显式约束“只用 transform 和 opacity”这是我从踩坑里总结出来的。早期我不加这条约束模型很喜欢用left和top来做位移动画代码看起来没问题跑起来也动但一开性能面板就发现帧率掉到 30 以下因为每一帧都在触发重排。加上这条约束后模型会改用transform: translate()性能立刻正常。这背后的原理是浏览器的渲染分层transform和opacity的变化可以在合成层单独处理不需要重新计算布局和绘制。而left、top、width、height会触发完整的 layout → paint → composite 流程。模型本身不懂这个性能差异你不说它就按最直觉的方式写。3.3 运动节奏的描述技巧给“感觉”而不是给“数字”很多人写提示词喜欢给精确数字比如“轮子每秒转 3 圈”。这其实不是最优解因为模型对“每秒 3 圈”的视觉想象和你不一样而且不同元素之间的节奏协调它算不好。更好的做法是给相对关系和感觉。比如我会写“轮子转速与踩踏节奏匹配看起来自然不突兀”“身体起伏幅度要小像真实骑行时的重心变化”。这种描述让模型自己去协调各元素的时间轴出来的效果反而更和谐。我对比过给感觉描述的版本各部件动作的同步性明显好于给死数字的版本。3.4 提示词里必须避开的三个雷区第一个雷区是要求真实物理模拟。你让它“模拟真实的空气阻力和轮胎摩擦力”它会试图写一堆复杂的 JS 物理计算结果往往是画面直接崩掉。CSS 动画擅长的是“看起来对”不是“物理正确”。第二个雷区是元素数量过多。我试过让它画“一群鹈鹕骑着自行车穿过繁忙的街道”结果生成了上百个 DOM 元素浏览器直接卡死。控制在 50 个元素以内是安全线。第三个雷区是模糊的“好看”要求。你说“做得好看一点”模型不知道你指什么可能给你加一堆花哨的渐变和阴影反而破坏了动画的清晰度。要具体比如“配色用低饱和度的蓝灰调背景简洁”。4. 代码结构拆解模型到底生成了什么4.1 整体骨架一个自包含的单文件模型输出的典型结构是一个完整的 HTML 文件从!doctype html开始到/html结束中间包含style和script。我拿一个实际生成的版本给你拆一下骨架。!doctype html html langzh-cn head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 title鹈鹕骑行动画/title style /* 场景容器、元素定位、关键帧动画 */ /style /head body div classscene div classpelican.../div div classbicycle.../div /div script /* 可选的时序控制、交互逻辑 */ /script /body /html注意meta charsetutf-8这一行模型基本每次都会带上这是好事因为中文标题和注释不会乱码。viewport那行也常出现虽然桌面动画用不上但说明模型有移动端适配的意识。4.2 场景容器与坐标系设计模型通常会用一个大容器固定画布尺寸比如.scene { position: relative; width: 1440px; height: 810px; overflow: hidden; background: linear-gradient(#87ceeb, #e0f6ff); }position: relative是关键它让所有子元素可以用absolute相对它定位。overflow: hidden保证超出画面的部分被裁掉比如自行车从右边进来时不会撑出滚动条。这个结构非常标准几乎每次生成都是这个套路。4.3 关键帧动画的组织方式模型组织动画有两种常见方式。一种是每个元素一个独立的keyframes另一种是复用同一个关键帧但用不同的animation-duration和animation-delay来错开。后者更优雅代码更短。比如轮子旋转keyframes spin { from { transform: rotate(0deg); } to { transform: rotate(360deg); } } .wheel-front { animation: spin 0.8s linear infinite; } .wheel-back { animation: spin 0.8s linear infinite; }两个轮子共用spin只是应用在不同元素上。而踩踏动作因为涉及多个关节模型往往会单独写一个更复杂的关键帧用百分比控制不同阶段的姿态。4.4 JS 在这里扮演什么角色纯 CSS 动画其实不需要 JS但模型经常会加一点 JS 来做时序协调或者随机化。比如让云朵的初始位置随机或者让整个动画在页面加载后延迟启动。这部分不是必须的但加上之后画面会更有“活气”。我个人的做法是如果只是展示纯 CSS 就够了代码更干净如果需要交互比如点击暂停、鼠标跟随再让模型加 JS。提示词里明确说“不需要交互”能省掉不少冗余代码。5. 实操全流程从零复现一个动画5.1 环境准备你其实只需要一个浏览器这套东西对环境的依赖低到离谱。你不需要装 Node、不需要构建工具、不需要任何框架。一个现代浏览器加一个文本编辑器就够了。我常用的是 VS Code但其实记事本也能干活。如果你用 VS Code建议装一个 Live Server 插件改完代码保存后浏览器自动刷新调动画的时候特别方便。不装也行手动刷新多按几次 F5 而已。提示文件保存时编码一定要选 UTF-8否则中文注释和标题会变乱码。VS Code 默认就是 UTF-8基本不用管。5.2 第一步把提示词喂给模型打开你常用的对话界面把前面那个四要素模板填好发出去。这里有个小技巧先要结构再要细节。第一轮先让它生成一个能跑的基础版本确认动画逻辑对了再第二轮让它优化配色、加细节。一次性要求太多模型容易顾此失彼。我第一轮通常会说“先生成一个最简可运行版本动画逻辑正确即可不用美化”。拿到能跑的版本后心里就有底了。5.3 第二步保存并在浏览器打开把模型输出的代码完整复制保存为pelican.html双击用浏览器打开。如果画面是动的恭喜你核心链路通了。如果不动先检查两件事一是代码有没有被截断模型有时会省略中间部分二是style标签有没有闭合。我遇到过好几次模型输出到一半停了代码不完整浏览器自然不显示。这时候直接说“继续”或者“输出完整代码”就行。5.4 第三步调参优化动画节奏基础版本能跑之后就是调细节。最常调的是animation-duration它决定动作快慢。轮子转太快会显得鬼畜太慢又像卡住。我的经验值是轮子一圈 0.6 到 1 秒之间比较自然踩踏一个完整循环 1 到 1.5 秒。调的时候直接改 CSS 里的数字保存刷新看效果反复几次就能找到舒服的节奏。这一步没有标准答案全凭眼睛判断。5.5 第四步性能验证按 F12 打开开发者工具切到 Performance 面板录一段几秒的操作看帧率曲线。如果稳定在 60fps 附近说明没问题。如果掉帧八成是用了触发 layout 的属性回去把left/top换成transform: translate()。我还会看一眼 Layers 面板确认动画元素被提升到了合成层。如果没提升可以手动加will-change: transform强制提升但别滥用加多了反而吃内存。6. 常见问题与排查技巧实录6.1 画面完全不动怎么办这是最高频的问题。排查顺序我整理成了一张表按可能性从高到低排。现象可能原因排查方法完全静止代码被截断检查文件末尾是否有/html完全静止关键帧名拼写不一致对比animation和keyframes的名字完全静止animation属性被覆盖检查是否有重复定义动一下就停缺少infinite在 animation 里补上动一下就停animation-fill-mode问题检查是否需要forwards我踩过最坑的一次是模型把keyframes spin写成了keyframes Spin大小写不一致CSS 里关键帧名是区分大小写的结果死活不动找了半天。6.2 动画卡顿掉帧的定位思路先看是不是元素太多。打开 Elements 面板数一下 DOM 节点超过 100 个就要警惕。再看动画属性如果用了box-shadow、filter: blur()这类高开销属性做动画基本必卡。解决办法是把这些静态效果和动画分离动画只动transform和opacity。还有一个隐蔽的坑background-position动画。它看起来只是背景移动但实际会触发重绘元素一多就卡。改用transform: translate()移动一个带背景的子元素性能好很多。6.3 元素位置错乱的修复方法模型算坐标偶尔会出错尤其是嵌套定位的时候。常见表现是某个部件飘到画面外或者和其他部件重叠。修复思路是给每个部件加一个临时边框border: 1px solid red一眼就能看出它的实际占位然后调top/left或transform的值。我一般会先把所有部件的边框都打开整体对齐后再去掉。这个方法土但极其有效比盯着代码猜坐标快十倍。6.4 模型输出不完整或偷懒的应对模型有时候会用/* ... 其他代码 ... */这种注释省略中间部分或者干脆说“由于篇幅限制”。这时候别客气直接说“输出完整代码不要省略任何部分不要用注释代替代码”。多催几次它就会老实输出。如果它反复偷懒可以换个策略让它分块输出先输出 HTML 结构再输出 CSS最后输出 JS你手动拼起来。虽然麻烦点但保证完整。7. 这套玩法的边界与延展7.1 它擅长什么、不擅长什么擅长的是循环动画、简单位移、状态切换这类声明式能表达清楚的效果。比如加载动画、图标动效、场景循环、数据可视化的过渡。这些用 CSS 做又短又稳。不擅长的是复杂物理、真实光影、精细粒子。你让它做流体模拟、布料飘动、光线追踪它会写出一堆看起来很唬人但跑起来一塌糊涂的代码。这类需求还是得回到 Canvas 或 WebGL而且最好用专门的库。7.2 从单场景到多场景切换单个动画玩熟了可以试试让它做多场景切换。比如一个页面里放三个场景用 JS 控制定时切换每个场景有自己的动画。这时候提示词要写清楚“三个独立场景每 5 秒切换一次切换时淡入淡出”。我做过一个版本三个场景分别是白天、黄昏、夜晚的城市自行车一直在骑背景随时间变化。效果挺惊艳的代码也就两百多行。7.3 和实际项目结合的几个方向最直接的用法是做产品演示动画。以前做官网的产品介绍动效得找设计师出图、前端手写现在描述清楚就能出初稿改起来也快。第二个方向是教学演示比如讲物理的简谐运动、讲算法的排序过程用动画比静态图直观得多。第三个方向是快速原型产品经理有个想法直接生成个动画看看感觉比画原型图生动。我个人最看好的还是演示和教学这两个方向因为对“物理正确”要求不高对“看起来对”要求高正好是这套玩法的甜区。7.4 一个我常用的进阶技巧最后分享一个我压箱底的技巧让模型自己迭代。第一版出来后把浏览器里的截图或者你对效果的具体不满描述给它比如“轮子转得太快鹈鹕的腿没跟上背景云朵移动太生硬”让它针对性修改。模型对具体的、带方向的反馈响应很好往往一两轮就能调到满意。比你自己去改 CSS 快多了毕竟它一次能改好几个地方还不会漏。我现在的流程基本是生成 → 看效果 → 提意见 → 再生成来回三四轮一个像样的动画就出来了。这套流程跑顺之后做个小动效的时间从半天压缩到了十几分钟这是我实际用下来最大的收益。