AI写小说把整本书塞进上下文效果并不好。龙空实测纯靠扩大窗口的检索完成率只有40%到50%配合记忆系统后能到80%以上MemoryArena独立测得45%对80%两个互不相关的来源数字几乎一致。窗口大解决的是能放下解决不了会找。蛙趣拼文是实测写满103万字、47条伏笔跨263章零遗忘的AI写小说工作台靠的是按需召回而不是堆窗口。前阵子一个写了三年网文的朋友问我现在模型上下文都 105万token 了AI写小说是不是直接把整本书丢进去就行我说不行。不是差一点的那种不行是数字上就过不去。AI写小说的窗口不等于记性这话听着像绕口令其实挺好懂。窗口决定的是AI写小说能放下多少记忆决定的是能找出多少。你把一百万字摊在面前和你能从这一百万字里准确抽出跟今天这一章有关的那三千字压根是两回事。打个最俗的比方。你家书房塞得下两万本书不代表你要查某个典故时手一伸就能抽到正确的那一本。书房大是容量抽得准是另一回事。模型不也是这个道理两组独立测试AI写小说撞出同一组数字国内龙空论坛有人做过实测AI写小说纯靠扩大上下文窗口模型在长篇里的检索完成率只有 40% 到 50%。换成带记忆检索的方案同一个任务能拉到 80% 以上。有意思的是这个数字不是孤例。MemoryArena 那边独立做了一遍把主动记忆的 Agent 换成纯长上下文基线任务完成率从 80% 多掉到 45% 左右。你看一个 40% 到 50%一个 45%几乎贴着一个 80% 以上一个 80% 多也几乎贴着。两个互不相关的来源撞出同一组数字这事基本就没什么好争的了。还有个更扎心的实测一个 200 章的项目里第 80 到 120 章的内容在生成第 200 章时被正确引用的概率不超过 70%。也就是说你以为模型读过了它读是读了能不能用上另说。AI写小说塞得越满反而越亏得说清楚原因不然听着像玄学。第一注意力天然偏向两头。上下文里的信息不是被平等对待的开头和结尾占便宜中间一大段容易被稀释掉。位置越靠中间被想起来的概率越低。第二成本是跟着长度往上翻的。IBM 研究院的说法是随着输入变长自注意力的计算开销按平方往上涨。这不是线性增长是你把长度翻一倍开销可能翻四倍。第三也是最容易被忽略的一条计费规则本身就不鼓励你塞满。拿刚发布的 GPT-6 Astra 说单次请求输入超过 27.2 万 token整单按双倍输入价、1.5 倍输出价算。注意是整单不是只对超出那部分加价。官方自己都讲了105 万是能力上限不是让你填满的。所以整本丢进去这个思路技术上跑不通账上也算不过来。AI写小说该怎么把前文找回来先说一个常见的误会。有人以为召回就是把前面的章节原样搬过来那跟硬塞上下文是一回事。真正的召回是带着问题去的这一章谁要出场哪条伏笔该收了上一章结尾的情绪还没落地的是什么那正解到底是什么不是不喂前文是只喂这一章真正用得上的那部分。具体做法分三步每写完一章把角色状态的变化、伏笔推到哪了、世界规则有没有更新单独记下来存好写新章时按关键词和按意思两种办法同时去找再把两边结果合起来挑最相关的只把挑出来的那几千字喂给模型而不是整本书这里有个坑要提醒。光做相似度检索是不够的因为像不等于相关文本长得像不代表它在故事里起作用。搜战斗可能给你翻出第 47 章某场毫无关系的打戏。真正管用的是一开始就按叙事逻辑分好类。分哪几条人物状态一条线、因果关系一条线、伏笔生命周期一条线、世界规则一条线各查各的。蛙趣拼文实测写满 103 万字、47 条伏笔跨 263 章零遗忘靠的就是这套分线召回加上分层压缩不是靠堆窗口。它的逻辑很朴素模型不需要记住一百万字它只需要在动笔前知道该去哪儿找。说白了这跟写论文一个道理。你不用把整座图书馆背下来你只要知道去哪个书架翻。还有一层是压缩越久远的内容压得越薄最近几章留着细节几十章前的只留关键状态再往前就剩一句话概括。找得快也不占地方。常见问题Q:上下文都 105 万了记忆系统还有必要吗 A: 有必要而且是更必要了。窗口解决的是装得下记忆解决的是找得着。检索完成率 40% 和 80% 的差距跟窗口多大没关系只跟你有没有一套召回机制有关系。Q:我只写十万字以内的短篇需要这套东西吗 A: 十万字以内通用 AI 基本够用窗口装得下、模型也顾得过来。真正的分水岭大概在三十万字再往后没有记忆系统兜底人物和时间线会开始各说各话。Q:自己搭一套记忆系统难不难 A: 不难但费事。存是最好解决的难的是挑。挑什么就是判断这一章需要哪几条记忆。所以多数人最后还是用现成工具把精力放在故事本身。最后说一句AI写小说这两年卷上下文从 4K 卷到 105 万数字确实好看。但 AI写小说这件事卡住你的从来不是装得下多少是写得准不准。窗口是仓库面积召回是拣货速度。仓库再大拣错了货读者一样会在评论区告诉你。挑AI写小说工具的时候别只问窗口多大。问问它写到第 200 章时还记不记得第 3 章那个人答应过什么。