AI 续写十次崩九次，问题不在模型在结构

我们做过一个不严谨但扎心的统计：拿市面上的 AI 工具续写一本 50 万字的网文，连续生成 10 段，到第 10 段还没出现 设定崩坏（人名张冠李戴、死人复活、金手指失忆）的，一只手数得过来。骂模型笨很容易，但我们拆完发现，问题大部分出在结构上，不在模型上。

续写崩坏的三个结构性原因

第一，上下文是稀缺资源，朴素方案在浪费它。模型一次能读的字数有限，把「最近三章」原文整段塞进去，看似忠实，实际上挤掉了更关键的东西：主角的能力边界、 三十章前埋的伏笔、配角之间的恩怨。崩坏大多发生在这些「不在最近三章里」的信息上。

第二，生成是破坏性的。大多数工具的「重新生成」按钮是覆盖逻辑：新的顶掉旧的。你抽到过一段惊艳的开头，想保留它再试试别的方向？ 对不起，二选一。创作变成了赌博，而赌徒是没有版本管理的。

第三，长跑没有存档点。续写到第 40 章发现第 25 章拐错了方向，想回去重走？单线工具里这意味着删掉 15 章。沉没成本会逼着你 将错就错——很多「越写越崩」就是这么来的。

把版本管理的思路搬进小说

写代码的人五十年前就遇到过一模一样的问题，他们的答案是版本控制：任何修改都不覆盖历史，想试新方向就开分支， 分支之间随时切换对比。我们把这套思路搬进了 Foreverse 的阅读器：

在任何一章、任何一个段落，你都可以开一条新分支往下写。原文纹丝不动，旧分支完整保留，每条分支有自己的 续写记录和上下文状态。世界树长什么样、从哪里分的叉、每条线走到了哪，一张图看得清清楚楚。 「重新生成」在这里不存在覆盖——它只是又一条更短的分支。

设定不该靠模型「记住」，该靠系统供给

解决上下文问题，我们借鉴了酒馆社区用世界书管理设定的经验：把人物、地点、规则做成结构化档案，按当前剧情的 相关性挑选注入，而不是把原文一锅端。打个比方，模型不需要背下整本书，它需要的是一位贴身的设定助理—— 写到谁，谁的档案就递到手边。档案怎么建、怎么挑，是我们打磨最久的部分，这里卖个关子，但效果可以直说： 同一本书、同一个模型，崩坏率的差距是肉眼可见的。

工具应该让你更敢试错

我们不认为 reroll 是创作，赌博式的生成只会让人疲惫。好的续写工具应该像好的编辑器：每一次尝试都被保留、 可对比、可回退，你因此敢于把剧情推向更冒险的方向。模型每年都在变强，但结构问题不会自己消失—— 这是工具该做的事，也是我们选择从阅读器这一层动手的原因。