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,519 @@
+一个小时如果多个模型写，那内容还能贯通吗？不是一个模型处理完菜呢记住上下文吗？
+
+可以贯通，但前提是：**不能依赖“某一个模型自己记住上下文”**。
+
+你要做 API 自动流水线，正确思路是：
+
+> **不是让模型记住小说，
+> 而是让你的系统记住小说，
+> 每次调用模型时，把它当前需要知道的上下文喂给它。**
+
+所以多个模型写完全没问题。关键在于你系统里要有一个**统一记忆中台 / 小说状态库 / Context Builder**。
+
+你当前项目已经有 `MemoriesModule`、`StoryBiblesModule`、`CharactersModule`、`EpisodesModule`、`ScriptsModule`，也有小说库和真人短剧流程，所以架构基础是能承接这个设计的。
+
+---
+
+# 一、为什么不能靠一个模型“自己记住”？
+
+API 调用和你在 ChatGPT 里连续聊天不一样。
+
+API 每次调用本质上都是：
+
+```text
+你给模型一段输入
+模型返回一段输出
+调用结束
+```
+
+模型不会天然记得上一章写了什么，除非你下一次调用时重新把必要上下文传进去。
+
+所以不管你用一个模型，还是多个模型，都必须做：
+
+```text
+数据库保存上下文
+↓
+每次写新章前拼装上下文
+↓
+模型根据上下文写
+↓
+写完后更新数据库记忆
+```
+
+这才是稳定方案。
+
+---
+
+# 二、多个模型会不会导致风格乱？
+
+会有风险，但可以控制。
+
+核心不是“只能用一个模型”，而是要有一个**统一的小说圣经和风格规则**。
+
+每个模型写作前都必须收到同一套规则：
+
+```text
+小说圣经
+人物档案
+世界观规则
+文风规则
+禁用桥段
+前 3-5 章摘要
+当前人物状态
+当前伏笔状态
+本章章节卡
+```
+
+这样即使用 Claude 写正文、GPT-5.5 做质检、豆包做对白优化，它们也都围绕同一个“项目记忆”工作。
+
+真正的主控不是某个模型，而是你的系统。
+
+---
+
+# 三、正确的理解方式
+
+你可以把它理解成拍电影。
+
+不是一个人从头到尾完成所有工作。
+
+```text
+总导演：控制整体风格
+编剧：写剧情
+分镜师：拆镜头
+演员指导：控制角色表现
+剪辑师：控制节奏
+审片人：检查问题
+```
+
+不同人参与，电影仍然能统一，是因为有：
+
+剧本；
+人物设定；
+导演风格；
+分镜表；
+连续性记录；
+制片流程。
+
+AI 小说流水线也一样。
+
+多个模型能贯通，靠的是：
+
+```text
+小说圣经 + 上下文记忆 + 章节卡 + 质检回写
+```
+
+不是靠某个模型脑子里一直记着。
+
+---
+
+# 四、你的系统里应该谁来“记住上下文”？
+
+应该由这 5 个东西记住。
+
+## 1. NovelBible / IPBible
+
+保存最高设定。
+
+包括：
+
+故事主题；
+世界观；
+人物设定；
+主线；
+分卷结构；
+风格要求；
+禁止事项；
+短剧改编规则。
+
+它是全书宪法。
+
+---
+
+## 2. CharacterState
+
+保存人物当前状态。
+
+比如：
+
+岑青当前知道了什么；
+陈淑蘅有没有说出真相；
+周榕是否已经被确认；
+人物关系发展到哪里；
+谁受伤了；
+谁还隐藏秘密。
+
+不能只保存初始人设。
+长篇必须保存“当前状态”。
+
+---
+
+## 3. ChapterMemory
+
+每章写完后保存摘要。
+
+例如：
+
+```text
+第 12 章：
+岑青在清洁间逼问陈淑蘅，陈承认“林照”不是一个人，但拒绝说出其他女工名字。新增伏笔：旧签到簿中有一页被撕掉。下一章必须追查被撕掉的一页。
+```
+
+下一章不需要塞完整正文，只要塞这种摘要。
+
+---
+
+## 4. ForeshadowMemory
+
+保存伏笔。
+
+比如：
+
+```text
+F001：灰蓝外套被多人穿过
+状态：已揭示一半
+预计回收：第 18 章
+
+F002：签到簿被撕掉的一页
+状态：未回收
+预计回收：第 22 章
+```
+
+这样 AI 不会忘伏笔。
+
+---
+
+## 5. StyleMemory
+
+保存文风。
+
+比如：
+
+```text
+语言克制，不煽情。
+对白短，避免解释型台词。
+场景有电影感。
+不写狗血冲突。
+不写打脸复仇。
+每章至少有一个可视频化场景。
+```
+
+每次写作都传进去。
+
+---
+
+# 五、多个模型分工时，怎么保证贯通？
+
+推荐你这样设计：
+
+```text
+GPT-5.5：总控 / 章节卡 / 质检 / 记忆更新
+Claude：正文写作 / 文学润色
+豆包/Kimi：中文口语化 / 短剧对白 / 听书稿
+GPT-5.5：最终连续性检查
+```
+
+流程如下：
+
+```text
+1. Context Builder 从数据库取上下文
+2. GPT-5.5 生成章节卡
+3. Claude 根据章节卡写正文
+4. GPT-5.5 检查是否跑偏
+5. Claude 或豆包修稿
+6. GPT-5.5 更新记忆库
+7. 进入下一章
+```
+
+这里最关键的是第 1 步和第 6 步。
+
+只要上下文拼装和记忆更新稳定，多个模型就能贯通。
+
+---
+
+# 六、上下文拼装器才是核心
+
+你系统里要有一个：
+
+```text
+NovelContextBuilderService
+```
+
+每次写第 N 章，它自动拼：
+
+```json
+{
+  "bible_summary": "小说核心设定摘要",
+  "style_rules": ["克制", "电影感", "不狗血"],
+  "forbidden_rules": ["不能提前揭露周榕", "不能让陈淑蘅主动全盘交代"],
+  "current_volume_outline": "当前卷纲",
+  "recent_chapter_summaries": [
+    "第10章摘要",
+    "第11章摘要",
+    "第12章摘要"
+  ],
+  "active_characters": [
+    {
+      "name": "岑青",
+      "current_state": "已经发现林照可能不是一个人，但还没有证据闭环"
+    }
+  ],
+  "active_foreshadows": [
+    {
+      "code": "F002",
+      "title": "被撕掉的签到页",
+      "status": "developing"
+    }
+  ],
+  "chapter_card": {
+    "chapter_no": 13,
+    "goal": "追查签到簿缺页",
+    "ending_hook": "缺页出现在姚知知的画本里"
+  }
+}
+```
+
+模型拿到这个上下文，就算换模型，也知道该怎么写。
+
+---
+
+# 七、一个模型从头写到底，反而不一定最好
+
+你担心多个模型不连贯，这个担心是对的。
+但“一个模型从头到尾写”也有问题。
+
+它可能：
+
+写着写着人设变；
+越写越水；
+忘记伏笔；
+重复表达；
+章节节奏越来越像模板；
+自己发现不了自己的问题。
+
+所以更好的方案是：
+
+```text
+一个模型负责创作
+另一个模型负责审稿
+系统负责记忆
+```
+
+也就是：
+
+> **模型写，不让模型自己当唯一裁判。**
+
+---
+
+# 八、你这个系统最稳的配置
+
+我建议你分三种模式。
+
+## 模式 1：精品模式
+
+适合投稿、精品短剧、重点 IP。
+
+```text
+GPT-5.5：小说圣经、章节卡、质检、记忆
+Claude：正文初稿、文学润色
+豆包/Kimi：中文对白优化、短剧口语化
+GPT-5.5：最终一致性检查
+```
+
+质量最好，成本最高。
+
+---
+
+## 模式 2：平衡模式
+
+适合批量生产可用小说。
+
+```text
+GPT-5.5：小说圣经、章节卡、质检
+豆包小说 2.0 Pro：正文初稿
+Kimi/通义：润色
+GPT-5.5：记忆更新和抽检
+```
+
+性价比最高。
+
+---
+
+## 模式 3：低成本模式
+
+适合测试题材。
+
+```text
+豆包/Kimi：章节卡和正文
+DeepSeek/通义：摘要和记忆
+GPT-5.5：每 5 或 10 章做一次总审
+```
+
+成本低，但精品率低。
+
+---
+
+# 九、不要让多个模型同时写同一章
+
+这里要注意。
+
+多个模型可以协作，但不要这样：
+
+```text
+Claude 写前半章
+豆包写后半章
+Kimi 写结尾
+```
+
+这样很容易断风格。
+
+正确做法是：
+
+```text
+同一章只让一个主写模型完成完整正文
+其他模型只做检查、润色、对白优化
+```
+
+例如：
+
+```text
+第 13 章：
+Claude 写完整正文
+GPT-5.5 检查
+豆包只优化对白
+Claude 最后统一润色
+```
+
+这样风格才不会碎。
+
+---
+
+# 十、并发怎么做？
+
+如果你想“一小时多模型并发生产”，不能并发写连续章节。
+
+错误方式：
+
+```text
+模型 A 写第 1 章
+模型 B 同时写第 2 章
+模型 C 同时写第 3 章
+```
+
+因为第 2 章需要知道第 1 章最后真实写成什么，第 3 章又依赖第 2 章。
+
+这样必乱。
+
+正确并发方式是：
+
+```text
+第 1 章正文生成中
+同时可以并发：
+- 生成角色视觉资产
+- 生成场景资产
+- 生成听书稿结构
+- 生成封面提示词
+- 生成质量评估候选
+```
+
+连续章节最好还是串行。
+
+可以做“半并发”：
+
+```text
+先生成第 1-10 章章节卡
+然后第 1 章正文完成后，更新记忆
+再写第 2 章
+```
+
+章节卡可以提前批量生成。
+正文最好按顺序生成。
+
+---
+
+# 十一、最推荐的自动化流程
+
+你可以这样跑：
+
+```text
+1. 一次性生成全书粗纲
+2. 一次性生成前 30 章章节卡
+3. 第 1 章正文生成
+4. 第 1 章质检
+5. 第 1 章修复
+6. 第 1 章记忆更新
+7. 第 2 章根据最新记忆重新校准章节卡
+8. 第 2 章正文生成
+9. 循环
+```
+
+也就是说，章节卡可以提前，但每章写作前要允许重新校准。
+
+---
+
+# 十二、你需要在后台加一个“上下文快照”
+
+每次模型调用前，都保存它当时看到的上下文。
+
+表可以叫：
+
+```text
+AgentRunContextSnapshot
+```
+
+保存：
+
+```json
+{
+  "agent_name": "ChapterWriterAgent",
+  "model": "claude-opus",
+  "chapter_no": 13,
+  "input_context": {},
+  "output_text": "",
+  "quality_score": 88
+}
+```
+
+为什么要保存？
+
+因为后面如果某章写崩了，你要知道：
+
+模型当时看到了什么；
+是不是上下文少了；
+是不是章节卡错了；
+是不是模型自己跑偏；
+是不是质检漏了。
+
+这个对调试非常重要。
+
+---
+
+# 十三、最终答案
+
+多个模型可以写，而且适合你的系统。
+
+但不能靠模型自己记住。
+要靠你的系统记住。
+
+正确架构是：
+
+```text
+数据库 = 长期记忆
+NovelContextBuilder = 上下文拼装器
+GPT-5.5 = 总编剧 / 质检 / 记忆更新
+Claude = 主写手
+豆包/Kimi = 中文短剧对白和听书本土化
+```
+
+最关键规则：
+
+```text
+同一章一个主写模型
+连续章节按顺序写
+每章写完必须更新记忆
+所有模型都读取同一个小说圣经和上下文快照
+短剧/听书基于小说版本快照派生
+```
+
+一句话：
+
+> **不是让一个模型记住全部，而是让你的系统成为“小说大脑”。模型只是不同岗位的员工，每次上岗前都读取同一份档案。**