ainovel-cli

只需一句话，AI 写完一部小说

深夜两点，网文作者小张盯着空白的文档发呆。下一章的冲突怎么设计？女配角的动机是否自洽？已经连续卡文三天了。

就在这时，他打开终端，输入：

ainovel-cli --headless --prompt "废物流男主觉醒天赋，修炼路上遇到亦敌亦友的天才少女"

然后关掉电脑去睡觉。第二天醒来，桌面上静静躺着一份完整的 500 章小说大纲和前 20 章正文——全部由 AI 自动生成，无需值守。

这不是科幻，而是 ainovel-cli 正在做的事。

---

背景：AI 写小说的三个难题

AI 写小说不是新鲜事，但写一部连贯的、长达数百章的长篇作品，远比写一首诗或一段对话困难得多。业界普遍面临三大困境：

1. 上下文丢失：写到第 50 章时，AI 早已忘记第 3 章埋下的伏笔，导致情节前后矛盾、人物性格割裂。

2. 缺乏全局规划：没有宏观大纲的指导下，AI 容易"写到哪算哪"，中后期剧情拖沓或烂尾。

3. 风格漂移：随着篇幅增长，AI 的语言风格逐渐偏离初始设定，越写越像流水账。

voocel/ainovel-cli（及其越南语分支 kentjuno/ainovel-cli）尝试用多 Agent 协作架构从根本上解决这些问题。

---

核心架构：Coordinator 驱动的薄 Host 模式

ainovel-cli 的设计哲学是：让 LLM 做所有内容决策，代码只负责执行和存储。

系统由五层组成：

Host（薄外壳）

最外层是 Host，职责极其简单：启动进程、恢复中断进度、观察执行状态、必要时注入人工干预。它不包含任何业务逻辑代码，本质上是一个"进程管理器 + 状态恢复器"。

关键设计：Crash 安全。即使在写作过程中断电或强制终止，Host 也能从最近的 checkpoint 精确恢复，不会丢失进度。

Coordinator（LLM 长循环）

Coordinator 是整个系统的核心，它在一个 LLM 调用周期内反复运行：读取当前上下文 → 判断下一步调用哪个子代理 → 获取子代理结果 → 更新状态 → 决定是否继续。

这种"Coordinator 单次 Run 内循环"的设计避免了状态机的复杂维护——所有流程决策都交给 LLM 本身完成，代码只负责工具调用和状态持久化。

三层子代理：Architect / Writer / Editor

代理	职责	关键能力
Architect	世界观设定、章节规划	维护"卷→部→章"三层上下文，支持 500+ 章节的规划
Writer	章节正文写作	严格遵循"章节契约"，保持人物视角和风格一致
Editor	七维度评审	一致性、人物、节奏、叙事线、伏笔回收、文笔、吸引力

三者的协作模式并非流水线式的单向传递，而是由 Coordinator 按需调度——某些简单场景下 Writer 独立工作，复杂转折处三代理协同评审。

Store（持久化存储）

所有中间产物（大纲草稿、章节正文、评审意见、checkpoint）统一存储在本地文件系统。Coordinator 通过工具调用读写 Store，而非依赖内存状态。这使得系统天然支持断点续写。

---

核心技术栈

ainovel-cli 使用 Go 1.25 开发，选型思路很清晰：

• charmbracelet/bubbletea：构建 TUI（文本用户界面），提供彩色终端交互体验
• charmbracelet/bubbles：TUI 组件库（进度条、文本框等）
• voocel/agentcore：自研 Agent 核心框架，负责 Agent 调度和工具协议
• voocel/litellm：统一接口层，封装了 OpenRouter、Anthropic、OpenAI、Gemini、Deepseek、Ollama 等多家 LLM 提供商的 API

项目引入了 voocel 自研的 agentcore 和 litellm 两个内部库，说明作者在构建一个更大的 Agent 工具生态，ainovel-cli 可能是这个生态中的旗舰应用。

---

亮点功能详解

滚动规划（Rolled Planning）

传统方案是一次性生成完整大纲，然后按大纲逐章写作。问题在于：大纲写完后，市场风向、作者偏好可能早已改变，白写了大量规划。

ainovel-cli 采用滚动规划：先写出当前需要的章节，后续的"卷/部"大纲在需要时才逐步扩展。这避免了"一次性完整规划"的浪费，也减少了大纲与实际写作脱节的问题。

实时干预

在写作过程中，用户可以随时输入修改意见（例如"让男主的妹妹复活"），Coordinator 会评估影响范围（只影响相关章节还是需要全局调整），然后自主修改对应部分。这个过程不需要暂停写作进程。

七维度质量评审

Editor 代理从七个维度对每章进行评分：情节一致性、人物性格、节奏控制、叙事连贯性、伏笔回收、文笔质量、读者吸引力。不合格的章节会被 Writer 重写，直到通过评审。

AI 文风检测

内置"疲劳词"黑名单（不禁、竟然、仿佛 等）和 AI 味句式检测规则，对机械重复的表述发出警告，提升文本可读性。

---

部署方式

Docker（推荐，10 分钟搞定）

git clone https://github.com/kentjuno/ainovel-cli.git
cd ainovel-cli
mkdir config workspace
docker build -t ainovel-cli-vi .
docker run --rm -it   -v "$PWD/config:/root/.ainovel"   -v "$PWD/workspace:/workspace"   ainovel-cli-vi

源码编译（需要 Go 1.25+）

go build -o ainovel-cli ./cmd/ainovel-cli/
./ainovel-cli

Ollama 本地模型（免费）

不想花钱买 API Key？可以用 Ollama 拉取免费模型本地运行：

ollama pull gemma4:12b   # 推荐 ≥ 14B 参数模型

配置文件 config/config.json 指定 provider 为 ollama，填入本地地址即可。注意：小于 14B 的模型可能难以准确遵循复杂的 Coordinator 协议，建议使用 Qwen 或 Gemma 等 instruction-following 能力强的模型。

---

这个项目的意义

ainovel-cli 不是一个"演示 Demo"，而是一个生产可用的工具。它解决了 AI 长篇写作中最核心的问题——上下文一致性和全局规划，通过多 Agent 协作将这个难题分解为可管理的子问题。

从技术视角看，它代表了一种**"让 LLM 做决策，让代码做执行"**的 Agent 设计范式。所有业务逻辑（何时写作、何时评审、如何调整）都封装在系统提示词中，而非硬编码的 if-else 逻辑。这种设计的好处是：升级 LLM 模型就能直接提升整个系统的能力上限。

从创作视角看，它降低了长篇小说创作的门槛。专业作家可以用来快速生成初稿和世界设定，业余爱好者可以用来验证故事想法，网文平台甚至可以用它做批量内容生产的底层引擎。

---

局限与风险

1. 输出质量依赖模型能力：使用廉价模型（如 7B 以下）时，Coordinator 的调度决策质量明显下降，可能出现情节逻辑混乱。
2. 纯命令行门槛：非技术用户需要一定命令行基础，Windows 用户建议使用 Docker 方式。
3. 版权争议：自动生成的小说内容涉及版权灰色地带，各平台政策不一，使用前需了解当地法规。
4. 多语言限制：kentjuno 分支仅支持越南语界面，但核心协议来自中文原版 voocel/ainovel-cli，功能本身是语言无关的。

---

总结：ainovel-cli 是一个思路清晰、实现扎实的 AI 长篇写作工具。它用多 Agent 协作解决了 AI 写作的上下文丢失和全局规划难题，技术架构上体现了"LLM 驱动、代码服务"的设计哲学。对于有兴趣探索 AI 文学创作或 Agent 协作范式的开发者来说，这是一个值得研究的上游项目。