学习了花园老师的开源 Skill，我设计了一个视频全自动生产工作流
摘要
看完花园老师 ConardLi 那篇关于 garden-skills 的文章后，我突然意识到：Skill 的价值不只是提示词，而是把复杂任务拆成稳定的生产线。于是我基于web-video-presentation、自己原来的hyperframes-quality-director、short-video-director subagent、MiniMax TTS 和一个网页启动页，搭出了一套口播视频自动生产工作流。
01
不是又收藏了一个 Skill，而是被一种方法点醒了
我第一次看到花园老师 ConardLi 那篇文章《啊？我刚开源的 Skills 已经 7K Star 了？！》时，真正吸引我的，不只是 7K Star 这个数字。
更打动我的是他对 Skill 的理解。
花园老师在文章里讲到，Skill 真正有价值的地方，不是提示词写得多漂亮，而是把一套可重复、可稳定执行的方法交给 Agent。
这个观点一下子点醒了我。
因为我之前其实一直在用 HyperFrames 做视频。
我做的不是那种直接丢一句 prompt 生成一段随机视频的方式，而是用网页来模拟视频：先把文案变成一个可以播放的网页演示，再配音、录屏、渲染成 MP4。
这种方式的好处很明显。
网页是可控的。
文字、画面、章节、动画、进度、字幕，都可以被代码控制。
不像很多视频生成方式，一次生成完之后，哪里不满意就很难局部修改。网页视频可以一页一页改，一段一段调。
所以我一直觉得，这个方向是对的。
但实际做下来，我也遇到了很多问题。
02
我原来做视频的痛点：能跑通，但不稳定
之前用 HyperFrames 做视频时，最让我头疼的不是“做不出来”。
而是经常“做出来了，但差一口气”。
比如：
• 一个页面停留太久，旁白讲了一大段，画面却几乎不动；
• 屏幕上虽然有字，但真正跟随旁白的字幕没有逐句出现；
• TTS 是后补的，声音时长和页面节奏对不上；
• 画面看起来像自动播放 PPT，少了一点真正视频该有的推进感；
• 每次都能出片，但每次都要重新解释规则。
也就是说，我之前已经有了一个能跑通的技术路线，但还没有形成一套稳定的视频生产系统。
直到我看了花园老师这篇文章。
他在文章里介绍了web-video-presentation 这个 Skill。
它可以把文章、脚本、课程、产品 Demo、技术分享等文字内容，转成基于网页制作的演示视频。
它不是直接生成 MP4，而是先生成一个网页视频效果。
每一步对应一段旁白、一组画面、一段节奏。
录屏的时候，就像在播放一个精心设计过的视频。
这个思路和我之前做 HyperFrames 视频的方向非常接近。
但花园老师这篇文章给了我一个新的启发：
我之前是在“做视频”。
而 Skill 的思路，是把“做视频”拆成一条稳定的生产线。
这两件事差别很大。
如果只是做视频，每次都要重新判断：文案怎么拆、画面怎么排、字幕怎么跟、配音怎么接、节奏怎么验收。
但如果把它做成工作流，这些判断就可以被前置、被拆解、被固化。
于是我开始想：
能不能基于花园老师的web-video-presentation，结合我自己原来做的hyperframes-quality-director，再加上一个专门负责短视频节奏的 short-video-director，把整个口播视频流程串起来？
不是每次都临时提示。
而是只要我说“我要做一个视频”，系统就自动进入一条固定的视频生产链路。
03
第一步：先把“视频任务”识别成专门的工作流
这个想法出来之后，我做的第一件事，不是直接改页面。
而是先这个视频工作流的入口。
以后只要任务是：
• 文章转视频；
• 口播稿转视频；
• 公众号文章转视频；
• 课程稿转视频；
• 观点文案转网页视频；
就默认进入“口播驱动网页视频工作流”。
这一步很重要。
因为这种视频不能按普通网页做，也不能按普通 PPT 做。
它的核心不是页面，而是口播。
页面只是承载口播节奏的一种形式。
04
第二步：把质量问题前置，而不是做完再返工
接着，我把hyperframes-quality-director 放在最前面。
它负责做质量门。
以前我容易等视频做完之后才发现问题：
这里停留太久。
那里字幕没跟上。
这段旁白和画面不匹配。
某一页太像静态 PPT。
现在这些问题要前置。
在真正写页面之前，就要明确：
• 有没有逐句字幕；
• 有没有逐行字幕；
• 有没有长时间静止画面；
• 有没有整段旁白压在一个页面里；
• TTS 时长怎么驱动画面；
• 最终怎么抽帧验收。
这样就不是做完再返工，而是从一开始就把质量标准写进流程。
05
第三步：加入 short-video-director，专门做口播编导
这次最关键的调整，是加入short-video-director。
因为我发现，视频节奏不是简单地“3-5 秒换一页”。
一开始我也以为，一个 step 控制在 3-5 秒比较好。
但真正做了几条视频之后，我发现这个规则还不够准确。
字幕是字幕。
画面是画面。
字幕必须跟着旁白逐句出现。
但画面不一定每一句都要换。
有些句子虽然分成了好几句，但它们表达的是同一个意思，就应该放在同一个画面里，通过局部高亮、关键词出现、结构推进来完成动态变化。
反过来，有些地方虽然只讲了一两句，但语义已经转折，就应该切到新画面。
所以新的逻辑应该是：
字幕按句子走。
画面按语义走。
画面切换不再被固定时间绑死，而是根据文案里的逻辑关系来判断。
哪几句话关系紧密，就放在同一个画面里。
哪一句开始进入新观点、新原因、新案例、新结论，就切新画面。
这就是short-video-director 要做的事。
它不是简单拆句，而是做编导判断。
它要输出一个beat-plan.md，把每一段口播对应到：
• 这一段说什么；
• 屏幕字幕是什么；
• 逐句字幕怎么出现；
• 画面要怎么动；
• 是否需要换画面；
• 是否需要在同一个画面内做动态推进；
• 预计时长是多少；
• 有没有超长 narration；
• 有没有字幕缺失。
有了这个 beat-plan，后面的网页实现就不会乱。
06
第四步：让 web-video-presentation 按 beat-plan 实现页面
接下来web-video-presentation 不再只是把文章转成一页页网页。
它要根据编导规划，把每一组口播变成对应的画面状态。
这一层负责真正的网页视频表现：
• 主题；
• 版式；
• 章节；
• 动画；
• 键盘推进；
• 录屏结构；
• 视觉节奏。
花园老师文章里提到的主题系统，也给了我很大启发。
他做了很多主题方向，比如技术、杂志、终端、数据、科普等等。
这让我意识到，视频工作流不能每次都让我在聊天里描述“我要什么风格”。
风格选择应该变成一个明确的操作界面。
于是我又做了一个网页启动页。
以后我发起视频任务时，系统会先跳出一个网页，让我选择主题和配音。
这个页面里可以看到不同主题的视觉预览，也可以试听不同 TTS 音色。
我点完之后，工作流就知道这条视频该用什么视觉风格、什么声音。
这一步看起来只是一个小页面，但它把过去非常模糊的“你想要什么风格”，变成了一个可选择、可记录、可复用的入口。
07
第五步：TTS 不再后补，而是反过来驱动画面节奏
花园老师文章里提到，新版支持自定义 TTS，并且把 TTS 做成可插拔方式。
这点也正好打到我的痛点。
我之前用过 Edge TTS，能用，但声音质感不够好。
后来我接入了 MiniMax，并且克隆了自己的声音。
这样做视频的时候，就可以优先使用我自己的音色，而不是每次都用一个通用机器声音。
更关键的是，TTS 不能最后随便贴上去。
现在的逻辑是：
1. 先稳定 beat-plan；
2. 再生成每段音频；
3. 用 ffprobe 读取真实音频时长；
4. 再用真实时长去驱动画面推进。
这样画面节奏就不是靠估算。
声音讲了多久，画面就配合多久。
如果某段音频超过预期，就回到 beat-plan 拆分或重写。
这一步让视频从“自动播放 PPT”，更接近“有人认真讲完一条片子”。
08
第六步：让 reviewer 先审分镜，再审实现
最后，我加入 reviewer 做交叉复查。
它不负责审美，也不判断创意好不好。
但它不是只在最后看代码。
这次重新调整之后，reviewer 会先在beat-plan.md 阶段介入。
因为short-video-director 负责切分口播节奏和语义画面组，但它也可能切得不够准。
比如，同一个意思被拆成了几个画面，视频就会跳得太快。
又比如，几个完全不同的观点被塞进同一个画面，观众就会觉得乱。
所以 reviewer 要先检查：
• 断句是否合理；
• 同一个意思有没有被拆散；
• 不同观点有没有被硬塞在一起；
• 字幕和画面有没有混在一起；
• 画面是不是按语义组切，而不是按固定秒数机械切。
如果 reviewer 发现 beat-plan 切得不合理，就退回给short-video-director 重新调整。
等 beat-plan 稳定之后，web-video-presentation 再进入页面实现。
实现完成后，reviewer 再做第二次复查。
这一次，它检查这条工作流有没有守住规则：
• 有没有 beat-plan；
• narration 有没有过长；
• 字幕有没有逐句逐行；
• 页面 step 能不能追溯到 beat-plan；
• 字幕轨和画面组有没有分开；
• 页面是不是按语义组推进，而不是按字幕句子机械换页；
• TTS provider 有没有正确接入；
• 有没有把 API key 写进公开文件；
• 渲染脚本有没有静默降级；
• 最终验收有没有音频轨、视频轨、抽帧和 contact sheet。
这样，一个口播视频从文案到成片，就被拆成了几个清楚的角色。
hyperframes-quality-director 负责质量标准。
web-video-presentation 负责网页视频结构。
short-video-director 负责口播编导和节奏。
MiniMax TTS 负责配音。
reviewer 负责前置语义复审和最终结构复查。
渲染脚本负责输出 MP4 和验收材料。
09
现在这条工作流大概怎么跑？
现在整个流程大概是这样：
1. 我打开一个窗口，说我要做一个视频；
2. 然后把文案发进去；
3. 系统识别这是口播驱动网页视频；
4. 接着弹出网页，让我选择主题和配音；
5. 选完之后，short-video-director 拆 beat-plan；
6. reviewer 先检查断句和语义分组是否合理；
7. 如果切分不合理，就退回 short-video-director 返修 beat-plan；
8. web-video-presentation 按最终 beat-plan 做页面；
9. MiniMax 生成配音；
10. ffprobe 读取音频时长；
11. 页面按音频节奏推进；
12. reviewer 再做代码和结构复查；
13. 最后渲染 MP4，并输出抽帧验收。
这就是我今天调教出来的视频自动生产工作流。
它还不是最终形态。
但我现在反而更清楚下一步要继续优化什么。
比如，字幕和画面必须彻底分开。
字幕要按口播逐句走。
画面要按语义组走。
一个画面可以承载几句紧密相关的话，但这个画面内部必须有动态变化，不能只是静态停留。
再比如，启动页后面还可以接后端 session。
用户在网页上选完主题和配音之后，结果直接写回工作流，不需要手动复制。
再比如，不同类型的视频还可以有不同的编导策略。
课程型、观点型、产品演示型、招商型、案例型，画面组织方式都不一样。
如果你也在做知识内容、课程口播、招商视频或企业观点视频，真正值得优化的可能不是某一个提示词，而是一整套可以反复出片的工作流。
10
最后
这次最大的收获是，我终于把“做一条视频”这件事，从一个临时任务，变成了一条可复用的生产线。
这也是我从花园老师这篇文章里学到的东西。
Skill 的价值，不只是让 Agent 多会一个技巧。
它更像是把一个复杂工作拆成流程、标准、接口和验收。
当这些东西沉淀下来之后，下一次再做同类任务，就不需要重新从零开始。
这对我很重要。
因为我做的不是一次性炫技。
我想要的是长期稳定地生产内容。
尤其是口播视频这种东西，如果每条都从头磨一遍，成本太高。
但如果能把脚本拆解、主题选择、字幕规则、画面节奏、TTS、验收都沉淀下来，一个人也可以搭出一套自己的视频生产系统。
所以，这次学习花园老师的开源 Skill，对我来说，不是简单“用了一个工具”。
更像是让我重新理解了一件事：
真正值得沉淀的，不是某一次成功生成的结果。
而是让好结果可以反复出现的工作流。