feat: expand novel IP and production workflows

2026-09-18 08:14:05 +02:00
parent b2ae4600b4
commit d9c81a3ac0
235 changed files with 117971 additions and 2721 deletions
@@ -0,0 +1,415 @@
+那小说呢 ，也是要安排好每个章节的大纲核心？然后每次提交api 生成一个章节？
+
+对，**小说也应该像短剧分镜一样，先安排好每章的大纲核心，然后每次 API 只生成一个章节**。
+
+但小说和视频分镜有一个区别：
+
+> **视频分镜可以相对独立；
+> 小说章节必须更重视上下文承接。**
+
+所以小说不能只是“第 1 章、第 2 章、第 3 章各自独立生成”。
+正确流程是：
+
+```text
+全书总纲
+↓
+分卷大纲
+↓
+章节大纲 / 章节卡
+↓
+每次 API 生成 1 章
+↓
+章节质检
+↓
+章节记忆更新
+↓
+下一章基于最新记忆继续生成
+```
+
+---
+
+# 一、小说章节就像“剧集分场”
+
+你的理解可以这样类比：
+
+| 短剧系统      | 小说系统       |
+| --------- | ---------- |
+| 全剧设定      | 小说圣经       |
+| 分集大纲      | 分卷大纲       |
+| 分镜脚本      | 章节卡        |
+| 每个镜头单独生成  | 每个章节单独生成   |
+| 场记保证连续性   | 章节记忆保证连续性  |
+| 角色锚点保证不换脸 | 人物状态保证不崩人设 |
+| 分镜质检      | 章节质检       |
+
+所以小说系统也应该“先规划，再逐章生产”。
+
+---
+
+# 二、不能一次让 AI 写很多章
+
+不要这样：
+
+```text
+请一次性写第1章到第10章
+```
+
+这样很容易出现：
+
+人设飘；
+伏笔乱；
+章节水；
+节奏失控；
+上一章结尾和下一章开头接不上；
+某些重要情绪跳过去。
+
+正确做法是：
+
+```text
+一次只写一章。
+写完一章，立刻更新记忆。
+下一章再根据最新记忆写。
+```
+
+最多可以一次生成“章节大纲”，但正文最好一章一章来。
+
+---
+
+# 三、章节卡是小说流水线的核心
+
+每一章生成前，都要先有一张“章节卡”。
+
+章节卡就像短剧分镜的拍摄单。
+
+一张合格章节卡应该包含：
+
+```text
+章节编号
+章节标题
+本章目标
+本章开场承接
+本章主要冲突
+本章出场人物
+本章场景
+本章必须发生的事件
+本章人物状态变化
+本章新增伏笔
+本章推进伏笔
+本章回收伏笔
+本章禁止事项
+本章结尾钩子
+本章适合改编短剧的场景
+```
+
+比如：
+
+```json
+{
+  "chapter_no": 12,
+  "title": "五种笔迹",
+  "chapter_goal": "岑青发现林照名字下有五种不同笔迹",
+  "opening_from_previous": "承接上一章姚知知说‘她有好几双手’",
+  "main_conflict": "岑青追查旧签到簿，物业试图阻止她查看仓库记录",
+  "characters": ["岑青", "裴让", "陈淑蘅", "物业管理员"],
+  "scenes": [
+    {
+      "location": "海风大厦负一层仓库",
+      "purpose": "找到旧签到簿",
+      "visual_value": "手电照在潮湿纸页上，五种笔迹露出来"
+    }
+  ],
+  "must_happen": [
+    "岑青找到旧签到簿",
+    "同一个林照名字下面出现五种笔迹",
+    "陈淑蘅看到签到簿后明显紧张",
+    "裴让提醒岑青证据还不够"
+  ],
+  "foreshadows_to_add": [
+    "签到簿中间缺了一页"
+  ],
+  "foreshadows_to_advance": [
+    "林照不是一个人"
+  ],
+  "must_not_happen": [
+    "陈淑蘅不能立刻说出全部真相",
+    "不能直接揭示周榕真实身份",
+    "不能让物业管理员脸谱化成坏人"
+  ],
+  "ending_hook": "岑青发现签到簿被撕掉的一页，撕口很新",
+  "adaptation_notes": {
+    "short_drama_value": "适合改成悬疑揭示场景",
+    "key_visual": "五种笔迹",
+    "key_prop": "旧签到簿"
+  }
+}
+```
+
+有了这张章节卡，模型生成正文就不容易乱。
+
+---
+
+# 四、每次 API 生成章节时传什么？
+
+不要传全部小说正文。
+
+每次传：
+
+```text
+1. 小说圣经摘要
+2. 当前卷纲
+3. 最近 3-5 章摘要
+4. 本章出场人物当前状态
+5. 本章相关伏笔
+6. 本章章节卡
+7. 文风规则
+8. 禁止事项
+```
+
+例如写第 12 章时，传：
+
+```json
+{
+  "bible_summary": "现实主义悬疑小说，核心主题是被城市抹去的人如何重新被确认……",
+  "current_volume_outline": "第一卷：寻找不存在的林照。核心任务是让岑青从单人英雄叙事走向多人身份真相。",
+  "recent_chapter_summaries": [
+    "第9章：岑青采访九楼医生，得知林照每天凌晨修灯。",
+    "第10章：姚知知画出多只不同的手。",
+    "第11章：裴让找到门禁记录异常，同一时间两个楼层出现林照。"
+  ],
+  "character_states": [
+    {
+      "name": "岑青",
+      "state": "已经怀疑林照不是一个人，但缺少证据"
+    },
+    {
+      "name": "陈淑蘅",
+      "state": "知道林照身份共用真相，但还在隐瞒"
+    }
+  ],
+  "active_foreshadows": [
+    {
+      "code": "F003",
+      "title": "姚知知画中的五只手",
+      "status": "developing"
+    }
+  ],
+  "chapter_card": {},
+  "style_rules": [
+    "克制",
+    "电影感",
+    "不煽情",
+    "不狗血",
+    "对白短而有张力"
+  ]
+}
+```
+
+这样写到第 100 章，传的上下文也不会无限变大。
+
+---
+
+# 五、小说章节生成流程应该这样设计
+
+你的自动化流水线可以按这个步骤跑：
+
+```text
+01 创建小说项目
+02 生成小说圣经
+03 生成全书粗纲
+04 生成第一卷细纲
+05 生成第 1 章章节卡
+06 调用 API 写第 1 章正文
+07 调用 API 润色第 1 章
+08 调用 API 质检第 1 章
+09 如果不合格，自动修复或重写
+10 保存终稿到 NovelChapter
+11 更新章节摘要、人物状态、伏笔状态
+12 生成第 2 章章节卡
+13 重复流程
+```
+
+也就是：
+
+```text
+章节卡 → 正文 → 质检 → 记忆更新 → 下一章
+```
+
+这和你现在短剧的：
+
+```text
+分镜 → 视频片段 → 候选 → 质检 → 合成
+```
+
+逻辑是一样的。
+
+---
+
+# 六、章节正文最好一章一章串行生成
+
+可以并发的内容：
+
+```text
+生成角色视觉档案
+生成场景资产
+生成伏笔表
+生成章节卡
+生成听书稿
+生成短剧适配
+生成封面
+生成标题
+```
+
+但正文最好：
+
+```text
+第1章完成 → 更新记忆 → 第2章
+第2章完成 → 更新记忆 → 第3章
+第3章完成 → 更新记忆 → 第4章
+```
+
+不要这样并发：
+
+```text
+模型A写第1章
+模型B同时写第2章
+模型C同时写第3章
+```
+
+因为第 2 章需要知道第 1 章最后实际写成什么，第 3 章也需要承接第 2 章。
+
+---
+
+# 七、长篇小说最稳的“章级流水线”
+
+你可以照这个做后台任务。
+
+```text
+GenerateChapterCardJob
+↓
+WriteChapterDraftJob
+↓
+PolishChapterJob
+↓
+QualityCheckChapterJob
+↓
+RepairChapterJob，可选
+↓
+FinalizeChapterJob
+↓
+UpdateNovelMemoryJob
+↓
+PrepareNextChapterJob
+```
+
+如果某章评分不够：
+
+```text
+低于 75 分 → 整章重写
+75-84 分 → 局部修复
+85 分以上 → 通过
+```
+
+如果连续 3 次修不好：
+
+```text
+进入人工审核
+```
+
+这样能自动化，但不会让系统一路写崩。
+
+---
+
+# 八、章节卡和短剧改编要提前关联
+
+你后续要做小说 / 听书 / 短剧同步，所以章节卡里要提前有改编字段。
+
+比如：
+
+```json
+{
+  "chapter_no": 12,
+  "title": "五种笔迹",
+  "adaptation": {
+    "audio_value": "适合听书悬疑推进，重点突出签到簿发现过程",
+    "drama_value": "适合短剧第4集核心揭示",
+    "visual_scenes": [
+      "负一层仓库寻找签到簿",
+      "手电照亮五种笔迹",
+      "陈淑蘅看到签到簿后沉默"
+    ],
+    "key_dialogues": [
+      "你们要真相，是因为你们有地方放真相。我们没有。"
+    ],
+    "props": [
+      "旧签到簿",
+      "手电",
+      "门禁卡"
+    ]
+  }
+}
+```
+
+这样后面生成短剧和听书时，就不用重新从小说里硬拆。
+
+---
+
+# 九、小说系统和短剧系统的对应关系
+
+```text
+小说圣经
+↓
+短剧 StoryBible
+
+小说人物档案
+↓
+短剧 Character / ActorProfile
+
+小说章节
+↓
+短剧 Episode 或 EpisodeScript
+
+小说章节卡里的 visual_scenes
+↓
+短剧 StoryboardShot
+
+小说关键对白
+↓
+短剧对白 / 配音
+
+小说场景资产
+↓
+短剧 Location / Prompt Builder
+
+小说道具资产
+↓
+短剧 Props / 分镜 Prompt
+```
+
+所以章节卡越结构化，后续短剧越省事。
+
+---
+
+# 十、最终答案
+
+对，小说也应该这样：
+
+> **先安排全书、分卷、每章大纲核心；
+> 然后每次提交 API 生成一个章节；
+> 写完章节后更新记忆，再生成下一章。**
+
+最稳结构是：
+
+```text
+小说圣经
+→ 分卷大纲
+→ 章节卡
+→ 单章 API 生成
+→ 章节质检
+→ 章节记忆更新
+→ 下一章
+```
+
+一句话：
+
+> **视频靠分镜控制画面；小说靠章节卡控制剧情。
+> 分镜是拍摄执行单，章节卡就是写作执行单。**