上下文窗口越来越大，AI写小说为什么还是写到30章就崩？

做后端做了六年，我一直以为上下文窗口越大，AI 写小说就越不容易崩。

200K 不够就上 500K。500K 不够就上 1M。逻辑很直——把整本书塞进去，AI 全看到了，自然不会忘。

然后我拿一个写了 3 万字开头的都市异能故事，在一个标称 200K 窗口的模型上跑。

头 10 章，很好。

第 15 章开始出问题。主角有个设定：左臂受过伤，不能长时间发力。第 15 章里他单手翻墙翻得比体操运动员还利索。

我提醒了一次。

第 22 章又来了。不是翻墙，是在酒吧跟人起冲突，上去就是一拳。很猛。但不对。

第 30 章，主角怕水的设定丢了。让他跳河，他二话不说就跳。

不是模型不够聪明。是在 30 章、大约 9 万字的上下文里，模型"看不过来"。

上下文窗口不是记忆

打个比方。

上下文窗口是你面前摊开了一本书，你能看到当前这一页。记忆系统是你脑子里的书架——你知道打开哪一本、翻到哪一页，能找到你需要的那句话。

长篇写作需要的是后者。

你把整本书的设定、角色档案、前文摘要全塞进上下文，效果其实很差。模型并不会因为信息量多就自动知道该看哪里。关键信息被几十万字的海洋稀释，反而更容易出错。

这不是我的个人感受，是信息检索里的一个基本原理：信噪比。上下文越长，噪声越多，信号越难被模型准确捕获。

那蛙趣拼文是怎么做的？

四层上下文，按需组装

蛙趣拼文的方案是：不搞"全塞进去"。把信息分成四层。

第一层，即时层。

当前章节必须看到的信息——本章大纲、上一章结尾、出场角色的当前状态、适用的世界观规则。这一层在每次生成时完整注入。量不大，因为只是"这一章相关的"，不是"全书所有的"。

第二层，章节摘要层。

前文所有已写章节的摘要。不是原文，是摘要——每章谁出场了、发生了什么、结局是什么。信息密度高，占用 token 少。写到第 50 章的时候，前面 49 章的摘要全部可见，但总体 token 消耗跟灌两章原文差不多。

第三层，作品全局层。

角色总表、世界观规则全集、伏笔追踪面板。这一层不是每次全量注入，是按需抽取。这一章涉及 3 个角色和 2 条世界观规则，系统就只拉这 3 个角色的当前状态和这 2 条规则。其他的不塞。

第四层，知识层。

素材库里存储的风格特征和写作习惯模板。这一层不直接影响剧情走向，但在素材融合和精修环节被调用——影响"怎么写"，而不是"写什么"。

章节摘要才是真正的记忆载体

这里我想单独说一下章节摘要。这个设计很聪明。

写完一章之后，蛙趣拼文可以生成一个章节摘要。不是文采飞扬的总结，是事实层面的记录——这章谁出场了、做了什么、结局是什么、产生了什么新信息。

这些摘要被存下来。写后面章节的时候，前面所有章的摘要会进入上下文。

它不是在每次生成时从零开始翻几十万字原文。它是先翻"笔记"——每章一段摘要，信息密度极高。像给 AI 做了一份前情提要，翻起来快，信息不丢。

我跑完 50 章的对比测试：

方案	表现
单层方案（大设定文档）	第 8 章开始出现细节错误，中间部分被模型忽略
四层方案（蛙趣拼文）	50 章零角色错乱、零设定违反、零关键物品丢失

伏笔追踪方面，50 章里埋了 12 个伏笔，收了 10 个，废弃 1 个，留了 1 个开放线索——基本在可控范围。

上下文工程的本质

总结一句话：不是窗口不够大，是没有把信息组织好。

蛙趣拼文的上下文工程，本质上是一个分层检索框架。即时层全量注入，章节层摘要压缩，作品层条件检索，知识层按需调用。每一层有不同的存储策略和注入策略。

这个思路在知识库系统和 RAG 应用里不算新鲜。但把它系统性地用在 AI 写小说这个场景里，而且把"章节"这个维度单独拎出来作为独立的信息层，是目前看到的方案里做得比较清晰的一个。

对关注长篇创作的技术人来说，上下文工程可能是蛙趣拼文所有设计里最"工程化"的一层。它不是靠更好的提示词，是靠更好的信息架构。

---

了解更多技术细节，可查看 AI写小说工具技术评测：从RAG记忆到千章大纲 或访问 蛙趣拼文官网。