起因:AI 写长篇,平台从哪来
我在做 AI 长篇小说生产。后端不缺:一个自建的 OpenAI-compatible 网关,加阿里云百炼的 Qwen 系,纯文本链路。缺的是上层——一个能管"大纲→分章→章节生成→记忆→修订→导出"的写作工作台。
GitHub 上这类项目 2026 年冒出来一大批。但我和大多数人的处境有个关键差别:我已经有一条在产的私有写作流水线,几部长篇在跑。所以我的调研问题不是"选哪个",而是"换不换底座"。这两个问题的答案完全不同——后面会看到。
我花了两天做了一次源码级尽调,方法和我上次扒漫剧平台那次一样:57 个候选、11 个浅克隆深读、6 轮对抗核验(专门派 agent 读源码找反例,设法推翻深读结论)。结论先放这儿:
- 给读者的开源底座建议:Fork nigh/show-me-the-story(MIT),第二选择 novelclaw(MIT);
- 给我自己的答案:不换底座,继续演进在产流水线,从 4 个开源项目抄设计;
- Star 最多的 webnovel-writer(6539★)一致性机制全场满分,但 GPL-3.0,只能当设计教科书。
格局:57 个候选,真正能写长篇的就五个流派
57 个仓库扫完,分五类:全链路长篇平台(webnovel-writer、show-me-the-story、novelclaw、ai_novelgenerator、goink)、轻量 CLI 引擎、Claude Code 技能套件、记忆框架、以及一大堆玩具和停更项目。
真正跑通"大纲→章节→记忆→修订"闭环的只有五家,架构分三派:
- 阶段流水线派:webnovel-writer 每章走 prepare→draft→review→polish→commit 五个真实阶段,show-me-the-story 四层管线带独立的事实核查步骤。阶段之间落盘,崩了从章节续跑。
- Agent 自主派:goink 用 ReAct 循环加 31 个工具,awesome-novel-agent 拆 9 个专职 agent。灵活,但章节重跑成本高。
- 模板驱动派:ai_novel、ainovel-cli。便宜、确定,上限低——ai_novel 只有 3 章上下文窗口,写长篇必塌。
我的判断和漫剧调研同构:长篇连载是长流程、按章计费、必须断点续跑的批处理,阶段流水线优于自主 agent 自由发挥。你不会希望写到第 280 章崩了之后,agent 重新思考一遍人生。
发现一:一致性是长篇的生死线,各家差距极大
300 万字写下来,角色名写错、伏笔忘了收、人设漂移,读者一眼就看出来。各家方案:
- webnovel-writer:章节提交时原子更新 state/索引/摘要/记忆/向量五份派生文件,一致性检查器卡关——深读给了满分 10/10(未核验,降一档信);
- ai_novelgenerator:角色状态每章更新循环 + consistency_checker 门禁,三层记忆(近章全文/滚动摘要/Chroma 向量检索)是标准答案级的架构;
- show-me-the-story:机制最巧——伏笔状态机(planted→progressing→resolved,逾期未回收会告警)+ 成稿事实核查;
- novelclaw:18 个记忆库 + 事实卡,记忆粒度最细。
上下文管理也收敛到同一答案:近期章节全文 + 每 5 章滚动摘要压缩 + 长期 RAG 向量检索。先做摘要、按需上向量,是最省钱的起步路线。
发现二:文本层的 Provider 是真的可插拔——和漫剧调研完全相反
上次扒漫剧平台,所有"可插拔 Provider"的宣称都被我在源码里证伪了,图片视频层换谁都要写代码。这次完全不同:文本 LLM 有 OpenAI-compatible 事实标准,配置级接入是真的。
show-me-the-story、novelclaw、ai_novel、ainovel-cli 都是 base_url/api_key/model 三件套,接自建网关或百炼的 compatible-mode 都是改配置的事,不用写 adapter。小动作还是有一点——默认模型名硬编码、上下文长度假设——但那是十分钟的活,不是四周的活。
发现三:License 又赢了,这次倒下的是 6000 星的工程标杆
对抗核验环节(每个项目派两个"推翻者",任务是读源码找反例)再次证明它是最值钱的设计。修正记录里最有分量的几条:
- ai_novel(kele-tao):README 自称 MIT,实际是 Apache-2.0;代码注释里写着"仅供学习和个人创作";“完整工作台"是夸大,实为半成品;
- webnovel-writer(6539★):GPL-3.0。自用不发行没事,想产品化、闭源分发就撞墙;
- awesome-novel-agent(613★):GPL-3.0 外加"商用联系作者”;
- ai_novelgenerator(5905★):AGPL-3.0,GUI 最完善、一致性机制最强,但导出能力 3/10, License 又是雷;
- goink:AGPL-3.0 + EULA 双层约束。
算下来,License 干净(MIT/Apache 无附加条款)、架构又完整的,只剩 show-me-the-story 和 novelclaw 两个 MIT 选手——都是几百星的小项目。这和漫剧调研的结局一模一样:高星项目的 License 成片倒下,最后能用的都是小而有诚意的。
发现四:没有一家能开箱导出"章节→场次→对白"
我做小说的下游是漫剧生产线,需要小说产出能转成结构化的场次/对白 JSON。盘点结果:零开箱即用。novelclaw 有章节 JSON 导出端点但没场次粒度;show-me-the-story 的正文是 Blocks 数组(段落/对白/场景切换三种块),扩展一个块类型就能出场次 JSON——这也算最接近的;其余基本没有。
这段对接永远要自己写。对我这种已有下游产线的人,这是"不换底座"的决定性一票。
最终选择
**给想从零起步的读者:Fork show-me-the-story。**MIT 零风险、Go 单二进制 + Svelte WebUI、真实四层管线、伏笔状态机、滚动摘要、事实核查、OpenAI-compatible、progress.json 断点续跑,还有单章重写端点。深读评估的改造量约 30%,主要是把 Blocks 扩展出场次/对白结构、加番茄/起点题材模板。如果你更看重记忆体系和 Web 面板,第二选择是 novelclaw。
**给我自己:不换底座。**决策链很短——调研问题不是"哪个最好",而是"换底座值不值"。57 个候选里唯一经过真实生产验证的是我自己在跑的那条流水线;对抗核验给它找出 4 个真缺口(一致性注入偏弱、批量默认单章、导出没组件化、仓库没 LICENSE),但全是增量能修的,不是架构腐烂。拿几部在跑的长篇去赌一个新底座的回归风险,换不来任何我缺的东西——我缺的设计(伏笔状态机、章节原子提交、三层记忆、钩子库)全都可以从开源项目抄过来,甚至大部分是从 MIT 项目直接抄码。
**工程分最高的 webnovel-writer 为什么不能当底座?**三个理由:GPL-3.0、没经过对抗核验(那个一致性满分是深读 agent 的自述)、零生产验证。它最值钱的"章节原子提交"设计已经进了我的演进清单——用它的思想,不背它的 License。这跟漫剧调研里 dramaclaw 的剧本完全同构:工程分不等于底座资格。
一个诚实的免责声明:show-me-the-story、novelclaw、webnovel-writer 的深读结论没经过对抗核验(核验名额给了总分前三),真 Fork 之前值得再补一轮。另外 5629★ 的 MIT 项目 oh-story-claudecode 我这次没来得及深读,形态是 Claude Code 技能套件,值得盯一眼。
三条方法论教训
- “生产验证"是权重最高的维度,而开源写作项目全是 demo 级。README 里的"已完成百万字小说"要当广告看,除非你能看到连载链接。
- 对抗核验专治深读的彩虹屁。让 agent 夸项目,它能找出二十个优点;让另一个 agent 设法推翻,才能挖出"自称 MIT 实为 Apache"“仅供学习和个人创作"这种藏在注释里的生死细节。
- GPL/AGPL 项目的正确用法是抄设计不抄码。个人创作产出物不受 GPL 感染(输出不是衍生作品),但把 GPL 代码并进私有仓库就是违规。三层记忆抄 ai_novelgenerator 的架构、章节提交抄 webnovel-writer 的思想,一分钱法律风险没有。
完整报告(15 维度评分、逐项目源码证据、12 阶段演进计划、交接 JSON schema)存在我的私库里,这篇是公开浓缩版。如果你也在选 AI 长篇写作的开源底座,希望这篇帮你省下两天。