AI小说工厂(一)：从效果不好到七十二轮迭代

用 AI 写小说，试过现成工具总觉得”流程可以，效果不行”。这个系列记录我从零造一条长篇小说生产线的全过程：72 轮迭代、从纯 Python 单页工具进化到 Docker 多架构镜像发布、在 NAS 上夜里挂机写书。这是第一篇，先把整个项目的来龙去脉讲清楚。

起点：一个”效果不行”的判断

动手之前我先部署过两个开源方案：

• ainovel-cli（Go，TUI 界面）：多 agent 全自动生成，方法论很硬核，但 TUI 操作繁琐，而且它的完整 agent 工具调用体系复杂度高、token 成本也高；
• AI_NovelGenerator（Python，Tkinter）：雪花写作法 + 章节蓝图 + 双记忆，管线设计验证过，但界面是桌面程序时代的产物。

两个都不满意，但不满意的点很值钱：我不是需要更多功能，而是需要”产出质量”和”顺手”。把两个项目的方法论拆开吸收、扔掉它们的壳，就是本项目的起点。

前一个项目 AI_Cartoon（小说转漫剧，本博客有记录）验证过一套我自己顺手的架构：FastAPI + 线程池任务 + 文件即数据库 + 原生单页 Web UI + 多 Provider LLM 抽象。漫剧项目的流程能跑但成片效果一般——问题出在”写故事”这一环，而不是渲染那一环。所以这次的全部火力都对准文本质量。

吸收了什么：两个仓库的方法论清单

从 ainovel-cli 吸收的（无法直接复用 Go 代码，抄思想）：

• 核心哲学”事实层确定，语义层自主“——确定性引擎做编排，LLM 只做创作工序
• 三层记忆：卷/弧/章三级摘要 + 角色状态快照 + 上下文预算裁剪
• 反 AI 味判据库：三段式排比、四字成语堆砌、”不禁/一丝/一抹”、情绪贴标签、强行升华点题——每一条都是靶子
• voice.md 式写作标准：开头尽快建立冲突、情绪用身体反应、前情不复述

从 AI_NovelGenerator 吸收的（Python，直接对标实现）：

• 雪花写作法四步架构：核心种子 → 角色动力学 → 世界观 → 三幕情节，每步落盘断点续传
• 章节蓝图七字段卡：章节定位/核心作用/悬念密度/伏笔操作/认知颠覆/简述——当前章与下一章同时注入保衔接
• 双记忆：全局滚动摘要 + 角色状态树（物品/能力/关系网，定稿时增量更新）
• 一致性审查：设定+角色状态+摘要+正文 → 冲突报告（原版只打印不闭环，我改成自动修复循环）

明确不做的和要做的一样重要：不上向量数据库（chromadb 那套重依赖，先用确定性检索）、不做 TUI、不做多用户云部署、第一版不做分层大纲（后来加了）。每个”不做”都是为了把复杂度押在最短路径上。

架构：沿用一套被验证过的骨架

AI_Novels/
├── run.sh                # 一键启动(自动 venv,打印手机访问地址)
├── app/
│   ├── main.py           # 全部 REST 路由
│   ├── pipeline.py       # 生成管线:架构→蓝图→逐章→批量
│   ├── prompts.py        # 全部提示词模板(质量核心,最大单文件)
│   ├── store.py          # 文件即数据库(原子写)
│   ├── jobs.py           # 线程池任务+结构化日志+进度
│   ├── retrieval.py      # 确定性中文 bigram 检索
│   ├── rules.py          # 硬规则引擎(禁词/疲劳词/偏好)
│   ├── facts.py          # 章节事实卡+伏笔账本
│   ├── webnovel.py       # 爽点密度/黄金三章体检
│   ├── aitrace.py        # AI 痕迹检测(规则层)
│   ├── sourcelib.py      # 原著导入/拆解/书影库
│   └── providers/llm.py  # 6 家 LLM 抽象
├── frontend/             # v2.0 起的 Vue3+Vuetify 前端
└── projects/<id>/        # 数据全在这:JSON+正文,任何阶段可手改

三个贯穿始终的决策：

1. 文件即数据库。角色、蓝图、章节、记忆全是明文 JSON，进程杀了改了重启了都不丢状态，排查问题就是打开文件看
2. 任务级模型路由。架构、蓝图、正文、审查、定稿各自可以指定不同的 Provider——便宜模型干粗活（摘要），旗舰模型干细活（正文），这是成本控制的关键一环
3. mock Provider 全程可跑。零 Key 零成本走完全流程，CI 式回归测试的基础

一键流水线：创建之后只有一个按钮

用户新建项目后看到的第一个界面就是”一键开始”，它背后的编排长这样：

def one_click_start(pid: str, job, write: bool = True) -> dict:
    """创建项目后一键启动:续写导入(如需)→ 架构 → 蓝图 → 自动批量写作。
    已有产物自动跳过对应阶段;写作含一致性审查/记忆更新/滚动蓝图扩展/
    预算熔断/失败裁定。写作中向知识库添加的资料会被后续章节即时检索注入。"""
    meta = store.get_project(pid)
    if not meta:
        raise RuntimeError("项目不存在")
    mode = meta.get("mode", "original")
    stages = []
    if mode == "continue" and not meta.get("continue_done"):
        jobs.log(job, "阶段 0:导入原著正文与记忆 …", mod="source")
        continue_from_source(pid, job)
        stages.append("import")
    if mode != "continue" and not store.get_architecture(pid)["architecture"]:
        jobs.log(job, "阶段 1/3:生成小说架构 …", mod="arch")
        gen_architecture(pid, job)
        stages.append("arch")
    if not store.get_blueprint(pid):
        if mode == "continue":
            jobs.log(job, "阶段 2/3:生成续写蓝图(承接原著既成事实)…", mod="board")
            gen_continue_blueprint(pid, job)
        else:
            jobs.log(job, "阶段 2/3:生成章节蓝图 …", mod="board")
            gen_blueprint(pid, job)
        stages.append("blueprint")
    if not write:
        ...

注意模式分叉：原创走雪花架构，续写模式跳过架构直接生成”承接原著既成事实”的续写蓝图，同人走原著融合四步。同一个编排函数消化三种创作模式，靠的是每个阶段前的产物检查——有就跳过，没有就补，天然幂等。

新建项目时的模式与骨架选择：

功能全景：现在它能干什么

72 轮迭代攒下来的完整能力清单：

• 创作管线：雪花/打脸/闯关/悬念/单元剧/种田六种骨架、七字段蓝图卡（>25 章滚动窗口）、卷→弧分层大纲、逐章写作带一致性审查与有界修复、自动扩写、三重记忆（滚动摘要/角色状态/远章检索）
• 质量体系：七维编辑评审 + 失败裁定、硬规则引擎（禁词/疲劳词/偏好）、事实卡与伏笔账本、爽点密度与黄金三章体检、AI 痕迹检测（规则层 + 可选 LLM 复核）
• 外围生态：书影库（小说/电影拆解成结构化档案，豆瓣+TMDB）、同人多世界、文风系统（预设+仿写画像）、知识库（联网检索入库+按相关性注入）、EPUB 导出、书架沉浸阅读、封面三级降级生成
• 工程侧：夜间任务 + 配额协议（按套餐窗口的真实重置时间智能续跑）、一键流水线、GitHub 私有仓库、Docker 多架构镜像、NAS 部署 + Tailscale 远程访问

迭代节奏：这 72 轮是怎么分布的

回看开发日志的节奏很有意思：

• 第一天晚：从 0 到全流程可跑（10 个 Phase 一夜完成），真实 GLM-5.3 端到端验证两章，质量机制实证生效（第 2 章审查发现 2 个 major 冲突，自动修复后复审通过）
• 第二天：同人工作台、书影库、夜间挂机、滚动规划、文风统计、EPUB、封面、系统通知、全书体检……功能大爆炸，穿插着十几个修 bug 轮次
• 第三、四天：GitHub 化、Docker 化、NAS 部署、前端重构成 Vue3、移动端根治、爽文度量、反伪爽文、六骨架、傻瓜式套餐——从”能用”进化到”好用”再进化到”给家人用”

每一轮都是”用户反馈 → 定位 → 修复/实现 → E2E 验证 → 记日志”的完整闭环。日志本身就是这个项目最重要的工程实践之一：942 行的开发日志让任何一轮决策的上下文都可回溯，这个系列的博客能写起来，全靠它。

这个系列怎么读

后面八篇按”内核 → 质量 → 工程”的顺序展开：

• (二) 创作内核：蓝图卡、滚动窗口、三重记忆——AI 写 200 章不崩的架构基础
• (三) 编辑部：七维评审、硬规则、事实卡伏笔账本——AI 自己当编辑的闭环
• (四) 度量车间：爽点密度、黄金三章、AI 痕迹——把主观感受变成确定性分数
• (五) 反伪爽文：当 AI 的文学先验撞上用户要的一爽到底（系列思想浓度最高的一篇）
• (六) 事故与排查：require 报错三次反转、全站裸文本事故、夜间 175 章全失败
• (七) 多 AI 协作：对抗审查、分工修复、合并验证——人类当调度器
• (八) 前端三部曲：900 行原生 JS → 认输照抄 → Vue3+PWA
• (九) 部署与 NAS：Docker 多架构、配额夜间挂机、Mac↔NAS 工作流

每篇都有真实代码和踩坑记录。先从内核开始。