章节生产流水线与前后审核体系设计方案

状态：草案，待评审排版日期：2026-08-01 关联文档：03-engines.md、02-data-model.md、06-改造方案-同步解耦与并发加固.md

1. 问题陈述

当前章节生成缺少"章节前后衔接的审核"，典型故障：

上一章结尾写主角"在黑夜中睡着了"，下一章开头又写他"在黑夜中发呆"。

这类矛盾的本质：章与章之间的即时状态（时间、地点、伤势、在做什么、谁在场）没有结构化记录，也没有任何一道关卡负责校验。现有机制只靠"上一章结尾 900 字原文 + 滚动摘要"注入 prompt，让模型自己悟——悟错就漏，漏了也没人拦。

本方案要解决的三个问题：

章末瞬态无记录：圣经（facts）只记跨章持久事实，不管"章末那一刻人在哪、几点、什么状态"。
一致性检查无牙齿：checker.py 只在落库后跑一次，结果仅展示，不阻断、不自动改、不落库追踪。
无审核工作流：生成完成即 finalized，不存在"待审核 → 通过/驳回"的状态机；审校四维（plot/prose/pacing/character）不含连续性维度。

2. 现状诊断

现有流程（backend/app/engines/pipeline/chapter.py 的 generate_chapter()）：

取大纲 → 上下文组装 → 草稿(快模型) → 定稿(强模型)
→ 校对+审校回炉(≤3轮) → 字数守卫 → 落库(finalized)
→ 一致性检查(仅展示) → 章后抽取(写圣经) → 滚动摘要 → 文风备忘

诊断结论（调研依据见第 6 节，关键文件均有行号）：

上下文组装已经相当厚：蓝图、滚动摘要、最近 2 章结尾各 900 字、时序圣经硬约束、到期伏笔、避免重复清单——问题不在"给的不够"，而在给了但没有结构化、没有校验闭环。
章末衔接的唯一依据是结尾 900 字原文：模型要从散文里自行推断"现在几点、人在哪、睡着了没有"。推断错无任何兜底。
一致性检查是摆设：checker.py 在正文落库之后才跑（chapter.py:481-483）；圣经为空时直接跳过（checker.py:35-36）；issues 不落库，用户看完就丢；且矛盾正文照样被 extract_and_apply 抽进圣经，污染反而固化。
审校与一致性互不知晓：审校四维不含连续性，checker 的连续性问题上不了审校门。
无人工审核位：连写队列一章接一章全自动推进，没有任何"人看一眼再放行"的节点；chapters.status 无 pending_review 类状态。
无故事内时间线：facts 的有效区间是章节号，不是剧情时间（第几天、时辰），时间矛盾只能靠运气。
knowledge_states 只写不读：生成 prompt 未注入"该角色目前不知道什么"，知识隔离没闭环。

3. 开源调研结论

调研了 7 个 GitHub 项目与 4 篇论文，与本方案最相关的三个：

3.1 ainovel-cli（Go，多 Agent 长篇引擎，约 1.2k star）— 工程参考价值最高

Writer 每章固定工具顺序：novel_context → read_chapter（回读前文）→ plan_chapter → draft_chapter → check_consistency（强制在 draft 之后、commit 之前） → commit_chapter。即"先生成、后审核、再提交"三段式。
角色状态变更追加日志（state_changes.jsonl）：每次状态变化结构化记录，弧边界生成角色快照。
相关章节智能推荐：每章写作时按伏笔/角色出场/状态变化/关系四个维度反查历史章节供回读——状态被结构化后，写作时能检索到"最近一次角色状态"。
七维质量评审，每项必须引用原文举证；评审结果分流重写或打磨队列。
/diag 诊断专门检查角色消失、时间线缺口、关系数据停滞。

3.2 MuMuAINovel（FastAPI，约 2.8k star）— 上下文与状态回写的细节样板

衔接锚点：写第 N 章时直接注入第 N-1 章完整正文（P0 层），从机制上让模型亲眼看到结尾状态。
角色当前状态字段：角色卡带"当前状态/心理/处境"，并标注"第 N 章变更"。
PlotAnalyzer 章后分析：每章生成后 LLM 低温度提取钩子/伏笔/情节点/角色状态变化（before → after）/冲突，写回记忆库供下章注入——形成"生成 → 结构化分析 → 回写 → 下章注入"闭环。
伏笔三级提醒：本章必须回收 / 已超期 N 章 / 3 章内到期。

3.3 novel-master（Claude Skill，纯提示词协议）— 审核规范最详尽，可直接当需求清单

章节生产五拍：骨架 → 正文 → 润色 → 质检（先报告问题，再决定修复） → 同步（角色状态、规则变化、伏笔变化写回追踪文件）。
一致性检查输出固定三列：问题点 / 证据段落 / 修正建议；必查项 21 条，含"时间跨度与地理距离不匹配""伤势与行动能力一致"等具体条目。
每章末尾强制输出"记忆更新清单"并写回追踪文件。

3.4 反面教材与学术依据

gpt-author（2.5k star）：只有"大纲 + 逐章生成"，无任何状态管理——正是"睡着又发呆"问题的典型来源。证明只靠前置大纲必然产生此类矛盾。
ai-novel-lab：初稿 40 章后复审发现时间线混乱等 5 大类问题，连贯性仅 73/100；波次修订后到 93/100。证明事后复审 + 批量修订是必需的兜底。
Re3 / DOC（EMNLP）：draft → rerank → edit 循环；对最佳续写做事实一致性编辑而非整章重写。
ConStory-Checker（微软 2026）：一致性错误分类法 5 大类 19 子类；检测管线四阶段：定向提取矛盾易发文本段 → 两两配对判定 → 证据链（原文引用 + 定位）→ JSON 报告。关键发现：事实性和时间性错误最高发，集中在叙事中段。

3.5 可借鉴的"五层防线"（按实施成本从低到高）

衔接锚点前置注入：写新章时强制注入上一章结尾状态（最便宜，单独做就能消掉一大半矛盾）。
章末状态回写：每章提交后强制产出结构化状态更新（角色状态 before→after、时间、地点、伏笔变动），落库成可查询数据。
状态感知的上下文组装：写新章时注入"角色当前状态（标注第几章变更）+ 单章摘要 + 按状态变化反查的相关历史"。
生成后审核硬门：独立 checker 调用，报告必须引用原文举证，修复走 revise 而非整章重写，不通过不放行。
跨章兜底复审：弧/卷边界评审、离线诊断、全书波次修订。

4. 设计目标与原则

目标：把"章节间连续性"从"靠模型自觉 + 事后提示"升级为"结构化状态 + 硬门禁 + 人工审核位"。

原则：

事实层确定，语义层自主（借自 ainovel-cli）：状态回写、门禁判定、状态机流转由确定性代码执行；创作内容交给 LLM；边界判断（这算不算矛盾）交给 LLM 但必须举证。
先报告，再决定修复：审核产出结构化问题清单（问题/证据/建议），自动修复只处理明确项，模糊项交给人。
最小侵入：复用现有抽取器、滚动摘要、审校回炉框架，不推翻重写。新机制以"插入新阶段 + 新增表"为主。
可降级：所有新 LLM 调用失败时不阻塞主流程，但必须在章节上留痕（标记"未过连续性门禁"），不允许静默通过。

5. 总体流程设计

5.1 新流程总览

【写前】章前审核（Pre-flight）
  蓝图 vs 上一章章末状态 → 矛盾在动笔前拦下
        ↓
【生成】上下文组装（新增：章末交接契约注入）
  草稿 → 定稿 → 校对+审校回炉（审校新增"连续性"维度）
        ↓
【章末状态提取】End-State Extraction（新）
  结构化产出"章末交接契约"，暂存不写库
        ↓
【写后】一致性门禁（Continuity Gate，新）
  ① 契约自检：本契约 vs 上章契约（规则+LLM 双判）
  ② 正文对照：checker 升级——必须对照上章正文 + 圣经，举证原文
  ③ 门禁判定：硬矛盾 → 自动修订(revise) 回炉，封顶 N 轮；
              仍不过 → 落库但标记 quarantined，不抽圣经、不更新摘要
        ↓
【落库】快照 + 契约写库 + 章后抽取(圣经) + 单章摘要 + 滚动摘要
        ↓
【人工审核】pending_review → approved / 驳回重写
  issues 落库，可标记 已解决/已忽略
        ↓
【跨章兜底】每卷末离线诊断（时间线缺口/角色消失/伏笔停滞）

5.2 核心新机制：章末交接契约（Chapter Handoff Contract）

这是解决"睡着又发呆"的关键数据结构。每章定稿后、落库前，用 LLM 低温度提取本章节末状态：

json

{
  "chapter_no": 12,
  "in_story_time": "第三日 深夜",
  "location": "破庙内",
  "scene_continues": false,
  "characters": [
    {
      "name": "沈墨",
      "location": "破庙内",
      "physical": "左臂刀伤未愈",
      "emotional": "戒备、疲惫",
      "doing": "刚入睡",
      "knows": ["黑衣人来自听雨楼"],
      "unresolved_intent": "明日动身去渡口"
    }
  ],
  "open_threads": ["庙外脚步声未查明"],
  "time_jump_hint": "next_morning"
}

用途：

写前注入：生成第 N+1 章时，第 N 章的契约作为 P0 级上下文注入草稿 prompt（比 900 字原文更明确，且二者并存——原文供语感，契约供事实）。
门禁比对：第 N+1 章自己的契约产出后，与第 N 章契约做规则比对：
- doing=刚入睡 + time_jump_hint=none，而下章契约 doing=清醒发呆 且时间在深夜 → 矛盾。
- 上章 location=破庙，下章无时间跳跃却 location=渡口 → 矛盾。
- physical=左臂刀伤未愈，下章无治疗事件却写其挥剑激战 → 矛盾。
- 规则拿不准的边界情况，交给 LLM 仲裁（单次调用，输入两章契约 + 上章结尾原文，输出矛盾/合理 + 证据）。
时间线累积：in_story_time 形成故事内时间轴，补齐现在没有的"剧情时间"维度。

落库：新表 chapter_states（或并入 chapter_summaries），一章一条，重写章节时随版本快照。

5.3 写前审核（Pre-flight Check）

生成按钮按下后、草稿调用前，快速校验（快模型档，一次调用）：

本章蓝图 vs 上一章契约：蓝图若写"清晨渡口出发"而上章契约是"深夜刚入睡、未提天亮"，提示"蓝图与上章结尾状态矛盾，是否调整蓝图？"
本章出场角色 vs 角色当前状态：出场角色是否活着、是否在场。
到期伏笔是否被蓝图遗漏（复用现有 foreshadow_reminders 逻辑，升级为硬提示）。

产出：警告列表。默认只警告不阻断（蓝图本身可以故意安排时间跳跃），但警告随生成结果一起展示，连写队列模式下可配置为"遇硬矛盾暂停"。

5.4 写后一致性门禁（Continuity Gate）

把现在"跑完就扔"的 checker.py 升级为有牙齿的门禁：

输入升级：除圣经外，新增两个对照源——上一章契约 + 上一章结尾原文。圣经为空不再直接跳过，改走"仅对照上章"的降级路径。
输出升级：沿用 ConStory-Checker / novel-master 的报告格式——每个问题必须含 问题点 / 证据段落(原文引用) / 修正建议 / 严重程度(blocker|major|minor)，落库到新表 chapter_issues。
门禁动作（替代现在的"仅展示"）：
- blocker：自动修订——把 issues 拼成修订指令走现有 build_revision_directive 回炉（复用审校回炉通道，与其共享 review_max_revisions 上限），修订后重跑门禁。
- 回炉封顶仍有 blocker：落库但标记 status=quarantined——不做章后抽取（矛盾不进圣经）、不更新滚动摘要、连写队列在此暂停。用户处理（人工改/确认忽略/再重写）后才放行。这解决现在"矛盾正文照样抽进圣经"的污染固化问题。
- major：落库为 pending_review，issues 展示，人工决定。
- minor：落库即 pending_review，仅提示。
与审校合并：审校四维增加第五维"连续性"，checker 的 major/blocker 结果折算进该维度分数，一套门槛看全局，避免两套 LLM 判断互不知晓。

5.5 人工审核工作流

chapters.status 扩展状态机： drafting → pending_review → approved；旁路 quarantined（门禁拦截）、stale（上游重写，已有）。
approved 才计入"可连写下一章"的前置条件（可配置：严格模式必须 approve 才能连写；宽松模式 quarantined 以外即可）。
chapter_issues 支持状态流转：open → resolved / ignored，ignored 的问题在重写该章时不再重复报警（按正文指纹判断是否仍适用）。
前端 GenResultCard 已有 issues 展示区，扩展为可操作面板：逐条"采纳→自动修订 / 忽略 / 人工改完标记已解决"。

5.6 跨章兜底（离线诊断）

借 ainovel-cli 的 /diag 思路，新增"全书体检"命令/面板（手动触发或每卷末自动）：

时间线缺口：in_story_time 序列回退/跳空检测。
角色消失：主要角色超过 N 章未在契约或正文出现。
伏笔停滞：超期未回收（复用现有四态调度表）。
契约缺失：历史章节无契约数据（兼容期常见），提供"批量补提取"工具。

5.7 数据模型变更

变更	内容
新表 `chapter_states`	chapter_id、契约 JSON、正文指纹、created_at；随章节版本快照
新表 `chapter_issues`	chapter_id、来源(gate/preflight/diag/审校)、severity、问题/证据/建议、status(open/resolved/ignored)、正文指纹
`chapters.status`	增加 `pending_review`、`approved`、`quarantined`
`chapter_summaries`	增加 `chapter_summary` 单章独立摘要字段（滚动摘要保留）——顺带解决"第 N 章发生了什么"无法精准检索的问题
`facts`（可选，P2）	增加 `in_story_time` 剧情时间标注，或独立时间线表

5.8 前端变更（概要）

生成结果卡：契约摘要展示（"章末状态：深夜·破庙·刚入睡"）、issues 可操作面板。
章节列表：状态图标（待审/已通过/被拦截）。
新增"全书体检"面板：诊断报告 + 一键跳转问题章。
项目设置：门禁严格度（blocker 是否自动回炉、连写是否要求 approved）、章前审核开关。

6. 与现有代码的对接点

新机制	插入位置 / 复用对象
写前审核	`chapter.py:275-327` 上下文组装之前，新增 preflight 步骤；复用 `bible.py`、`foreshadow.py`
契约注入	`CHAPTER_DRAFT_PROMPT`（`prompts/chapter.py:61-120`）新增 `handoff_contract` 占位符；与 `recent_tail` 并存
契约提取	定稿后、落库前，新增 LLM 调用（强模型档、低温度，理由同 `extractor.py` 注释"抽错污染全书"）
一致性门禁	升级 `engines/consistency/checker.py`；落库前移到 `chapter.py:442` 快照之前
自动修订	复用 `build_revision_directive` + 审校回炉循环（`chapter.py:376-434`）
审校第五维	`review_chapter` / `judge_passed` 增加 continuity 维度，输入含门禁结果
quarantined 暂停	`generate-queue`（`chapters.py:239-301`）遇 quarantined 即停（与现有"失败即停"语义一致）
issues 面板	`GenResultCard.tsx` 扩展示区为可操作

7. 分阶段实施路线

P0 — 直通用户痛点（最小闭环）

chapter_states 契约表 + 章末契约提取 + 下章注入。
checker 升级：对照上章契约 + 结尾原文、举证格式、issues 落库。
门禁判定：blocker 自动回炉，封顶后 quarantined 并暂停连写。
审校增加连续性维度。

做完 P0，"睡着又发呆"这类矛盾：写新章时模型能明确看到上章状态（契约注入），写岔了门禁能拦（对照检查 + 回炉），拦不住也不污染圣经（quarantined）。

P1 — 审核工作流

章节状态机（pending_review/approved/quarantined）+ 前端操作面板。
issues 状态流转（resolved/ignored）+ 重写时按指纹去重。
写前审核（蓝图 vs 上章契约）。

P2 — 兜底与检索增强

单章独立摘要字段 + 全书体检诊断。
故事内时间线（契约的 in_story_time 升级为独立时间线表）。
（可选）按状态变化反查相关历史章节注入（ainovel-cli 四维推荐思路，有 embedding 之前用规则查询）。

P2 实施状态（2026-08 收尾）：

⑧ 全书体检：✅ 已做（engines/diagnosis.py + POST /diag-async，逐章跑一致性检查、问题以「诊断」来源落库，编辑部入口）。单章独立摘要字段：❌ 不做（滚动摘要已覆盖生成上下文，唯一消费方是 ⑩，做了是死代码）。
⑨ 时间线：✅ 轻量落地（engines/timeline.py，不独立建表——契约已有 in_story_time/地点/跳跃提示，零 LLM 聚合，注入预审/门禁 prompt + 看板展示 + GET /timeline）。
⑩ 反查注入：❌ 不做（圣经硬约束 + 契约 + 滚动摘要已三路注入，规则检索只会撑大 prompt 带来噪声）。
附带两项：✅ 契约一键重提（/contract-reextract-async，重提上章+本章契约并重检门禁）；✅ 老书批量补契约（/contracts/backfill-async，审核报告透出缺契约章数）。

历史数据兼容：旧章节无契约，提供"批量补提取"后台任务；契约缺失时门禁自动降级为现有行为（仅对照圣经），不阻塞老书继续写。

8. 风险与取舍

LLM 调用次数增加：每章新增契约提取 + 门禁 + 可选章前审核约 2-3 次调用。对策：契约提取与门禁用低温度小输出（JSON），成本远低于正文生成；提供项目级开关。
误报打断连写：门禁误判 blocker 会暂停队列。对策：严重程度分三级，只有 blocker 阻断；连写模式可配置宽松档；ignored 问题按指纹去重不再报警。
契约提取本身出错：低温度 + JSON 结构校验 + 与正文指纹绑定；契约错误导致门禁误报时，用户可在 issues 面板一键"契约有误，重新提取"。
状态机迁移：存量 finalized 章节映射为 approved，行为不变。

附：调研项目索引

项目	地址	主要借鉴点
ainovel-cli	github.com/voocel/ainovel-cli	三段式生成、状态变更日志、七维举证评审、离线诊断
MuMuAINovel	github.com/xiamuceer-j/MuMuAINovel	衔接锚点、角色当前状态字段、章后 PlotAnalyzer 闭环
novel-master	github.com/dashenbibi/novel-master	质检三列报告格式、21 条必查项、记忆更新清单
AI-Novel-Writer	github.com/EthanYoQ/AI-Novel-Writer	审稿报告→修稿两阶段、后处理失败停止连写
ai-novel-lab	github.com/xindoo/ai-novel-lab	全书复审 + 波次修订兜底
论文	Re3 (arXiv:2210.06774)、DOC (arXiv:2212.10077)、ConStory-Checker (arXiv:2603.05890)	draft-rerank-edit 循环、一致性错误分类法、证据链检测管线

章节生产流水线与前后审核体系设计方案 ​

1. 问题陈述 ​

2. 现状诊断 ​

3. 开源调研结论 ​

3.1 ainovel-cli（Go，多 Agent 长篇引擎，约 1.2k star）— 工程参考价值最高 ​

3.2 MuMuAINovel（FastAPI，约 2.8k star）— 上下文与状态回写的细节样板 ​

3.3 novel-master（Claude Skill，纯提示词协议）— 审核规范最详尽，可直接当需求清单 ​

3.4 反面教材与学术依据 ​

3.5 可借鉴的"五层防线"（按实施成本从低到高） ​

4. 设计目标与原则 ​

5. 总体流程设计 ​

5.1 新流程总览 ​

5.2 核心新机制：章末交接契约（Chapter Handoff Contract） ​

5.3 写前审核（Pre-flight Check） ​

5.4 写后一致性门禁（Continuity Gate） ​

5.5 人工审核工作流 ​

5.6 跨章兜底（离线诊断） ​

5.7 数据模型变更 ​

5.8 前端变更（概要） ​

6. 与现有代码的对接点 ​

7. 分阶段实施路线 ​

8. 风险与取舍 ​

附：调研项目索引 ​