我用状态机管了一个50 章的长篇项目 AI只是其中一环

写一本 50 章的网文，最难的不是"写不出来"，是写到第 30 章的时候忘了第 10 章写过什么。

主角的修为在第 10 章还是炼气中期，第 35 章就到了筑基，合理。但第 18 章埋的一个伏笔，本来准备第 25 章回收——结果第 25 章写完发现根本没埋下去，因为第 18 章改过一次大纲，伏笔被覆盖了。

这种事发生三次之后，我决定不再相信自己的脑子。

项目概览

50 章番茄修仙小说，约 7 万字，三周写完。工具链：Git + Python + Claude Code + 纯文件系统。没有数据库，没有后端服务。

目录结构：

 复制代码project/
├── 正文/               # 50 个 .md 文件，每章一个
├── 大纲/                # 总纲、节拍表、时间线、详细大纲
├── 设定集/               # 世界观、力量体系、主角卡、反派设计
├── 审查报告/             # 每章的 AI 审查结果存档
├── .webnovel/           # 状态机 + 知识图谱 + 摘要
└── .story-system/       # 合约树（调性、禁忌、规则）

写作流程是一条流水线，每章走固定工序：预检 → 起草 → 审查 → 修改 → 提交 → Git tag。

下面拆核心设计。

状态机：不让跳步

每章写之前跑一次预检：

 复制代码preflight checks:
  - 项目根合法?
  - 上章审查通过?(blocking_count=0?)
  - 占位符残留?(没有[待...]或{占位})
  - 合同树未过期?

任何一项不过，流程阻断。不让你写。

这听起来很烦——灵感来了想立刻写，但预检没跑完不准动笔。实际上它挡掉的问题比它制造的多：有一次预检发现上章的审查报告被误删了，如果没跑预检就直接写新章，那章的剧情就会建立在没有审查确认的状态上——后面改起来更麻烦。

状态机的状态流转：

 复制代码draft → reviewed(pass/fail) → polished → committed → tagged
                      ↖ blocking: fix & re-review

每章只能前进，不能回退。写坏了就修，不能跳到下一章假装没发生。

合约树：后写的章不能推翻前面的设定

这是项目的核心设计。三层结构：

 复制代码MASTER_SETTING.json（全局不可变）
  └── volume_NNN.json（卷级节奏、核心冲突）
       └── chapter_NNN.json（本章硬约束、时间锚点、禁区）

每章写之前刷新一次合约树。刷新时会检查：本章的设定是否与 MASTER_SETTING 冲突？时间线是否单调递增？主角的境界是否跳级？

设定集（角色卡、世界观、力量体系）是合约树的支撑数据。角色卡上写着：主角林渊，"冷静布局者，不会因为挑衅拍桌子"。

第 48 章有一场戏：林渊发现关键角色失踪，前世记忆闪回触发。初稿写了他"一掌拍在桌上冲出门去"，合约检查直接 blocking，因为行为与角色卡冲突。改成"手指在袖中不自觉地收紧，指节卡在弯曲的位置"——通过了。

合约树不阻止你写戏剧冲突，但它阻止你用违反设定的方式写。

审查引擎：比你更清楚你犯了什么错

每章写完后过审查。审查不是"写得好看吗"这种主观判断——是结构化的问题分类：

 复制代码issues[]:
  - severity: high | medium | low
  - category: ai_flavor | continuity | character | timeline | logic
  - evidence: 原文引用
  - fix_hint: 修改建议
  - blocking: true | false

blocking 的问题不修复不能进下一道工序。

几个真实案例：

案例一：替读者做判断

原文：

审查结果：medium，展示后紧跟解释。
修改：删掉"这是他在思考时的一个习惯动作"。

改后：

字数减半，信息密度反而更高。

案例二：句式疲劳

第 49 章灭门战，战斗场面密集。审查发现"不是X，是Y"句型在全章出现约 15 次。

单看都没问题。连续 15 次，阅读节奏死了。

审查引擎能发现这种问题，是因为它统计的是全文级的句式频率，而不是单句质量。人写的时候不会注意到上一段用过同样的结构——但机器会。

案例三：跨章的状态线索

主角在第 34 章右手手指开始僵化——这是阳寿消耗的物理代价。第 47 章老掌门交令牌，审查验证：林渊接令牌时有没有写"指节卡了一下"？

如果没写，flagged。因为角色卡的状态记录里明确写着"第 34-35 章手指僵硬感加剧，这是持续的状态线索，不能断"。审查引擎每次都会检查当前章节是否覆盖了活跃状态线索。

这是单体项目，没有团队协作的问题。但 50 章的长度，人的记忆撑不住这种粒度的连续性审查。引擎可以。

AI 味的可量化定义

写了 50 章，被审查引擎报了无数 issue 之后，我对"AI 味"有了一个可操作的定义：

AI 味 = 展示 + 解释 + 升华的三段式结构。

AI 写作的典型产出是：展示一个画面 → 紧接着解释这个画面的含义 → 再紧接着总结这个含义的重要性。

而好的写作只需要第一段。让读者自己完成后面两步。

第 46 章初审时，"AI 味"维度的评分是 67/100。第 47 章升到 92/100。不是我的写作能力在一章之间进步了 25 分——是第 47 章写的是老掌门交权和密谈，全是动作和对话，没有给解释留空间。

所以去掉 AI 味不是换词汇（把"缓缓"改成"慢慢"只是治标），是砍掉解释性叙述的信心。

审查引擎里专门有一条规则叫"展示后紧跟解释"，专抓这个模式。它的触发条件是：在一个动作/画面描述之后，紧接着出现"不是……是……""这意味着……""因为……"这类结构。

这套管线能复用吗

项目配置全部开源：

• .story-system/: 合约树的 schema 和实例
• .webnovel/: 状态机、知识图谱、摘要
• 大纲/: 总纲、节拍表、时间线、详细大纲的完整模板
• CLAUDE.md: 操作手册，所有流程和指令

纯文件系统 + Python 脚本，无外部依赖。clone 下来之后装一个 Claude Code 就能跑。Issue 和 PR 都开着。

适用场景：

• 长篇幅内容（50 章+），需要保持设定一致性
• 多人协作写同一世界观，需要统一的约束层
• 想用 AI 辅助但不让 AI 替你做决定

不适用：

• 写诗、散文——规则越强越压抑
• 追求极度个性化语言风格——审查系统会砍风格化的冗余
• 不想看命令行

项目仓库：github.com/R2h1/novel

读完 CLAUDE.md 就能上手。有问题开 issue。