www
520 lines
9.9 KiB
Markdown
520 lines
9.9 KiB
Markdown
一个小时如果多个模型写，那内容还能贯通吗？不是一个模型处理完菜呢记住上下文吗？
|
|
|
|
可以贯通，但前提是：**不能依赖“某一个模型自己记住上下文”**。
|
|
|
|
你要做 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
|
|
同一章一个主写模型
|
|
连续章节按顺序写
|
|
每章写完必须更新记忆
|
|
所有模型都读取同一个小说圣经和上下文快照
|
|
短剧/听书基于小说版本快照派生
|
|
```
|
|
|
|
一句话：
|
|
|
|
> **不是让一个模型记住全部，而是让你的系统成为“小说大脑”。模型只是不同岗位的员工，每次上岗前都读取同一份档案。**
|