AI长篇小说工具真正解决的不是“替你写”，而是让角色、世界观、章节蓝图、审稿和修稿不再散落在几十个聊天窗口里
AH-0614推荐的是 EthanYoQ/AI-Novel-Writer。原帖只用了很短一句话概括：先定题材、人设、世界观，再做大纲、角色图谱、章节蓝图，最后才生成正文。fileciteturn36file3L963-L967 截至2026-08-15，官方仓库仍在维护，采用GPL-3.0。当前README把它定位为面向长篇小说的本地优先桌面工作台，并已经形成“前提 → 角色 → 世界
AI长篇小说工具真正解决的不是“替你写”，而是让角色、世界观、章节蓝图、审稿和修稿不再散落在几十个聊天窗口里
AH-0614推荐的是 EthanYoQ/AI-Novel-Writer。原帖只用了很短一句话概括：先定题材、人设、世界观，再做大纲、角色图谱、章节蓝图，最后才生成正文。fileciteturn36file3L963-L967
截至2026-08-15，官方仓库仍在维护，采用GPL-3.0。当前README把它定位为面向长篇小说的本地优先桌面工作台，并已经形成“前提 → 角色 → 世界观 → 章节蓝图 → 草稿 → 审稿 → 修稿 → 定稿”的完整流程。它支持Windows x64和macOS Apple Silicon，项目资料保存在本地；但当用户配置OpenAI、DeepSeek、Gemini或其他云端模型时，提示词和相关上下文仍会发送到对应服务商。citeturn755177view3
这件事最值得alphahole提炼的，不是“AI写小说很厉害”。
而是：
Long-form Generation ≠ Long-form Production。
1. 长篇最难的是状态，不是单段文字
短内容可以一次生成。
长篇小说需要持续维护：
角色年龄； 关系； 伤痕； 秘密； 道具； 地理； 世界规则； 时间线； 伏笔； 章节目标； 已经兑现的承诺。
如果这些东西只存在于聊天上下文里，模型一换窗口、一压缩上下文、一重开会话，连续性就会崩。
所以真正的资产不是Prompt。
是Story State。
2. 章节蓝图比“直接写正文”更重要
长篇创作最容易失败的流程：
灵感 → 直接生成5000字 → 看着还行 → 下一章继续。
几章以后，故事开始出现：
动机漂移； 角色功能重复； 冲突没有升级； 伏笔没人记得； 章节像一串随机事件。
章节蓝图的价值是提前规定：
这一章解决什么？ 新增什么冲突？ 谁发生变化？ 埋什么信息？ 哪些内容绝对不能提前揭示？
Chapter Blueprint = Local Contract。
它让每章都有自己的任务，而不是只靠“续写”。
3. Character Bible与World Bible必须可版本化
角色不是一张静态人设卡。
真正长篇里，角色会发生变化。
因此更合理的结构是：
Base Identity； Current State； Known Facts； Hidden Facts； Relationship State； Change Log。
世界观也一样：
规则； 例外； 已揭示程度； 当前读者知道什么。
这能避免一种常见AI错误：
模型知道作者知道的全部秘密，于是让角色提前知道。
Author Knowledge ≠ Character Knowledge。
4. “本地优先”必须和“全本地”区分
当前项目资料、SQLite、角色卡、蓝图可以保存在电脑。
但如果你调用云模型，相关上下文仍会离开设备。
因此正式规则：
Local Project Storage ≠ Local Inference。
对于： 未发表小说； 商业IP； 合作剧本； 敏感设定；
作者仍需要知道：
发送了哪些上下文； 模型服务商是谁； 是否保留日志； API Key如何保存； 是否可以使用本地模型。
5. AI审稿不是文学评价的最终事实
结构化审稿很有用。
可以找：
重复； 角色名错； 设定冲突； 节奏失衡； 信息提前泄露； 章节目标缺失。
但“更感人”“更有文学性”“人物更立体”不能仅靠单模型评分决定。
所以审稿分两层：
Deterministic Continuity QA； Editorial Judgment。
AI Review ≠ Final Editorial Authority。
6. 修稿必须保留Diff
如果每次AI修稿直接覆盖正文：
作者很快不知道：
哪句被改； 为什么改； 哪个角色语气被抹平； 伏笔是不是被删了。
因此修稿工作流应该保存：
Before； After； Reason； Accepted/Rejected； Affected Canon。
这和代码Diff完全同构。
Creative Revision Needs Change History。
7. 知识库也要防“整本都塞进去”
官方当前README明确强调：长篇创作不是把整本小说塞进每次请求，而是围绕当前章节蓝图、相关角色、世界观、历史摘要和参考文风组织上下文。citeturn755177view3
这条很重要：
Context Selection > Context Volume。
上下文越多，不代表连续性越好。
旧草稿、已废设定、被修改的人设，如果一起塞入，反而会污染生成。
所以内容需要：
ACTIVE； SUPERSEDED； DRAFT； CANON。
8. 批量生成必须有暂停和失败边界
当前工具已经支持批量章节任务、暂停、取消，并且后处理失败会停止后续章节。citeturn755177view3
这比“连续生成20章”成熟。
因为创作自动化最大的风险是：
错误很便宜地被复制。
所以继续沿用：
Cheap Preview Before Expensive Batch。
一章通过，再继续。
9. 版权问题不能因为AI而消失
如果导入：
整本他人小说； 付费网文； 受版权保护的影视字幕； 某作者大量作品；
作为参考文风或知识库，仍然涉及来源与使用权。
尤其商业出版时，需要区分：
灵感参考； 事实资料； 授权文本； 受保护表达。
Tool Capability ≠ Content Rights。
10. 真正可产品化的是Story Production OS
输入：
Premise； Characters； World； Plot； Chapter Blueprint； Canon； Draft； Review； Revision； Continuity； Rights。
然后每章都能回答：
为什么写这一章？ 这章改变了什么？ 引用了哪些设定？ 有没有违反Canon？ 哪些伏笔推进了？ 哪些改动需要回写人物/世界状态？
11. 对alphahole的商业启发
它可以进一步变成：
小说创作OS； 短剧前期Story Bible； 品牌IP连续内容系统； 儿童故事系列； 游戏剧情生产。
收费点不是“每月生成多少字”。
而是：
少跑偏； 少返工； 连续性更稳定； 团队协作更清楚； IP资产可复用。
Stop Rule
如果一个AI长篇系统：
直接正文优先； 角色状态不可追踪； 旧设定不能Supersede； 审稿只给主观分； 修稿覆盖原文； 批量生成无中途Gate； 云模型数据路径不透明； 版权来源不记录；
就还不是生产系统。
AI写小说真正跨过玩具阶段，不是它能一次写一万字，而是第六十章还能知道第一章发生了什么、哪些规则已经改变、哪些秘密角色还不知道，以及为什么这一章必须这样写。