Dalang 做 90 秒 AI 动画：4 道审批门为什么不是随时能叫停

截至 2026-10-31 抓取，sandalkuilang/dalang 这个 GitHub 仓库有 573 次提交、1 个 star、0 个 fork。它把一件很重的活塞进 Claude Code 插件市场：给它一个主题，还你一部带脚本、AI 配音、逐词计时、音乐和动画画面的 MP4。为什么现在值得看？因为它的 README 没把卖点放在“生成速度多快”上，而是放在“每个阶段都有一道审批门”。这里必须先分清一件事：有两个同名的 DALANG。GitHub 上 sandalkuilang/dalang 是一个 Claude Code skill，做本地 AI 动画；HackQuest 上那个 DALANG 是另一个项目，做的是”链上结算的动画生成”，靠 x402 协议用 USDT0 付款、OKX 做结算方，一次工具调用算一个计费单位，0.49 美元，还带一个免费的 storyboard 预览层让调用方先看报价再决定付不付。下面讲 GitHub 版为主，两个项目不要混。另外要说准确：README 里同时写了两件事 —— 一是 approval gate at every stage，二是在 Brief 之后两个模式都是 hands-off、”the agent passes its own gates and hands you the film”。也就是说闸门是流程内部的自检点：发起方在 Brief 阶段一次性把方向定了，之后就是自动跑完 —— GitHub 版 README 里没有”报价批准”这层机制，那是链上版的。所以“每步可叫停”这个说法其实偏了。GitHub 版 README 里能确认的只有三句：每个阶段有一道 approval gate；Brief 问完之后两个模式都 hands-off；以及”the agent passes its own gates and hands you the film with its metrics” —— 也就是闸门是流程内部的自检点，agent 自己过闸，成片连同度量一起交给你。中间没有给用户留”随时喊停”的位置。“付费前先看预览再决定”那句是链上版 DALANG 的机制，不属于 GitHub 这个本地 skill，别混用。这正好对上普通用户对 AI 视频最不放心的地方：中间过程不可控 —— 但要看清”不可控”被消除了多少，答案是”流程内的可控”，不是”随时能插手”。

从仓库自己的表述看，这套”每阶段都有闸门”的机制落在三个具体动作上：Express workflow 里先做 Preflight，把 Brief 里的所有问题一次性问完，而不是边做边问；然后是事实核查与脚本各交给一个 subagent 作业，Gate 1 自己去跑 lint；再然后才是配音，同样是一个 subagent 作业。README 里还写了”渲染高的档位”这种分级，说明它把成本控制也做进了流程。这三点合起来才是”四道审批门”能落地的原因 —— 门不是加在流程末尾，而是插在每个会花钱或会返工的环节前面。

这里顺带说清 Dalang 依赖的 HyperFrames 是什么：Apidog 的这篇教程解释得很直白 —— After Effects 和 DaVinci 本来不是为 AI 智能体设计的，HyperFrames 的做法是把 HTML 变成视频帧，让 Claude Code 去渲染。换句话说 Dalang 里的”画面”不是传统剪辑软件里的图层，而是网页。这解释了它为什么能做到逐词计时和自动化审批门：底层是可编程的 HTML 渲染，而不是拖时间线的工程软件。

安装后先被问完所有问题

安装命令本身只有两行：

claude plugin marketplace add sandalkuilang/dalang
claude plugin install dalang@dalang

重启 Claude Code 后，agent 会先运行 preflight.mjs 检查机器环境。然后你可以用任何语言下需求，README 给了两个例子：“make a 45 s YouTube Short about why steel ships float”和“haz un video de 90 s sobre la fotosíntesis”。这里有一个和常见生成器相反的设计：所有问题都在开头问完。Express 和 Studio 的 Brief 阶段一次收集需求，之后进入无人值守状态。另一个细节是版本隔离——官方写得很清楚，每个版本住在自己的文件夹里，更新插件后旧版本不会污染制作中的视频。所以一部剪到一半的片子可以在旧版本里继续，而不是被迫升级重做。对于需要长周期修改的人来说，升级不是“替换”，而是新增一个可回退的版本。

Express 与 Studio：两条车道，两套引擎

官方把产出分成两条车道：Express 默认走快速路线，适合 30–90 秒的讲解视频，README 写大约 20 分钟工作；Studio 面向必须和真实物体一致、甚至要打开内部结构的主题。两者的差别不只是画质高低，而是建模路径和交付物不同。

| 维度 | Express | Studio |
| 适合 | 30–90 秒讲解片，约 20 分钟工作 | 需要完全像真实对象，可打开查看内部 |
| 输入 | 主题；照片、数据表、手册可选 | 主题加 3–5 张对象照片、剖面图或手册页 |
| 建模 | 干净 3D study model 或等距真形状 | 从你的 2D 照片生成 Blender 脚本，存入模型库 |
| 场景引擎 | Canvas 2D 或 three.js | three.js |
| 视频与语音 | 语音 VoiceStudio 或 Kokoro；视频 HyperFrames + ffmpeg | 语音 VoiceStudio 或 Kokoro；视频 HyperFrames + ffmpeg |
| 交付 | final.mp4、字幕、POST.md、metrics | 高渲染 final.mp4、字幕、POST.md、metrics、可复用对象资产 |

选择时的一个实用信号：Express 推荐 object-studio 的干净 3D 学习模型，Studio 则面向需要拆解机械、产品、生物结构的场景。相机是慢速单向轨道，所以成片更接近“稳定推进的讲解镜头”，而不是频繁切换的短视频节奏。

审批门是产品，不是胶带

这个仓库最值得读的是 workflow 里的 Gate 1 到 Gate 4。官方强调了“Words first”：声音在任何一帧之前录制，每个剪辑点都落在一个计了时的单词上，第一个词前和最后一个词后留有余地，背景音乐自由铺在下面。这和很多视频生成器“先出画面再配声音”的顺序相反。因为先有语音和逐词计时，画面可以按单词节奏来切，而不是让 AI 自己猜哪个词对应哪个镜头。

在 Express 流程里，事实和脚本由子代理分别跑，Gate 1 自己跑 lint；配音完成后 Gate 2 检查干净 take、加 padding 和 captions；一个 planner 写出 SPEC 和 storyboard，多个 builder 并行填充镜头组，Gate 3 做一次组装检查；最后渲染由 Gate 4 收尾。Studio 是同一条逻辑的”精细档”：同样先 Preflight、再 Brief，之后多出 Blender 建模这一段，再往下走同样的闸门检查。项目概述里”每个阶段都有审批门”那句对两个模式都适用。

同名“DALANG”会撞车：这不是链上那个

搜索 Dalang 时很容易把两个项目混在一起。HackQuest 上有一个中文项目页 DALANG — Storyboard-to-Animatic Studio，但那是 OKX A2MCP 的链上代理：把一行 brief 变成 1080×1920 的垂直动画视频，一次工具调用通过 x402 计价，金额是 $0.49 USDT0，并且强调有 free storyboard-preview 和 quote tier。那个项目的技术栈是 Web3 和 Python；而这个 GitHub 仓库是 JavaScript、three.js、Blender 和 Claude Code 插件，README 里没有出现 OKX、x402 或 USDT0。同一名字，两条路线：一个按调用次数向人或其他 agent 收钱，一个装在自己机器上本地跑。

Dalang 之外还有别的路线，比如做成 Claude Code skill 的 YouTube 动画工具，但那些依赖第三方语音 API、需要自备 key，走的是订阅制。跟 Dalang 放在一起看很清楚：本地免费、API key 订阅两种模式分得很清楚。

免费的完整账单与它的边界

“免费和本地”并不等于零成本。README 说的是工具栈免费、本地，但没有说 Claude Code 本身的额度、机器算力、渲染时间谁来付。如果你用 Express 做一个 30–90 秒短片，官方给的“约 20 分钟工作”更可能指 agent 的活跃工作时间，不是墙上的等待时间；语音合成、Blender 建模、ffmpeg 合成都要消耗 CPU 或 GPU，高渲染的 Studio 输出在普通电脑上可能等很久。这是我的判断，不是官方口径。

另一个边界是事实质量：Gate 1 跑的是 lint，不是事实核查。脚本里的论点、数字、因果仍然需要用户自己确认，否则四道审批门只保证流程正确，不保证内容正确。截至 2026-10-31，该仓库只有 1 个 star、0 个 fork，在一个已有 573 次提交的项目里，说明它还没有经过大量真实用户检验；接口和依赖可能随时变化，不能把它当成稳定产品。

一个可复算的时间账

如果给 Dalang 写 Brief 时不确定 45 秒该写多长，可以拿一个公开的同类示例做一次复算。那个示例成片 57.8 秒、脚本 148 词，换算成每分钟语速（注意：这是社区里另一个工具的示例参数，不是 Dalang 官方的建议值）：

148 词 / 57.8 秒 × 60 秒 ≈ 153.6 词/分钟

按这个语速，一个 45 秒短片大约需要 115 词。（这是按上面那个换算比例推的，属于估算；官方仓库没有给不同长度的字数对照表。）这只是我的推算，Dalang 官方没有给语速数据；但它的“先录音再切画面”原理意味着脚本长度直接决定成片长度，所以 Brief 里控制词数比事后改画面更有效。若你的脚本只有 80 词，按每分钟 154 词算大约 31 秒，会落在 Express 的 30–90 秒区间内，但可能太短，不适合需要完整论证的主题。这个算式可以在任何计算器里复现，输入两个来源数字即可。