企业官网建设流程全解析

1. 这个标题到底在说什么：先拆掉“直出视频”的滤镜

先把结论摆在前面：所谓“Claude Opus 5.5 直出视频”，并不是模型真的吐出了一个 mp4 文件，而是它一次性生成了一段能自己动起来的 HTML + CSS + JavaScript 代码，你在浏览器里打开，就看到了一段“视频”。这个区别非常关键，因为一旦你误以为它真的在做视频编码，后面所有的提示词设计、参数调整、效果优化都会跑偏。

我最早看到这个说法的时候也愣了一下，因为从技术路径上讲，当前主流大模型的原生输出模态里，视频生成和代码生成是两条完全不同的链路。视频生成走的是扩散模型那一套，逐帧去噪、时序一致性、运动建模，算力消耗巨大；而“直出视频”这个说法，本质上是模型把动画逻辑用代码表达了出来——它生成的是“播放视频的播放器”，而不是“视频本身”。

那为什么大家会觉得震撼？因为过去你要做一个网页动画，得自己写关键帧、调缓动曲线、算时间轴，现在你只需要一段描述，模型就把这一整套东西给你写好了。这背后真正被验证的能力，是长上下文下的结构化代码生成能力，以及对视觉运动规律的隐式理解。它得知道“鹈鹕骑自行车”这个画面里，轮子要转、腿要蹬、身体要上下起伏，还得让这些动作在时间轴上对齐，这已经不是简单的“写个 div”了。

所以这篇文章我想聊的，不是“哇模型好厉害”，而是把这套东西拆开：它到底怎么实现的、提示词该怎么写、代码结构长什么样、哪些坑我踩过、怎么让它稳定输出而不是抽卡。适合谁看？前端想偷懒做动效的、做 AI 应用想接这类能力的、以及单纯好奇“这玩意儿到底靠不靠谱”的人。哪怕你只会写<div>，看完也能自己复现一个。

我下面所有的拆解，都基于一个核心判断：模型输出的是可运行的网页动画代码，而不是视频文件。抓住这一点，后面的一切才立得住。

2. 为什么是 HTML + CSS + JS 这条路线

2.1 三条技术路线的取舍逻辑

要让模型“生成动态画面”，理论上至少有三种做法，我把它们摆在一起对比一下，你就能明白为什么 HTML 这条路胜出。

模型最终大量采用第三条路线，原因很实在：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 个，全程稳定 60fps，CPU 占用不到 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 lang="zh-cn"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>鹈鹕骑行动画</title> <style> /* 场景容器、元素定位、关键帧动画 */ </style> </head> <body> <div class="scene"> <div class="pelican">...</div> <div class="bicycle">...</div> </div> <script> /* 可选的时序控制、交互逻辑 */ </script> </body> </html>

注意<meta charset="utf-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 画面完全不动怎么办

这是最高频的问题。排查顺序我整理成了一张表，按可能性从高到低排。

我踩过最坑的一次是模型把@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 快多了，毕竟它一次能改好几个地方，还不会漏。我现在的流程基本是：生成 → 看效果 → 提意见 → 再生成，来回三四轮，一个像样的动画就出来了。这套流程跑顺之后，做个小动效的时间从半天压缩到了十几分钟，这是我实际用下来最大的收益。