Drama Skills

一套给 AI 短剧与漫剧创作用的 agent 技能，共十一个，装进已经在用 Agent Skill 规范的助手——Claude Code、Codex，或任何认这个格式的环境——然后在项目目录里写 Markdown 来驱动。其中一个技能负责初始化项目与路由，另外十个覆盖原著分析与改编、故事开发、分集剧本、资产决策、图片提示词、分镜与冻结关键帧、指定目标模型的视频提示词、走 adapter 的确认后生产、剪辑成片和审查。最硬的约束是每集最多五份 Markdown，没有并行的数据库：剧本、视觉设定、分镜、图片提示词、视频提示词就是创作者读和改的东西，盘上其余文件都是脚本自己的记录。跨镜一致性写成可核对的事实而不是愿望：必须跨镜保持的造型变成一条连续性锁，锁面能原样贴进提示词；每一镜要说明依据了哪些设定集条目；参考图按状态区分，已经存在并检查过的、计划要挂的、还缺的，不会混在一起。生成要花钱，所以生产阶段会把这一批的准确内容打出来，创作者确认之前一个接口都不调。本地创作台是只监听回环的 Python 标准库服务加原生前端，读的还是同一批文件，不会变成第二个事实来源。

谁做的拥有并维护这个仓库的组织账号，README 里还列了同组织的另外五个项目。提交几乎全出自一个 GitHub 账号：332 次里 worldwonderer 占 329 次，MrChenfafafa 三次；作者字段在 pitechen、PiteChen、worldwonderer 之间来回换，324 次提交来自同一个邮箱地址。202 次提交带共同作者尾注，且全部指名某个 Claude 模型；README 说这套技能是从团队自 2025 年以来跑过的一千多个短剧项目里蒸馏出来的。

1. 01

   九十天、十八个版本，几乎每个提交都出自同一个名字

   仓库建于 2026-07-16，当天傍晚 22:50 的第一个提交写着「Open-source release: short-drama Agent Skill suite」。到 2026-09-28，它累计了 332 次提交——7 月 40 次、8 月 208 次、9 月 84 次——和十八个 release，从 2026-07-26 的 v0.1.0 到 2026-09-28 的 v0.8.1，另有一个始终没成为 release 的 tag v0.3.0-rc.1。版本标题本身就是日程表：v0.4.0 交付十个可独立安装的技能、确认后生产与八集 Golden Sample；v0.6.0 是 Creator-first 五文档工作流；v0.7.0 加入剪辑技能；v0.6.6 记下对白容量终于有了数字、几条模型断言被实测推翻。周围还有 2,413 个星、520 个 fork、8 个 watcher、1 个开着的 issue，以及约 74 MB 里的 558 个文件，MIT 许可，GitHub 归类为 Python。贡献者只有两个账号：worldwonderer 占 332 次里的 329 次，MrChenfafafa 三次；作者字段在 pitechen、PiteChen、worldwonderer 之间来回换，324 次提交来自同一个地址。202 次提交带共同作者尾注，每一条都指名某个 Claude 模型——Opus 5 一百一十一条、带百万上下文的 Opus 5 六十五条、Opus 5.5 十二条、Fable 5.1 九条、Opus 4.8 两条、Fable 5 两条、Opus 5.5 一条。它不是周末玩具：README 说这套技能是从团队 2025 年以来跑过的一千多个 AI 短剧／漫剧项目、以及近 8 万行逐渐维护不动的自建工具里蒸馏出来的，自建工具里只剩排队抽卡。

2. 02

   十一个技能，同一种形状，每条规则背后都有一个 Python 文件

   skills/ 下是十一个目录，长得几乎一样：一份 SKILL.md、一个放文字规则的 references/、一个放检查脚本的 scripts/、一个放模板与示例记录的 assets/，再加一个小小的 agents/openai.yaml——正是它让同一个目录在 Codex 里也看得见。short-drama 负责初始化项目、路由与创作台，另外十个是流水线上的各阶段。安装是一条命令 npx skills add zenstory-ai/drama-skills -y -g，或者把这些目录软链到 ~/.claude/skills、${CODEX_HOME:-$HOME/.codex}/skills；README 强调每个目录都是独立安装单元，2026-07-26 的一篇决策笔记把这条写成规则：一个技能不许引用另一个技能的文件。目录里的重量是代码而不是文字：edit_tool.py 130,747 字节、project_tool.py 101,685、production_tool.py 93,209、dashboard_server.py 83,782、creator_markdown_check.py 76,402、provider_adapters.py 70,718，分布在三十一个脚本文件里，每个脚本旁边都躺着一份 selftest.py。还有第十二个技能不在安装路径上，位于 maintainers/skills/short-drama-knowhow，装的是内部方法——盲评前向评估、卡片与覆盖、晋升台账——公共仓库并不安装它。

3. 03

   五份 Markdown，和它们底下的结构化记录

   一集最多五份 Markdown，旁边刻意不放数据库：剧本、视觉设定、分镜、图片提示词、视频提示词，等到剪片再多一份剪辑单。这个选择的代价写在检查器里。creator_markdown_check.py 读这五份文件，报的是原因而不是「校验失败」；README 把公开样例故意改坏两处来演示——一处是冻结关键帧提示词写到了本镜视觉依据没覆盖的人物，另一处是分镜写 2 秒而视频提示词写成 3 秒——于是打出两行报错，分别点出漏掉的人物和不一致的秒数。Markdown 底下还有一层结构化记录：样例改编的参考运行里，shots.jsonl 42,111 字节、motion-specs.jsonl 65,244、keyframes.jsonl 43,960、image-prompt-specs.jsonl 18,586，另有角色、地点、地点视图、造型、道具、道具状态、出现记录、连续性差量与创作者决策。跨镜一致性因此是文件事实而不是指望：必须跨镜保住的造型变成一条连续性锁，锁面能原样贴进提示词；参考图按状态而不是按文件名区分，计划的槽位不会被当成已经存在的图。

4. 04

   每条规则都写明谁有权执行它

   一条没法被反驳的建议没什么用，所以套件给每条规则贴上四级标签之一：structural_invariant 由脚本核对、可以直接阻断；reviewed_invariant 要求审查者引用证据；craft_default 通常能加强单集，创作者说明理由即可覆盖；taste_option 属于创作者——钩子形态、弧线形状、留多少白。2026-07-16 那篇笔记把这套东西叫「规则四级分级与脚本边界」，故事开发参考文档则把读者需要的那条线画出来：数字形式约束可以记为创作者的选择，但不能反过来证明剧情质量。于是数字住在项目里而不是套件里：develop 阶段提出一份节奏档案，创作者接受或改写后写进项目文件、状态才变成已接受；剧本、分镜与审查只拿已接受的数值做算术核对，未接受的档案算未声明，不算默认值。提出用的那张表对每种制作形态各有九个字段——第一个钩子最迟在第 5 秒、情绪触点间隔不超过 30 秒、每集至少一次有对手参与的反转、集尾停在峰值、下一集先接上一集最后一拍、旁白占可发声字数不超过 0.3、目标平均镜长真人 2.5 秒或漫剧 3.0 秒、近景类占比不低于 45%、第一个大爽点最迟在第 1 集——文档里好几个值被明确标成未实测的起点，而不是测量结果。

5. 05

   被测的是模型，所以他们真的去跑了

   这套套件关于视频模型的判断，大多写成 evaluations/model-behavior-probes.md 里的一行——一份 18,319 字节的实测日志，而不是转述别人的建议。PR #176 写了方法：约 170 条视频，模型是 MiniMax H3、Seedance 2.5 与 Wan 3.0，每组先跑基线臂，产物去掉臂身份后再盲判，往日志里追加十七行，然后才把结论写回各方言文件——9 秒三切、每切挂一张关键帧的容器把切点误差压在 0.12 秒内，生成次数只有三分之一；写具体取景赢过只写「medium shot」，后者八次里出了远景 3、中远景 3、中景 2；Wan 3.0 的中文自然语速约 4.6 字/秒，装不下的部分会被丢掉；本该闭嘴的内心独白，三种写法十二次里只有四次全程闭嘴，于是改法的方向变成让分镜把嘴放到画面外，而不是继续调措辞。PR #186 接着跑下一轮：反应镜配方在盲评里拿到清晰 3.9/5、自然 4.0/5；每场写一句光并挂定调图之后，第一场的亮度离散从 18.3 降到 6.6、冷暖离散从 9.3 降到 4.2；把同一角色另一句话的合成挂成音色参考，Wan 上相似度从约 0.3 升到 0.69，而 Seedance 只对一部分角色有效。数字后面永远跟着局限——每臂三次、一个镜头、一条执行路径——README 的常见问题也复述了这条边界：样本小，生成之后仍要核对。

6. 06

   社区报了什么，评审又找出了什么

   侦察报告里有三十个 issue 与 pull request 被整篇读过，从 #157 到 #187，外加 issue #168。那个 issue 是用户报告生成出来的视频把台词安到了错误的脸上；回复里量了十九条片段，发现每个说话段的基频都落在 300–370 Hz 的儿童区间——声音一直是对的——最后交付的是两条提示词写法，而不是一句保证。PR #157 则是反方向：一版成片交给了外部 Codex 评审，它找出了作者自己的度量全都没抓到的三处验收盲区。开场七镜从来没有生产过，却没有任何东西出声；画内文字不在任何验收表上，于是模型自己编的一句话正好停在全集落点上；接镜校色过冲，一段实测 −15.9 的镜头被校成 +8.7、成了全片最蓝，而全片色差范围反而更好看。这些修法后来都变成了能力：未采用的镜头必须逐个写出镜号和理由，v0.7.1 起连「001 至 009」这种范围写法都不再接受——拿同一份剪辑单去试，新规则立刻点出八个镜头。另一些 PR 修的是文字本身：一条已经硬化成跨模型禁令、又和工具实际能力冲突的建议被去掉；README 改成围绕真实产出，并补上十条常见问题，来源是若干 issue，验证方式按 PR 自己的说法是三轮独立对抗核对、共 16 个 agent。仓库也留着被否掉的东西：一份 13,546 字节的创作台方案躺在 rejected/ 里；笔记规则禁止把一篇笔记改写成相反的决定，所以 2026-09-27 用阶段视图取代单页创作台时，新笔记写明取代了旧笔记并互相链接。同一段时间里测试数从 568 走到 571、610、636 和 697，持续集成另有一个 Windows 任务专门回归安装、分集导入与创作台。