我把短剧创作拆成了 12 个可复用模块：一套 creator-first 的 AI 创作工作流

一、起因：一个人干一个团队的活

写短剧这件事，传统流程是一个团队：编剧写剧本、美术出视觉、导演弄分镜、后期做剪辑、责编把质量关。我一个人全干，还要保证每集质量稳定——靠意志力是不行的，必须靠工作流。

于是我把整套创作过程拆成了 12 个技能模块，每个模块只干一件事，模块之间用清晰的契约连接。这篇文章讲这套系统的设计思路，以及那些「不设计好就会反复踩」的机制。

二、核心设计：creator-first 五文档

整套系统的心脏是一个叫 creator-first 的原则：每一集只维护五份 Markdown 文档——

文档	内容	owner 技能
`剧本.md`	单集剧本	short-drama-write
`视觉设定.md`	人物/造型/地点/道具	short-drama-assets
`分镜.md`	镜头与冻结关键帧	short-drama-storyboard
`图片提示词.md`	资产图片提示词	short-drama-image-prompts
`视频提示词.md`	视频/时间线音乐提示词	short-drama-video-prompts

关键决策：不建立并行的结构化创作真相。也就是说，不存在「数据库里存一份结构化剧本、Markdown 里再存一份」的情况——五份文档就是唯一真相。结构化数据只在需要时从文档派生，派生品用完即弃。这个决策省掉了大量「两边的数据对不上」的同步噩梦。

三、路由表：12 个模块各司其职

系统入口是一个路由技能，用户任何请求按类型分派：

用户要做什么	去向
开发点子、系列承诺、改编分集	short-drama-develop
分析长篇原著（值不值得改）	short-drama-novel-analyze
写或改单集剧本	short-drama-write
拆人物、造型、地点、道具	short-drama-assets
写资产图片提示词	short-drama-image-prompts
做镜头和冻结关键帧	short-drama-storyboard
写视频/音乐提示词	short-drama-video-prompts
实际生成媒体	short-drama-produce
剪成成片	short-drama-edit
审稿校验	short-drama-review
项目初始化、Dashboard	short-drama（路由本身）

路由的第一条纪律：不为补齐名义流水线伪造上游。用户直接拿来一个现成剧本要拆资产，就从拆资产开始，不逼他先补一份大纲。流水线是服务创作的，不是伺候流水线。

四、三个关键机制（这才是系统的灵魂）

机制 1：决策档案——会话里说的，必须落盘

创作里有很多项目级决定：目标视频模型、画幅、单集时长、提示词语言。这些决定在对话里说一次，下一轮会话就忘了，然后方言和时长要重猜，前后集不一致。

解法是决策档案，而且是三步不是一步：

# 1) 先写一条决策记录（JSONL，带 decision_id）
{"decision_id":"CD-H3","status":"accepted","accepted_value":{"target_video_model":"minimax-h3",...}}

# 2) 发布 + 接受
project_tool.py publish <project> --owner short-drama --artifact-id AR-PROFILE ...
project_tool.py accept <project> --artifact-id AR-PROFILE --decision accepted

# 3) 写入权威字段
project_tool.py set-authority <project> --field /creator_authority/production_profile/choices ...

档案只接受已发布且已接受的创作者决策，状态只有 accepted 和 unset 两态——unset 表示还没决定，不造中间状态。这个设计的价值：任何跨阶段的决定都有据可查，换一个会话接手也不会走样。

机制 2：生产边界——preview → confirm → run

外部媒体生产（烧的是真金白银的 GPU 时间）永远保留三道门：先预览，再显式确认，最后运行。没有任何「AI 觉得可以就直接生成」的通道。生成前的预览单就是给创作者的最后一眼。

机制 3：Dashboard 脱离会话

创作台是个本地 Web 服务，关键在 --detach——服务进程脱离当前 shell 独立运行，会话结束、终端关闭、智能体退出都不影响它。地址和 pid 记录在 .short-drama/dashboard.json，同一 workspace 重复启动只打印同一个链接，不開第二个端口。

这个坑是真金白银学来的：早期版本 Dashboard 挂在会话上， Agent 一退出创作台就没了，创作者正看着呢，页面死了。

五、交付边界：export 不伪造审批

项目导出用 export 打包当前状态（五份文档 + 制作成果），附 manifest 和 checksum，排除私有输入、凭据、绝对路径。

一个细节我特意写死在文档里：export 是当前状态快照，manifest 里 asserts_approval 恒为 false——它不声称任何审查或创作者接受。需要带审批证据的正式交付包走另一条路径。工具不伪造它没有做过的事，这条边界省掉了未来所有的扯皮。

六、视觉对账：并行支线的暗坑

图片提示词和分镜是可以并行的两条支线，但后完成的那支很容易引用另一支的旧状态。系统要求：请求横跨视觉设定、图片提示词、分镜时，结束前按当前五文档做一次视觉依赖对账——不因可并行，就把后完成的一支留在旧引用之外。

视频提示词阶段还有个真实高频场景：输入参考图缺失。系统的处理是给出三条路——把已有图片绑成 REF-...；用 PLAN-... 先写逐镜挂图计划照常产出；或明确改走文生视频——不把「没有手工指定」当成明确选择文生视频。三选一，把决策权还给创作者。

七、这套系统给了我什么

质量稳定：每集都走同一套契约，不靠状态起伏；
可接管：决策全部落盘，任何会话都能接着干；
可复用：12 个模块不止能用于这一部剧，下一部直接 init 开新项目；
可审计： export 边界清晰，交付物不带私货。

如果你也要搭 AI 创作工作流，我的建议就一条：先设计契约，再写模块。文档结构、决策档案、生产边界这三样想清楚了，模块反而是最便宜的部分。

下一篇讲这套系统里最重的一条生产线——本地 ComfyUI 出图出片的具体实战。