root/ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: expand novel IP and production workflows

Browse Source
This commit is contained in:
www
2026-09-18 08:14:05 +02:00
parent b2ae4600b4
commit d9c81a3ac0
235 changed files with 117971 additions and 2721 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/chatgpt/novel/1.md
+550
View File
@@ -0,0 +1,550 @@
一个长篇小说，怎么才能让ai记住上下文不乱？怎么写提示让ai 设计和写?
长篇小说让 AI 不乱，核心不是“一次性把所有设定塞进去”，而是建立一套**小说生产流程**：
> **总设定文档 → 分卷大纲 → 单章卡片 → 写作提示词 → 章节完成后更新记忆库**
AI 最容易乱的原因是：
人物设定没固定、剧情进度没记录、伏笔没管理、每次写章都把前文忘了、提示词只说“继续写”，没有告诉它“哪些东西不能改”。
---
# 一、长篇小说必须拆成 5 个文件
你不要只给 AI 一个大提示词，要把小说拆成 5 个“上下文文件”。
## 1. 世界观设定表
记录小说的底层规则。
包括：
世界类型；
时代背景；
城市 / 宗门 / 朝代 / 公司 / 学校；
力量体系；
社会阶层；
禁忌规则；
核心矛盾；
不能违背的世界规律。
比如修仙小说要写清楚：
境界等级；
寿命变化；
灵根规则；
法宝等级；
宗门结构；
丹药体系；
功法限制；
飞升规则；
主角金手指边界。
否则 AI 后面很容易乱加设定。
---
## 2. 人物档案表
每个重要角色都要建档。
必须包含：
姓名；
年龄；
身份；
外貌固定特征；
性格；
说话方式；
核心欲望；
恐惧；
秘密；
人物弧光；
和主角关系；
当前剧情状态；
禁止改动事项。
尤其要写“禁止改动事项”。
比如：
女主不能突然变恋爱脑；
男主不能突然圣母；
反派不能无脑降智；
师父不能提前暴露真实身份；
某角色第 80 章前不能死亡；
某秘密第 120 章前不能揭开。
---
## 3. 主线大纲表
长篇小说一定要先做“阶段设计”，不要直接让 AI 写第一章。
建议这样拆：
第 1 卷：入局，1–50 章
第 2 卷：成长，51–120 章
第 3 卷：反转，121–200 章
第 4 卷：大乱，201–320 章
第 5 卷：终局，321–500 章
每一卷都写清楚：
本卷目标；
本卷反派；
本卷主线事件；
本卷主角成长；
本卷重要伏笔；
本卷结尾爆点；
不能提前揭开的秘密。
---
## 4. 章节进度表
这是防止 AI 忘上下文的关键。
每写完一章，就更新一次。
格式建议：
第几章；
本章发生了什么；
人物状态变化；
新增设定；
新增伏笔；
已回收伏笔；
下一章必须承接什么；
当前不能忘的细节。
比如：
第 17 章：主角第一次使用“灰烬回溯”，代价是失去三小时记忆。新增伏笔：主角醒来时手里有一枚黑色铜钱。下一章必须写他追查铜钱来源，不能直接跳到宗门大比。
这样 AI 就不会写着写着断层。
---
## 5. 伏笔管理表
长篇最容易乱的是伏笔。
伏笔必须单独管理。
表格字段：
伏笔编号；
首次出现章节；
表现形式；
真实含义；
预计回收章节；
回收方式；
当前状态。
比如：
F001：主角梦里反复听见钟声。
首次出现：第 3 章。
真实含义：前世镇魂钟在召唤他。
预计回收：第 86 章。
当前状态：未回收。
这样 AI 才不会把伏笔忘掉，或者提前乱揭晓。
---
# 二、每次让 AI 写章节时，不能只说“继续”
错误提示词：
> 继续写第 18 章，写精彩一点。
这样 AI 很容易乱。
正确方式是每章都给它这 7 样东西：
1. 当前总设定摘要
2. 当前人物状态
3. 前 3 章剧情摘要
4. 本章目标
5. 本章必须出现的事件
6. 本章禁止事项
7. 本章结尾钩子
---
# 三、长篇小说标准工作流
你可以按这个流程操作：
## 第一步：先让 AI 设计总设定
不要写正文。
先让它输出世界观、主角、反派、主线、卷纲。
## 第二步：让 AI 设计全书结构
比如 300 章，就先做：
10 卷结构；
每卷 30 章；
每卷核心事件；
每卷结尾爆点。
## 第三步：让 AI 设计前 30 章细纲
不要一次设计 300 章细纲。
太细会僵硬，也容易后面改不动。
建议：
先设计全书粗纲；
再设计第 1 卷细纲；
写完第 1 卷后，根据实际剧情调整第 2 卷。
## 第四步：每章写作前生成“章节卡”
章节卡包括：
本章标题；
本章目标；
本章冲突；
出场人物；
场景；
关键信息；
伏笔；
结尾钩子。
## 第五步：根据章节卡写正文
正文提示词不要太空，要告诉 AI：
字数；
风格；
视角；
节奏；
对白比例；
心理描写比例；
禁止事项。
## 第六步：写完后立刻总结本章
让 AI 输出：
本章摘要；
人物变化；
新增设定；
新增伏笔；
待回收问题；
下一章承接点。
把这个总结放入“章节进度表”。
---
# 四、你可以直接用的总控提示词
下面这个是“长篇小说总导演提示词”，你可以保存起来，每次开新小说都先用它。
你现在是一名专业长篇小说总策划、网文主编、文学作家、剧作结构师和连续剧导演。我要创作一部长篇小说，请你不要急着写正文，先帮我建立一套稳定、不乱、不崩设定的长篇小说生产系统。
小说基础方向如下：
【题材类型】：
【预计字数】：
【预计章节数】：
【目标读者】：
【核心卖点】：
【风格要求】：
【禁止内容】：
【参考气质】：
【主角类型】：
【故事核心】：
请你按以下结构输出：
一、小说一句话核心
用一句话概括这部小说最吸引人的地方。
二、核心主题
说明这部小说真正要写的情感、人性、命运或社会议题。
三、世界观设定表
包括时代背景、空间结构、社会规则、力量体系、职业体系、资源体系、禁忌规则、核心矛盾。
四、主角档案
包括姓名、年龄、身份、外貌、性格、核心欲望、内心恐惧、能力边界、人物缺陷、成长弧光、最终变化。
五、重要人物档案
至少设计 8 个重要角色。每个角色必须包含：身份、欲望、秘密、与主角关系、人物弧光、禁止改动事项。
六、反派与阻力系统
不要只设计一个反派，要设计多层阻力：个人反派、组织反派、制度阻力、命运阻力、主角自身弱点。
七、全书结构
按卷设计。每卷包括：卷名、章节范围、本卷目标、本卷主要冲突、本卷主角成长、本卷核心反转、本卷结尾爆点。
八、伏笔系统
设计至少 20 个伏笔。每个伏笔包括：编号、首次出现位置、表面含义、真实含义、预计回收位置、回收效果。
九、爽点 / 情绪点 / 思考点
分别说明这部小说如何吸引读者继续看。
十、写作规则
列出这部小说后续写作时必须遵守的规则，尤其是不能改动的人设、不能提前暴露的秘密、不能违反的世界观规律。
十一、第一卷细纲
请先设计第一卷 30 章细纲。每章包括：章节标题、本章目标、主要事件、冲突、伏笔、结尾钩子。
注意：
1. 先设计，不要写正文。
2. 设定必须稳定，不能前后矛盾。
3. 不要使用套路化、狗血化、低级爽点。
4. 每个设定都要服务主线。
5. 所有后续正文必须严格遵守本次设定。
---
# 五、每章写作提示词
这个是你真正写正文时用的。每写一章，就复制一次，然后填入本章信息。
你现在继续创作长篇小说《小说名》。请严格遵守我提供的世界观、人设、剧情进度和伏笔表，不得擅自修改核心设定，不得提前揭露未到揭示时机的秘密，不得让人物行为脱离已有性格。
【当前总设定摘要】
在这里粘贴世界观、主线、主角目标、力量体系等核心设定摘要。
【主要人物当前状态】
1. 主角：
2. 重要角色 A：
3. 重要角色 B：
4. 重要角色 C：
【前 3 章剧情摘要】
第 X 章：
第 X+1 章：
第 X+2 章：
【本章信息】
章节编号：
章节标题：
本章字数：
本章视角：
本章场景：
本章出场人物：
本章核心目标：
本章主要冲突：
本章必须发生的事件：
本章必须埋下的伏笔：
本章必须回收的伏笔：
本章结尾钩子：
【本章禁止事项】
1. 不得改变人物已有性格。
2. 不得提前揭露未到时间的秘密。
3. 不得跳过关键情绪转折。
4. 不得用巧合强行推动剧情。
5. 不得写与主线无关的水剧情。
6. 不得让反派无脑降智。
7. 不得让主角突然获得没有铺垫的新能力。
【写作风格】
语言要有画面感和节奏感，情绪表达克制但有张力。场景要具体，动作要清楚，对白要符合人物身份。不要空泛总结，不要说教，不要流水账。每一场戏都要推动剧情、人物关系或伏笔。
请根据以上信息，正式创作本章正文。
正文结束后，请额外输出：
1. 本章 300 字摘要；
2. 人物状态变化；
3. 新增设定；
4. 新增伏笔；
5. 已回收伏笔；
6. 下一章必须承接的内容。
---
# 六、章节写完后的“记忆更新提示词”
这个非常关键。
每写完一章，不要马上继续写下一章，而是先让 AI 整理“记忆库”。
请根据刚刚完成的章节，更新小说记忆库。要求信息简洁、准确、可用于后续续写，不能加入正文中没有发生的内容，不能猜测未来剧情。
请按以下格式输出：
一、本章剧情摘要
用 300 字以内概括本章真实发生的事件。
二、人物状态更新
逐个列出本章出场人物的状态变化，包括心理变化、关系变化、受伤情况、获得物品、暴露秘密、立场变化。
三、世界观 / 设定更新
列出本章新增或确认的世界规则、地点、组织、能力、道具、历史信息。
四、伏笔更新
1. 新增伏笔：
2. 推进中的伏笔：
3. 已回收伏笔：
4. 不能忘记的未解问题：
五、时间线更新
说明本章发生在什么时间，距离上一章过去多久。
六、空间位置更新
说明主要人物当前所在地点，下一章开始时应从哪里承接。
七、下一章承接建议
列出下一章必须承接的 3 至 5 个重点。
八、禁止遗忘事项
列出后续写作绝不能忘记或改掉的细节。
---
# 七、最稳定的提示词组合方式
每次写新章节时，建议你给 AI 的上下文不要太长，但要精准。
最佳组合是：
**小说总设定摘要 1000 字以内**
+
**人物档案精简版 1000 字以内**
+
**最近 3 章摘要 1000 字以内**
+
**伏笔表 500 字以内**
+
**本章章节卡 500 字以内**
总共 4000 字左右就够了。
不要每次都塞几十万字前文。
那样 AI 反而容易抓不住重点。
---
# 八、长篇小说防乱的 10 条铁律
## 1. 不要一次让 AI 写太多章
一次最多写 1 章。
最多最多写 2 章。
不要让它“一口气写 10 章”。
---
## 2. 每章必须有章节卡
没有章节卡，AI 很容易水剧情。
---
## 3. 每章完成后必须总结
总结不是给人看的，是给后面续写当记忆用的。
---
## 4. 伏笔单独管理
不要指望 AI 自动记住伏笔。
伏笔必须编号。
---
## 5. 人物必须有“禁止改动事项”
比如：
主角不能主动杀无辜者；
女主不说网络流行语；
师父不能提前暴露修为；
反派不会亲自下场做低级事。
---
## 6. 每卷结束要重新校准
写完一卷后，让 AI 做一次：
剧情复盘；
人物复盘；
伏笔复盘；
节奏问题检查；
下一卷调整建议。
---
## 7. 设定不要无限膨胀
AI 很喜欢加新组织、新境界、新神器、新敌人。
你要明确写：
“除非我要求，不得新增核心势力、境界等级和主线设定。”
---
## 8. 主角能力必须有代价
没有代价，长篇很快崩。
要写清楚：
能力限制；
使用条件；
副作用；
成长路径；
不能做什么。
---
## 9. 反派不能降智
长篇最怕反派前期很强，后期突然傻。
要写：
反派目标；
反派资源；
反派情报边界；
反派行动逻辑；
反派不会做什么蠢事。
---
## 10. 每 10 章做一次体检
让 AI 检查：
有没有人设偏移；
有没有设定冲突；
有没有伏笔遗漏；
有没有节奏拖沓；
有没有主线偏离；
有没有重复桥段。
---
# 九、你真正要记住的一句话
长篇小说不是靠一个超级提示词写出来的。
它靠的是：
> **设定文档固定世界，人物档案固定性格，章节卡控制当章，记忆库承接上下文，伏笔表管理长期线索。**
你后面可以这样操作：
先让 AI 设计《请确认她来过》的**长篇版总设定文档**；
再让 AI 设计**5 卷结构**；
再设计**第 1 卷 30 章细纲**；
然后每章用“章节写作提示词”写；
写完每章用“记忆更新提示词”压缩上下文；
下一章继续把记忆库贴进去。
这样写 30 万字、50 万字，都不容易乱。
docs/chatgpt/novel/10.md
+370
View File
@@ -0,0 +1,370 @@
那视频生成模型也是一样的道理，自己调用api 和网页版是由差距的？
是的，**视频生成模型也是一样的道理：自己调用 API 和网页版/官方工作台，效果可能有明显差距。**
原因不是“API 模型更差”，而是：
> **网页版/官方工作台通常不是只把你的提示词直接丢给模型。
> 它背后还有一整套产品层优化：提示词增强、参数补全、参考图处理、镜头约束、安全过滤、重试、候选筛选、后处理。**
你自己调用 API，如果只是：
```text
prompt → video API → result
```
效果通常会比网页版差一截。
---
# 一、网页版为什么看起来更好？
视频生成网页版一般会帮用户做很多隐藏工作。
## 1. 自动优化提示词
你输入：
```text
白裙女仙释放法相天地
```
网页版可能内部扩写成：
```text
cinematic fantasy scene, vertical 9:16, realistic CG, ancient Chinese xianxia goddess, white torn dress, consistent face, dramatic lighting, purple energy, slow camera push-in, debris flying, epic scale...
```
也就是说，它会帮你补：
角色描述；
镜头语言；
光影；
画风；
动作；
时长；
比例；
负面约束；
一致性要求。
API 如果你不自己做 Prompt Builder，就没有这层增强。
---
## 2. 自动选择参数
网页版可能会自动根据场景选择：
分辨率；
时长；
比例；
运动强度；
参考图权重；
镜头稳定性；
真实感增强；
风格模式；
人物一致性模式。
API 需要你自己传参数。
传错一个参数，效果就可能变差。
---
## 3. 自动处理参考图
图生视频时，网页版可能会对参考图做：
裁剪；
人脸检测；
主体识别；
背景分离；
清晰度增强；
安全检测；
角色区域锁定；
首帧优化。
自己 API 调用时，如果你只是把图片 URL 直接传过去，可能效果不稳定。
---
## 4. 自动做失败重试
网页版有时会偷偷做多次候选，选一个最好的展示给你。
API 如果你只生成一次，看到的就是一次抽卡结果。
所以你系统里要做：
```text
同一分镜生成 2-4 个候选
↓
自动评分
↓
人工/系统选择最佳
↓
再进入合成
```
你当前架构已经支持“同一分镜用多个视频模型生成多个候选，并在合成前选择每个分镜最终候选片段”，这是正确方向。
---
## 5. 自动后处理
网页版可能还会做：
稳像；
补帧；
锐化；
去闪烁；
人脸修复；
音画对齐；
字幕排版；
转码压缩；
封面截取。
API 原始输出不一定包含这些。
你现在已有 FFmpeg 合成、标准化片段、裁剪/补齐、竖屏 720x1280、fps、字幕、BGM、SFX、音频混合等流程，这部分已经接近“自建网页版产品层”。
---
# 二、视频 API 要想接近网页版，必须自己补 7 层
你要把视频生成系统做成这样：
```text
小说/剧本/分镜
↓
Prompt Builder
↓
Provider Router
↓
参数适配器
↓
参考图/角色资产处理
↓
多候选生成
↓
质量评分/人工选择
↓
FFmpeg 后处理
↓
成片
```
不是简单：
```text
提示词 → API → 视频
```
---
# 三、你当前系统已经做对了哪些？
根据你上传的架构，你已经做了很多正确的东西：
1. 有 `AiRouterService`，能按分镜自动选择普通/高价值路线、fallback、成本估算、预算限制；
2. 有 `PromptBuilderService`，已经能输出角色一致性、场景类型、镜头、灯光、VFX、负面词、唇形策略等；
3. 有角色库，区分“真人脸包”和“项目角色锚点图”；
4. 有多个视频 Provider：豆包 Seedance、可灵、海螺、Sora、Mock；
5. 有候选片段生成和选择；
6. 有 FFmpeg 合成流程；
7. 有 Provider 长任务轮询和恢复机制。
所以你的系统不是从零开始。
你现在要补的是“让 API 调用尽量接近网页版效果”的产品层细节。
---
# 四、自己调用 API 最容易差在哪里？
## 1. Prompt 太直接
比如你直接传：
```text
女主在废墟中释放紫色法术
```
模型可能会乱。
应该传：
```text
角色固定描述 + 场景 + 动作 + 镜头 + 情绪 + 光影 + 风格 + 时长 + 负面词
```
你现有 `PromptBuilderService` 已经开始做这个，但你文档里也写了，小说、故事圣经、角色抽取、分集、脚本、普通分镜等文本步骤还需要统一更严格的 schema、重试、验证和 Prompt 版本管理。这个要继续补。
---
## 2. 没有角色资产锁定
短剧最怕：
第一镜一个脸；
第二镜换脸；
第三镜衣服变了；
第四镜年龄变了。
所以必须有：
```text
角色视觉档案
角色锚点图
角色状态变体
服装版本
参考图使用规则
负面提示词
```
你当前 Character Library 已经有 `CharacterDesignVersion`、`CharacterState`、`ActorProfile`，而且真人脸包和项目定妆已经拆开，这是对的。
---
## 3. 不同 Provider 参数不统一
豆包、可灵、海螺、Sora 的能力不一样。
有的支持 5 秒；
有的支持 10 秒；
有的支持首帧；
有的支持角色参考图；
有的对真人照片更敏感；
有的适合动作；
有的适合情绪对话。
所以你需要 Provider 能力矩阵。
你文档里也明确写了待优化点：需要显式配置 Provider 的时长、分辨率、首帧、尾帧、角色参考图、真人照片、多参考图、同步声音等能力。
这个必须做。
---
## 4. 没有多候选和评分
视频生成本质上有随机性。
同一提示词生成 1 次，可能一般；
生成 4 次，可能有 1 个很不错。
所以你的系统要支持：
```text
每个分镜生成 N 个候选
↓
自动评分
↓
人工选择 / 自动选择
↓
进入合成
```
评分维度：
人物是否一致；
动作是否完成；
镜头是否稳定；
是否崩脸；
是否多手多脚；
是否符合分镜；
是否可用于成片。
---
# 五、你要不要用网页版？
我的建议：
## 测试模型上限时，用网页版
比如你想知道豆包、可灵、海螺某个模型“最高能做到什么效果”，可以用网页版测试。
因为网页版通常有更完整的产品优化。
---
## 批量生产时，用 API
你的目标是小说/听书/短剧自动化流水线，最终一定要 API。
因为网页版无法稳定做：
任务队列；
成本统计；
多模型 fallback；
批量分镜生成；
素材入库；
版本管理；
自动合成；
失败重试；
用户项目隔离。
---
# 六、正确策略：先用网页版反推 API 参数
你可以这样做：
```text
1. 在网页版手动测试高质量效果
2. 记录输入提示词、参数、参考图、时长、比例
3. 分析它适合什么场景
4. 反推成你系统里的 Prompt Template
5. 写进 PromptBuilder
6. 用 API 批量验证
7. 不断调整 Provider Profile
```
比如你测试发现：
豆包 Seedance 2.0 适合电影感动作；
可灵适合图生视频和角色动作保持；
海螺 Fast 适合低成本对话镜头；
Sora 适合高价值关键镜头。
那你的 Router 就可以这样分：
```text
普通对白镜头 → 海螺 Fast / 豆包 Fast
情绪揭露镜头 → 豆包 Seedance 2.0
高价值动作镜头 → 可灵 / Sora
玄幻神通镜头 → 豆包 Seedance / 可灵
```
你当前 Router 已经有普通路线和高价值路线，这是正确框架。
---
# 七、最终答案
是的：
> **视频生成 API 和网页版也会有差距。**
但差距不是因为 API 一定弱，而是网页版多了产品层优化。
你要做 API 系统，就要自己补：
```text
Prompt Builder
Provider 能力矩阵
角色锚点图
参考图预处理
多候选生成
质量评分
失败重试
FFmpeg 后处理
成本路由
```
你的系统目前已经有一半以上基础，尤其是 Router、Prompt Builder、Character Library、LiveAction、FFmpeg、Provider Layer 都已经存在。下一步重点不是换模型，而是继续把 **Provider 能力矩阵 + Prompt 调试面板 + 视频质量评分 + 多候选自动选择** 做完整。
一句话：
> **网页版是“模型 + 官方产品优化”；
> API 是“裸模型能力 + 你自己的工程优化”。
> 你要想 API 接近网页版，就要把官方隐藏的产品层，在自己的系统里重建出来。**
docs/chatgpt/novel/11.md
+661
View File
@@ -0,0 +1,661 @@
目标肯定是把api优化到接入网页版，我最总要的是自动化流水下，人工，效率太低；网页版应该也是掉api的把，按官网的api文档参数传递参数，？
对，你的判断基本正确：
> **网页版本质上也是调用模型服务，但它不等于“公开 API 文档里那几个参数直接调用”。**
更准确地说：
```text
网页版 = 模型 API + 官方产品层优化 + 内部路由 + 隐藏参数/策略 + 后处理
你自己接 API = 公开 API + 你自己实现产品层优化
```
所以你的目标应该是：
> **把自己的 API 流水线做成“接近网页版体验”的产品层，而不是只照文档传 prompt。**
---
# 一、网页版是不是也调 API？
大概率是。
但它调的可能是：
1. 官方内部 API；
2. 与公开 API 类似但参数更多的接口；
3. 包含系统 prompt、路由、自动优化、重试、候选筛选的服务；
4. 可能还带有前处理、后处理和质量筛选。
所以不能简单理解成：
```text
网页版输入框内容 = API prompt
网页版生成按钮 = 公开 API 调用
```
真实情况更像：
```text
用户输入
↓
官方前端
↓
提示词增强
↓
安全审核
↓
模型路由
↓
参数补全
↓
生成多个候选 / 重试
↓
质量过滤
↓
后处理
↓
展示结果
```
你自己接 API，就需要把中间这些层做出来。
---
# 二、按官网 API 文档传参数够不够？
**能跑通，但不一定能跑出网页版效果。**
官网 API 文档告诉你的是：
```text
接口怎么调用
参数怎么传
返回值怎么解析
错误怎么处理
```
但通常不会完整告诉你：
```text
网页版内部怎么改写 prompt
网页版怎么选模型
网页版怎么设置隐藏参数
网页版怎么做多候选
网页版怎么判断哪条结果最好
网页版怎么做图像预处理
网页版怎么做后期增强
```
就像你调用视频模型 API：
```json
{
"prompt": "一个女人在雨夜奔跑",
"duration": 5,
"ratio": "9:16"
}
```
可以生成视频。
但网页版可能内部实际会变成：
```text
realistic cinematic vertical short drama, Chinese woman, rainy night street, wet asphalt reflections, handheld tracking shot, medium close-up, anxious but restrained expression, natural motion, dramatic lighting, no face distortion, no extra fingers, stable camera...
```
还可能自动加：
```text
参考图处理
镜头稳定约束
人物一致性约束
负面词
运动强度
光影风格
候选筛选
失败重试
```
所以文档参数是基础，**产品层优化才决定最终效果**。
---
# 三、你要做的不是“人工网页版”，而是“API 自动网页版”
你的目标很清楚：自动化流水线，人工太低效。
那你应该把网页版背后的逻辑拆成系统模块：
```text
Prompt Builder
Provider Router
Capability Matrix
Context Builder
Asset Preprocessor
Candidate Generator
Quality Evaluator
Retry / Repair
Post-processing
Cost Controller
```
你当前系统已经有不少基础：架构里已经有 `AiRouterService`、`PromptBuilderService`、`ProviderConfig`、`LiveActionModule`、`MediaModule`、`FFmpeg`、`RenderTask`、`BullMQ Worker`，而且视频侧已经支持 Provider fallback、成本估算、候选片段、人工选择和合成流程。
所以你现在不是从 0 做，而是要继续补齐“官方网页版隐藏的优化层”。
---
# 四、API 要接近网页版，需要做 10 层
## 1. Prompt 增强层
不要让用户原始输入直接进模型。
```text
用户提示词 / 小说章节 / 分镜
↓
Prompt Builder
↓
模型专用 Prompt
```
你现在真人视频已有 `live-action-prompt-engine-v2`，能输出 scene type、camera、lighting、VFX、negative prompt、actor consistency rules 等，这个方向是对的。
但还要继续加强：
```text
豆包专用模板
可灵专用模板
海螺专用模板
Sora 专用模板
图生视频模板
文生视频模板
真人短剧模板
玄幻大场面模板
对话镜头模板
```
---
## 2. Provider 能力矩阵
不同模型能力不一样，不能统一传同一组参数。
要记录：
```text
支持时长
支持比例
支持分辨率
是否支持首帧
是否支持尾帧
是否支持角色参考图
是否支持多参考图
是否允许真人照片
是否支持同步声音
是否支持种子 seed
是否支持运动强度
失败率
平均耗时
平均成本
适合场景
```
你上传的架构文档里也明确把 Provider 能力矩阵列为待优化点，包括时长、分辨率、首帧、尾帧、角色参考图、真人照片、多参考图、同步声音等。
这层必须做。
---
## 3. 参数适配层
你不能写死：
```text
duration=5
resolution=720p
ratio=9:16
```
应该由 Router 根据 Provider 能力自动转。
比如：
```text
豆包支持 5s / 10s
可灵支持 5s / 10s，图生更稳
海螺 Fast 适合低成本对话
Sora 适合高价值镜头
```
同一个分镜，传给不同 Provider 的参数应该不一样。
---
## 4. 角色一致性层
短剧最重要的是角色不换脸。
你现在已经有：
```text
GlobalCharacter
GlobalCharacterAsset
Character
CharacterImage
CharacterDesignVersion
CharacterState
ActorProfile
```
而且设计上区分了“真人脸包”和“项目内定妆锚点图”，这很正确。
下一步要强化：
```text
角色视觉档案
角色锚点图优先级
服装状态变体
受伤状态变体
同一集角色锁定配置
每个镜头引用哪个角色版本
```
不要每个镜头重新描述一个角色。
---
## 5. 参考图预处理层
网页版通常会自动处理图。
你自己 API 要做：
```text
裁剪主体
统一比例
增强清晰度
去水印/去杂乱边缘
人脸区域检测
生成角色锚点图
生成场景首帧
保存参考图版本
```
尤其是图生视频，首帧图质量决定一半结果。
---
## 6. 多候选生成层
不要一个分镜只生成一次。
建议：
```text
普通镜头：1-2 个候选
重要镜头：3-4 个候选
关键爆点镜头：多 Provider 生成
```
你的现有架构已经支持“同一分镜可以用多个视频模型生成多个候选，合成前选择最终片段”，这个要保留并加强。
---
## 7. 自动质量评分层
每个候选视频要打分。
评分维度：
```text
角色是否一致
是否崩脸
动作是否完成
镜头是否稳定
是否符合分镜
画面是否真实
是否多手多脚
是否有明显伪影
是否适合接入下一镜头
是否可用于成片
```
低分自动重试，高分进入候选池。
---
## 8. 失败重试 / Fallback 层
你现在 Router 已经有 fallback：
普通路线、高价值路线、成本检查、预算检查、Provider 跳过原因。
继续加强：
```text
Provider 超时但外部 running → 继续轮询
Provider 失败 → 换备用模型
同模型失败 2 次 → 降级 prompt
动作太复杂失败 → 自动拆成两个镜头
时长不支持 → 自动拆段
```
---
## 9. 后处理层
API 原始视频不是成片。
你要做：
```text
统一分辨率
统一帧率
统一色调
裁剪补齐
镜头拼接
字幕
配音
BGM
SFX
响度标准化
封面截图
转码
```
你当前 FFmpeg 已经做了标准化片段、竖屏 720x1280、fps、concat、音频混合、字幕、BGM、SFX、编码 fallback 等，这是非常正确的方向。
---
## 10. Prompt 调试面板
这是你后面提质最关键的后台工具。
每个分镜要能看到：
```text
原始分镜
最终 Prompt
负面词
Provider
Provider 参数
参考图
Router 决策
跳过原因
成本估算
生成结果
评分
失败原因
```
你文档里也提到需要增加“Prompt 调试面板”，展示最终提交给 Provider 的完整参数、参考图、负面词、成本估算，方便测试。
这个必须做，越早做越好。
---
# 五、网页版效果怎么反推到 API？
你可以用一个“反推流程”。
## 第一步：网页版测试
同一个镜头在网页版测：
```text
简单 prompt
详细 prompt
图生视频
不同参考图
不同时长
不同动作复杂度
```
记录：
```text
输入词
生成效果
失败点
角色一致性
动作完成度
画面风格
```
---
## 第二步：总结模板
把好结果拆成模板：
```text
角色描述模板
场景模板
动作模板
镜头模板
光影模板
负面词模板
```
---
## 第三步：写进 Prompt Builder
例如：
```text
xianxia_transformation_template
realistic_dialog_template
identity_reveal_template
emotional_closeup_template
action_chase_template
```
你现有 Prompt Builder 已经有 `dialog`、`conflict`、`reveal`、`identity_reveal`、`xianxia_transformation`、`action` 等场景模板，可以继续扩展。
---
## 第四步：API 批量验证
同一分镜跑：
```text
豆包
可灵
海螺
Sora
```
记录真实成本、耗时、成功率、质量评分。
---
## 第五步：更新 Router
最后把经验变成规则：
```text
对话镜头 → 海螺 Fast
情绪特写 → 豆包 Seedance 2.0
动作镜头 → 可灵 / 豆包
玄幻大场面 → 豆包 / Sora
关键爆点 → 高价值路线
普通过渡 → 低成本路线
```
这样你的 API 系统会越来越接近甚至超过手工网页版效率。
---
# 六、官网 API 文档参数要怎么用？
你要分三层用。
## 第一层：硬参数
这些必须严格按文档：
```text
model
prompt
image_url / reference_image
duration
aspect_ratio
resolution
callback_url
seed
watermark
```
---
## 第二层：业务参数
这是你系统自己的参数，不一定传给 Provider，但用于路由和控制：
```text
scene_type
route_tier
importance_score
motion_intensity
emotion_intensity
character_consistency_required
cost_level
retry_policy
candidate_count
```
---
## 第三层：Prompt 组件参数
这些最终会被 Prompt Builder 合成 prompt：
```text
character_identity
costume
location
main_action
camera_shot
camera_move
lighting
mood
visual_style
continuity_rules
negative_prompt
```
也就是说，后台不要只保存一个 `prompt_text`。
最好保存：
```json
{
"raw_prompt": "",
"prompt_components": {},
"final_prompt": "",
"negative_prompt": "",
"provider_params": {},
"router_decision": {}
}
```
你文档里 Prompt Builder 已经输出 prompt components、negative prompt、director plan、motion director、lip sync policy 等，这个方向继续做。
---
# 七、你的最终方向是对的
你的目标不是：
```text
人工去网页版一个个生成
```
而是：
```text
用 API 复刻网页版背后的自动化产品层
```
最终应该是：
```text
小说章节
↓
自动转剧本
↓
自动分镜
↓
自动角色锁定
↓
自动选 Provider
↓
自动构建 Prompt
↓
自动生成多候选
↓
自动质检
↓
自动选择 / 人工少量审核
↓
自动合成
```
人工只做：
```text
选题
角色锚点确认
关键分镜审核
最终成片确认
```
不是每个镜头都人工调。
---
# 八、你现在最该补的三个功能
按优先级：
## 1. Provider 能力矩阵
这是 API 稳定性的地基。
不做这个，就会大量 Provider 报错、参数不匹配、生成失败。
---
## 2. Prompt 调试面板
没有这个，你不知道为什么某个镜头生成差。
---
## 3. 视频质量评分 / 多候选自动选择
没有这个，你只能人工看大量视频，效率会很低。
---
# 九、最终答案
是的，网页版大概率也是基于模型服务，但它不是简单调用公开 API 参数。
你的目标应该是：
> **用公开 API + 自己的 Prompt Builder + Router + 角色资产 + 多候选 + 质检 + 后处理，做出接近网页版甚至更适合批量生产的自动化系统。**
按官网 API 文档传参数只是第一步。
真正决定效果的是你自己的产品层。
一句话：
> **网页版强在“官方替你做了优化”；
> API 强在“你可以把优化变成自动化流水线”。
> 你要做的，就是把网页版里的人工和隐藏优化，沉淀成自己的后台规则、Prompt 模板、Router 策略和质检系统。**
docs/chatgpt/novel/12.md
+608
View File
@@ -0,0 +1,608 @@
我目前的系统是拆了分镜，每个分镜单独给模型发api 这样应该不会乱把，每个分镜都市独立的，等于现实的导演一集一集的擦hi开取景安排好了完整流程，不管谁接手，只需要按每个分镜定好的流程内容去拍摄就可以了
对，你这个理解**大方向是对的**：
> **每个分镜单独发 API，不会像长篇小说那样严重依赖前后 100 章全文。**
> 因为分镜本身就是“拍摄执行单”，模型只需要按当前镜头要求生成画面。
这和现实剧组很像：
```text
总导演 / 编剧先定全剧
↓
分集导演拆场
↓
分镜导演定镜头
↓
摄影、美术、演员按分镜执行
↓
剪辑统一成片
```
所以你的系统按“分镜独立生成”是正确路线。
但是要注意一句：
> **分镜可以独立生成，但不能完全孤立。**
如果每个分镜只给当前镜头内容，而不带角色、服装、场景、前后镜头连续性，就可能出现：
第一镜女主短发；
第二镜女主长发；
第三镜衣服颜色变了；
第四镜场景灯光变了；
第五镜动作方向反了；
第六镜人物情绪接不上。
所以最稳的做法是：
> **每个分镜独立发 API，但每个分镜都必须携带统一的“拍摄资产包”。**
---
# 一、你的分镜 API 模式是对的
你现在这种：
```text
第1镜 → 单独调用视频模型
第2镜 → 单独调用视频模型
第3镜 → 单独调用视频模型
……
最后 FFmpeg 合成
```
是目前 AI 短剧最现实、最可控的方式。
因为如果你让模型一次生成 1 分钟、3 分钟、5 分钟完整短剧，问题会更多：
画面漂移；
人物换脸；
动作断裂；
台词不稳；
剧情遗漏；
生成失败成本高；
不好返修；
单个镜头坏了要整段重来。
所以拆分镜是对的。
一个镜头坏了，只重做一个镜头，不影响整集。
---
# 二、但每个分镜不能只传“当前动作”
错误示例：
```text
女主走进房间，看见桌上的门禁卡。
```
这样模型可能不知道：
女主是谁；
她长什么样；
她穿什么；
现在是什么情绪；
房间是什么风格；
上一镜她从哪个方向进来；
门禁卡是什么样；
整体画风是什么；
镜头比例和时长是多少。
正确应该传：
```text
角色固定信息
+ 当前角色状态
+ 场景固定信息
+ 道具固定信息
+ 本镜头动作
+ 镜头语言
+ 情绪状态
+ 前后连续性
+ 负面词
+ Provider 参数
```
这就是我说的“拍摄资产包”。
---
# 三、每个分镜 API 应该包含 8 类信息
## 1. 项目级风格
每个镜头都要统一。
例如：
```text
写实真人短剧风格，9:16竖屏，720p，电影感低饱和，真实自然光，克制表演，不夸张，不网红滤镜。
```
这保证整集质感统一。
---
## 2. 角色固定资产
每个出现的角色都要引用同一个角色档案。
例如：
```json
{
"character_id": "cen_qing",
"name": "岑青",
"visual_identity": "31岁中国女性，短黑发，清瘦脸型，眼神冷静，素色衬衫，深色外套",
"anchor_image_id": "asset_xxx",
"current_state": "刚发现门禁卡身份异常，情绪克制但警觉",
"must_keep": [
"短黑发",
"清瘦脸",
"深色外套",
"冷静克制表情"
]
}
```
如果 Provider 支持参考图，就传锚点图。
如果不支持，就把视觉描述写进 Prompt。
---
## 3. 角色状态变体
同一角色在不同剧情阶段可能服装、伤势、妆容不同。
比如：
```text
normal_state
rainy_state
injured_state
fire_scene_state
office_state
```
不能每个镜头临时改。
你当前系统已经有 `CharacterState` 和 `CharacterDesignVersion`，这个就应该用起来。
---
## 4. 场景固定资产
例如：
```json
{
"scene_id": "old_investigation_room",
"location": "临时调查室",
"visual_identity": "简陋办公室，白板贴着火灾楼层图，桌上有证物袋和电脑，冷白灯，窗外下雨",
"lighting": "冷白室内光 + 电脑屏幕冷光",
"color_palette": "灰蓝、旧白、暗黄"
}
```
这样第 1 镜和第 2 镜不会变成两个完全不同的房间。
---
## 5. 道具资产
重要道具必须固定。
比如：
```json
{
"prop_id": "burned_access_card",
"name": "烧焦门禁卡",
"visual_identity": "一张边缘烧焦起泡的塑料门禁卡，卡面残留两个汉字：林照，磁条断裂"
}
```
短剧里道具是线索，不能乱变。
---
## 6. 本镜头执行内容
这才是当前分镜本身：
```json
{
"shot_no": 3,
"duration_sec": 5,
"shot_size": "close-up",
"camera_movement": "slow push-in",
"main_action": "岑青把烧焦门禁卡放到电脑旁，盯着屏幕等待系统检索",
"emotion": "安静、不安、警觉",
"dialogue": ""
}
```
---
## 7. 前后镜头连续性
这是防止剪辑不连贯的关键。
例如：
```json
{
"previous_shot": {
"ending_state": "裴让把证物袋推到岑青面前",
"character_position": "岑青坐在桌子左侧，裴让站在右侧",
"prop_position": "证物袋在桌子中央"
},
"current_shot_start": "从桌面证物袋特写开始",
"next_shot_expectation": "电脑屏幕出现身份匹配失败"
}
```
不是每个镜头都需要很多，但关键镜头要带。
---
## 8. 负面约束
比如：
```text
不要换脸，不要改变发型，不要改变服装颜色，不要夸张表演，不要卡通风，不要多余人物，不要出现错误文字，不要手指畸形，不要突然切换场景。
```
视频模型很容易自作主张，负面词必须有。
---
# 四、最稳的分镜任务结构
你的视频 API 任务最好不是只保存一个 prompt，而是保存结构化 JSON。
建议这样：
```json
{
"project_id": "p001",
"episode_id": "e001",
"shot_no": 3,
"duration_sec": 5,
"aspect_ratio": "9:16",
"resolution": "720p",
"provider": "volcengine_seedance_20",
"route_tier": "premium",
"style_pack": {
"visual_style": "写实真人短剧，电影感，低饱和，真实光影",
"tone": "克制、悬疑、现实主义",
"negative_style": "不要网红滤镜，不要动漫风，不要夸张表演"
},
"characters": [
{
"character_id": "cen_qing",
"name": "岑青",
"anchor_image_id": "asset_cenqing_anchor_v1",
"state_code": "investigation_dark_coat",
"visual_prompt": "31岁中国女性，短黑发，清瘦脸型，冷静眼神，素色衬衫，深色外套",
"continuity_rules": [
"保持同一张脸",
"保持短黑发",
"保持深色外套",
"表情克制"
]
}
],
"location": {
"scene_id": "investigation_room",
"prompt": "简陋临时调查室，白板上贴火灾楼层图，桌上有证物袋、电脑，冷白灯，窗外下雨"
},
"props": [
{
"prop_id": "burned_access_card",
"prompt": "烧焦起泡的门禁卡，边缘发黑，磁条断裂，卡面残留两个汉字"
}
],
"shot": {
"shot_size": "close-up",
"camera_movement": "slow push-in",
"main_action": "岑青把烧焦门禁卡放在电脑旁，盯着屏幕等待系统检索",
"emotion": "安静、不安、警觉",
"dialogue": "",
"sfx": "轻微雨声、电脑风扇声"
},
"continuity": {
"previous_shot_end": "裴让把证物袋推到岑青面前",
"current_start": "桌面证物袋特写",
"next_shot_need": "电脑屏幕出现身份匹配失败"
},
"final_prompt": "",
"negative_prompt": ""
}
```
然后由你的 `PromptBuilderService` 把这个结构转成不同 Provider 的最终 Prompt。
---
# 五、你的“导演比喻”是正确的，但还差一个“场记”
你说：
> 不管谁接手，只需要按每个分镜定好的流程内容去拍摄。
这句话对。
但现实剧组还有一个非常重要的岗位：**场记**。
场记负责记录：
上一镜演员站哪；
手里拿什么；
衣服有没有扣上；
杯子在桌子哪边；
上一句台词是什么情绪；
下一镜怎么接。
AI 视频里也需要“场记系统”。
对应到你的系统就是：
```text
ShotContinuityService
```
它负责每个镜头之间的连续性。
比如：
```json
{
"episode_id": "e001",
"shot_no": 5,
"ending_state": {
"cen_qing_position": "桌子左侧",
"peirang_position": "门口右侧",
"prop_access_card": "电脑键盘左边",
"emotion": "岑青第一次产生怀疑"
}
}
```
生成第 6 镜时，就把第 5 镜 ending_state 带进去。
这样剪辑会更顺。
---
# 六、什么时候分镜可以完全独立？
这些镜头可以高度独立：
```text
空镜；
环境镜头；
道具特写；
转场镜头；
梦境片段；
监控画面；
回忆碎片；
单人特写；
无连续动作的对白镜头。
```
比如：
```text
烧焦门禁卡特写
旧楼外墙空镜
雨水落在警戒线上
电脑屏幕显示查无此人
```
这些镜头前后依赖很弱，单独生成没问题。
---
# 七、什么时候不能完全独立？
这些镜头要带连续性：
```text
同一场戏里的连续对话；
同一动作拆成多个镜头；
角色从 A 点走到 B 点；
打斗；
追逐；
拥抱；
递东西；
开门进房间；
人物情绪逐渐变化；
同一空间内连续切镜。
```
比如：
```text
第3镜：裴让把证物袋推给岑青
第4镜：岑青打开证物袋
第5镜：岑青拿出门禁卡
第6镜：电脑显示查无此人
```
这几个镜头必须共享：
桌子位置；
人物站位；
门禁卡样子；
灯光；
动作承接。
否则合成后会跳。
---
# 八、你的系统现在应该补的核心模块
基于你当前已拆分镜的流程，我建议补这几个：
## 1. ShotContextBuilder
给每个分镜拼上下文：
```text
项目风格
角色资产
场景资产
道具资产
当前分镜
前后镜连续性
Provider 参数
```
---
## 2. ShotContinuityService
保存每个镜头的开始状态和结束状态。
字段包括：
```text
人物位置
人物情绪
服装状态
手持道具
场景状态
动作完成情况
下一镜承接点
```
---
## 3. ShotAssetLock
锁定角色、服装、场景、道具。
比如：
```text
第1集第1-12镜，岑青统一使用 character_state = investigation_dark_coat
海风大厦楼梯间统一使用 scene_asset = haifeng_stairwell_v1
门禁卡统一使用 prop_asset = burned_access_card_v1
```
---
## 4. ShotQualityCheck
生成后检查：
```text
人物是否一致；
服装是否一致；
动作是否完成；
场景是否错误；
有没有多余人物；
有没有崩脸；
是否符合时长；
是否能接上前后镜。
```
---
## 5. ShotRetryPolicy
根据失败类型自动重试。
比如：
```text
换脸 → 加强角色描述 / 使用锚点图 / 换图生视频
动作失败 → 简化动作
场景乱 → 加首帧图
手部崩 → 避免复杂手部动作 / 改景别
文字错 → 不让模型生成可读文字，后期字幕加
```
---
# 九、你现在的路线和小说流水线怎么接？
小说流水线生成短剧时，应该先生成：
```text
Episode
EpisodeScript
StoryboardShot
ShotAssetLock
ShotContinuityPlan
```
然后你现有视频系统按每个 `StoryboardShot` 单独生成。
也就是：
```text
小说章节
↓
短剧剧本
↓
分镜
↓
分镜资产锁定
↓
每镜单独 API
↓
候选片段
↓
连续性检查
↓
合成
```
这样就不会乱。
---
# 十、最终判断
你目前的做法：
> **分镜拆开，每个分镜单独发 API。**
这是正确的，而且是 AI 短剧自动化的主流可控方案。
但要加一句：
> **分镜独立生成，不等于分镜没有上下文。**
最稳结构是：
```text
每个分镜独立调用 API
但每个分镜都带：
角色锁定
场景锁定
道具锁定
本镜头动作
前后连续性
统一风格
负面词
Provider 适配参数
```
一句话总结：
> **你现在像导演把戏拆成了镜头，这是对的；下一步要补“场记”和“资产锁定”，保证每个接手拍摄的 AI 模型拍出来能剪成同一部戏。**
docs/chatgpt/novel/13.md
+415
View File
@@ -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 生成
→ 章节质检
→ 章节记忆更新
→ 下一章
```
一句话：
> **视频靠分镜控制画面；小说靠章节卡控制剧情。
> 分镜是拍摄执行单，章节卡就是写作执行单。**
docs/chatgpt/novel/2.md
+1709
View File
File diff suppressed because it is too large Load Diff
docs/chatgpt/novel/3.md
+1183
View File
File diff suppressed because it is too large Load Diff
docs/chatgpt/novel/4.md
+1109
View File
File diff suppressed because it is too large Load Diff
docs/chatgpt/novel/5.md
+250
View File
@@ -0,0 +1,250 @@
写小说全世界那个ai模型最好
按**纯小说创作质量**来说，目前我会这样排：
## 第一名：Claude Fable 5 / Claude Opus 4.8
如果你只问“全世界哪个模型最会写小说”，我的判断是：
> **Claude 系列目前最适合写文学性、人物情绪、长篇叙事和细腻对白。**
Anthropic 官方也把 Claude 明确定位到创意工作场景：它适合更快、更大规模地做创意构思、扩展创作能力、处理重复劳动。([Anthropic][1])
另外，Anthropic 官方文档显示，Claude Opus 4.8 是当前 Opus 层级最强模型，支持 1M 上下文和 128k 最大输出，适合复杂推理、长周期任务和高自主性工作。([Claude API Docs][2])
**适合做：**
现实主义小说；
女性向 / 情感向；
人物群像；
文学感短故事；
长篇人物弧光；
细腻心理描写；
高级对白；
治愈、悬疑、人间观察。
**缺点：**
API 参数限制比较多；
部分模型温度等采样参数不能自由调；
自动化工程接入时要适配它的 Messages API 规则；
中文网文爽感不一定比国内模型强。
---
## 第二名：GPT-5.5 / GPT-5.5 Pro
如果你不是只要“文笔”，而是要做你这种**自动化小说流水线**，我更建议把 GPT-5.5 放在核心位置。
OpenAI 官方说明 GPT-5.5 擅长写作、代码调试、在线研究、数据分析、文档与表格创建、软件操作，以及处理混乱的多步骤任务；API 版本也支持 1M 上下文。([OpenAI][3])
**GPT-5.5 最强的地方不是单章文笔，而是：**
小说圣经设计；
世界观逻辑；
长篇结构规划；
多 Agent 编排；
JSON Schema 稳定输出；
质量检查；
伏笔管理；
人物一致性检查；
小说转剧本；
小说转听书；
短剧分镜提示词生成。
也就是说：
> **Claude 更像顶级作家。
> GPT-5.5 更像总编剧 + 架构师 + 审稿人 + 自动化系统调度员。**
你现在要做的是 API 自动化流水线，所以 GPT-5.5 非常重要。
---
## 第三名：Gemini 3.1 Pro
Gemini 3.1 Pro 更适合长上下文、多资料综合、知识整理、跨文档分析。Google 官方称它面向复杂任务，并通过 Gemini API、Vertex AI、Gemini App、NotebookLM 等渠道提供。([blog.google][4])
**适合做：**
长篇资料整理；
大型世界观材料分析；
多文档改编；
历史文化题材；
科幻设定考据；
把小说拆成知识库；
长上下文回溯。
**不建议让它作为主写手。**
它可以做资料和结构，但最终正文文风通常不如 Claude，自动化工程能力也不如 GPT-5.5 稳。
---
## 第四名：Kimi / DeepSeek / 通义 / 智谱 / 豆包
这些国内模型适合你的商业流水线做**中低成本批量生产**。
尤其你系统里已经配置了：
豆包小说 2.0 Pro；
DeepSeek 小说；
通义小说；
Kimi 小说；
智谱小说；
OpenAI Responses 小说。
根据你上传的架构文档，你的 Provider 层已经有 `NovelProvider`，并且启用了豆包、DeepSeek、通义、Kimi、智谱、OpenAI 等小说模型，这很好。
**国内模型适合做：**
章节初稿；
爽文节奏；
中文短剧对白；
网感标题；
低成本批量生成；
听书稿改写；
短剧口语化台词；
分镜初稿。
**但不建议全部交给单一国内模型。**
因为长篇高级感、人设稳定性、伏笔控制、文学质感，还是要靠更强模型做总控和质检。
---
# 我的最终推荐
你这个系统不是单次聊天写小说，而是要接 API 自动流水线。
所以不要问“只用哪个模型”，应该按 Agent 分工用模型。
## 最优组合
| 环节 | 推荐模型 |
| ------------- | -------------------------------- |
| 小说圣经 / IP 圣经 | GPT-5.5 Pro 或 Claude Opus 4.8 |
| 世界观 / 人物 / 伏笔 | GPT-5.5 或 Claude Opus 4.8 |
| 正文初稿 | Claude Fable 5 / Claude Opus 4.8 |
| 中文网文章节初稿 | 豆包小说 2.0 Pro / Kimi / 通义 |
| 润色提升 | Claude Opus 4.8 |
| 连贯性检查 | GPT-5.5 |
| JSON 结构化输出 | GPT-5.5 |
| 小说转听书 | 豆包 / Kimi / GPT-5.5 |
| 小说转短剧剧本 | GPT-5.5 + 豆包 |
| 分镜 / 视频提示词 | GPT-5.5 |
| 低成本批量测试 | 豆包小说 2.0 Lite / DeepSeek / Kimi |
---
# 如果只能选一个
## 只追求小说质量
选：
> **Claude Opus 4.8 / Claude Fable 5**
它最适合写“像人写的小说”。
---
## 只追求自动化流水线稳定
选：
> **GPT-5.5**
它最适合你这种 NestJS + Provider + Queue + JSON Schema + 多 Agent 的系统。
---
## 只追求中文批量低成本
选：
> **豆包小说 2.0 Pro + Kimi / 通义 做备选**
你系统里已经有豆包小说 Provider，后续可以把它作为中文小说初稿主力。
---
# 我建议你的生产配置
你的小说系统可以这样设默认路线：
```text
高质量路线：
GPT-5.5 生成小说圣经
Claude Opus 4.8 写正文
GPT-5.5 做质检和记忆更新
成本平衡路线：
GPT-5.5 生成小说圣经
豆包小说 2.0 Pro 写正文
GPT-5.5 / Kimi 做质检润色
低成本批量路线：
豆包小说 2.0 Lite / Kimi 写初稿
DeepSeek / 通义 做章节卡
GPT-5.5 只做关键节点质检
```
---
# 给你的架构建议
你的后台 Provider 已经区分 `TextProvider`、`NovelProvider`、`VoiceProvider`、`VideoProvider`。下一步应该在小说流水线里做一个 **NovelRouter**，类似你现有真人视频的 `AiRouterService`。
它按任务选择模型：
```text
bible_generation → GPT-5.5 / Claude Opus
chapter_draft → Claude / 豆包小说
polish → Claude
continuity_check → GPT-5.5
memory_update → GPT-5.5 / Kimi
audio_script → 豆包 / Kimi
drama_script → GPT-5.5
storyboard_prompt → GPT-5.5
```
这样才是最适合你的方案。
一句话：
> **世界上单论小说文笔，Claude 最强；
> 单论自动化小说工业流水线，GPT-5.5 最稳；
> 单论中文批量成本，豆包 / Kimi / 通义更适合。
> 你的系统最好是 Claude 写、GPT-5.5 管、国内模型批量跑。**
[1]: https://www.anthropic.com/news/claude-for-creative-work "Claude for Creative Work \ Anthropic"
[2]: https://docs.anthropic.com/en/docs/about-claude/models/whats-new-claude-4-8?utm_source=chatgpt.com "What's new in Claude Opus 4.8"
[3]: https://openai.com/index/introducing-gpt-5-5/ "Introducing GPT-5.5 | OpenAI"
[4]: https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/ "Gemini 3.1 Pro: Announcing our latest Gemini AI model"
Claude 最强 是啥公司的
Claude 是 **Anthropic** 公司的 AI 模型。
**Anthropic** 是一家美国 AI 公司，核心产品就是 **Claude** 系列模型。它和 OpenAI、Google DeepMind、xAI、Meta AI 这些公司属于同一类大模型公司。
简单理解：
| 模型 | 公司 |
| ----------------- | ----------- |
| ChatGPT / GPT-5.5 | OpenAI |
| Claude | Anthropic |
| Gemini | Google |
| Grok | xAI |
| Llama | Meta |
| 豆包 | 字节跳动 / 火山引擎 |
| 通义千问 | 阿里 |
| 文心一言 / 千帆 | 百度 |
| Kimi | 月之暗面 |
| DeepSeek | 深度求索 |
Claude 的特点是：**写作、长文理解、人物情绪、文学表达、长篇创作比较强**。
所以我前面说，如果单看“小说文笔和人物细腻度”，Claude 通常很适合当主写手。
但你要做 API 自动化小说流水线，我还是建议：
**Claude 负责正文质量，GPT-5.5 负责架构、质检、上下文管理，豆包/Kimi/通义负责中文低成本批量生成。**
docs/chatgpt/novel/6.md
+261
View File
@@ -0,0 +1,261 @@
我就是要写中文 高质量小说 做剧本
你要的是：**中文高质量小说 + 后续能做剧本/短剧**。
那我建议不要只选一个模型，而是按“主编—作家—编剧—质检”分工。
# 最适合你的模型组合
## 1. 中文高质量小说主写手
优先级：
```text
Claude Opus / Claude Fable
GPT-5.5
豆包小说 2.0 Pro
Kimi
通义千问
```
如果单看**人物细腻、心理、文学感、长篇情绪**，Claude 还是很强。
但如果你要写的是**中文商业小说 + 后续改短剧**，我不建议完全依赖 Claude。因为 Claude 有时中文表达会偏“翻译腔 / 文艺腔”，短剧对白不一定最接地气。
---
## 2. 中文短剧剧本主力
优先级：
```text
GPT-5.5
豆包 2.0 Pro
Kimi
通义千问
Claude
```
短剧剧本最重要的不是文笔，而是：
场景清楚；
对白能演；
情绪推进快；
每集有钩子；
人物行动明确；
适合视频生成。
这方面 **GPT-5.5 更适合做总编剧和剧本结构师**。
---
## 3. 中文网感 / 本土化对白
优先级：
```text
豆包 2.0 Pro
Kimi
通义千问
DeepSeek
```
这些模型更适合做：
中文口语；
短剧对白；
平台感标题；
章节爽点；
听书稿口语化；
短视频分镜文案。
你现在系统里已经启用了豆包小说、DeepSeek 小说、通义小说、Kimi 小说、智谱小说和 OpenAI Responses 小说 Provider，这个基础是对的。
---
# 我给你的最终推荐
## 高质量路线
适合你要做精品中文小说、投稿、短剧测试。
```text
GPT-5.5：小说圣经 / 世界观 / 人物关系 / 伏笔 / 章节卡
Claude：正文初稿 / 文学润色 / 人物心理
GPT-5.5：连贯性检查 / 伏笔检查 / 剧本改编
豆包 2.0 Pro：中文短剧对白本土化 / 听书稿口语化
```
这是最稳的。
---
## 成本平衡路线
适合批量测试多个题材。
```text
GPT-5.5：小说圣经 / 章节卡 / 质检
豆包小说 2.0 Pro：正文初稿
Kimi / 通义：润色或改写
GPT-5.5：最终质检和剧本改编
```
这条路线成本低很多，质量也能控制。
---
## 低成本批量路线
适合大量跑选题、测试市场。
```text
豆包小说 2.0 Lite / Kimi：章节初稿
DeepSeek / 通义：章节卡和摘要
GPT-5.5：每 5 章或每 10 章做一次总审
```
这条路线不适合直接做精品，但适合筛选题材。
---
# 如果你只允许我选一个模型
如果只能选一个模型来做整个系统：
> **选 GPT-5.5。**
原因不是它单章文笔一定最强，而是它最适合你的工程系统：
能设计小说；
能写章节；
能做 JSON 结构化；
能做质检；
能做上下文记忆；
能改剧本；
能生成分镜；
能生成视频提示词；
适合 API 流水线。
Claude 更像“高级作家”。
GPT-5.5 更像“总导演 + 主编 + 架构师”。
你现在做的是自动化系统，不是单次聊天写一篇文章，所以 GPT-5.5 必须做中枢。
---
# 我建议你后台默认这样配置
你现在已有 Provider 类型，包括 `TextProvider`、`NovelProvider`、`VideoProvider`、`VoiceProvider` 等，而且小说和短剧模块已经分开，这很适合做路由分工。
建议新增一个：
```text
NovelRouter
```
按任务自动选模型。
## NovelRouter 默认策略
| 任务 | 推荐模型 |
| ------- | --------------------- |
| 选题深化 | GPT-5.5 |
| 小说圣经 | GPT-5.5 |
| 人物档案 | GPT-5.5 + Claude |
| 世界观 | GPT-5.5 |
| 伏笔库 | GPT-5.5 |
| 章节卡 | GPT-5.5 |
| 中文正文初稿 | Claude / 豆包小说 2.0 Pro |
| 文学润色 | Claude |
| 中文口语优化 | 豆包 / Kimi |
| 连贯性检查 | GPT-5.5 |
| 伏笔检查 | GPT-5.5 |
| 章节质量评分 | GPT-5.5 |
| 小说转听书 | 豆包 / Kimi |
| 小说转短剧剧本 | GPT-5.5 |
| 短剧对白本土化 | 豆包 2.0 Pro |
| 分镜脚本 | GPT-5.5 |
| 视频提示词 | GPT-5.5 |
---
# 你的目标下，模型不能这样用
不要这样：
```text
一个模型从小说圣经写到最终短剧
```
一定会出现：
上下文乱；
人设飘；
伏笔忘；
文风不稳定；
短剧改编不顺；
视频提示词不可控。
正确做法是：
```text
GPT-5.5 管结构
Claude 写质感
豆包/Kimi 做中文口语和短剧本土化
GPT-5.5 再做质检和改编
```
---
# 高质量中文小说 + 短剧的最佳流程
你系统里可以这样跑：
```text
1. GPT-5.5 生成 IP 圣经
2. GPT-5.5 生成全书结构 / 分卷 / 伏笔
3. GPT-5.5 生成章节卡
4. Claude 写小说正文
5. Claude 做文学润色
6. GPT-5.5 做连贯性和伏笔检查
7. 豆包/Kimi 做中文口语自然化
8. GPT-5.5 生成短剧剧本
9. 豆包 2.0 Pro 优化短剧对白
10. GPT-5.5 生成分镜和视频提示词
```
---
# 最终答案
你要写**中文高质量小说并改剧本**，最佳不是单模型，而是：
```text
GPT-5.5 + Claude + 豆包/Kimi
```
具体分工：
```text
GPT-5.5：总策划、结构、上下文、质检、剧本、分镜
Claude：小说正文、人物心理、文学润色
豆包/Kimi：中文本土化、短剧对白、听书稿
```
如果你要我帮你定系统默认配置，我会这样设：
```text
精品模式：
GPT-5.5 + Claude + 豆包 2.0 Pro
平衡模式：
GPT-5.5 + 豆包小说 2.0 Pro + Kimi
低成本模式：
豆包小说 2.0 Lite + Kimi + GPT-5.5抽检
```
你现在做的是**小说/听书/短剧内容中台**，不是单纯写小说。
所以真正最强方案是：
> **GPT-5.5 当总导演，Claude 当主笔，豆包/Kimi 当中文短剧编剧。**
docs/chatgpt/novel/7.md
+519
View File
@@ -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
同一章一个主写模型
连续章节按顺序写
每章写完必须更新记忆
所有模型都读取同一个小说圣经和上下文快照
短剧/听书基于小说版本快照派生
```
一句话：
> **不是让一个模型记住全部，而是让你的系统成为“小说大脑”。模型只是不同岗位的员工，每次上岗前都读取同一份档案。**
docs/chatgpt/novel/8.md
+511
View File
@@ -0,0 +1,511 @@
如果这样，那章节越多，后续要传递给api的参数就越多？
是的，**如果你每次都把前面所有章节正文传给 API，章节越多，参数一定越来越大，成本会爆，速度也会慢。**
但真正的长篇小说系统**不能这么做**。
正确做法是：
> **不是把全部正文传给模型，
> 而是把“压缩后的关键记忆 + 当前章节相关内容”传给模型。**
也就是说，后面写第 100 章，不需要把前 99 章全文都传进去，只需要传：
```text
小说圣经摘要
当前卷纲
最近 3-5 章摘要
本章相关人物状态
本章相关伏笔
本章章节卡
禁止改动规则
文风规则
```
这样 API 输入会长期保持稳定，不会随着章节无限增长。
---
# 一、错误做法：全文堆上下文
比如写第 80 章时，你把第 1–79 章全部塞进去：
```text
第1章全文
第2章全文
第3章全文
...
第79章全文
请写第80章
```
这个做法有几个问题：
1. token 成本越来越高；
2. 请求越来越慢；
3. 模型容易被大量旧内容干扰；
4. 真正重要的信息反而被淹没；
5. 超过上下文长度后直接无法调用；
6. 多模型协作时更难稳定。
所以长篇流水线绝对不能靠“全文传递”。
---
# 二、正确做法：三层记忆压缩
你要做的是**分层记忆**。
## 第一层：永久核心记忆
每次都传，但内容要很短。
包括：
```text
小说一句话核心
世界观规则
主角核心人设
主要角色不可改动项
文风规则
禁用桥段
短剧改编规则
```
控制在 **1000–2000 字**。
这部分相当于小说宪法。
---
## 第二层：近期记忆
每次只传最近 3–5 章摘要。
比如写第 80 章，只传：
```text
第75章摘要
第76章摘要
第77章摘要
第78章摘要
第79章摘要
```
不传全文。
每章摘要控制在 150–300 字。
总共大概 **1000–1500 字**。
---
## 第三层：检索记忆
这部分不是每次都传全部，而是按本章需要查。
比如第 80 章出场人物是：
```text
岑青
陈淑蘅
姚知知
```
那就只查这几个人的状态：
```text
岑青当前知道了什么
陈淑蘅隐瞒了什么
姚知知上次出现在哪里
她们之间的关系变化
```
如果本章涉及某个伏笔，就只查相关伏笔。
比如：
```text
F012：被撕掉的签到簿缺页
F018：姚知知画本里的第五只手
```
不相关的伏笔不传。
---
# 三、写第 100 章时，真正传给 API 的应该是这样
不是：
```text
前99章全文 + 请写第100章
```
而是：
```json
{
"bible_summary": "小说核心设定摘要，约1500字",
"style_rules": [
"克制",
"电影感",
"不狗血",
"不打脸复仇",
"对白短而有张力"
],
"current_volume_outline": "当前第3卷卷纲摘要，约800字",
"recent_chapter_summaries": [
"第95章摘要",
"第96章摘要",
"第97章摘要",
"第98章摘要",
"第99章摘要"
],
"active_character_states": [
{
"name": "岑青",
"current_state": "已经确认林照不是一个人，但还缺最后证据"
},
{
"name": "陈淑蘅",
"current_state": "知道周榕真名，但仍不愿公开其他女工身份"
}
],
"active_foreshadows": [
{
"code": "F012",
"title": "签到簿缺页",
"status": "developing",
"expected_reveal": "第102章"
}
],
"chapter_card": {
"chapter_no": 100,
"title": "缺页",
"goal": "岑青找到签到簿缺失页的线索",
"must_happen": [
"姚知知交出画本",
"岑青发现画本夹层里有一页旧纸",
"陈淑蘅第一次失控"
],
"ending_hook": "纸页上不是一个名字，而是五个名字"
}
}
```
这个上下文即使写到第 500 章，也可以控制在 **4000–8000 字**以内。
---
# 四、上下文不是越多越好，而是越准越好
很多人误以为：
> 传越多，AI 越不会乱。
其实不一定。
真正有效的是：
```text
重要信息完整
无关信息少
当前任务明确
禁止事项清楚
```
你给模型塞 30 万字前文，它不一定抓得住重点。
但你给它一份高质量上下文：
```text
当前主线
当前人物状态
当前伏笔
上一章结尾
本章目标
不能写什么
```
它反而更稳。
---
# 五、你系统里要做“记忆压缩器”
每写完一章，就让 AI 或程序生成一份压缩记忆。
比如第 20 章正文有 3000 字，压缩成：
```json
{
"chapter_no": 20,
"summary": "岑青在旧仓库找到签到簿，发现林照名下有五种笔迹。",
"character_updates": [
{
"name": "岑青",
"update": "开始怀疑林照不是单一人物"
},
{
"name": "陈淑蘅",
"update": "看到签到簿后明显紧张，但拒绝解释"
}
],
"new_foreshadows": [
{
"code": "F020",
"title": "被撕掉的一页",
"surface": "签到簿中间缺了一页",
"hidden_truth": "缺页记录了火灾当晚真实值班名单"
}
],
"next_chapter_must_continue": [
"岑青需要追查缺页",
"陈淑蘅不能立刻说出全部真相"
]
}
```
以后第 50 章、第 100 章需要这个信息时，系统从数据库查这条摘要，不用查完整正文。
---
# 六、上下文传递应该有 4 个等级
## L1：每次必传
```text
小说圣经摘要
文风规则
禁用规则
本章章节卡
```
---
## L2：经常传
```text
最近 3-5 章摘要
当前卷纲
当前主线进度
```
---
## L3：按需传
```text
本章出场人物状态
本章相关伏笔
本章相关场景
本章相关道具
```
---
## L4：特殊情况才传
```text
某一章原文片段
某个角色上次出场完整段落
某个伏笔首次出现原文
某段重要对白
```
只有当模型需要复刻细节时，才传原文片段。
比如本章要回收第 12 章的一句台词，那就检索第 12 章相关原文片段传进去。
---
# 七、成本大概怎么控制？
假设一章 3000 字。
错误做法：
```text
写第100章时传前99章全文
≈ 30万字上下文
```
这非常贵，也不稳定。
正确做法：
```text
固定核心上下文：1500字
最近5章摘要：1500字
人物状态：800字
伏笔：800字
章节卡：800字
风格规则：500字
```
总共大概：
```text
5900字上下文
```
后续写到第 300 章，也还是差不多 5000–8000 字上下文。
成本是可控的。
---
# 八、你要加一个 Context Budget 机制
系统里要给每次调用设置上下文预算。
比如：
```json
{
"max_context_tokens": 12000,
"budget": {
"bible_summary": 2000,
"recent_summaries": 2000,
"character_states": 2000,
"foreshadows": 1500,
"chapter_card": 1500,
"style_rules": 1000,
"retrieved_original_snippets": 2000
}
}
```
如果超过预算，系统自动压缩。
优先级：
```text
本章章节卡 > 人物当前状态 > 最近章节摘要 > 相关伏笔 > 小说圣经摘要 > 原文片段
```
不是所有东西都平等。
---
# 九、你现有系统可以这样落地
你当前项目已经有 `MemoriesModule`，也有小说章节管理、故事圣经、角色、分集、脚本、分镜这些模块。文档里也提到后续需要把小说、故事圣经、角色抽取、分集、脚本、分镜等文本步骤统一成更严格的 schema、重试、验证和 Prompt 版本管理。
所以你现在应该补：
```text
NovelContextBuilderService
NovelMemoryCompressorService
NovelRetrievalService
NovelContextBudgetService
```
职责如下：
```text
NovelMemoryCompressorService：
每章写完后，把正文压缩成摘要、人物变化、伏笔变化。
NovelRetrievalService：
写新章前，从数据库检索相关人物、伏笔、场景、章节片段。
NovelContextBudgetService：
控制本次 API 输入不要超预算。
NovelContextBuilderService：
把所有信息拼成最终 Prompt。
```
---
# 十、一个稳定的 Context Builder 流程
```text
准备写第 N 章
↓
读取小说圣经摘要
↓
读取当前卷纲
↓
读取最近 5 章摘要
↓
读取章节卡
↓
根据章节卡识别出场人物
↓
读取这些人物当前状态
↓
根据章节卡识别相关伏笔
↓
读取这些伏笔状态
↓
如有需要，检索原文片段
↓
按 token 预算压缩
↓
拼成最终 API prompt
↓
调用模型写作
```
这样章节再多，也不会爆。
---
# 十一、最重要的数据库设计
你至少需要这几个表：
```text
NovelContextMemory
NovelCharacterState
NovelForeshadow
NovelChapterSummary
NovelAgentRunContext
```
如果你不想多建表，也可以先把它们合并进一个 `NovelContextMemory`，用 `memory_type` 区分。
例如：
```text
memory_type = bible_summary
memory_type = chapter_summary
memory_type = character_state
memory_type = foreshadow
memory_type = style_rule
memory_type = timeline
```
第一版这样就够。
---
# 十二、最终答案
你的担心是对的：
> **如果每次都传全部章节，章节越多，API 参数一定越来越多。**
但专业系统不会这么做。
专业系统是：
```text
全文入库
摘要常用
相关内容检索
上下文预算控制
每章写完更新记忆
每次调用只传必要信息
```
一句话：
> **小说全文存在数据库里，不存在 Prompt 里。
> Prompt 里只放当前模型完成任务必须知道的内容。**
这样写 30 章、300 章、1000 章，API 输入都可以保持稳定。
docs/chatgpt/novel/9.md
+331
View File
@@ -0,0 +1,331 @@
那 chatgpt 这个网页版是怎么做到记忆的，我使用网页版涩会给你从了120章节小说，挺好的
你在网页版感觉“120 章也记得住”，主要是因为 ChatGPT 产品层做了几件事，不是单纯“模型自己永久记住全文”。
简单说，网页版大概是这几层能力叠加：
```text
当前对话上下文
+ 上传文件解析
+ 长上下文窗口
+ 相关内容检索
+ 对话历史 / 项目文件 / 记忆能力
+ 系统自动挑选相关信息塞回模型
```
OpenAI 官方也说明，ChatGPT 的记忆包括“保存的记忆”和“引用聊天历史”，开启后会从过去对话里提取有用信息加入新对话；项目功能也可以把聊天、参考文件和自定义指令放在一起，让 ChatGPT 保持主题连续；文件上传也支持较大的文本/文档文件。([OpenAI Help Center][1])
---
# 一、网页版不是把 120 章永远塞进模型脑子里
你上传 120 章小说后，ChatGPT 能表现得不错，通常是因为：
1. 文件被解析成文本；
2. 系统知道这个文件属于当前会话/项目；
3. 你问问题时，系统会从文件和对话里找相关片段；
4. 把相关内容、摘要、上下文放进本次模型输入；
5. 模型基于这些内容回答。
也就是说，它不是“永久记住 120 章全文每个字”，而是：
> **文件在系统里，模型每次需要时可以被喂到相关内容。**
这和我前面说的小说流水线是同一个原理。
你的系统也要这么做：
```text
小说全文入库
章节摘要入库
人物状态入库
伏笔入库
按需检索
拼装上下文
再调用模型
```
---
# 二、为什么网页版看起来比普通 API 更聪明？
因为网页版 ChatGPT 已经帮你做了很多产品层工作。
比如：
## 1. 当前聊天本身有上下文
你在同一个聊天里连续讨论，前面的内容会作为上下文的一部分参与后续回答。
但这有长度限制，不是无限的。
---
## 2. 上传文件可以被引用
你上传小说文件后，ChatGPT 可以围绕文件问答、总结、分析。官方文件上传 FAQ 里提到，文本和文档文件有 token 上限，文件大小也有限制。([OpenAI Help Center][2])
这说明文件不是“变成模型永久记忆”，而是作为可处理的数据源。
---
## 3. ChatGPT 有记忆和引用聊天历史
官方说明，开启“Reference chat history”后，ChatGPT 会引用过去对话中有用的信息，让后续对话更个性化、更相关。([OpenAI Help Center][3])
但这类记忆更适合记：
你的偏好；
你的项目方向；
你常用技术栈；
你之前的要求；
你对风格的偏好。
它不适合当作“精确保存 120 章小说全文”的数据库。
---
## 4. Projects 可以聚合上下文
ChatGPT Projects 可以把聊天、文件和项目指令放在一起，让工作更连续。官方说明 Projects 可以组织聊天、上传参考文件、添加自定义指令，让 ChatGPT 围绕项目保持主题。([OpenAI Help Center][4])
这跟你系统里的“NovelSource + StoryBible + Memory + Character + Foreshadow”很像。
---
# 三、API 里为什么感觉不一样？
因为 API 默认不会自动帮你做这么完整的产品层。
API 更像一个模型调用接口：
```text
你传什么，它就基于什么回答。
```
如果你想让 API 也像网页版一样“记得住”，你要自己实现这些层：
```text
文件解析层
章节切分层
摘要层
向量检索层
上下文拼装层
记忆更新层
版本快照层
```
网页版帮你做了很多。
你自己的系统要自己做。
---
# 四、你系统应该仿照 ChatGPT 做什么？
你可以把 ChatGPT 的机制“产品化”到你自己的小说系统里。
## 1. 小说全文库
保存完整正文。
```text
NovelSource
NovelChapter
```
你现在已经有这部分。你的架构文档里也显示当前小说系统已支持小说源、章节、阅读器、章节导入和章节切割。
---
## 2. 小说摘要库
每章保存摘要。
```text
第1章摘要
第2章摘要
……
第120章摘要
```
后续写第 121 章，不传 120 章全文，只传相关摘要。
---
## 3. 人物状态库
不能只存人物初始设定，要存当前状态。
比如：
```text
主角当前知道什么
女主和男主关系到哪一步
反派是否暴露
某人有没有死亡
某秘密是否揭开
```
---
## 4. 伏笔库
专门管理伏笔。
```text
F001 首次出现第3章
当前状态 developing
预计第80章回收
```
---
## 5. 检索层
当写第 121 章时，系统根据章节卡自动检索：
```text
本章出场人物
相关伏笔
相关地点
上次出场章节
关键原文片段
```
---
## 6. 上下文拼装层
最后拼成给模型的输入：
```text
小说圣经摘要
当前卷纲
最近5章摘要
本章出场人物状态
本章相关伏笔
本章章节卡
相关原文片段
文风规则
禁止事项
```
这就等于你自己做了一个“小说版 ChatGPT 项目上下文”。
---
# 五、为什么你上传 120 章时效果还可以？
因为你给的是一个完整作品，任务可能是“分析、总结、改编、继续设计”。
这种情况下，模型可以通过文件检索和长上下文找到足够信息。
但如果你要自动写 300 章、500 章，情况就不一样了。
区别在这里：
| 场景 | 难度 |
| ------------------- | --- |
| 上传 120 章，让 AI 分析 | 较容易 |
| 上传 120 章，让 AI 改编剧本 | 中等 |
| 从第 1 章开始自动写到第 500 章 | 很难 |
| 多模型自动写长篇并保持伏笔、人设、节奏 | 更难 |
所以你做系统时不能只靠“上传全文让模型看”。
要做长期可控的记忆系统。
---
# 六、最接近 ChatGPT 网页版的自建方案
你可以这样设计：
```text
NovelSource = 文件/小说源
NovelChapter = 章节正文
NovelMemory = 自动摘要/人物状态/伏笔
NovelEmbedding = 章节向量索引
NovelContextBuilder = 上下文拼装器
AgentRun = 每次模型调用记录
```
写第 N 章时：
```text
1. 查 NovelBible
2. 查当前卷纲
3. 查最近 5 章摘要
4. 查出场人物状态
5. 用 embedding 检索相关旧章节片段
6. 查相关伏笔
7. 控制 token 预算
8. 拼 prompt
9. 调模型
10. 保存输出
11. 更新摘要/人物/伏笔
```
这就是你要在后台复刻的“ChatGPT 网页版长上下文体验”。
---
# 七、重点提醒
网页版看起来“记住”，但也会有问题：
1. 它不保证每个细节都准；
2. 它可能漏掉很早以前的小伏笔；
3. 它可能把相似角色混淆；
4. 它不会自动替你维护商业化流程；
5. 它没有你的数据库、成本、队列、版本、派生短剧任务控制。
所以你做系统不能完全依赖模型能力。
真正可控的是：
```text
系统记忆 > 模型记忆
结构化上下文 > 全文堆入
版本快照 > 当前文本覆盖
质检闭环 > 一次生成
```
---
# 八、对应你当前系统的落地判断
你现在项目里已经有：
```text
NovelsModule
StoryBiblesModule
CharactersModule
MemoriesModule
EpisodesModule
ScriptsModule
LiveActionModule
Provider Layer
BullMQ Worker
```
这些模块非常适合做“网页版 ChatGPT 类似的小说项目上下文”。
下一步不是纠结“API 怎么像网页版一样记住”，而是补：
```text
NovelContextBuilderService
NovelMemoryCompressorService
NovelEmbedding/RetrievalService
NovelVersionSnapshot
NovelAgentRunContextSnapshot
```
一句话：
> **ChatGPT 网页版是 OpenAI 帮你做了上下文管理；
> 你接 API，就要在自己的系统里做同样的上下文管理。**
[1]: https://help.openai.com/en/articles/8590148-memory-faq?utm_source=chatgpt.com "Memory FAQ"
[2]: https://help.openai.com/en/articles/8555545-file-uploads-faq?utm_source=chatgpt.com "File Uploads FAQ"
[3]: https://help.openai.com/en/articles/11146739-how-does-reference-saved-memories-work?utm_source=chatgpt.com "How does “Reference saved memories” work?"
[4]: https://help.openai.com/en/articles/10169521-projects-in-chatgpt?utm_source=chatgpt.com "Projects in ChatGPT"