一句话看懂：一位网文作者在实测 AI 写长篇后，系统梳理了 GitHub 上 5 个开源方案，核心结论是：大模型的上下文窗口解决不了剧情失忆，真正决定长篇能否写下去的是状态锁、角色知识边界和改稿后的级联更新。
事件核心：发生了什么
X 用户 @Passenger0522 此前晒出番茄小说后台截图，称用两周时间从零搭建 AI 写作流程，在读人数达到 935 人、单日收入 10.31 元，随后针对评论区集中提出的“几十万字后剧情吃书”问题，把 GitHub 上主流开源小说项目扒了一遍，筛出 5 个代表方案：面向 Codex 的 oh-story、独立中文 Web 工作台 MuMuAINovel、走本地 YAML 资产的 Ani Book Skill、Go 语言写的多 Agent 终端工具 ainovel-cli，以及 Claude Code 插件 Webnovel Writer v6。作者给出的判断标准很直接：用同一份 5 章细纲测试三件事——第 3 章交给侍女的玉佩第 6 章会不会从主角兜里冒出来、只告诉侍女的秘密别人会不会提前知道、第 10 章回头改第 3 章系统能否揪出后文冲突。
为什么重要
这轮讨论戳破了一个常见误解：把书塞进大模型的上下文窗口，不等于剧情逻辑就自动连续。长篇小说真正的工程难点在于状态管理——世界客观真相、读者已知信息、角色主观知晓必须分层存放，否则反派密谋的内容主角下一章就“未卜先知”。目前公开信息显示，这些项目普遍采用权威 JSON 状态配合串行锁、事实源与只读投影解耦、YAML 加 SQLite 索引等思路，本质是把 AI 写作从“一次性生成”推向“可维护的状态机”，这也是开源生态相对闭源写作工具更容易被改造的地方。
对用户/开发者/创作者的影响
对网文创作者，选型可以按习惯对号入座：已经在用 Codex 的先试 oh-story，注意安装后必须新开会话跑 story-setup 检查 hooks 是否获得宿主信任；不想碰命令行的看 MuMuAINovel，但要在网页大改旧章后手动点“重新分析”，并用 Docker 时把 Chroma 向量目录挂到宿主机防丢记忆；追求稿件和数据完全私有的看 Ani Book Skill，代价是没有一键安装包、需要自己配 Python 环境。用 ainovel-cli 的多 Agent 流程较费 Token，且全自动文字容易磨平角色语气，关键剧情建议人工润色后再 sync。Claude Code 用户注意别下错版本，master 分支的 v6 才对应 Claude Code，v8 换了宿主且目前偏向 Windows。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是这些项目的状态同步能否在几十万字规模下保持稳定，而不只是通过 5 章细纲测试；二是级联更新和角色知识边界能否成为写作工具的标配能力，而非极客手工配置；三是当 AI 写作收入还停留在“一顿加蛋猪脚饭”量级时，创作者愿意为记忆管理投入多少工程成本。目前公开信息显示，社区规模仍小，长期维护和跨项目兼容性有待观察。
