如果这样，那章节越多，后续要传递给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 输入都可以保持稳定。