让 AI 写完一本短篇：momo 的流水线
一句话脑洞进去，一本十章的短篇出来。中间每一步交给谁、为什么写手和审稿人要用两家模型。
手里的模型额度多到用不完，于是想做个实验：AI 在文学创作上到底能走多远？不追求一步到位写长篇，先从五万字以内的短篇开始。
这个实验叫 momo。
一句话开书
用法只有一行：
node src/cli.ts new "我在殡仪馆做夜班入殓师，某晚推进来的遗体，是三天后的我自己" --platform zhihu --id yiti
node src/cli.ts run yiti按平台给默认篇幅：知乎 10 章 × 2000 字，番茄 12 × 2000，起点 12 × 3000。中断了也不怕，重跑同一条命令会从断点继续。
每一章都走同一条线
章纲 → 正文 → 程序检查 → 审稿 → 修改 → 复核 → 抽取事实 → 定稿
几个刻意的设计：
- 程序检查先于审稿。 字数、套话、重复、格式这些机械问题用代码查，不浪费模型的注意力。
- 改完要复核。 没改到位、或者改出了新错，就再改一次。
- 事实单独抽出来。 每章定稿后抽出人物、伏笔、设定的变化，汇总成一份状态表，下一章写之前先读它。这是防止前后矛盾的关键。
- 全书后 30% 进入收尾。 不再记新伏笔，优先回收旧的。展开阶段每章最多埋 3 条，避免挖坑不填。
整个流程由代码驱动，只调用最基础的 /chat/completions，不依赖工具调用、JSON 模式或流式输出。越简单，换模型越方便。
四个角色，各用各的模型
| 角色 | 负责 | 为什么选它 |
|---|---|---|
| planner | 设定、大纲、章纲 | 结构能力强，慢点无所谓 |
| writer | 正文、修改 | 对比下来文笔最好 |
| reviewer | 审稿 | 必须和写手不是同一家 |
| extractor | 抽事实 | 最快，抽取准确 |
最有意思的发现是审稿：让一个模型审自己写的稿，它会太宽容。 换一家模型来审，才能挑出真问题。
每个角色都配了备选模型，遇到限流或连续失败就自动换下一个，一整晚挂着跑也不用盯。
还没解决的
- 长篇。五万字以上要处理的上下文和伏笔规模完全不同，放在第二阶段。
- 写得“对”不等于写得“好看”。程序能查出错误，但好不好看，最后还得靠人读。
下一步是多跑几本，自己当读者，挑出 AI 最容易写崩的地方。