AI 短剧真正难的，可能从来不是“让 AI 写出一个故事”。
难的是：当故事变成几十集短剧之后，人物能不能保持一致、剧情能不能持续推进、场景和道具能不能复用、剧本能不能落到时长、分镜能不能直接进入生成流程。
这也是 shuohao-skills GitHub 仓库 值得关注的地方。
它没有把 AI 简单包装成一个“写作助手”，而是尝试把小说改编成 AI 短剧的整个过程拆成多个可以被 Agent 执行、验证和衔接的 Skill：从大纲、角色、美术，到剧本、分镜，再进一步提供镜头语汇卡库。当前仓库已经形成了相对完整的制作管线。(GitHub)
一、它解决的不是“生成”，而是“生产”
很多 AI 创作工具的思路是：
给我一个故事，我帮你生成内容。
shuohao-skills 的思路则更接近：
给我一个故事，我把它拆成一套可以继续生产的结构化资产。
这两种思路看起来只差一点，实际上完全不同。
传统 AI 对话式创作往往是一环一环地生成：
小说 → 剧本 → 人物 → 场景 → 分镜
问题在于，每一步都可能重新理解一次前面的内容。
于是很容易出现：
- 第一集的角色长相和第十集不一样；
- 同一个场景在不同集数里出现完全不同的视觉设定；
- 小说里的配角太多，全部搬进短剧后制作成本失控；
- 剧本写得很精彩，但实际时长根本装不下；
- 分镜为了“好看”重新做了剧情决定，导致和剧本脱节。
shuohao-skills 的核心思想，是让这些问题尽可能在结构层和规则层被解决，而不是等到最后生成视频时才发现。
仓库目前将流程明确拆成 novel-outline、novel-characters、novel-art、novel-script、novel-storyboard 五个主要环节，并另外提供 shot-recipes 镜头语汇库。(GitHub)
这实际上已经很接近传统影视制作中的“前期开发—资产制作—剧本—分镜”流程，只不过执行者从人类制作团队的一部分，变成了 AI Agent。
二、第一步不是写剧本，而是先“改编大纲”
整个体系的起点是 novel-outline。
它负责把一本小说转换成短剧制作所需要的结构，包括：
- 改编说明；
- 人物表；
- 爽点/节拍表；
- 分集梗概；
- 资产清单；
- 场景与叙事道具等生产信息。
更重要的是，它并没有完全依赖模型“自觉保持质量”。
仓库设计了大量确定性的质量检查，例如人物数量上限、节拍间隔、第一集钩子、主要节拍的位置、分集必填字段、场景复用、引用完整性等。(GitHub)
这里有一个非常值得借鉴的理念：
不要让模型自己判断“我写得合不合格”，而应该尽可能让程序判断。
例如，一个模型可以说：
“这一版人物数量合理。”
但程序可以直接检查：
主角是否超过规定数量？
支线人物是否超过上限？
有没有人物被定义却从未使用？
有没有场景被引用却没有定义？
连续多少集没有重要节拍？
前者属于“语言判断”，后者属于“工程验证”。
对于 AI 工作流来说，这是非常重要的区别。
三、人物不是一段描述，而是一项生产资产
第二个 Skill 是 novel-characters。
它的目标也不是简单地总结人物性格，而是把人物变成后续生成流程可以使用的角色资产。
一个人物可以得到：
- 人物身份与基本信息；
- 外貌；
- 性格；
- 动机；
- 人物弧线；
- 人物关系；
- 形象生成提示词；
- 负面提示词；
- 风格标签；
- 音色设计提示词；
- 角色设定图。
甚至还包含角色关系图，以及用于视觉一致性的角色模型表。(GitHub)
这意味着“角色”从文本里的一个名字，变成了一个可以贯穿后续流程的数据对象。
比如：
林晚
不再只是：
女主角，聪明、坚强。
而可以进一步变成：
林晚 → 角色 ID → 外貌设定 → 服装 → 身材 → 表情 → 声音 → 人物关系 → 出场集数 → 生成参考图
一旦这样做，后面的美术、剧本和分镜就有了一个共同的“锚点”。
这对于 AI 视频尤其重要。
因为 AI 视频最大的痛点之一就是一致性。
真正可用的生产系统，不应该每次都重新问：
“这个角色长什么样？”
而应该让系统知道：
“这是角色 ID C-003，请按照已经确定的角色资产生成。”
四、场景和道具同样需要被资产化
novel-art 解决的是另一个容易被忽略的问题：
场景不是背景图，而是生产资产。
它会处理场景和叙事道具，并强调：
- 一致性锚点；
- 光照变化；
- 状态变化；
- 尺度参照；
- 无人、无手、白底的设定图提示词。
同时，它能够读取前面大纲产生的资产清单，从而减少重新整理需求的工作。(GitHub)
这背后其实是影视工业里的一个基本思想：
同一个摄影棚不能因为拍不同镜头，就变成五个完全不同的地方。
AI 生成更容易犯这个错误。
如果没有统一的场景资产，模型可能在每次生成时重新发挥：
第一次是现代办公室，第二次变成豪华酒店，第三次又像会议室。
单张图片可能都很好看，但放在同一部短剧里，观众马上会发现世界观不稳定。
所以，AI 短剧的核心问题之一并不是“生成得够不够漂亮”，而是：
能不能让生成结果属于同一个世界。
五、剧本开始进入“工程化”
到了 novel-script，事情就从创意生产进一步进入执行阶段。
这个 Skill 不只是要求模型“把每集写出来”，而是把剧本拆成场次和节拍流，并对时长进行确定性折算。
其中一个很有意思的设计，是按照语速计算分集时长，同时检查前几拍的冷开场和钩子兑现。台词本还可以按照角色聚合，并附带音色提示词，以便进一步对接 TTS。(GitHub)
这解决了一个很现实的问题：
AI 很擅长写“看起来很长”的东西，却不一定擅长写“刚好能拍完”的东西。
比如要求：
本集 90 秒。
模型可能给你写出一篇 2500 字的精彩剧情。
从文学角度，它可能没有问题。
从制作角度，它已经失败了。
因此，一旦加入“语速 → 台词时长 → 总时长”的确定性计算，剧本就从文学文本变成了生产文件。
这是 AI 创作工具从“Demo”走向“Production”的重要一步。
六、分镜的关键：不要让它重新发明剧情
最后一个主要环节是 novel-storyboard。
这里的设计尤其体现出工程思维。
它将内容拆成：
段 → 分镜 → 分镜图
并对单个生成段的时长、镜头长度、主图与子图切点等进行约束，同时把镜头提示词和具体时间点进行对账。(GitHub)
更重要的一句话是仓库对整个管线的定义：
改编大纲收敛结构，剧本、场景、角色三者同步迭代，分镜只做输出不做新决定。(GitHub)
这其实是整套系统最重要的设计之一。
很多 AI 工作流的问题，是每个 Agent 都拥有“重新创作”的权力。
于是：
小说 Agent 改一次；
大纲 Agent 改一次；
剧本 Agent 又改一次；
分镜 Agent 再改一次。
最后得到的已经不是原来的故事。
shuohao-skills 则试图建立一种单向约束关系：
上游决定什么，下游就负责把它实现出来。
这和软件工程里的接口、数据结构以及编译流水线非常相似。
七、真正值得关注的是“质量门”
如果只看功能列表，这个仓库可能只是：
“一套帮助 AI 做短剧的 Prompt。”
但如果深入看它的实现，会发现作者更在意的是另一个问题：
如何让 AI 工作流可验证。
例如不同 Skill 都设置了明确的质量门：
novel-outline有多项结构检查；novel-art检查美术资产完整性；novel-script检查剧本结构和时长；novel-storyboard则进一步检查分镜节奏、切点和提示词等。(GitHub)
仓库甚至要求每一个 Skill 都带有 scripts/selftest.mjs，而且自测不能调用模型、不消耗额度，用于覆盖确定性逻辑。(GitHub)
这件事情看起来很“程序员”，但实际上恰恰可能是 AI Agent 产品化的关键。
因为模型本身是不稳定的。
今天它理解正确，明天可能就换一种表达。
如果整个系统的正确性完全依赖模型，那么每次模型升级，都可能让工作流悄悄退化。
但如果把能够确定的规则交给代码：
模型负责创造，代码负责验收。
系统就会稳定很多。
八、它真正展示的是一种新的“AI 制作团队”
从这个角度看，shuohao-skills 并不只是几个 Skill 的集合。
它更像是一支虚拟制作团队：
改编策划负责小说 → 短剧结构；
角色设计师负责角色资产；
美术指导负责场景和道具；
编剧负责剧本；
分镜师负责镜头；
镜头语汇库则提供标准化的视觉语言。
而 Claude Code / Codex 充当的是连接这些岗位的 Agent 执行环境。
这也是为什么它选择 Skill，而不是一个巨大 Prompt。
一个巨大 Prompt 的问题是：
所有事情都混在一起。
Skill 的优势则是：
每个阶段都有明确输入、输出和职责。
这让整个流程更接近软件工程中的模块化设计。
九、开源方式也很值得借鉴
从工程实现来看，仓库采用了比较明确的自包含结构。
每个 Skill 都有自己的 SKILL.md、README、脚本、参考资料和示例，并要求拥有独立的自测脚本。安装脚本可以自动检测 Claude Code 或 Codex，并通过软链接安装 Skill，因此更新仓库后无需重复安装。(GitHub)
目前项目采用 Apache 2.0 License。(GitHub)
这意味着它并不是一个只适合作者自己电脑使用的 Prompt 集合，而是在尝试建立一种可以复制、测试和扩展的 Agent Skill 工程规范。
对于想自己构建 AI Agent 工作流的人来说，这一点甚至比短剧本身更加值得研究。
十、最值得学习的，不是某个 Prompt，而是这套方法论
如果把 shuohao-skills 抽象一层，会得到一个很有价值的 AI Agent 工作流模型：
1. 把复杂任务拆成阶段
不要让一个 Agent 从头做到尾。
2. 每个阶段产生结构化资产
不要只输出 Markdown。
角色应该有角色数据，场景应该有场景数据，剧本应该有结构化信息。
3. 给资产建立唯一身份
角色、场景、道具、镜头都应该能够被后续阶段引用。
4. 把确定性规则交给代码
数量、ID、引用关系、时长、字段完整性等问题，不应该浪费模型能力。
5. 让上下游存在明确边界
上游做决定，下游负责执行。
6. 用测试保护工作流
模型可以变化，但确定性的规则应该持续可验证。
这套方法不仅适用于 AI 短剧。
它同样适用于：
- 游戏剧情生产；
- 动画制作；
- 广告创意生产；
- 长篇小说改编；
- AI 漫画；
- 虚拟人内容生产；
- 产品宣传视频；
- 企业培训视频。
结语：AI 内容生产正在从“聊天”走向“流水线”
过去我们讨论 AI 创作，经常讨论的是：
哪个模型写得最好？
哪个模型画得最好？
哪个视频模型效果最好？
但当 AI 真正进入规模化生产之后，问题会逐渐变成：
这些模型能不能被组织起来？
shuohao-skills 的价值，恰恰在于它没有试图制造一个“无所不能的超级 Prompt”，而是把一部短剧拆成多个可执行、可验证、可复用的生产环节。
从小说到大纲，从大纲到角色和美术资产，从剧本到分镜，再到最终生成管线，它试图建立的其实是一套 AI 原生的内容工业流程。
这可能也是未来 AI Agent 最值得关注的方向之一：
模型越来越像“工人”，而真正决定生产效率的，是工作流。
当 Prompt 变成 Skill，当 Skill 变成 Pipeline，当 Pipeline 再变成可测试、可复用的生产系统，AI 内容创作才真正开始从“会生成”走向“能生产”。
暂无评论内容