一整套 AI 短剧的 skill，终于有人把整条流程开源了

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/shuohao-drama-skills/ 「芋道源码」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

shuohao-skills 是 GitHub 上的一个开源项目，干的事情一句话能说完，把小说改编成 AI 短剧的前期流程打包成六个 skill，装进 AI 编程工具里就能跑。

做 AI 短剧的人应该有体会，费时间的从来是前面那一长串准备。小说要拆，大纲要排，角色长什么样、什么声线要提前定下来，剧本要一集一集卡时长，最后分镜还得几秒几秒地切。这些活儿很碎，而且省不掉。

一条只往前走的流水线

整套设计一张图就能说明白。

整条流程的结构示意

小说原文进去，先出改编大纲，把故事结构收敛住。然后剧本、场景清单、角色设定这三块同步迭代，互相约束。最后才是分镜，分镜这一层只做输出，不再做新的创作决定。

这条原则作者直接写进了 README。创作类工具最怕的就是每个环节都在偷偷改前面定好的东西，改到最后没人说得清哪版算数。

六个 skill 里，五个串成这条管线，剩下一个 character-refs 是独立出图用的，不归在管线里。

五段串成一条管线，外加一个独立出图

第一段 novel-outline 管大纲。丢一本小说进去，出来五件套，改编说明、人物表、爽点表、分集梗概、资产清单。改编和从零写新故事不一样，得先决定砍哪条线、合并哪些人、爽点往哪放，这些都在这一步定死。它有 14 道质量门，全部是脚本在查，不靠模型自己觉得行；手里已经有大纲的话，还能走体检模式，让它把结构问题筛一遍。

短剧改编大纲报告

第二段 novel-characters 做角色设定集。人物画像、形象提示词、音色提示词、角色设定图都在里面，它能直接读大纲阶段产出的文件，角色表自动预填，不用重输一遍。

这里有个判断做得挺细。同一部剧里两个角色的提示词写得太像，脚本会算一遍相似度，超过 0.75 就点名报错，告诉你是哪两个角色撞了。这个阈值是量出来的，自带样例里四个角色两两最高才 39%，而「只改年龄和衣服颜色」的雷同用例能到 98%，中间余量很大。

更有意思的是它有意不查的东西。角色设定图那三分区的排版规范是一大段固定文本，真实角色之间本来就有六成以上的词重合，所以这一项干脆不设门。作者的注释写得很直白，误拦的门比没有门更糟。

角色设定集报告

character-refs 是六个里唯一真出图的，也是最不依赖小说的一个，自己原创的角色也能用。一段话描述角色，它拆字段、补全、跟你确认，然后先出一张正面全身的锚点图，后面的大头照、侧面、背面、细节图全都只参考这张锚点。出图方式四选一，自己部署的 ComfyUI、codex 内置出图、OpenAI 的接口，或者自定义命令，第一次用的时候选一种就行。

角色参考图报告

第三段 novel-art 出场景和叙事道具的设定集。每个场景有一致性锚点、不同光照和状态的变体、尺度参照，提示词统一要求无人无手白底。10 道质量门，同样全是脚本检查。这一步产出的设定图后面会一直用，切分镜的时候，分镜图就是拿它当参考图出的，画面风格从头到尾不容易跑偏。

美术设定集报告

第四段 novel-script 写剧本。按场次加节拍流来组织，动作和台词交替。时长这一块卡得很死，台词按语速折算成秒数，动作按节拍估，每集都要落在目标时长里，超了或者少了，报告里直接红字标出差多少秒。开头钩子也是一道门，冷开场的前三拍必须把它兑现掉，过不了就打回。台词本按角色聚合成一份，带着音色提示词，可以直接对接 TTS 配音。

剧本报告

第五段 novel-storyboard 出分镜。一段最长 15 秒，段里切成 2 到 5 秒一个分镜，这是硬门。分镜图的主图钉在 0.00 秒，子图各自钉在切点上，MiniMax H3 的提示词和切点时刻会逐字对账，改了秒数没同步改提示词就会被抓出来。全部弄完 export 一下，出 H3 或者 Seedance 的投产包，每段一个文件夹，提示词和分镜图都在里面，拿去喂视频生成管线就行。

它有 18 道质量门，是六个里门最多的一段。

分镜报告

每一道门都由脚本把守

把五段的门数摆在一起看，大纲 14 道、角色设定集 10 道、美术 10 道、剧本 10 道、分镜 18 道，无一例外都是代码在查，不花模型额度。

仓库里还把自测做成了硬要求，每个 skill 都必须带一个 selftest 脚本，覆盖全部确定性逻辑，跑起来不调模型也不花额度。整仓一次跑完只要一秒左右，作者干脆没配 CI，理由是本地跑一遍比等流水线更省事。

装起来是一条命令

本机已经在用 Claude Code 或者 codex 的话，装起来很简单，克隆仓库再跑一条脚本就行。

git clone https://github.com/eternityspring/shuohao-skills.git
cd shuohao-skills
./scripts/install.sh

脚本会自己检测本机装的是哪个运行时，把所有 skill 软链过去。以后 git pull 更新立刻生效，不用重装。只想装某一个也行，把 skill 名字加在命令后面；想只装到 codex，或者干脆取消软链，都留了对应的参数。

前置要求不多。Node 要 18 以上，脚本只用标准库，没有 npm 依赖；跑 skill 用的是当前会话的额度，不需要额外配任何 API key；只有 character-refs 出图那一步要选一种出图方式。

仓库首页

报告合成器顺手做的三件事

跑完管线会一段出一份 HTML 报告，仓库里另有一个组装脚本，能把五份合成一张单页，左边导航切换，跑到哪段就有哪段的面板，只跑了一段也不报错。

它处理的三件事都挺实在。五份报告共用 57 个类名，其中有 13 个同名但定义不同，所以给每份样式都加了作用域前缀；各报告的脚本原本是直接全局查询 DOM 的，合成一页后只会命中第一个，于是给每份脚本套了一层作用域代理；图片路径也要按输出文件的位置重算。

这三件事全在组装器里做，五个 skill 一行都不用改。组装器不引用任何 skill 的代码，只是调各自的渲染命令拿产物再拼装，所以某个 skill 改了渲染，这边自动跟上。每个 skill 都是自包含目录，看中哪个可以单独拷走。

单页默认一次只显示一个面板，五份加起来将近六十万字符，全展开会很卡。左下角有个平铺入口，数字键 1 到 5 可以切面板，也能用锚点直接分享到某一屏。

它管到哪一步为止

这套东西到分镜投产包为止，不直接出成片。它管的是文本和分镜之间的约束，最后视频好不好看，还得看后面的生成和制作环节。

平台验证也要说清楚，作者写明了只在 macOS 加 Node 24 上验过。代码本身没有平台相关的调用，Linux 和更低版本的 Node 理论上也能跑，但没实际验过，真碰到了问题可以去仓库提 issue。

报告默认中文，管线各段的报告都能切成英文界面，角色相关的报告还内置了日文。

被单独拎出来的是检查

这个项目最值得说的地方，是它把检查单独拎出来做了。能检查的东西基本都落到了脚本里，时长、提示词相似度、切点对账，全是脚本在查，不靠模型自觉。AI 写东西经常写完没人核，这套 skill 等于给每一环配了个不会累的校对。

它还顺手把每个 skill 都做成了自包含的目录，可以单独拷走，不必接受整套流程。这一点比功能多少更能说明作者的取向。

项目是 Apache-2.0 许可，目前四千多 Star，八月上旬建库，最近一次提交就在这几天。

仓库在 https://github.com/eternityspring/shuohao-skills