AI 写长篇，为什么要把“建议”和“正史”分开
模型可以快速生成情节和文字，但长篇创作要保持一致，就必须分开模型建议、待修改草稿和作者已经确认的故事事实。
生成一段通顺文字已经不难。真正困难的是写完几十章后，人物仍然记得自己经历过什么，世界规则没有悄悄改变，早期伏笔还能在合适的位置回收。
这不是把上下文窗口做大就能彻底解决的问题。更根本的难点，是怎样管理故事状态，以及最终由谁做决定。
模型输出不等于故事事实
在普通聊天里，模型上一轮的回答自然会成为下一轮上下文。但在小说创作中，如果每次建议都自动成为事实，一次随口补充的人物背景会进入后续章节，未经确认的时间线也会逐渐固化。
因此 NovelFlow 区分三类内容：
- 建议：模型提出、尚未被作者采纳的可能性。
- 草稿：正在编辑的叙事文本，可以反复改写。
- 正史（canon）：作者明确确认、后续推理可以依赖的事实。
这样做看起来多了一次确认，却能避免系统在作者不知情时把建议变成事实。
正史应该是可追溯的状态
正史不应该只是一大段被塞进提示词的文字。每项事实至少要记录来源、确认时间和影响对象。例如：
interface CanonFact {
id: string;
statement: string;
sourceSceneId: string;
entities: string[];
acceptedAt: string;
}当作者修改“角色 A 不会游泳”时，系统可以找到依赖这项事实的场景，而不是要求作者凭记忆搜索整部作品。版本记录也让“为什么现在是这样”可以回答。
检索比无条件塞入更重要
每次请求都带上全部设定，不仅成本高，也会让当前任务失去重点。更合适的做法，是先判断这一章涉及哪些人物、地点和事件，再取回相关正史和近期文本。
上下文应该由任务决定：
- 写对话时优先提供人物关系、语气和最近互动；
- 检查时间线时提供事件顺序与日期约束；
- 续写场景时提供直接前文和未解决目标。
系统的价值不在“记住一切”，而在需要时拿出正确的那部分。
“由人确认”不能只是一句口号
如果界面只有一个“重新生成”按钮，作者仍然很难控制系统。真正的人工参与，需要把每个决定清楚地展示出来：新增了哪些事实、和现有正史有什么冲突、接受后会影响哪些内容，并允许作者只采纳建议的一部分。
好的 AI 创作工具不会努力让作者退出流程，而会减少作者处理低价值机械工作的时间。
这也决定了产品指标。除了生成速度，还应该观察作者拒绝和修改建议的成本、一致性问题被发现的时机，以及错误进入正史后能否安全回退。
一条更稳健的生成链路
NovelFlow 当前采用的简化链路是：
- 根据写作任务检索相关正史。
- 生成候选文本与候选事实。
- 对候选事实执行冲突检查。
- 由作者编辑并明确接受。
- 保存正文版本，单独更新正史。
模型负责提供更多可能性，普通代码负责可靠地保存状态，作者负责叙事决定。这三件事不应该混在一次无法检查的调用里。
结语
AI 写作的长期价值不会只来自更像人的句子，而来自更可靠的协作关系。只要系统明确区分“模型说过什么”和“作品确定了什么”，作者就能放心利用模型的速度，而不用交出故事的所有权。