← 返回帮助

🎬 故事台卡 · 完整生产流水线架构

一张确认的故事卡,从进入生产到写出每一集正文,中间经过哪些环节 —— 尤其是「每一个场景的戏,究竟从哪里开始写」

[STORY-CARD PRODUCTION PIPELINE · incremental spine mode]runOriginal → runOriginalIncremental · server/src/novel-runtime/

先看结论:场景的戏,是分两层写出来的

很多人以为「写场景」是一步。其实在本系统里,一场戏的诞生分成两层,中间隔着一次交接:

分场·逐场蓝图层buildOriginalConstraints → planOneEpisode):把「本集」拆成若干「场」,每一场先写出一段逐拍蓝图(summary)——这一场逐拍发生什么、谁对谁做成什么、落定动作是什么。这是场戏第一次成形,但还是「设计稿」,不是剧本文字。

逐场写正文层renderOriginal → renderScene → 写手):拿着上一步每一场的蓝图,一场一次 LLM 调用,把蓝图展开成真正的剧本正文——【场次头】、△动作、角色(语气):台词。这才是「写每一个场景的戏」的那一步。

→ 我们最近调的「短剧投稿格式 / 台词是主食 / △ 动作纪律 / 去外貌padding」,全部作用在 第 ②层(写手 v2-format-locked)。而「一场里发生什么事、几个节拍」,主要由 第 ①层(分场蓝图)决定。想换思路,先想清楚要动哪一层。

一次性前置环节(每部剧一次) 每集循环(逐集重复) 场戏成形 场戏成文
A故事卡 → 故事前提(G1)premiseOverride · premise.json

用户在故事台选中的卡(StoryCardAuthorized)被合成为 OriginalPremise:直接走 premiseOverride 入口,引擎不再重新生成/评选卡。若无卡则走点子锦标赛生成前提。

确认的故事卡 / 一句点子 标题·核梗·题材·主角·控制性主题·canonFacts
B脊梁路由routeSpine()

从前提解释型路由出主线脊梁(progression 升级 / reckoning 清算 / romance-approach 靠近 / survival-expedition 求生 / operations 经营 …)。脊梁决定这部戏的「节奏招式」与状态账。

spineKey + 可选副脊梁
C人物网(G2)buildCharacterWeb() · character-web.json

主角 / 对手 / 配角,各自的人格原型、独门办法、可见限制、声口与关系。人物网是后面所有环节的「唯一人物正典」,姓名/性别/身份不许串换。

protagonist / opponent / others + 声口表
D覆盖层规划(按题材,可选)planActionSetpieces / planCampaignLadder / synthesizeGrowthBible

按脊梁与题材,预置可选覆盖层:动作/奇观场面卡(打斗题材)、战役阶梯(战争题材)、升级圣经(progression)。它们是给下游分场/写手的世界事实,不是硬闸门。

setpiece-plan / campaign-ladder / growth-bible
E脊梁百科 / 全局蓝图synthesizeSpineBible() · spine-bible

合成全局「轻锚专项账 / 百科」(progression 走升级圣经,不出百科)。至此一次性前置环节结束,进入逐集循环。

全局百科 / 脊梁蓝图 · 锚点规则
🔁 每集循环 for epNo = 1 … writeEpisodes
总集数(如 24)只决定「规划到多远」;writeEpisodes 决定「实际写出几集正文」。以下每一集依次重复。
F1本集创作蓝图planNextEpisodeIncremental() · episode-plan.json

从「已写正文 + 状态账」派生本集规划:3秒钩子 / 主打情绪 / 集尾卡点 / 本集节拍 / 三引擎升级 / 反转类型 / 欲望按钮 / 脊梁证明 / 因果骨架(causalLedger)/ 必演场这一步决定「本集发生什么」,还没到「场」。

前情状态 + 脊梁 + 覆盖层 本集 EpisodePlanItem(集级蓝图)
F2分场 · 逐场蓝图buildOriginalConstraints() → planOneEpisode()

把本集拆成若干「场」(场数由内容定)。每场用一次 LLM 产出一段 逐拍蓝图 summary + eventAnchor(本场唯一事件)、irreversibleAction(落定动作)、lastImage(最后画面)、sceneShape、欲望按钮、反转类型…

这一步还会注入:人性招式 / 场景炸药包 / 各种透镜(量级 · 亲密 · 喜剧 · 动作价值)/ 媒介档 scriptProfile;并做「猩猩测试」机器修 + 连续性责编去重(防后场把前场再演一遍)。分场风险信号只做顾问、不阻断。

本集蓝图 + 人物网 + 透镜 RewriteConstraints.scenes[](每场一份逐拍蓝图,仍是设计稿)
F3逐场写正文renderOriginal() → renderScene() → pickWriterBuilder(writerVersion)

拿着 F2 每一场的蓝图 summary,一场一次 LLM 调用,写成真正的剧本正文。这里选择写手版本(v1-current 冻结基线 / v2-format-locked 短剧投稿标准格式),落地【场次头】+ △动作 + 角色(语气):台词,媒介档与各透镜也在此落到文字。

→ 「台词是主食 / △ 动作纪律 / 连招浓缩 / 去外貌padding / 开场提速」都是这一层的写手指令。换写手 = 换这一步的 builder,蓝图(F2)不动。

每场 SceneBeat.summary(蓝图) 每场剧本正文文本
F4健康检查 + 元语汇清洗unhealthy() · scrubMetaLeaks()

正文健康度异常则重写一次;清洗「集/剧本/编剧/观众」等元语汇泄漏。仍是机器修,不打回。

F5责编复盘 + 状态吸收review(顾问) · absorbWrittenEpisode()

责编只出顾问信号写进 review.json(不阻断);状态吸收把本集发生的不可逆事实 / 关系变化 / 未了钩子写回状态账,供下一集的 F1 读走——这就是「增量」的闭环。

F6落盘screenplay/ep-NNN/episode.md

本集正文写入标准项目布局,自动出现在剧本工厂 #/screenplay。循环回到 F1 写下一集。

写手版本注册表(可回退不动 git)

v1-current 冻结、永为默认;v2-format-locked 为并存新分支,靠 writerVersion flag 选择。调旋钮改坏了,把 flag 切回 v1 即可,不必 git revert。作用点= F3。

媒介档 scriptProfile(opt-in)

short-drama / tv-series / film。影响 F2 的场景颗粒与 F3 的台词/非台词配比。不传=与历史行为一致。作用点= F2 + F3。

为什么分两层

「一场发生什么事」(F2 蓝图)与「这场戏怎么写成字」(F3 正文)是两个问题。分开后可以只换写手不动剧情,也可以只改分场不换写手 —— 换思路时先定位到底要动哪一层。

顾问 ≠ 闸门

分场风险、责编复盘、健康检查全是顾问/机器修,不打回、不阻断(播放器必须出声)。唯一「硬」的是写手版本与格式契约。