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