一个小时如果多个模型写，那内容还能贯通吗？不是一个模型处理完菜呢记住上下文吗？

可以贯通，但前提是：**不能依赖“某一个模型自己记住上下文”**。

你要做 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
同一章一个主写模型
连续章节按顺序写
每章写完必须更新记忆
所有模型都读取同一个小说圣经和上下文快照
短剧/听书基于小说版本快照派生
```

一句话：

> **不是让一个模型记住全部，而是让你的系统成为“小说大脑”。模型只是不同岗位的员工，每次上岗前都读取同一份档案。**