www
9.4 KiB
如果这样，那章节越多，后续要传递给api的参数就越多？
是的，如果你每次都把前面所有章节正文传给 API，章节越多，参数一定越来越大，成本会爆，速度也会慢。
但真正的长篇小说系统不能这么做。
正确做法是：
不是把全部正文传给模型， 而是把“压缩后的关键记忆 + 当前章节相关内容”传给模型。
也就是说，后面写第 100 章，不需要把前 99 章全文都传进去，只需要传：
小说圣经摘要
当前卷纲
最近 3-5 章摘要
本章相关人物状态
本章相关伏笔
本章章节卡
禁止改动规则
文风规则
这样 API 输入会长期保持稳定，不会随着章节无限增长。
一、错误做法：全文堆上下文
比如写第 80 章时，你把第 1–79 章全部塞进去：
第1章全文
第2章全文
第3章全文
...
第79章全文
请写第80章
这个做法有几个问题：
- token 成本越来越高；
- 请求越来越慢；
- 模型容易被大量旧内容干扰；
- 真正重要的信息反而被淹没；
- 超过上下文长度后直接无法调用；
- 多模型协作时更难稳定。
所以长篇流水线绝对不能靠“全文传递”。
二、正确做法：三层记忆压缩
你要做的是分层记忆。
第一层：永久核心记忆
每次都传，但内容要很短。
包括：
小说一句话核心
世界观规则
主角核心人设
主要角色不可改动项
文风规则
禁用桥段
短剧改编规则
控制在 1000–2000 字。
这部分相当于小说宪法。
第二层：近期记忆
每次只传最近 3–5 章摘要。
比如写第 80 章，只传：
第75章摘要
第76章摘要
第77章摘要
第78章摘要
第79章摘要
不传全文。
每章摘要控制在 150–300 字。
总共大概 1000–1500 字。
第三层：检索记忆
这部分不是每次都传全部，而是按本章需要查。
比如第 80 章出场人物是：
岑青
陈淑蘅
姚知知
那就只查这几个人的状态：
岑青当前知道了什么
陈淑蘅隐瞒了什么
姚知知上次出现在哪里
她们之间的关系变化
如果本章涉及某个伏笔，就只查相关伏笔。
比如：
F012：被撕掉的签到簿缺页
F018：姚知知画本里的第五只手
不相关的伏笔不传。
三、写第 100 章时，真正传给 API 的应该是这样
不是：
前99章全文 + 请写第100章
而是：
{
"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 越不会乱。
其实不一定。
真正有效的是：
重要信息完整
无关信息少
当前任务明确
禁止事项清楚
你给模型塞 30 万字前文，它不一定抓得住重点。
但你给它一份高质量上下文：
当前主线
当前人物状态
当前伏笔
上一章结尾
本章目标
不能写什么
它反而更稳。
五、你系统里要做“记忆压缩器”
每写完一章，就让 AI 或程序生成一份压缩记忆。
比如第 20 章正文有 3000 字，压缩成：
{
"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：每次必传
小说圣经摘要
文风规则
禁用规则
本章章节卡
L2：经常传
最近 3-5 章摘要
当前卷纲
当前主线进度
L3：按需传
本章出场人物状态
本章相关伏笔
本章相关场景
本章相关道具
L4：特殊情况才传
某一章原文片段
某个角色上次出场完整段落
某个伏笔首次出现原文
某段重要对白
只有当模型需要复刻细节时，才传原文片段。
比如本章要回收第 12 章的一句台词，那就检索第 12 章相关原文片段传进去。
七、成本大概怎么控制？
假设一章 3000 字。
错误做法：
写第100章时传前99章全文
≈ 30万字上下文
这非常贵，也不稳定。
正确做法：
固定核心上下文：1500字
最近5章摘要：1500字
人物状态：800字
伏笔：800字
章节卡：800字
风格规则：500字
总共大概：
5900字上下文
后续写到第 300 章，也还是差不多 5000–8000 字上下文。
成本是可控的。
八、你要加一个 Context Budget 机制
系统里要给每次调用设置上下文预算。
比如：
{
"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
}
}
如果超过预算，系统自动压缩。
优先级：
本章章节卡 > 人物当前状态 > 最近章节摘要 > 相关伏笔 > 小说圣经摘要 > 原文片段
不是所有东西都平等。
九、你现有系统可以这样落地
你当前项目已经有 MemoriesModule，也有小说章节管理、故事圣经、角色、分集、脚本、分镜这些模块。文档里也提到后续需要把小说、故事圣经、角色抽取、分集、脚本、分镜等文本步骤统一成更严格的 schema、重试、验证和 Prompt 版本管理。
所以你现在应该补：
NovelContextBuilderService
NovelMemoryCompressorService
NovelRetrievalService
NovelContextBudgetService
职责如下：
NovelMemoryCompressorService：
每章写完后，把正文压缩成摘要、人物变化、伏笔变化。
NovelRetrievalService：
写新章前，从数据库检索相关人物、伏笔、场景、章节片段。
NovelContextBudgetService：
控制本次 API 输入不要超预算。
NovelContextBuilderService：
把所有信息拼成最终 Prompt。
十、一个稳定的 Context Builder 流程
准备写第 N 章
↓
读取小说圣经摘要
↓
读取当前卷纲
↓
读取最近 5 章摘要
↓
读取章节卡
↓
根据章节卡识别出场人物
↓
读取这些人物当前状态
↓
根据章节卡识别相关伏笔
↓
读取这些伏笔状态
↓
如有需要，检索原文片段
↓
按 token 预算压缩
↓
拼成最终 API prompt
↓
调用模型写作
这样章节再多，也不会爆。
十一、最重要的数据库设计
你至少需要这几个表：
NovelContextMemory
NovelCharacterState
NovelForeshadow
NovelChapterSummary
NovelAgentRunContext
如果你不想多建表，也可以先把它们合并进一个 NovelContextMemory，用 memory_type 区分。
例如：
memory_type = bible_summary
memory_type = chapter_summary
memory_type = character_state
memory_type = foreshadow
memory_type = style_rule
memory_type = timeline
第一版这样就够。
十二、最终答案
你的担心是对的：
如果每次都传全部章节，章节越多，API 参数一定越来越多。
但专业系统不会这么做。
专业系统是：
全文入库
摘要常用
相关内容检索
上下文预算控制
每章写完更新记忆
每次调用只传必要信息
一句话：
小说全文存在数据库里，不存在 Prompt 里。 Prompt 里只放当前模型完成任务必须知道的内容。
这样写 30 章、300 章、1000 章，API 输入都可以保持稳定。