我把一个 AI 小说工具拆到测试层,最后只敢让它先写十章

一边是已经写过的故事，一边是还没发生的章节，中间那台机器负责把线接住。

看到「支持 500 章以上」时，我先怀疑了一下。

五百章很好写进 README，人物却很难活过五百章。很多 AI 小说到了几十章以后，主角像换了个人，配角说没就没，世界规则也开始看心情执行。模型每天都在写新内容，小说却一点点失去自己的过去。

所以源码下载到 D:\project 后，我没有急着生成故事。我先跑项目测试，接着翻存储结构、章节工具和几组角色提示词。我想知道它把哪些东西写进文件，又凭什么判断下一步该干什么。

测试没有全绿。流程、存储、章节工具链和 Host 模块都过了，Agent 层卡在一项契约测试上。底层依赖截断了工具报错，仓库期待的完整诊断信息没有传回来。

一个小故障，谈不上致命。它至少提醒我，眼前是个仍在施工的项目。后来再看那句「500 章」，心态就平静多了。

ainovel-cli 用 Go 编写，运行在命令行里。用户选择模型服务、填入 API Key，再给一句创作要求，它便开始规划和写作。

外表有点像自动写书工具，内部更接近一套小说生产系统。

它会把故事前提、人物资料、世界规则、章节正文、伏笔、关系变化、编辑意见、费用和运行状态写进本地文件。程序停了，可以接着跑；模型换了，上一章发生过什么仍然留在硬盘里。

普通聊天常把记忆寄托在一个越来越长的窗口中。窗口没有消失，重要信息也可能被几万字正文盖住。ainovel-cli 走的是另一条路：先把事实留下，再根据眼前的任务取回一小部分。

这件事听上去朴素，做长篇时却很重要。小说写到后面，作者经常要查的就是几件事：谁知道了秘密，谁还在撒谎，哪条规则已经付出过代价。

项目里最显眼的角色是 Architect、Writer 和 Editor。

Architect 管故事前提、人物档案、世界规则以及卷和故事弧的安排。Writer 一次只接当前章节，动笔前要读上下文，写完还得检查和提交。Editor 回过头看人物、节奏、连贯性、伏笔、钩子和文字质量。

Arbiter 平时不出现。碰上程序无法靠状态表决定的岔路，它才做一次语义判断。比如一条临时要求会影响哪些章节，连续失败后应该暂停还是重试。

— Engine 负责调度，几个创作角色只处理各自手里的工作。

还有一个不写小说的 Engine。它读取文件里的状态，检查当前章是否提交、弧末评审是否完成、返工队列是否清空，然后把任务交给对应角色。程序查得到的答案，就不麻烦模型临场发挥。

这里有个细节我挺喜欢。Writer 不能在聊天里贴出一章正文，然后宣布工作完成。正文必须经过工具保存；一致性检查没做，它也过不了关。

写作因此慢了一点，过程却留下了痕迹。

长篇工具很容易走向一个诱人的方案：第一天生成几百个章名，以为这就叫规划。

ainovel-cli 没有这么干。它先保存故事终点、长期线索和大致规模，再搭出前两卷的骨架。眼下要写的第一个故事弧会展开得很细，后面的内容先留着。

等这一弧写完，Editor 总结人物状态和已经发生的变化，Architect 再规划下一弧。到了卷末，系统再做一次范围更大的回顾。

我读到这里才明白，它声称能写很长，依靠的并不是一份庞大到没人愿意检查的预制大纲。计划会随着正文往前滚。已经写下来的情节拥有更高优先级，后续安排得适应它。

每一章也有固定顺序。Writer 先加载小说状态，回读最近章节和相关旧章节，列清楚这一章会改变什么，随后写草稿、查一致性、提交。人物关系、时间线和伏笔账本也在提交时更新。

这比直接让模型「续写下一章」麻烦不少。可长篇的问题往往就藏在那些被省掉的步骤里。

项目为近处、中段和远处保存了不同粒度的摘要。刚写过的章节有章摘要，一个阶段结束后有故事弧摘要，走完一卷再留下卷摘要。人物快照、关系状态、事件时间线和伏笔另外记账。

— 系统先压缩旧故事，再沿着角色、状态、关系和伏笔找回有关章节。

准备写新章时，系统会查当前涉及哪些角色、关系和伏笔，再把相关章节推荐给 Writer。最近几章负责找回语气，远处的原文只有在确实相关时才重新读取。

上下文过长也有一套处理顺序。旧工具结果先清掉，特别长的内容再裁剪，然后尽量用本地结构化记忆替换旧对话。实在压不下去，才让模型生成摘要。

我不认为这能彻底解决长篇失忆。摘要会漏，人物状态也可能写错，错误一旦进入账本，后面的章节还会认真继承它。好处在于问题有地方可查。作者能打开文件改掉那条错误状态，总比在几十万字聊天记录里猜模型忘了什么容易。

不装工具也能借用这套办法。我自己会保留四份东西：故事大方向、人物当前状态、每章发生的有效变化、还没有兑现的伏笔。写完一章就补几行。几行够了，剧情复述得太完整，下一次照样找不到重点。

项目 README 提到 500 章以上的连续创作，仓库文档还记录过一次 235 章、127 万字的长跑。这组数据来自旧 Coordinator 架构。2026 年 7 月，项目切换到 Engine 与 Arbiter；新架构同等规模的首跑数据仍未补上。

公开 Issue 里也能看到使用者遇到的麻烦。有些模型或中转服务生成不了稳定的工具参数，commit_chapter 会连续失败；同时打开多个 TUI，资源占用也可能上去。

项目更新很快。v0.7.5 在 2026 年 8 月 2 日发布，修过 Windows 通知、同一本书的多进程访问冲突和长篇状态写入效率。更新频繁意味着问题有人处理，也意味着今天的使用经验未必适用于下个月。

许可证还有一处需要留神。README 底部写着 MIT，仓库里的 LICENSE 文件是 Apache 2.0。个人试用不太受影响，二次开发和分发时就不能含糊了。我会先按正式许可证文件处理，同时向作者问清楚。

至于 Editor，它的评审结果只有接受、打磨、重写三档。轻微瑕疵可以继续，阅读明显卡顿时定点修，逻辑和设定出了硬伤才整章返工。

这个标准比「每章都打磨到完美」现实。模型可以一晚上生成很多字，作者的审稿速度并不会跟着翻倍。

ainovel-cli 没有锁死模型服务。OpenRouter、Anthropic、Gemini、OpenAI、DeepSeek、Qwen、GLM、Grok 和 Ollama 等接口都能接入，几个角色也可以分别用不同模型。

我按 100 章做了一次粗算。每章约 3000 个汉字，成书大约 30 万字。规划、正文、编辑、摘要和读取设定合计使用 400 万至 1000 万输入 token、60 万至 100 万输出 token，先不考虑大规模重写。

图里给了两个预算区间。整本都用 Gemini 2.5 Flash，预留 4 至 8 美元；换成 Claude Sonnet 4，我会按 30 至 70 美元准备。两组数都给失败重试、思考 token 和少量返工留了余量。

公开单价的核对链接放在文末。实际开销还会被章节长度、上下文读取量和返工次数拉动，跑到一半换模型也会影响结果。项目本身能记录每次调用，预算不够时可以停。

API 费用并没有吓到我。审稿时间更难办。每章只检查二十分钟，100 章已经超过三十三小时。碰上人物动机不成立，或者中段需要重排，时间还会继续增加。

ainovel-cli 适合两类人。一类正在写长篇，愿意自己检查人物和事实，只想把记忆、规划、返工和成本整理好；另一类对多 Agent 长周期协作感兴趣，想看一个任务怎样跨越多次模型调用继续运行。

把成书质量全部交给自动流程，我目前不敢。程序能检查状态文件，读不出作者究竟有没有生活经验；Editor 能挑出设定冲突，也未必知道一句话为什么让人难受。

正式投稿还要另外处理合规问题。《人工智能生成合成内容标识办法》从 2025 年 9 月 1 日起施行，发布生成合成内容时需要主动声明，并使用平台提供的标识功能。小说平台的合同、原创保证和 AI 使用规则，也得在投稿当天重新查看。

签约同样别先算美账。番茄小说公开福利页中，普通独家作品按合同取得分成；千字 15 至 3000 元的保底或买断面向业内高人气或有突出历史成绩的作者。新人签约后能拿多少，得看作品和合同，页面上的最高数字不能直接放进收入预期。

这篇文章能确认的内容到这里。新架构还没有同等规模的长跑记录，我手里的验证也只到模块测试。让我现在替它担保五百章，证据不够。

真要试，我会找一个不急着发表的故事，保持逐章验收。跑多少章先不定，写完十章再决定是否继续。

资料来源

•voocel/ainovel-cli 项目仓库

•ainovel-cli Releases

•ainovel-cli Issues

•Gemini 2.5 Flash 价格

•Claude Sonnet 4 价格

•《人工智能生成合成内容标识办法》

•番茄小说网作家福利

— 资料与价格核对日期：2026 年 8 月 10 日。运行和投稿前，请重新查看软件版本、模型价格与平台规则。