关于 Personal Agent 的几点想法：它靠什么认识你
2026/10/6 11:03:36
1. 当大模型开始"画"视频：一个被误读的能力边界
第一次看到"Claude Opus 5.5 直出视频"这个说法，我本能地皱眉。作为一个长期跟踪大模型能力边界的人，我太清楚当前主流大语言模型的输出形态了——文本、代码、结构化数据，最多加上图像理解。视频？那是扩散模型和视频生成模型的活儿，跟一个以推理见长的语言模型有什么关系？
但把标题里的关键词拆开看，事情就清楚了：HTML、CSS、提示词、Claude Code。这几个词凑在一起，指向的其实是一个被很多人忽略的事实——所谓"直出视频"，本质上是模型用 HTML + CSS + JavaScript 生成了一段可交互的动画，而不是真正意义上的视频文件。它没有编码成 MP4，没有帧序列，没有音频轨道，它输出的是一段能在浏览器里跑起来的代码，而这段代码"看起来像视频"。
这个区别非常关键。如果你以为 Claude Opus 5.5 能像 Sora 那样根据一句话生成一段真实拍摄风格的视频，那你一定会失望。但如果你理解它输出的是基于 Web 技术的动态视觉内容，那你会发现这个能力其实相当实用：做产品演示、做加载动画、做数据可视化、做教学演示、做网页小游戏，全都能用上。
我写这篇东西的目的很直接：把"直出视频"这个噱头背后的真实技术路径讲清楚，把提示词怎么写、代码怎么调、坑在哪里，一次性说明白。适合两类人看——一类是被标题吸引想搞清楚到底怎么回事的技术爱好者，另一类是手里有 Claude Code 或者类似工具、想真正把它用起来的开发者。不需要你是前端高手，但至少得知道<div>和<style>是干嘛的。
先说结论：Claude Opus 5.5 生成的"视频"，是一段自包含的 HTML 文件，通过 CSS 动画和 JavaScript 时间轴驱动视觉元素运动，最终在浏览器里呈现出类似视频的连续画面效果。它的优势是体积小、可交互、可参数化；劣势是无法生成真实影像、无法处理复杂光影、性能受浏览器渲染能力限制。理解了这个定位，后面的所有操作才有意义。
2. 拆解"直出视频"的真实技术链路
2.1 从提示词到可播放画面，中间到底发生了什么
很多人以为流程是"输入提示词 → 输出视频"，实际上中间隔了好几层。我把真实链路拆给你看：
第一层，语义解析。模型先理解你的提示词描述的是什么场景——是"一个球从左上角弹到右下角"，还是"文字逐字浮现然后淡出"，还是"粒子汇聚成 Logo"。这一层决定了后续生成什么元素、什么运动轨迹。
第二层，结构规划。模型会在内部决定用哪些 HTML 元素承载视觉内容。通常是一个容器<div>作为舞台，内部放若干子元素作为"演员"。舞台尺寸、定位方式（absolute 还是 flex）、层级关系（z-index）都在这一层确定。
第三层，样式与动画生成。这是核心。模型会写 CSS，用@keyframes定义关键帧动画，用transition定义状态过渡，用transform做位移旋转缩放，用opacity做淡入淡出。如果是复杂时间轴，还会生成 JavaScript 用requestAnimationFrame或setTimeout来编排多个元素的出场顺序。
第四层，自包含封装。最终输出一个完整的 HTML 文件，CSS 通常内联在<style>标签里，JS 内联在<script>标签里，不依赖外部资源。这样你双击就能打开，不需要搭服务器。
提示：如果你拿到的代码引用了外部 CDN 资源（比如某个动画库），那它就不是完全自包含的，离线环境下会失效。生成后第一件事就是检查有没有外部依赖。
2.2 为什么是 HTML + CSS，而不是 Canvas 或 WebGL
这是个值得说清楚的选择问题。模型生成动态视觉内容，理论上有多条路：纯 CSS 动画、Canvas 2D 绘制、WebGL 渲染、SVG 动画。Claude Opus 5.5 在大多数场景下会优先选CSS 动画 + DOM 元素，原因有几个。
一是可读性和可修改性。CSS 动画的代码结构清晰，你一眼能看出哪个元素在动、怎么动、动多久。Canvas 的绘制逻辑是命令式的，一堆ctx.fillRect()调用，改起来费劲。对于"生成后还要微调"的场景，CSS 方案友好太多。
二是渲染性能的确定性。CSS 的transform和opacity动画会被浏览器放到合成层处理，走 GPU 加速，不触发重排重绘，性能稳定。Canvas 需要你自己管理重绘节奏，写不好就掉帧。
三是模型自身的训练分布。互联网上 CSS 动画的代码量远大于精心优化的 Canvas 动画代码，模型在这方面的"手感"更好，生成的代码更符合直觉、更少出 bug。
但 CSS 方案也有明显短板。当元素数量超过几百个、或者需要复杂的光照和粒子效果时，DOM 节点开销会拖垮性能。这时候模型可能会切换到 Canvas。我的经验是：简单运动、少量元素、强调可读性，用 CSS；大量粒子、复杂物理、强调性能，用 Canvas。你在提示词里可以主动指定，比如"用 Canvas 实现粒子效果"，模型会照做。
2.3 一个典型输出的代码骨架长什么样
为了让你有直观感受，我把模型生成"视频"时最常见的代码结构抽象出来。它通常长这样：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>动画演示</title> <style> /* 舞台容器 */ .stage { width: 1440px; height: 810px; position: relative; overflow: hidden; background: #0a0a0a; } /* 演员元素 */ .actor { position: absolute; animation: move 3s ease-in-out infinite; } /* 关键帧 */ @keyframes move { 0% { transform: translate(0, 0); opacity: 0; } 50% { opacity: 1; } 100% { transform: translate(800px, 400px); opacity: 0; } } </style> </head> <body> <div class="stage"> <div class="actor"></div> </div> </body> </html>这个骨架里，.stage是固定尺寸的舞台，.actor是运动元素，@keyframes定义了它的运动轨迹。真实生成的内容会复杂得多——多个元素、多条时间轴、缓动函数、颜色渐变、阴影、滤镜。但万变不离其宗，你理解了这套结构，就能读懂和修改任何输出。
注意1440px × 810px这个尺寸，它对应 16:9 比例，是视频和演示场景的通用规格。如果你要竖屏内容，改成810px × 1440px即可。这个细节在提示词里最好明确写出来，否则模型可能给你一个自适应尺寸的容器，导出时不好控制。
3. 提示词怎么写，才能让模型"拍"出你要的画面
3.1 描述运动，而不是描述静态画面
这是最容易踩的坑。很多人写提示词的习惯是描述一个静态场景："一个蓝色圆球在白色背景上"。模型拿到这种描述，可能给你一个静止的圆球，因为它没被告知要动。
正确的做法是把时间维度写进去。你要描述的是"什么元素，在什么时间，从什么状态，变成什么状态"。比如：
- 差："一个蓝色圆球"
- 好："一个蓝色圆球从画面左上角出发，沿抛物线轨迹运动到右下角，过程中颜色从蓝色渐变为紫色，落地时产生一圈涟漪扩散效果，整个动画循环播放，单次时长 3 秒"
第二种描述里包含了起点、终点、轨迹、颜色变化、附加效果、循环方式、时长七个要素。模型拿到这些信息，生成的代码基本能一次到位。
我总结了一个提示词模板，实测下来命中率很高：
生成一个 [尺寸] 的 HTML 动画，包含 [元素数量] 个 [元素类型]，运动方式为 [轨迹描述]，配色为 [色值或色系]，单次动画时长 [X] 秒，[循环/单次] 播放，使用 [CSS/Canvas] 实现，代码自包含无外部依赖。
这个模板把关键参数都框住了，模型不需要猜，输出稳定性大幅提升。
3.2 用"分镜"思维组织复杂动画
当你要的动画包含多个阶段时，平铺直叙的描述会让模型抓不住重点。这时候要用分镜的方式，把动画拆成几个时间段，每段描述清楚。
举个例子，你要做一个"文字逐字浮现，然后整体放大，最后粒子散开"的开场动画。提示词可以这样写：
生成一个 1440x810 的 HTML 开场动画，分三个阶段： 第一阶段（0-2秒）：标题文字"HELLO"逐字从下方滑入，每个字间隔 0.15 秒，带轻微回弹缓动； 第二阶段（2-3秒）：整行文字从中心放大 1.5 倍，同时背景从深蓝渐变为紫色； 第三阶段（3-5秒）：文字炸裂成 50 个粒子向四周飞散，粒子逐渐透明消失。 使用 CSS 动画实现，代码自包含。这种写法把时间轴、元素行为、缓动方式、颜色变化全部交代清楚，模型生成的代码结构会非常清晰，每个阶段对应一组@keyframes，改起来也方便。
3.3 那些让效果"高级"起来的细节词
同样的运动，加不加细节词，观感差距巨大。以下这些词我在实践中发现特别管用，建议收藏：
| 细节维度 | 关键词 | 效果 |
|---|---|---|
| 缓动 | ease-in-out、cubic-bezier、回弹 | 运动更自然，不生硬 |
| 层次 | 视差、景深、前后景分离 | 画面有立体感 |
| 光影 | 发光、阴影、渐变、辉光 | 元素有质感 |
| 节奏 | 错峰、延迟、依次、波浪 | 多元素不呆板 |
| 质感 | 毛玻璃、噪点、扫描线 | 有设计感 |
比如"粒子散开"和"粒子带辉光、错峰散开、带轻微回弹"，后者生成的效果明显更耐看。这些词本质上是给模型的"风格锚点"，让它知道你要的是精致效果而不是粗糙 demo。
注意：细节词不要堆太多。一次加三到四个就够了，堆太多模型会顾此失彼，反而生成逻辑混乱的代码。我试过一次塞了十几个效果词，结果模型把动画时间轴写崩了，元素全挤在一起。
3.4 尺寸、帧率与性能的取舍
提示词里要不要写帧率？答案是：CSS 动画不需要写帧率，Canvas 动画需要。
CSS 动画由浏览器合成器驱动，帧率自动跟随显示器刷新率，通常是 60fps，你写不写都一样。但 Canvas 动画需要你自己控制重绘节奏，这时候要明确告诉模型目标帧率，比如"使用 requestAnimationFrame 驱动，目标 60fps"。
尺寸方面，1440×810是通用选择，但如果你要做移动端展示，改成390×844（iPhone 尺寸）更合适。尺寸越大，浏览器渲染压力越大，尤其是元素多的时候。我的经验是：元素数量在 50 个以内，1440×810 无压力；超过 200 个，建议降到 960×540 或者改用 Canvas。
还有一个隐藏参数是will-change。这个 CSS 属性告诉浏览器"这个元素要动，提前优化"。模型有时候会加，有时候不加。如果你发现动画卡顿，手动给运动元素加上will-change: transform, opacity;往往能明显改善。
4. 拿到代码之后：调试、修改与导出
4.1 先跑起来，再谈优化
模型生成的代码，第一件事是在浏览器里打开看效果。别急着读代码，先看它动起来是什么样。因为很多时候模型生成的代码逻辑是对的，但视觉呈现和你想的不一样——可能是颜色不对，可能是节奏太快，可能是元素位置偏了。
打开方式很简单：把代码保存成.html文件，双击用浏览器打开。如果模型输出的是代码块，直接复制到编辑器里保存即可。推荐用 VS Code，装个 Live Server 插件，改完保存自动刷新，调试效率高很多。
第一次打开时重点看三件事：动画是否正常播放、元素是否都在可视区域内、有没有明显的卡顿或闪烁。这三件事决定了这段代码能不能用。
4.2 定位问题的排查链路
如果效果不对，按这个顺序排查，基本能覆盖 90% 的问题：
第一步，看控制台报错。按 F12 打开开发者工具，切到 Console 面板。如果代码里有 JS 错误，这里会红字提示。常见错误是变量未定义、函数名拼错、DOM 元素还没加载就操作了。
第二步，检查元素是否存在。切到 Elements 面板，看 DOM 结构里有没有你期望的元素。如果元素压根没生成，那是 HTML 结构的问题；如果元素在但看不见，那是 CSS 的问题（可能是display: none、opacity: 0、或者被其他元素盖住了）。
第三步，检查动画是否绑定。选中运动元素，在 Styles 面板看animation属性有没有生效。如果animation-name是空的，说明@keyframes名字对不上，或者选择器写错了。
第四步，检查时间轴。如果动画播了一次就停，看animation-iteration-count是不是1，改成infinite就循环了。如果动画根本不开始，看animation-delay是不是设了个很大的值。
第五步，检查性能。切到 Performance 面板录一段，看帧率曲线。如果掉到 30fps 以下，说明元素太多或者动画属性触发了重排。把width、height、top、left这类属性换成transform和opacity，性能会好很多。
我把常见问题和对应原因整理成表，方便对照：
| 现象 | 最可能的原因 | 处理方式 |
|---|---|---|
| 元素不显示 | opacity 为 0 或 display none | 检查初始状态样式 |
| 动画不播放 | keyframes 名称不匹配 | 核对 animation-name |
| 动画只播一次 | iteration-count 为 1 | 改为 infinite |
| 画面卡顿 | 动画属性触发重排 | 改用 transform/opacity |
| 元素位置偏移 | 定位基准不对 | 检查父元素 position |
| 颜色不对 | 色值格式错误 | 统一用十六进制或 rgb |
4.3 手动微调的三个高频操作
模型生成的代码，八成需要微调。以下三个操作我用得最多：
调速度。找到animation简写里的时间值，比如3s，改大改小即可。如果动画分多个阶段，每个阶段的@keyframes里都有时间百分比，改百分比能调整各阶段的占比。
调颜色。全局搜索色值，批量替换。如果模型用了 CSS 变量（--primary-color这种），改一处就全变了，非常方便。这也是我建议在提示词里要求"使用 CSS 变量管理配色"的原因。
调元素数量。如果粒子太少不够震撼，找到生成元素的 JS 循环，把循环次数从 50 改成 200。但要注意性能，数量翻四倍，渲染压力也翻四倍。
提示：改代码前先备份一份原始版本。模型生成的代码有时候改着改着就崩了，有备份能随时回退。
4.4 从 HTML 动画到"视频文件"的转换
如果你真的需要一个 MP4 文件（比如要发到不支持 HTML 的平台），有两条路。
第一条是录屏。用系统自带的录屏工具或者 OBS，把浏览器全屏播放的动画录下来。优点是简单直接，缺点是画质受录屏参数影响，而且录的时候要控制好起止时间。
第二条是用工具把 HTML 渲染成视频。比如用 Puppeteer 控制无头浏览器逐帧截图，再用 FFmpeg 合成视频。这条路画质可控、帧率精确，但需要写脚本。核心思路是：启动浏览器加载页面，按固定间隔截图，把截图序列喂给 FFmpeg。
# 截图序列合成视频的 FFmpeg 命令示例 ffmpeg -framerate 60 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p output.mp4-framerate 60表示每秒 60 帧，frame_%04d.png是截图命名格式，output.mp4是输出文件。截图时要注意，动画的每一帧都要对应一个截图，间隔要均匀，否则合成出来会忽快忽慢。
5. 这套能力真正能落地的几个场景
5.1 产品演示与数据可视化
这是我认为最实用的场景。你有一个数据看板，想让数字动起来、图表长出来、指标卡片依次浮现，用这套方案几分钟就能搞定。相比找设计师做动效、或者用专业工具导出视频，直接生成 HTML 动画的成本几乎为零，而且改数据、改配色都是改几行代码的事。
我做过一个销售数据的演示页，提示词里写清楚"三个指标卡片从下方依次滑入，数字从 0 滚动到目标值，柱状图的柱子从底部生长"，模型一次就生成了可用的代码。后续客户要改数据，我直接改 HTML 里的数字，动画逻辑完全不用动。
5.2 教学演示与概念可视化
讲算法、讲物理、讲数学，静态图讲不清楚，视频又不好做。用 HTML 动画可以精确控制每一个步骤的呈现。比如讲排序算法，让柱子一根根交换位置；讲抛物线，让小球沿轨迹运动并留下残影。这种"可交互、可暂停、可回放"的演示，教学效果比视频好得多。
5.3 网页小游戏与交互原型
热词里出现了"植物大战僵尸 HTML 完整代码"和"鹈鹕骑自行车提示词"，这其实反映了同一个需求：用 HTML + CSS + JS 快速搭一个能玩的小东西。模型生成游戏原型的效率很高，虽然不能直接商用，但用来验证玩法、做交互 demo 完全够用。
"鹈鹕骑自行车"这个提示词在圈子里流传很广，本质上是测试模型对复杂组合场景的理解能力——一只鸟、一辆车、鸟在车上、车在动、鸟跟着动。能把这个生成好的模型，说明它对元素层级和运动传递的理解到位了。
5.4 加载动画与品牌动效
网站加载时的等待动画、Logo 的入场动效、按钮的悬停反馈，这些都可以用生成的 HTML 动画来做。热词里的"数字加载动画效果 CSS"和"CSS 涟漪光圈扩散"就是典型需求。这类动画通常元素少、逻辑简单，模型生成的成功率极高，基本一次到位。
6. 我踩过的坑和总结出的经验
6.1 模型会"偷懒"，复杂动画要拆开要
这是我最深刻的体会。当你要求一个包含十几个元素的复杂动画时，模型有时候会简化处理——该有的元素少了几个，该有的缓动变成了线性，该有的层次变成了平铺。它不是不会，而是在长输出里倾向于"差不多就行"。
应对方法是拆开要。先让它生成基础结构和主要元素，确认没问题后，再追加提示词让它补充细节。比如先要"三个卡片滑入"，再要"给卡片加阴影和圆角"，再要"数字滚动效果"。分步走，每一步都验证，最终质量比一次性要高出很多。
6.2 颜色和字体是最容易翻车的地方
模型对颜色的理解有时候很迷。你说"科技感蓝色"，它可能给你一个饱和度极高的纯蓝，刺眼得很。你说"优雅的衬线字体"，它可能给你一个系统默认的宋体，毫无设计感。
我的做法是直接给具体值。颜色给十六进制，比如#1a73e8；字体给具体名称，比如"Helvetica Neue", Arial, sans-serif。不要指望模型理解抽象的美学描述，给它确定的东西，它才能给你确定的结果。
6.3 循环动画的首尾衔接要特别检查
循环播放的动画，如果首尾状态不一致，会出现明显的"跳帧"——动画播完一遍回到开头时，画面会突然闪一下。这是因为0%和100%的关键帧状态不匹配。
解决办法是确保0%和100%的属性值完全一致。比如元素从translate(0,0)运动到translate(800px,0)，如果要循环，得让它再回到translate(0,0)，或者用alternate方向让它来回运动。这个细节模型经常忽略，需要手动检查。
6.4 别指望一次生成就完美
我见过太多人拿到生成的代码，发现效果不对就放弃了，觉得"这模型不行"。其实问题往往出在提示词和预期上。模型生成的是初稿，不是成品。初稿的价值在于它把 80% 的重复劳动做完了，你只需要花 20% 的精力去调整那 20% 的细节。
调整的过程本身也是学习。你看模型怎么组织@keyframes、怎么用transform组合运动、怎么用 CSS 变量管理配色，看多了自己就会写了。这才是这套工具最大的价值——它不只是帮你干活，还在教你干活。
6.5 保存好你的提示词模板
每次调出一个满意的效果，把对应的提示词存下来。下次遇到类似需求，改几个参数就能复用。我现在的提示词库里存了二十多个模板，覆盖开场动画、加载动画、数据可视化、粒子效果等常见场景，效率比每次从零写高太多了。
提示词模板的维护有个小技巧：在模板里用占位符标记可变部分，比如[尺寸]、[主色]、[时长]，用的时候替换即可。这样模板的通用性最强，不会因为某个具体值写死了而没法复用。
说到底，Claude Opus 5.5 的"直出视频"能力，本质上是把前端动画开发的门槛降到了"会写提示词"的程度。它不能替代专业的视频制作，但在快速原型、教学演示、网页动效这些场景里，它带来的效率提升是实打实的。工具就在那里，用得好不好，取决于你愿不愿意花时间理解它的脾气。