历史 Dig · 2026 年 7 月—8 月
AI 长篇怎样不把人物和时间线写乱？
章节越多，难题就不再是模型能读多少字，而是哪条人物、时间、地点和伏笔仍然有效。读起来合理的新句子，不能悄悄变成下一章的事实。
一场戏的事实账本
四类记录分开，草稿才不能偷偷改设定。
先看事实属于哪一格，再把本场需要的编号交给草稿。新句子只能进入差异单，最后由作者决定。
- 01固定事实不可被正文静默改写
- 02当前状态人物此刻在哪里、知道什么
- 03未解冲突伏笔与未知继续保留
- 04变更记录合并或回退都留下原因
事实台账不是第二份正文：它只保留可引用事实、当前状态、未解冲突和作者批准的变化。草稿只能提交差异，不能直接改设定。
它和 Workflow 001 的关系
与当前主题的关系
它把“选哪个模型”改成“项目事实怎样在工具之外继续存在”。
展开说明
选择工具不等于保持连续性。带编号的事实台账、本章事实包与草稿差异，可以在聊天、模型或入口变化时保留作者认定的事实。这与 Workflow 001 的项目连续性问题直接相关，也为 Q03 的项目重入提供一个写作场景。
当时的记录状态
- AI 写小说
- 人物与时间线
- 标准记录
- 继续调查
- 历史 E2 · 两条作者讨论与结构化写作方法相互支持 · 未完成真实长篇试跑
当时的建议
当时的判断
正文只提交差异；设定由作者合并或回退。
展开完整判断与退回规则
把设定从聊天里拿出来，拆成可版本化的固定事实、当前状态、未解冲突和变更记录；每条用稳定编号。写一场戏前，只从台账提取本场必需事实、允许变化和作者语气参考，组成最小事实包。草稿中的新事实只能进入“待确认差异”，由作者合并到下一版台账或回退正文，不能让正文自动改写设定。
- 适合谁
- 已经有至少三章自己的稿件，开始遇到人物动机、时间、地点规则或伏笔前后矛盾，并愿意由作者亲自决定设定变化的人
- 为什么当时值得看
展开说明
越晚才发现设定漂移，返工越容易跨过多个章节。更危险的是让同一个模型既续写又宣布自己没有矛盾：它可能把刚写出的错误继续当作依据。
- 这份判断到哪里为止
展开说明
两条 Reddit 讨论是作者自述，其中一条发帖者后来说明自己也在做相关应用；它们只能作为问题与做法线索。novelWriter 是非 AI 写作软件，固定界面只能证明标签、引用和全书大纲可以被结构化呈现。长上下文论文研究的是问答和检索，不是小说质量。Git 说明版本历史机制，不证明文学质量、完稿率或销量。本站没有用这套方法完成真实长篇，也没有比较模型或招募独立作者复现。
读之前先对一下
是否适用
已有自己的连续稿件和一个明确冲突时，才值得做这次小试。
这条记录可能帮得上
- 已有至少三章自己的稿件，并能指出一处人物、时间、地点或伏笔冲突。
- 愿意把事实台账当作作者维护的来源，而不是让模型自动决定哪一版设定为真。
这些情况先不要照着做
- 还没有自己的连续稿件，只想比较哪一个模型“最会写小说”。
- 原稿、人物设定或未公开情节必须上传到未经授权的第三方插件才能继续。
- 希望系统自动裁定人物动机、作者语气或故意设置的不可靠叙述。
历史试法 · 三章一个冲突
当时的试法
先手工建立 12–20 条事实记录，再决定是否让一个模型辅助复核同一份脱敏事实包。
- 大概用时
- 35–50 分钟，只处理三章和一个冲突；到点即停
- 可能花费
- 第一轮不需要模型调用；使用现有文档与本地版本历史
- 权限边界
- 01
先做什么
展开这一步
从三章中挑一处已知矛盾，建立 12–20 条带编号的事实台账，至少区分固定事实、当前状态、未解冲突和变更记录。为矛盾所在场景提取一页最小事实包，再把草稿中新出现或被改写的事实列成差异；先由作者手动选择合并、保留为未知或回退。只有手动路线清楚后，才可把同一份脱敏事实包交给一个模型做辅助复核。
- 02
手里应该多出什么
展开这一步
一份版本化事实台账、一页本章事实包、一张草稿差异单，以及一项由作者签下的合并或回退决定。
- 03
怎样算成功
展开这一步
修订场景中的人物、时间、地点与未解冲突都能指回编号；每条新事实都有作者决定和变更记录。这里只证明这个冲突被处理，不证明长篇质量或后续章节不会再漂移。
- 04
遇到什么就停
展开这一步
找不到权威版本；事实包仍接近整章或整本书；模型开始吞掉作者语气或替作者解释动机；维护台账比本章写作更久；或继续需要上传未授权原稿。
- 05
怎么恢复原状
展开这一步
恢复上一版正文和事实台账，把冲突保留为未解项，并记录为何未合并；撤销新插件或云端索引权限。
BITSHOVEL R2 说明图 · 作者控制的连续性闸门
方法与界面
把固定事实、本章需要的信息和草稿新事实分开。
展开方法边界
第一张图使用固定虚构故事说明事实台账、场景包、差异和作者决定。后两张是 novelWriter 固定版本的项目方 Sample Project，只证明结构化引用与全书大纲可以呈现，不是 AI 运行或本站实测。
这个项目方示例把人物、地点和 POV 变成场景引用。它证明一种信息结构可见，不证明 AI 会自动遵守引用或发现冲突。
图片来源与说明
novelWriter 固定提交 4160785 的完整文档截图，Veronica Berglyd Olsen 与贡献者；应用 GPL-3.0-or-later，可见 Material Symbols 图标由 Google Inc 以 Apache-2.0 提供。BitShovel 无裁切、无改字转为 WebP。画面是上游 Sample Project，不是本站稿件或运行结果；novelWriter 未参与或背书本站。
打开来源页面 ↗查看使用与署名规范 ↗
全书大纲把场景顺序、人物、地点与摘要并列给人复核。它不是 AI 记忆、自动连续性检查、完稿或文学质量证据。
图片来源与说明
novelWriter 固定提交 4160785 的完整文档截图，Veronica Berglyd Olsen 与贡献者；应用 GPL-3.0-or-later，可见 Material Symbols 图标由 Google Inc 以 Apache-2.0 提供。BitShovel 无裁切、无改字转为 WebP。画面是上游 Sample Project，不是本站稿件或运行结果；novelWriter 未参与或背书本站。
打开来源页面 ↗查看使用与署名规范 ↗依据和来源
依据和来源
截至 2026-08-16，作者讨论、结构化写作软件、长上下文研究和版本方法支持问题与方法的不同部分；它们不证明 AI 能写好长篇。
展开证据边界
历史 E2 保留为当时标签。R2 加入当前 novelWriter 官方文档和长上下文研究，把“作者遇到漂移”“结构化引用可实现”“模型会不会写好长篇”分成三件事；仍没有本站完稿、读者反馈或独立作者结果。
- 01作者社区信号 · 本轮复核
一位长篇连载作者把人物、时间和情节漂移描述为持续困难
- 02带商业关联的社区信号 · 本轮复核
另一条讨论列出故事圣经、章节摘要和人工追踪，同时发帖者披露自己也在做相关应用
- 03当前项目方文档 · 本轮复核
novelWriter：标签与引用进入项目索引，并可在全书大纲中并列显示
- 04长上下文研究 · 本轮复核
Lost in the Middle：相关信息在长上下文中的位置会显著影响模型使用效果
- 05版本方法参考 · 本轮复核
GitHub：版本历史可以记录、比较并恢复文件变化
修订记录
修订记录
R2 不再让一份不断变长的故事圣经同时承担事实源、上下文和修订决定。
展开 2 次修订
- 第 1 次
把 AI 续写改成一次只处理一章，并由作者亲自维护人物、世界规则、时间线和未解冲突。
- 第 2 次
把一份不断变长的故事圣经拆成带编号的事实台账、本章最小事实包和草稿差异；正文不能直接改设定，所有变化由作者合并或回退。
- 更正前的说法
- 把人物、世界规则、时间线和未解冲突放在一份版本化故事圣经里；每次只给一章所需事实，生成后由作者更新事实源。
- 更正后的判断
- 把固定事实、当前状态、未解冲突与变更记录分开并编号；本章只拿最小事实包。新事实先进入草稿差异，由作者合并到下一版台账或回退正文，不能由正文静默改设定。
这条记录留下什么
这条记录留下什么
连续性来自作者维护的事实源，不来自更长的聊天记录。
如果一场戏修完后仍无法指出哪条事实被合并、保留未知或回退，这次流程就还没有形成可恢复的项目记忆。
回到 Dig 索引