如果你做电商，或者做AI工具相关的工作，"让AI做个产品宣传片"大概是个高频痛点。需求发出去，对方收到一份加了缓动的 PPT。
这个项目（alchaincyf/huashu-motion）走的是另一条路：不调用任何视频生成模型，直接输出一个HTML文件，由你自己的Chrome逐帧渲染。
一句话概括：它把拍片这件事拆成了可判定、可检查、可回滚的工程规则，交给 Agent 执行。作者实测跑完一支 22 秒动效片，账单约 1.95 元。
一、它到底在解决什么问题
一句话需求最容易产出的东西，是加了缓动的 PPT
"给我的产品做个30秒发布片"——把这种需求交给通用大模型，产出的通常是：一张产品图淡入、几行字轮播、背景铺个渐变，加一点缓动，看起来像给 PPT 加了动效。
问题不在于模型不会写字，而在于动效是一门有大量隐性判断的手艺。什么时候该快切，什么时候该停顿，该用滑入还是推近，哪一帧要留白让观众看清单品——这些判断通常藏在人类导演的直觉里。模型没有审美兜底时，几乎必然翻车。
它把导演方法论写进了一个 Skill 包
huashu-motion的选择不是再堆一批提示词模板，而是把方法论沉淀成规则：什么样的节奏算合格，颜色该从哪来，素材能不能占位，什么必须被自动检查拦住。
更关键的是，这些规则能判定对错——它们来自实测（后面会讲：21 支真实发布片逐帧量指标，142 支高互动片拆运动语言），而不是"多写几段形容词显得更专业"。这一点比文案写得好看重要得多。
这篇你能带走的五件事
- 它怎么把"片子"变成代码，以及这条路为什么绕开了视频生成模型；
- 人和 Agent 怎么在同一个预览里来回改片，改动能精确到某一帧的某一个元素；
- 导演规则、素材规则、质量门是怎么被量化下来的；
- 成本量级：单支 22 秒动效片约 1.95 元；
- 哪些部分你可以直接抄进自己的 AI 工作流，哪些必须自己重测。
二、它长什么样：一个 24KB 的 Skill 包
仓库里到底有什么
huashu-motion 是一个标准形态的 Agent Skill 包，核心是 skills/huashu-motion/SKILL.md（24,613 字节），旁边是 bin 目录（命令行工具）和 references 目录（方法论参考资料）。仓库用 JavaScript 编写，MIT 许可，目前有 158 个 fork、3 个开放 issue。
这里有个概念值得先说清楚。所谓 Agent Skill，常见形态就是"一个装着说明书和工具的目录"：Agent 读 SKILL.md 知道什么时候该用这套能力、按什么步骤用，需要动手时再调用 bin 里的命令行。它和传统的 shell 脚本的区别在于，脚本是给人按顺序执行的，Skill 是给模型按需调用的。
所以 huashu-motion 真正的交付物不是那几个 om 命令，而是 SKILL.md 与 references 里那套"怎么剪片子"的判断标准。这跟你装一个 npm 包不同，它更接近"给同事的一份拍片作业手册"。
一行命令装到六种 Agent 宿主
npx skills add alchaincyf/huashu-motion装完之后，它声明支持 Claude Code、Codex、WorkBuddy、Grok Bot、Muse、Dots 这六种宿主。也就是说同一份片子工作流，不绑死在某一个 Agent 产品上。
遵循开放标准这件事，值得单独说一句
这个包遵循 agentskills.io 的开放标准，README 首屏就挂着对应徽章。这条路线的意义在于分发成本几乎为零：不需要用户理解目录结构，不需要装运行时依赖，一条 npx 命令就完事。
对比一下"下个 zip、解压、把 bin 目录加到 PATH"这类传统安装方式，差距不在于省了几步，而在于新用户第一次成功跑起来的概率高得多。对想试用一个陌生项目的人来说，这个概率差别很大。
三、核心机制一：片子是代码，不是视频文件
一个项目等于一个 index.html
huashu-motion 的基本单位是"一个项目 = 一个 index.html"，里面是 HTML 加 GSAP（一个补间动画库）。逐帧渲染由用户自己的 Chrome 完成，不调用任何视频生成模型。
这个选择一上来就绕开了整条生成式视频路线的麻烦：没有采样噪声，没有"同一个 prompt 两次跑出来不一样"，没有私有格式。每个时间点画成什么样，取决于代码，和你的机器、你的 Chrome 版本有关。
片子能带走，还能导出成常见格式
因为底层是 HTML + GSAP，产物可以导出成 MP4、MOV（支持透明通道）、WebM、GIF，或者直接当分享页发出去。
这几种格式的适用场景差别很大：MP4 适合投放和上传平台；MOV 透明通道适合叠在别的画面上；WebM 体积小适合网页嵌入；GIF 适合在聊天窗口里直接发；分享页则是把整个交互片子原样交付给别人。
对一个电商团队来说，这意味着同一份素材可以同时喂给详情页、投放后台、社媒和客服对话，不用为每个渠道重新做一遍。
为什么"没有私有格式"这件事很值钱
生成式视频工具的输出是闭源格式，你改一个字的成本可能是重新跑一遍。代码化的片子是文本，改文案、改颜色、改时长都是改代码，然后重新渲染。
从工程角度看，这意味着片子进了版本控制，可以 diff、可以回滚、可以 review。这跟"一个 mp4 躺在网盘里"的处境完全不同。
代价也要说清楚
浏览器逐帧渲染不是免费的。22 秒 1080p 的片子意味着几千帧要画出来，渲染时间随分辨率和时长线性上升。适合做 15 到 60 秒的产品片，不适合做 10 分钟的长视频。
四、核心机制二：你指着画面改，它只改那一处
这是整个项目最值得学的地方，也是它真正的护城河。
om studio 在本机起一个编辑器服务
om studio 会在 127.0.0.1 上启动一个编辑器服务，你在本机浏览器里就能预览片子。关键动作是：Agent 执行 om inbox –wait 之后会阻塞在那里，等你提意见。
"阻塞"这两个字是整个设计的关键。大部分 Agent 工作流是"生成完就交卷"，你只能事后说"这里不好"，它再重新生成一版，能不能改对靠运气。而阻塞式回路把节奏交回给人。
评论里带着精确信息
人在预览里点一下某个元素，评论会自动携带四样东西：时间点、当前场景、被点中的元素、以及这个元素在源码中的位置。
你不需要写"第三秒那个蓝色按钮太亮了"，你只需要点它说一句"太亮"。技术信息由工具补齐。
Agent 的动作序列
拿到评论之后，Agent 先用 om look 加元素 ID 把那一帧连同局部截图放大看一眼，然后只改那一处，改完用 om done 回一句话，预览会停在原处刷新。
"只改那一处"是硬要求。这避免了 Agent 每次收到反馈就整体重写——那既慢，又容易把原本对的地方改坏。
所有版本都保留，可以撤回
每次修改都是独立版本，可以像设计稿那样 ⌘Z 往回退。对需要来回磨三轮、五轮的片子，这个设计省掉的是"改崩了找不回来"的焦虑。
实际使用时人在回路里的感受，大概接近在一个能点、能评论、能撤回的预览工具里带一个实习生改片——区别是这个实习生无限耐心，而且每次改动的范围都严格受限于你点的那个东西。
五、核心机制三：声音先写谱，再拍片
ABC 记谱法写节奏单
在"作曲家模式"下，Agent 不是随手配一段 BGM，而是先用 ABC 记谱法写一份节奏单。ABC 是文本记谱格式，长得像简化版的乐谱：字母代表音名，数字代表时值，竖线分小节。
节奏单里的标记跟片子的场景一一对齐——哪个场景对应哪一小节，是写死的。
采样乐器演奏，落地帧配音效
节奏单写完后，由三角钢琴、弦乐、鼓组的采样来演奏。画面上每一件事"落地"的那一帧，会配一个对应的音效。
"落地"这个词是关键：音效不是背景音乐，它跟着画面的动作走。按钮按下的那一刻、出场动画落定的那一刻，声音是钉在那里的。
全程本机生成，不调收费接口
合成在你自己机器上跑，不调用任何收费的语音或音乐 API。这意味着没有按量计费、没有排队等待、也没有把你的产品信息发到第三方。
对一个要处理未发布产品素材的团队来说，这条约束在某些场景下比"音质更好"更重要。
声音这条线最容易被低估
大多数 AI 视频尝试在声音上是妥协的：要么用一段通用 BGM 盖过去，要么干脆静音。而 huashu-motion 把声音当成结构的一部分——先有节奏单，再有画面。这两者顺序反过来，成本和效果都很难同时压住。
六、导演规则是实测出来的，不是拍脑袋
这个项目的 references 目录里放着它真正的资产：一套从真实发布片里量出来的导演规则。
21支真实发布片，逐支量指标
作者拿21支真实发布片做样本，包括 Apple、Nothing、GoPro、Google、Vercel、Linear、Anthropic 这些公司的产品片。用 FFmpeg 逐支量了四类指标：切点（画面什么时候切）、节拍、响度、能量曲线。
能量曲线是关键——它描述的是"整支片子的响度和视觉强度随时间怎么起伏"。顶级发布片几乎都有清晰的能量结构：中段有一次爆发，结尾收得住。
142支高互动发布片，拆出20种运动语言
"运动语言"指的是镜头和元素怎么动：滑入、推近、错位、遮罩转场、字块轮替等等。不同产品适合不同的运动语言——一个需要精确对比参数的工具演示，和一个要营造氛围的品牌片，运动语言完全不搭。
作者拆了 142 支高互动发布片，按产品类型整理出 20 种运动语言，每一种都写清了两件事：它在说什么，以及适合什么产品。
颜色是找来的，不是编出来的
颜色这条规则同样有实测支撑：顶级发布片的颜色几乎都是"找来的"——品牌色、产品外壳和界面的实际颜色、实拍画面里的光。所以流程是反过来的：先从产品本身找颜色，而不是先选一套好看的配色再往上贴产品。
配套工具 om swatch 会把色板和对比度摆出来看。对做电商的人这条挺关键——主图和详情页的配色直接关系到转化，而"看起来高级"和"跟产品本身是同一套色"往往是两件冲突的事。
节奏单的三条硬约束
具体到执行层，节奏单有三条不能破的规则：
- 3 秒内必须出现钩子
- 中段要有一次爆发
- 最响的那一下之前，先停一拍
第三条特别值得注意。"先停一拍"是留白，不是省事——观众的注意力需要在重音之前被重新抓住，否则最响的那一下就没有冲击力。
七、工程上最值得抄的硬约束
这个项目里"不许做什么"的清单，比"要做什么"的清单更值钱。下面这几条都是工程约束，不是审美建议。
只允许动 transform，禁止动布局
只允许改 x、y、scale、rotation 四个 transform 属性，禁止动 left、top、width、height。
原因不玄学：改布局会触发布局重排（reflow），在几十秒的片子里逐帧重排会明显掉帧；而 transform 可以走合成层，浏览器基本能保证不重排。om check 会直接拒绝 layout motion。
这一条对做 HTML 可视化、PPT 类输出的人同样适用，是一条能立刻抄走的性能契约。
项目根目录只允许一个composition
一个项目根目录下只允许有一个 composition 的 html 文件，草稿要放到 tools 子目录，否则检查会报"多个根 composition"。
这条约束的目的很单纯：让"这个片子到底是哪一个"永远没有歧义。做自动化流水线时，产物目录的确定性比灵活性重要。
一切都是时间的函数
不许用 Date.now()，不许用无种子的随机数，不许联网。随机要通过 OM.random(seed) 这种带种子的形式，弹簧动画要用闭式纯函数 OM.spring(0.1) 来算，而不是做物理积分。
这条约束换来的是可重现：同一个种子在任何一个时间点渲染出来的结果都一样。你可以在任何时刻暂停、截取某一帧，然后放心地继续跑。
om check和om qa各查什么
om check 会采样出帧，检查三类问题：切出画面（元素跑出安全区）、被遮挡、低对比文字。这三样是发布片最常见也最尴尬的事故。
om qa 查的是动效本身：单帧跳变、死时间（画面静止太久）、循环接缝（首尾衔接不自然）。
一个是"这帧有没有问题"，一个是"这段动顺不顺"，分工清楚。
让"指着改"在像素空间里也成立
用户点到的元素一律挂 data-om-id，这样点击就能反查到具体是哪个元素。canvas 和 WebGL 画出来的东西没法挂属性，就用 OM.region(id, t => [x,y,w,h] | null, label) 注册一个可点区域。
这行的意思是：即使是画在 canvas 上的粒子效果，也能被精确指到并反馈回源码位置。
素材必须是真的
logo 用真文件，不重画；界面在代码里重建，然后跟实拍截图逐帧对照；禁止灰底占位块。
这条是硬红线。占位素材是 AI 生成内容翻车最快的方式——一个看起来是产品截图的灰底方块，出现在投放素材里就是事故。
八、成本一瞥
一支 22 秒片，大约 1.95 元
作者用 DeepSeek V4.1 Flash 跑了一支 22 秒的动效片，经历三轮意见修改，缓存命中率 99.4%，按当时价格折算约 1.95 元。
99.4% 的缓存命中率是这里最值得注意的数字。它意味着 Agent 在改片子时，99% 以上的输入内容是重复的——同一份 SKILL.md、同一份 references、同一份已有的代码。模型只处理真正变化的那一小部分。
另一支片改到第 9 版拿了 91 分
另一支英文版片子改到第 9 版，分数是 91 分。评分由一个独立的评审 agent 按评分标准给出，90 分才算完成。
独立评审这一步的价值在于避免自评偏差。写片子的那个 agent 天然倾向于认为自己做得好，让另一个有明确评分标准的 agent 来打分，是一道有效的质量门。
对成本这件事的一个判断
一支 22 秒的商业级动效片，成本在两块钱以内——这可能比"贵不贵"更值得注意的一点是：它说明自建内容流水线的成本瓶颈，未必在模型档位上，更可能在方法论缺失上。
用贵一倍的模型、堆更长的提示词，未必能替代那套从实测里长出来的规则。
九、电商场景怎么用
最直接的三个用法
第一，做详情页和主图的动效版本。静态主图做完之后，把同样的画面用这套流程做成3到10秒的循环动效，投放到详情页或者信息流里。
第二，做新品发布节奏里的产品片。前面提到的"3秒钩子、中段爆发、最响之前停一拍"这套规则，本来就是按发布片的节奏写的。
第三，把视频号/抖音的封面和短片一次做完。同一个index.html导出 MP4、GIF、分享页三种产物，适配不同渠道。
ROI该怎么算
粗算一笔账：一支 22 秒片成本约 1.95 元，如果一个产品周期做 5 到 10 支，一次性投入在 10 到 20 元这个量级。真正花时间的不是模型调用，是人盯在预览上改片的那几轮。
所以省钱的重点不是压模型价，而是减少返工轮次。om inbox –wait 这套"人在回路里逐条指错"的机制，作用正是在这里——每一轮反馈都精确到单个元素，减少来回。
什么时候你用不上它
说了适用场景，也说说不适用的：
- 只需要一张静态主图或一段简单字幕视频，完整的导演工作流是杀鸡用牛刀；
- 你的片子需要大量真实人物出镜或者实拍素材，这个项目里"界面在代码里重建、逐帧对照实拍截图"的路线会很痛苦；
- 团队没有能盯预览做判断的人。这个项目把品味判断的责任还给了人，如果没人能判断"这里该不该停一拍"，它就退化成一个昂贵的自动生成器。
最后一条最容易被忽略。它不是全自动的，它是"把人类导演的判断成本从拍片转移到指哪改哪"。
十、同一批里还有两个相关项目
huashu-motion 之所以值得说，是因为它不是孤例。同一批被关注的仓库里，还有两个方向不同的项目，恰好补上了"怎么做"和"怎么管"的另一半。
tt-a1i/archify：把一个仓库变成一页纸答案
88,820星、6,004个fork、MIT许可，是一个体量相当大的Agent Skill。安装方式和huashu-motion同源，npx skills add tt-a1i/archify -g。
它做的事是：输入一句话或者一个仓库，输出一个可交互的 HTML 图。支持十种图型，包括 Architecture、Workflow、Sequence、Data Flow、Lifecycle、ERD、Class、Tree、Timeline、Waterfall。
其中最值得学的是"一页纸答案"的版式：结论先行，每块面板只回答一个问题，结论后面挂编号来源，仓库摘录还会锁定到具体的 commit。
"锁定到 commit"这件事解决的是一个具体的痛点——你把一份分析报告贴给同事，同事点进去发现仓库已经变了，证据链断掉。锁定 commit 等于给结论钉了一个时间戳。
它还有一条fail-closed的可选profile：部署归属这类判断如果缺少作者、区域、私有库范围等信息，它宁可失败也不隐式推断。宁可报错也不猜，这和自动修复链路里"没有证据就不声称修好了"是同一个价值观。
CLI是零依赖的，输出带 –json 机器可读，方便被巡检脚本消费。产物是自包含 HTML，社区已经把它改成上海 CityWalk 行程、飞书钉钉讨论用的架构图。
体积是个问题：单仓 917MB 级别的资产，依赖生态也多。
Charonyuu/whatsmyagentdoing：把 agent 会话画成一座办公室
想法很讨喜：把你本机所有 agent 的会话渲染成一座等距 2D 或 3D 办公室。
干活的 agent 坐在工位上思考、敲字、跑工具；需要你批准的时候站起来挥手；刚收工的 agent 会去茶水间接水、躺沙发、玩街机、打乒乓。窗户的光跟着本地时间走，2D 版还有一只猫。
状态机是明确的：Thinking、Running（会显示具体是哪个工具调用）、Writing reply、Waiting for you、Done、Interrupted、Error、Idle。
技术上的关键选择是：零 hook、零配置、零 API key。它直接读 Claude Code 的 ~/.claude/projects 目录下的 jsonl，以及 Codex 的 ~/.codex/sessions 目录下的 rollout 文件。
"能读日志就不加 hook"——这是一条最低成本的观测路径，比往主流程里插钩子干净得多。
列表视图按"需要你 → 工作中 → 已完成"三段分组，带当前回合实时计时器、一键复制 resume 命令、浏览器通知，可以按 Claude / Codex / subagent 过滤。支持 9 种界面语言。3D 场景包按需下载，每个 100 到 160KB，装之前按固定的 SHA-256 校验。–private 模式只显示状态不显示提示词，适合投屏演示。
局限也很清楚：它依赖 Claude Code / Codex / Gemini CLI 的会话日志格式，主 Agent 是 OpenClaw 的话路径并不一样。
一个更大的信号
把这几个项目放在一起看，方向很一致：Agent Skill 化已经不是新话题了。这些项目都遵循 agentskills.io 开放标准、都用 npx skills add 分发、README 首屏都挂徽章。
更值得注意的是第二层变化——Skill 里的方法论，正在取代 Skill 里的脚本。huashu-motion 的 bin 是 CLI，但真正值钱的是 references 里的导演规则。
还有两条反复出现的硬红线：真实素材与真实来源。一个项目反复强调禁止占位、禁止假 UI、禁止占位图；另一个反复强调 commit 级证据锚定、引用编号来源。
而在 Agent 观测这一侧，"看得见、管得住、记得住"三条线在并行推进：多 agent 编排、本机状态可视化、本地优先的记忆系统，各自都有高星项目在跑。
十一、可以直接抄走的三条
如果只带走三样东西，建议是这三条。它们不需要安装任何东西，读一遍就能用。
一、导演规则优于提示词模板
任何生成类Skill，都应该沉淀"结构、节奏、材质、品牌色来源"这几类可判定的规则，而不是堆形容词。
区别在于可判定与否。"画面要有高级感"不可判定，"3 秒内出现钩子、中段有一次爆发、最响之前先停一拍"可判定。规则一旦可判定，就能写成检查项，能进 CI，能在人工复核之前先拦一道。
给规则标注来源的实测样本量同样重要——21 支片量出来的规则和 2 支片拍出来的规则，读者自己会判断要不要信。
二、真实素材优先，加上独立评审闸门
生成物禁止占位内容：logo用真文件，界面在代码里重建并与实拍截图逐帧对照，灰底占位块直接判不合格。
发布前再加一道独立评审闸门：由另一个agent按明确的评分标准打分，90分才算完成。这一条能挡住"生成agent觉得自己做得挺好"这个最常见的漏洞。
三、零侵入观测
能读日志就不加hook，能读文件就不加配置。观测链路优先选最小侵入的实现——日志里通常已经有你要的信息，装一个hook反而会改变被观测系统的行为。
十三、写在最后
huashu-motion把一件通常被含糊处理的事写清楚了：做一支产品片，难的不是生成，是判断。什么时候切、什么时候停、用什么颜色、素材是不是真的——这些判断被量化成规则之后，才有可能交给一个没有人类审美兜底的 Agent 去执行。
这条路要跑起来不轻松：Node 22、Chrome、FFmpeg、55MB 采样包，macOS 上实测过，Codex 沙箱里还得手动放行本地预览和浏览器。
但如果只是想理解"AI 怎么做商业级动效"，或者想把里面那套规则用在自己项目上，读一遍 SKILL.md 和 references 就够了。这部分是完全公开的。