第二个工具试用：inkos，一个会自我审稿的 AI 小说系统

上期回顾：AI都发展到这个地步了吗（1）AI Novel Generator

上一个工具 AI Novel Generator 折腾了我一整个晚上——版本号坑、粘贴 bug、对话框不弹出、文件被清空——最后靠写 Python 脚本绕过 GUI 才生成了一章。

这次换第二个：inkos（Narcooo/inkos），GitHub 9000+ star，TypeScript 写的命令行多 Agent 小说创作系统。它的卖点跟第一个完全不同——没有 GUI，纯 CLI，主打"多 Agent 协作"和"自我审稿"。

安装：npm 一行命令

inkos 是 Node.js 项目，安装方式是 npm install -g @actalk/inkos。比上一个工具的 Python 依赖干净多了，一行命令搞定。

inkos --help 列出了完整命令清单。跟上一个工具的 GUI 按钮完全不是一个风格——这里所有操作都通过命令行完成，每个命令对应一个明确的动作：book create 建书，write next 写章节，short run 一键生成短篇，audit 审计，revise 修订，export 导出。

配置：.env 文件，简单直接

inkos 用 .env 文件管理 API 配置。在项目目录下运行 inkos init，自动生成模板：

需要填的变量不多，简单介绍一下：

• INKOS_LLM_PROVIDER 指定 LLM 服务商，填 openai 表示用 OpenAI 兼容接口（DeepSeek、Moonshot 等都走这个）。

• INKOS_LLM_BASE_URL 是 API 地址，我用的 DeepSeek 就是 https://api.deepseek.com/v1。

• INKOS_LLM_API_KEY 填 API Key。

• INKOS_LLM_MODEL 填模型名，比如 deepseek-chat。

• INKOS_LLM_API_FORMAT 填 chat，表示用对话接口格式。

• INKOS_LLM_STREAM 设为 true，启用流式响应，生成体验更流畅。

• 还有一个可选项 TAVILY_API_KEY——Tavily 是一个 AI 搜索 API，配了之后可以用 inkos radar scan 扫描网文平台的热门趋势，帮你选题材。我们这次只做写作流程测试，不做市场分析，所以没配。

填好 .env 后运行 inkos doctor 做体检：

9 项检查 8 项 OK，1 项有 [!!] 提示——Global Config 没设。这个可以忽略，全局配置是给多项目共享 API Key 用的，我们已经在项目级 .env 里配好了。注意最后一行：API Connectivity: OK，明确告诉你 API 连通了。上一个工具的"测试配置"点了没有任何反馈，对比之下，这个诊断体验好太多。

两种创作模式：长篇连载 vs 短篇一键

inkos 有两种创作模式，需要先搞清楚区别。

长篇模式用 inkos book create 创建新书，然后 inkos write next 逐章推进。每次写一章都会走"起草 → 审计 → 修订"三个 Agent 的流水线。最有特色的是它的"真相文件"机制——7 个结构化文件持续追踪小说状态：

story_bible.md 是世界观设定，style_guide.md 是文风指南，current_state.md 记录世界当前状态（谁在哪、谁知道什么），particle_ledger.md 是资源账本（谁有什么道具），pending_hooks.md 追踪未闭合的伏笔。写第 8 章时，Agent 会自动读取这些文件，确保角色不会突然变性格、伏笔不会忘。这比上一个工具的 global_summary.txt 精细得多。

短篇模式用 inkos short run 一键生成完整短篇。给它一个创作方向，它自动跑完整管线：大纲创建 → 大纲审核 → 全文初稿 → 初稿审阅 → 全文修订 → 打包。不需要逐章手动触发，一口气出成品。适合一次性完稿的短篇作品。

两种模式的输出分别存在 books/（长篇）和 shorts/（短篇）目录下，结构清晰不混淆。

题材支持：15 种内置模板

inkos genre list 可以查看内置题材模板，一共 15 种：玄幻、仙侠、都市、恐怖、科幻、LitRPG、Isekai、Cozy Fantasy、Progression Fantasy 等。支持题材种类还是不少的，主流方向都有覆盖。

短篇创作：一条命令，12 章出炉

这次我选了一个科幻短篇题材——当意识上传技术普及，政府设立"人性鉴定局"区分真人和 AI，主角是首席鉴定师，发现测试标准的原始数据竟然来自妻子——她是编号 000，人类第一个意识上传体。

运行命令：

inkos short run \  --direction ”科幻短篇 意识上传技术普及后AI与人类共存 政府设人性鉴定局 主角是鉴定师 发现测试流程有致命漏洞 某个真人类实际是最初版本上传AI 所有测试标准源自ta的错误数据 主角必须判定自己的爱人非人 规则与情感的撕裂 人性定义的终极追问” \  --lang zh \  --chapters 12 \  --chars 1000 \  --no-cover \  --json

第一次跑，429 限流了。DeepSeek 的免费额度在短篇管线的密集调用下撑不住——大纲、审核、初稿、审阅、修订，每一步都是独立的 API 请求，12 章全量生成请求量很大。等了一两分钟重跑，成功了。

生成的文件结构很清晰：

shorts/判定书-编号000-v2/├── outline/│   ├── v001.md# 大纲初版│   └── v002.md# 审纲后修订版├── reviews/│   ├── outline-v001.md# 大纲审核意见│   ├── draft-v001.md# 初稿审阅意见│   └── draft-v002-warning.md# 修订失败警告├── drafts/v001/chapters/# 12章初稿├── final/chapters/# 12章终稿├── final/full.md# 终稿全文├── final/sales-package.md# 销售包装方案└── status.json# 运行状态

终稿标题是《她死于测试通过》，约 12000 字，12 章。

大纲质量：这个 Agent 有东西

大纲标题《判定书：编号000》，副标题"她通过了一切测试，因为测试就是她写的。"

主角顾衍，人性鉴定局高级鉴定师，工作七年，亲手判定三千多个"人"的去留。妻子林晚被抽中年度复检，测试通过，但特征曲线与数据库最早的原始样本完全重合——编号 000，第一代上传意识。顾衍必须在 72 小时内提交最终鉴定结论。

大纲设计了四层反转链：测试标准源自苏晚的数据、苏晚从一开始就知道一切、局长周衡不是反派而是保护者、苏晚的非人判定是她自己申请的。每一层都推翻前一层的认知。

逐章方案也很详细，每章都标注了核心事件、反转节点和章尾钩子。比如第 1 章结尾："三天后，他会发现一个不该存在的数字。"

审稿 Agent：最大的惊喜

整个体验中最让我惊讶的是审稿意见。不是大纲审核，是初稿审阅（draft-v001.md）。

这个 AI 审稿员的水平，说实话，还算专业。它列出了初稿的几个核心问题：

"后半段从'侦探故事'变成'演讲比赛'"——前四章是标准的悬疑推进，但从第 7 章开始，主角拿出证据，反派沉默，认错。没有对抗，没有反扑，没有代价。"读者要看的不是'主角拿出证据，坏人认错'，而是'主角拿出证据，坏人反扑，主角付出代价，才勉强赢'。"

它还给周衡的转变提了具体修改建议："认错需要一个具体的触发点，而不是一段演讲。比如放出 000 当年申请自愿清除时的完整录音。"

关于林晚的坦白："来得太早，削弱了悬念。她不仅知道自己可能不是原生人类，还完全不害怕、不挣扎、不愤怒，直接进入'你还会爱我吗'的情感对话。"

甚至标题和结尾的错位也指出来了："《她死于测试通过》承诺的是悲剧结局，但结尾是林晚没死，两人在公寓里煮面。这不是'死于测试通过'，这是'幸存于测试通过'。"

最后一句总结："让主角赢，但要赢得痛。"

这种自我审核能力是上一个工具完全没有的。AI Novel Generator 的流程是"生成草稿 → 定稿"，没有审计环节，写完就完了，好不好全靠你自己读。inkos 多了一双"审稿的眼睛"，而且这双眼睛看得很准。

但审稿意见没有被应用——这是最大的遗憾

发现审稿意见这么精彩，我自然想知道：修订 Agent 有没有基于审稿意见重写初稿？

答案是：尝试了，但失败了。

draft-v002-warning.md 文件里写得很清楚："Stream interrupted after 14224 chars: Error: model reached the output limit (length)"。修订 Agent 试图基于审稿意见重写全文，但输出内容太长，被 API 的单次返回长度限制截断了。系统没有用不完整的改稿覆盖初稿，而是保留了完整的初稿作为终稿。

这是合理的安全机制，但结果是：12 章终稿和初稿完全一样，逐字逐句，一个字都没改。审稿意见只是"给我们看的"，没有被实际应用。

我尝试手动触发修订，但 inkos revise 只支持长篇模式（books/），对短篇（shorts/）直接报错 "Book not found"：

又试着重跑 inkos short run，希望它能重新走一遍修订流程。但系统检测到项目状态已是"完成"，直接跳过了，返回的还是原文件。coverError 字段从 "disabled" 变成了 "already-complete"，说明它知道自己已经跑过了，不想重复劳动。

所以短篇模式的管线实际上断了一截：大纲审核 → 修订 可以闭环（大纲 v001 被审后确实生成了 v002），但初稿审阅 → 修订这一段失败了，且没有手动重试的入口。你能看到问题在哪，但改不了。

终稿质量：框架惊艳，执行打折

第 1 章的开场：

测试舱的门打开时，里面的人还在喊。

"我是真的！你们再测一次！再测一次！"

顾衍没抬头。他盯着屏幕上的数据流，光标停在"判定"按钮上方。

冰冷的开场，主角的职业麻木感扑面而来。然后切到回家和妻子吃饭，林晚随口说被抽中复检——"顾衍的筷子顿了一下。'正常流程。'他说，'走个过场。'"温馨日常和即将到来的危机形成反差，张力拉满。

但后半段确实如审稿意见所说，泄气了。顾衍发现证据 → 展示证据 → 委员会接受，整个过程太顺。妻子林晚在坦白"我可能不是原生人类"之后，就变成了等待拯救的符号，失去了角色主动性。结尾两人煮面吃，跟标题"她死于测试通过"的悲剧承诺明显对不上。

12000 字的短篇，前半段写得是真不错，后半段如果能按审稿意见改一遍——加入反派反扑、让主角付出代价、把结尾改狠——质量会上一个台阶。可惜改不了。

顺便说一下：销售包装方案

inkos 还自动生成了一份销售包装方案（sales-package.md），包含简介、卖点提炼和封面提示词。

卖点写得挺像回事：

"规则与情感的极致撕裂：当'人性'可以被测试，爱一个人还需不需要证据？"

"反派不是恶人：导师维护错误体系，只因怕自己一生的意义崩塌。"

甚至连封面画面都描述好了："竖版 3:4 封面，近未来科幻冷色调。一位穿浅蓝色毛衣的女性坐在测试舱内，电极贴片贴在太阳穴，画面下方是鉴定师的背影，手悬在红色'判定'按钮上方。"

这个功能对公众号连载来说挺实用——推文的摘要和封面文案可以直接拿来改改用。

跟第一个工具对比

总结

inkos 的体验比 AI Novel Generator 好很多。安装干净，配置清晰，诊断完善，纯 CLI 没有 GUI 的那些破事。多 Agent 流水线是真正的工作流设计，不是简单的 API 调用封装。审稿 Agent 的专业程度超出预期——它找出的每一个问题都精准到位，修改方向也具体可操作。

但最大的遗憾恰好也在这：审稿做得好，改稿却失败了。短篇模式的修订 Agent 因为 API 输出长度限制被截断，且没有手动重试的入口。你能看到问题在哪，但改不了。这种"眼睛到手不到"的断裂感，比没有审稿更让人难受。

如果用长篇模式（逐章生成），每章篇幅短，修订 Agent 应该不会触发输出长度限制。这可能是 inkos 长篇模式比短篇模式更靠谱的原因——下一次试用如果走长篇模式，可以验证这个推测。

但有个明显的空白，支持题材没有"规则怪谈"。2026 年最火的网文方向，番茄巅峰榜 TOP50 里占四成的题材，这里找不到对应项。最接近的是 horror（恐怖）和 urban（都市），但规则怪谈的核心是"逻辑解谜+爽感反杀"，跟纯恐怖或纯都市都不完全一样。

好在 inkos 提供了 inkos genre create 命令，可以自定义题材模板——定义章节类型、疲劳词、叙事节奏、审计维度等。有技术能力的用户可以自己建一个"规则怪谈"题材档案，但这又回到了那个问题：需要多少配置工作才能让工具真正适配你的需求。

下一篇我们会试第三个工具。看看 900+ star 的 AI-automatically-generates-novels 能不能带来不一样的体验。

如果你也在尝试用 AI 写小说，欢迎在评论区聊聊。坑踩得越多，前面的路才越清楚。