AI写小说每章都要过安检?8级质量门禁详解

AI写小说每章都要过安检?8级质量门禁详解

前言

上一篇我们聊了AI写长篇为什么会在30章左右崩盘------一致性丢失、节奏失控、套路重复,本质上都是"跨章"问题。

有同学就问了:那到底怎么解决?光知道问题没用,得有方案。

这篇就来讲我的核心解决方案:质量门禁系统

你可能会想,写小说搞什么门禁?是不是太工程化了?但你想想,代码写完要过CI/CD检查,为什么小说写完不能过?道理是一样的------270章的体量,靠人眼逐字检查是不现实的,你必须让系统帮你兜底。


从"写完就发"到"写完先过安检"

大多数人的AI写作流程是这样的:

text 复制代码
prompt → AI生成 → 人工看一眼 → 发布

这个流程在写前10章时没问题。但到第30章时,你还能"看一眼"就发现主角的衣服颜色和第3章不一致吗?还能发现第7章埋的伏笔到第30章还没回收吗?还能发现连续4章的温度都是"温"吗?

不能。人眼看不出这些问题,但读者能感觉到------他们会觉得"不对劲",然后弃书。

长篇小说的质量问题,90%是跨章一致性问题。而人工检查跨章一致性,在270章的体量下,是不现实的。你需要自动化。

于是我设计了8级质量门禁。灵感来自CI/CD流水线------在软件开发中,代码提交后要过一系列自动化检查(编译、单元测试、集成测试、代码审查),任何一级不通过就阻断部署。我把同样的思路搬到了网文创作中。


8级门禁全景图

每一章从开始写到最终确认,要过8道"安检"。前2道在写作前拦截,中间4道在写作后自动检测,最后2道是收尾关卡。

text 复制代码
G1(状态加载) → G2(输入校验) → DRAFT(正文生成) → G3(大纲对齐) → G4(人设检查) → G5(节奏检查) → G6(反AI味) → G7(伏笔管理) → G8(人工确认)

借鉴CI/CD的"fail fast"原则------问题越早发现,修复成本越低。G1-G2在写作前 拦截环境问题,G3-G6在写作后 自动检测内容问题,G7-G8是收尾关卡。每一级都有明确的通过条件和退回指令。

门禁 名称 阶段 检测方式 拦截目标
G1 状态加载 写前 文件存在性检查 状态轨缺失
G2 输入校验 写前 输入文件校验 大纲/人物/素材缺失
G3 大纲对齐 写后 事件比对 偏离大纲
G4 人设一致性 写后 Soul Field规则匹配 人设崩塌
G5 节奏检查 写后 指标计算 节奏失控
G6 反AI味 写后 metrics.py自动检测 AI味超标
G7 伏笔管理 收尾 伏笔表状态更新 伏笔遗漏
G8 人工确认 收尾 作者审核 主观质量

写前门禁 G1-G2:写之前先检查"弹药"

在AI开始写任何一章之前,先确认两件事:状态轨是否完整(G1),输入文件是否齐备(G2)。如果"弹药"都不够,没必要开枪。

G1 · 状态加载检查

检查15条动态状态轨的JSON文件是否完整存在,且包含到上一章为止的最新状态。这是整个门禁系统的第一道防线------如果状态轨缺失,AI写出来的内容一定与前序章节不一致。

  • 通过条件:15条轨JSON文件全部存在且非空
  • 不通过时:阻断写作,输出缺失文件列表

来看检测逻辑:

python 复制代码
# G1: 状态加载检查
required_tracks = [
  "character_state", "foreshadow", "language_fp",
  "emotion_arc", "established_facts", "soul_field",
  "rhythm_temp", "climax_count", "hook_type",
  "chapter_summary", "props", "spatial_location",
  "info_asymmetry", "power_relation", "timeline"
]

missing = [t for t in required_tracks
           if not track_file_exists(t, chapter=current-1)]

if missing:
    return GATE_FAIL(
        action="BLOCK_WRITING",
        message=f"状态轨缺失: {missing}",
        fix=f"运行 init_tracks.py --chapter {current-1} 重新生成"
    )
return GATE_PASS()

为什么放在最前面?因为如果状态轨缺失,后面所有门禁的检查都是无意义的------没有状态数据,G3无法比对大纲,G4无法检查人设,G5无法计算节奏指标。G1是所有门禁的前提

G2 · 输入校验

检查写作所需的4项输入文件是否齐备:大纲第N章、人物档案、节奏卡第N章、素材库。这4项输入缺任何一项,AI的生成质量都会显著下降。

  • 通过条件:4项输入文件非空且内容有效
  • 不通过时:提示缺失项,附补全指引
输入 来源 缺失后果
大纲第N章 outline.md AI不知道本章该写什么核心事件
人物档案 characters.md AI不知道角色的人设和语言指纹
节奏卡第N章 pacing.md AI不知道本章的张弛/温度/爽点要求
素材库 material-prep.md AI缺乏行业知识和打脸场景参考

写后门禁 G3-G6:写完后自动"过安检"

AI生成正文后,4道自动检测门禁依次执行。这4道门禁是整个系统的核心------它们决定了你需不需要人工介入。

G3 · 大纲对齐检测

检查AI生成的正文是否与大纲第N章的核心事件一致。AI有时候会"自由发挥"------大纲说本章是"会议室打脸",AI写成了"走廊吵架"。

  • 通过条件:核心事件一致率 ≥ 80%
  • 不通过时:退回DRAFT,附偏离项+原始大纲

检测逻辑是提取大纲第N章的3-5个核心事件关键词,在正文中搜索匹配。如果匹配率低于80%,输出偏离说明:

python 复制代码
# G3: 大纲对齐
outline_events = extract_events(outline.chapter[N])
chapter_events = extract_events(generated_chapter)

match_rate = calculate_match(outline_events, chapter_events)

if match_rate < 0.8:
    return GATE_FAIL(
        action="REVISE_DRAFT",
        deviations=get_deviations(outline_events, chapter_events),
        suggestion="请按大纲核心事件重新生成,偏离项: {deviations}"
    )
return GATE_PASS()

G4 · 人设一致性检测

这是最关键的一道门禁。检查正文中是否有违反Soul Field铁律的内容------角色做了不该做的事、说了不该说的话、情绪反应不符合人设。

  • 通过条件:0条核心铁律被违反
  • 不通过时:退回DRAFT,标出违反的铁律+原文

来看Soul Field铁律检测示例:

python 复制代码
# G4: 人设一致性
soul_field = load_soul_field(character="lin_zhiwan")

violations = []
for rule in soul_field.core_rules:
    if rule.type == "absolute":
        if check_violation(generated_chapter, rule):
            violations.append({
                "rule": rule.text,
                "evidence": find_evidence(generated_chapter, rule),
                "suggestion": get_fix(rule)
            })

# 示例拦截:
# 规则: "林知晚不会在公开场合流泪"
# 证据: 第4段 "林知晚眼眶一红,泪水在众目睽睽之下滚落"
# 建议: 改为"林知晚抿了抿唇,指甲掐进掌心"

if violations:
    return GATE_FAIL(
        action="REVISE_DRAFT",
        violations=violations
    )
return GATE_PASS()

人设崩塌是读者弃书的第一原因。一旦角色做了"不像ta会做的事",读者的代入感立刻断裂。G4必须零容忍------任何一条核心铁律被违反,都必须退回重写。

G5 · 节奏检查

检查本章的节奏指标是否符合节奏卡的要求------张弛状态对不对、温度档位对不对、爽点有没有、钩子类型是否重复。

  • 通过条件:4项节奏指标全部达标
  • 不通过时:退回REVISE,附节奏修正建议
检查项 规则 检测方法
张弛状态 与节奏卡标注一致 分析本章情绪走向,判断是"张"还是"弛"
憋屈连续 ≤2章 检查前2章是否也是"张"
温度档位 与节奏卡一致,且不连续5章同档 分析情绪强度,映射到5档温度
钩子类型 存在且不连续3章同类型 检查章末100字的悬念类型

G6 · 反AI味检测

运行 metrics.py 脚本,对正文进行6项量化指标检测。这是让"去AI味"从主观判断变成客观指标的关键门禁。

  • 通过条件:6项指标全部在阈值内
  • 不通过时:退回REVISE,附超标项+替换建议
指标 阈值 超标示例
句式重复率 ≤3次连续 "她不禁...她不禁...她不禁..."
词汇多样性(TTR) ≥0.45 全章3000字只用了800个不同的词
AI高频词密度 ≤5次/千字 "缓缓""微微""淡淡"出现过多
段落长度方差 ≥80 所有段落都是150字左右(太均匀)
对话占比 30%-60% 全章80%都是对话
情绪词密度 ≤8次/千字 "愤怒""震惊""无奈"出现过多

G6是唯一一个量化检测"AI味"的门禁。其他门禁检查的是"对不对"(大纲对不对、人设对不对),G6检查的是"像不像人写的"。当6项指标全部达标时,读者基本无法分辨这是AI写的还是人写的。


收尾门禁 G7-G8:收尾关卡

前面6道门禁都通过了,还需要两道收尾关卡:伏笔管理(G7)和人工确认(G8)。

G7 · 伏笔管理

检查本章是否引入了新伏笔(需要登记)或回收了旧伏笔(需要更新状态)。伏笔管理是长篇小说最容易出问题的地方------埋了忘了回收,或者回收时和埋设时不一致。

伏笔登记表结构如下:

json 复制代码
// 伏笔登记表
{
  "id": "FB037",
  "planted_chapter": 30,
  "content": "周教授办公桌上那封未署名的信",
  "plan_recover_chapter": 45,
  "status": "planted",  // planted → recovered → closed
  "related_characters": ["zhou_professor", "lin_zhiwan"],
  "importance": "P0"  // P0=核心伏笔, P1=重要, P2=次要
}

如果P0级伏笔超过计划回收章节10章还未回收,系统自动发出预警。这是防止"烂尾"的最后一道防线。

G8 · 人工确认

前7道门禁全部是自动化检测,G8是唯一的人工关卡。作者阅读本章正文,做最终确认:通过则更新15条状态轨,进入下一章;驳回则退回DRAFT并附修改方向。

  • 通过:更新15条状态轨 → 进入下一章
  • 驳回:退回DRAFT,附驳回原因+修改方向

自动门禁能检测"对不对",但检测不了"好不好"。一段文字可能通过了所有自动检查,但读起来就是没有感觉------不够爽、不够燃、不够痛。这些主观质量只能靠人来判断。G8是不可替代的。


门禁的核心不是"拦截",是"精确退回"

这一节是我设计门禁系统时最花心思的地方,单独拎出来讲。

一个只会说"不合格"的门禁是没有用的------AI收到"不合格"这个反馈后,只能随机重写,大概率还是不合格。有用的门禁必须告诉AI"改哪里、怎么改"

每一级门禁不通过时,都会生成一个结构化的退回指令

json 复制代码
// 退回指令结构
{
  "gate": "G4",
  "action": "REVISE_DRAFT",
  "violations": [
    {
      "rule": "林知晚不会在公开场合流泪",
      "evidence": "第4段: '林知晚眼眶一红,泪水在众目睽睽之下滚落'",
      "suggestion": "改为: '林知晚抿了抿唇,指甲掐进掌心,但表情没有一丝波动'"
    }
  ],
  "priority": "P0",
  "max_retries": 3
}

退回指令包含4个关键字段:

字段 含义 为什么重要
violations 具体的违规项 告诉AI"哪里错了"
evidence 原文证据 告诉AI"哪句话有问题"
suggestion 修改建议 告诉AI"应该怎么改"
max_retries 最大重试次数 防止无限循环

借鉴CI/CD的**"fail fast, fix fast"原则。门禁不只是拦截器,更是修复指导器**。一个能告诉你"改哪里、怎么改"的门禁,比一个只会说"不合格"的门禁有价值100倍。


实战案例:前3章试写中的真实拦截记录

光说设计没用,来看真实拦截。在全局规划完成后,我进行了前3章的试写验证。8级门禁系统成功拦截了3次质量问题。

  • 3 总拦截次数
  • 2 G4人设拦截
  • 1 G5节奏拦截
  • 0 最终人设崩塌

案例1:G4拦截 --- 林知晚"公开流泪"

  1. 触发:第1章初稿,第7段 AI写道:"林知晚看着功劳簿上自己的名字被人划掉,眼眶一红,泪水在众目睽睽之下滚落。"
  2. G4检测 :违反Soul Field核心铁律 规则:"林知晚不会在公开场合流泪"(absolute级别)
  3. 退回指令: 建议改为:"林知晚看着功劳簿上自己的名字被人划掉,抿了抿唇,指甲掐进掌心。表情没有一丝波动,但攥着手机的手指发白。"
  4. 结果:AI按建议重写,G4通过。修改后的版本更符合"冷静但暗藏愤怒"的人设------没有流泪,但读者能感受到她的愤怒。

案例2:G4拦截 --- 沈婧"直接发怒"

  1. 触发:第2章初稿,第12段 AI写道:"沈婧猛地站起来,脸色铁青,'你什么意思?'"
  2. G4检测 :违反Soul Field核心铁律 规则:"沈婧永远在笑着的时候说最狠的话"(absolute级别)。沈婧不会"猛地站起来""脸色铁青"------那是普通反派的反应。
  3. 退回指令: 建议改为:"沈婧端起咖啡杯,嘴角弯了弯,'知晚,你最近是不是压力太大了?'语气温柔得体,但杯沿遮住了她眼底一闪而过的寒意。"
  4. 结果:AI按建议重写,G4通过。修改后的沈婧更有"笑面虎"的压迫感------笑着说出最狠的话,比直接发怒可怕十倍。

案例3:G5拦截 --- 连续3章温度"热"

  1. 触发:第3章初稿 节奏卡要求第3章温度为"热",但第1章和第2章也是"热"。连续3章"热"违反了"不可连续5章以上同一温度档位"的预警规则(虽然没到5章,但3章已经是预警线)。
  2. G5检测:温度单调预警 前3章温度:热 → 热 → 热。建议第3章降一档到"温",在第3章前半段安排一个过渡场景(日常/信息铺垫),后半段再升温到"热"。
  3. 退回指令: 建议在第3章开头加一个500字的日常过渡段(林知晚早晨在工位上整理文件,和同事闲聊),把温度从"热"降到"温",再在打脸场景升回"热"。形成"温→热"的章内温度曲线。
  4. 结果:AI按建议重写,G5通过。修改后的第3章有了"先抑后扬"的节奏感,打脸场景的爽感更强。

8级门禁的代价与权衡

门禁系统不是没有成本的,诚实地说说它的代价。

维度 无门禁 8级门禁 代价
单章写作时间 ~15分钟 ~30分钟 +100%
返工率 ~40%(后期更高) ~8% -80%
跨章一致性 第30章开始崩 270章不崩 质变
API调用成本 1次/章 1.3次/章(含重试) +30%
学习曲线 中(需理解门禁逻辑) 有门槛

单章时间增加100%,但返工率降低80%------总时间成本反而更低。更重要的是,没有门禁的系统在30章后会崩盘,崩盘后的修复成本是"重写"级别。门禁系统的真正价值不是"节省时间",而是**"保证不崩"**。


总结

门禁的本质不只是"自动化检查",它有三层含义:

第一层:拦截器 --- 在问题流入下一章之前拦住它。

第二层:修复指导器 --- 不只告诉你"不合格",还告诉你"改哪里、怎么改"。

第三层:质量保证体系 --- 通过8个维度的系统化检查,让每一章的质量可控制、可追溯、可量产。

核心要点提炼:

  1. 8级门禁分三个阶段:写前(G1-G2)、写后(G3-G6)、收尾(G7-G8),借鉴CI/CD的fail fast原则
  2. 门禁的核心不是拦截,是精确退回 --- 必须告诉AI"改哪里、怎么改"
  3. G4人设一致性检测是零容忍的 --- 人设崩塌是读者弃书的第一原因
  4. G6反AI味是唯一量化检测"像不像人写的"门禁 --- 把主观判断变成客观指标
  5. G8人工关卡不可替代 --- 自动检测管"对不对",人管"好不好"

在软件工程中,CI/CD流水线让代码质量从"靠程序员自觉"变成了"靠系统保证"。在AI写作中,8级门禁让章节质量从"靠作者感觉"变成了"靠系统保证"。

这就是工程化方法论的价值------把质量从"主观感觉"变成"系统保证"。

下一篇,我会拆解15条动态状态轨的数据结构和协同机制------这是G1门禁检查的对象,也是270章不矛盾的秘密。


本文是「AI写作工程化」系列第2篇。如果觉得有帮助,点个赞吧。你觉得这套门禁设计怎么样?评论区聊聊你的想法。

相关推荐
fulton1 小时前
AI写长篇小说为什么30章必崩
后端
fulton1 小时前
AI写到第30章就"失忆"?15条状态轨详解
后端
fulton1 小时前
这是核心创意卡最反直觉的地方:5项不可修改的设定,反而让大纲设计变得**更容易**而非更难。 | 维度 | 无约束 | 有5项锚点 | |---|---|
后端
Augustzero1 小时前
为什么线程不能说睡就睡?看懂等待与唤醒机制
c++·后端
云边有个稻草人1 小时前
SQL Server数据迁移不只是“搬过去”:金仓如何让复杂查询越迁越快
后端
桦说编程1 小时前
盘点并发集合里那些容易误判的行为
java·后端·性能优化
云边有个稻草人1 小时前
时序数据库如何告别手工分片?看金仓“超表”怎样简化海量数据管理
后端
Java编程爱好者1 小时前
面试官问"这段逻辑为什么这样写"——我才发现,这半年我写的代码,我自己都解释不了
后端
苍何3 小时前
偷偷分享 DeepSeek Harness 热榜挖到的 2 个实⽤插件
后端