huashu-motion：让编程 Agent 用代码制作可编辑的产品宣传片
来源：花叔 Huashu 的 huashu-motion 仓库，作者为花叔（
alchaincyf）。本文按仓库main分支在 2026 年 10 月 19 日的内容整理，重点阅读了 README、skills/huashu-motion/SKILL.md、方法文档、CLI 包信息和许可证。项目功能与效果介绍属于仓库作者的自述；本文不把展示样片、性能数字或模型体验当作独立基准测试。
图：仓库 README 中的交互演示。评论会带上时间、场景、被点选的对象和对应源码位置，供 Agent 定位修改。素材来源：huashu-motion README。
核心思路：把视频变成可检查、可修改的代码
huashu-motion 是一个面向编程 Agent 的 Agent Skill 与本地 CLI 项目，目标是用代码制作产品发布片、动效短片和解说视频。它不把视频交给生成式视频模型逐段生成，而是让 Agent 写一份浏览器可运行的 HTML 组合：动画由 GSAP、Canvas、Three.js、SVG 等网页技术绘制，每个时间点的画面都由代码和时间决定。
制作完成后，用户可以在本机浏览器里的 Studio 预览。对某一帧有意见时，直接在画面上点选、写评论；评论会进入本地收件箱，包含时间点、场景、被选对象及其源码位置。Agent 查看对应帧和局部放大图，再修改那个位置。标题、数字、颜色和停留时长等内容可以作为组合变量，直接在 Studio 里改。
所以它的重点不是“让 Agent 一次生成视频”，而是建立一条有中间稿、有视觉反馈、有代码编辑记录的制作循环：
研究产品 → 选导演方向 → 写节奏稿 → 制作 HTML 动画
↑ ↓
用户在画面评论 ← Studio 预览 ← 检查、配乐与渲染
一支片子是怎样做出来的
项目的 SKILL.md 把制作拆成多个阶段。它既规定了 Agent 如何工作，也要求 Agent 在最终交付前看真实画面，而不是只靠代码通过检查。
1. 先研究产品，再选表达方式
开始制作前，Skill 要求 Agent 阅读产品网站、界面、品牌和数据，理解影片需要传达的重点；然后参考用户偏好、此前项目经验和项目内的运动语言资料，确定影片结构与视觉方向。
对于没有指定风格的新项目，通常要先给出三个真正不同的方向，并各自制作关键帧卡片。方向需要在运动语言或材质上有所区别，不只是换一组颜色。颜色也要有来源，例如产品界面、品牌色或产品实体，而不是所有方案都套用同一种深底加亮色的外观。
方向确定后再写 treatment.md，列出演示节奏、时间点、关键画面和前后镜头的连续关系。项目把这一步作为开工前的中间工件，减少把完整成片一次性交给模型猜的风险。
2. 先打磨最重要的镜头
Skill 建议先做最关键的一镜，检查它在完整分辨率下是否成立，再补齐全片。每一镜都应有清晰的表达动作，例如聚合、拆分、对齐、连接或揭示；动画不是单纯给页面加装饰，而应该帮助观众理解产品或信息的变化。
对于运动密集的片子，项目建议先确定节奏路线和能量变化：开头尽早出现吸引点，中间有一次明显加速或爆发，最重要的落点前留出停顿。README 提到这些节奏规则来自作者对发布片的观察和整理。它们是项目的方法论，不是适用于所有题材的剪辑定律。
3. 用时间线与变量保留可编辑性
每个项目通常以根目录的 index.html 作为组合文件。Skill 建议将标题、关键数字、颜色、数据和停留时间定义成组合变量；画面里的关键对象用稳定 ID 标记；场景切换作为时间线标签。这样，Studio 才能把变量做成表单，也能把用户评论对应到画面对象。
动画需要能按任意时间点重新绘制，因此 Skill 要求动画状态由时间决定，避免依赖不稳定的实时时钟或未固定种子的随机值。对 Canvas 或 WebGL 场景，项目提供了注册区域的接口，让用户仍可在画面上点选逻辑对象。
这是一项有明确取舍的设计：与直接剪一段已生成的视频相比，代码组合更容易修改数据、重新排节奏和重渲染；但它要求 Agent 会写代码，也要求用户有能运行 Node、浏览器和 FFmpeg 的本地环境。
4. 在画面上提意见，按评论位置改
Studio 的评论循环是仓库最有辨识度的交互设计之一：
- 用户在预览画面中选择某个时间点和具体对象，写下意见。
om inbox --wait接收评论及其场景、时间和对象上下文。- Agent 用
om look查看整帧与点选位置的局部图。 - Agent 优先通过
om set改变量；需要改结构时，只修改组合源码中相关部分。 om done把一句话修改说明回传给 Studio，用户查看更新后的预览。
仓库还记录每一版，并提供 om undo。相比“感觉不对，整体再做一遍”，这种反馈携带空间和时间位置，能让意见直接连接到源码，也帮助保持其他已认可的部分不动。
5. 让声音和画面共同组织节奏
项目提供两条配乐路线。快速草稿可以选择内置产品类别与配乐方向；需要更强控制时，Agent 可以用 ABC 记谱法写乐谱，把乐谱标记和场景时间线对齐，再由音频工具渲染。OM.sfx() 可把音效标记放在动画落点上，om sound 根据组合生成音轨。
真乐器采样包是可选项。README 说明，运行 om samples build 会下载约 55 MB、按 CC0 与 CC-BY 授权的采样；不安装时仍可用合成音色。口播也可以选择 macOS 系统音色、Kokoro 或用户自己的录音；逐字对齐口播另需安装 whisper-cli。
这里的“本地生成”是指该项目说明其配乐生成不调用收费音乐 API；但可选的采样、语音模型和 whisper 模型会在首次使用时从各自来源下载，不能据此理解为整个工作流完全离线。
6. 检查脚本、画面和成片
项目把自动检查和人工视觉检查分开：
| 工具 | 检查内容 |
|---|---|
om check | 脚本、资源文件、运动规则，以及抽样画面中的裁切、遮挡和文字对比度 |
om still | 输出指定时间点的静帧，用于查看方向稿和关键画面 |
om qa | 分析最新渲染中的单帧闪现、静止空档、硬切和整体运动曲线 |
| 正常速度观看 | 由人判断节奏、审美和声音是否成立 |
通过 om check 不代表作品已经好看。Skill 明确要求 Agent 查看关键帧、检查每次场景切换后的第一秒，并按正常速度看一遍成片；能安排独立 Agent 冷审时，再增加一个不同视角。
7. 导出并沉淀本次经验
om render 可导出 MP4，也支持 MOV、GIF、WebM 等格式；项目说明渲染由用户本机安装的 Chrome、Chromium 或 Edge 执行。透明背景适合导出到剪辑软件继续包装；需要分享源码的场景，可以导出包含播放器和组合源码的 HTML 页面。
当用户确认完成后，Skill 还要求运行 om learn harvest，从工作过程的评论和修改中提取值得保留的经验。它区分用户明确表达的偏好、单次观察和经过多次验证的通用发现；个人偏好保存在本机，而不是自动写入共享仓库。
结构与安装方式
仓库主要由以下部分组成：
| 目录 | 职责 |
|---|---|
skills/huashu-motion/ | Skill 主文件、导演方法、节奏/颜色/声音指南、运动语言库、示例乐谱和经验记录 |
cli/ | om 命令：新建项目、Studio、评论收件箱、声音、检查、渲染和导出 |
runtime/ | 组合文件调用的 OM.* 运行时工具和逐帧渲染代码 |
studio/ | 浏览器编辑器、实时预览与画面评论界面 |
templates/ | 项目起步模板 |
examples/ | 演示组合 |
test/ | Node.js 测试 |
当前仓库包信息显示版本 0.1.1，要求 Node.js 22 或更高版本。README 列出的本地依赖包括 Chrome/Chromium/Edge 与 FFmpeg；具体语音和音色选项另有依赖。简单安装方式是通过 Agent Skills CLI 添加：
npx skills add alchaincyf/huashu-motion
也可以克隆仓库，把 skills/huashu-motion 链接到 Claude Code、Codex 等 Agent 的 Skill 目录。Skill 会调用仓库里的 bin/om。README 当前说明项目主要在 macOS 上实测；其他操作系统上的可用性不能只凭其遵循 Agent Skills 协议来推断。
适合什么场景，不适合什么场景
比较适合的场景：
- 需要产品发布片、功能演示、动态图表、解释型短片或口播包装；
- 希望直接修改标题、数字、配色、镜头时长，而不是从头生成整段素材；
- 可以在本机安装 Node、浏览器和 FFmpeg，愿意通过预览反复给反馈；
- 想把最终成片继续带入 CapCut、Premiere 等剪辑流程。
需要谨慎评估的场景：
- 必须自动生成真实人物、实拍素材或复杂自然运动。项目声明主要画面由代码绘制，不会凭空生成真人或实拍；需要这些素材时应自行提供。
- 需要完全无人审片。项目检查工具只能覆盖部分脚本和画面问题，审美、叙事和声音仍需人工判断。
- 运行环境没有图形浏览器或 FFmpeg，或希望完全离线。截图、渲染依赖本机浏览器，部分可选资源会联网下载。
- 期待任何模型都能稳定达到相同质量。项目 README 说明模型间的视觉品味存在差别；其样片和效果描述不等于跨模型、跨设备的基准测试。
许可与素材边界
仓库将代码和文档标注为 MIT 许可，但明确列出例外和第三方组件：豆子花叔 卡通角色及其在示范片、storytime 模板中的形象只用于项目演示，不属于 MIT 授权范围；GSAP、字体、乐器采样和语音模型等各自保留原有许可。
因此，安装和使用工具不等于取得所有演示角色、字体、声音素材或模型的再分发权。若要把仓库里的素材放进自己的商业项目，先按 LICENSE、THIRD_PARTY.md 和具体素材的原始许可逐项确认。本文仅链接仓库演示媒体，没有将其打包到 GPT88 博客资源中。
一个真实使用案例：一句提示词生成 Pi Agent Desktop 短片
Chasen 在 X 上分享，他用 huashu-motion 为 Pi Agent Desktop 制作了一支 30 秒产品宣传片。作者称任务从一句“给我的项目做个产品宣传片”开始，并使用 MiniMax M3.1 Flash，通过 OpenRouter 调用；他发布时表示该模型在 OpenRouter 上可免费使用。原帖还提到自己在 Claude Code 中使用 Ultra Code，以及花叔使用 Opus 5.5 的体验对比。
这是一则个人使用记录，不是可重复的速度或画质基准。原帖视频内容不可读取，因此不能据此判断成片镜头、品牌准确度或最终剪辑质量；“免费”也只反映作者发帖时的服务状态。实际模型可用性、价格、限额和 Skill 客户端兼容性应以当前服务页面为准。它能说明的是：对于界面和图形动效占主导的产品视频，Agent 可以把简短需求转成可预览的代码化影片，再通过 Studio 评论细化，而不是每次都从传统时间轴手动搭建。
总结
huashu-motion 把产品短片制作建模为一项可运行、可检查和可反复修改的代码工作：Agent 负责研究产品、组织镜头、写动画和声音；Studio 把用户意见定位到画面与源码；本机浏览器完成预览和渲染；检查工具补上可自动发现的问题。
它值得关注的不是“Agent 能不能一键生成商业级视频”这个宣传句，而是这条具体的人机协作链路：先给方向稿，保留可编辑变量，让视觉评论携带位置上下文，用真实渲染作为反馈，再由人确认最终成片。Chasen 的 Pi Agent Desktop 案例展示了快速启动的可能性，但不能替代对具体画面、事实、声音、许可和交付格式的检查。仓库提供了可以审阅的 Skill、CLI、运行时、模板、样片和测试，因此可以从源码判断它做了什么；样片质量、速度和跨平台表现仍应在自己的产品和机器上验证。
作者主页：花叔 Huashu（@alchaincyf） README 演示：指着画面改