novel-editing-patterns

name	novel-editing-patterns
description	网文章节修复与质量提升模式——爽点追回、弧线植入、节奏调整、字数补全
category	novel

网文编辑模式

来源：实战项目验证过的可复用模式。以下方法论不绑定特定书籍，案例部分标注为示例。

固定篇幅快节奏章节（优先规则）

当章节硬性要求约 2200 字，同时出现环境补字、动作碎片、重复确认、静态等待或爽点稀释时，必须先加载 references/2200-effective-content-standard.md。

核心纠偏： 不能以缩短章节解决节奏问题。应先保证剧情容量，再让 2200 字由冲突回合、人物决策、反方应对、结果兑现和反馈构成。该参考中的字数口径与内容密度双门槛，覆盖本技能后文所有宽松字数建议。

一、爽点沙漠诊断与追回

诊断

逐章检查 5 项（钱落地/震惊反应/打脸/收入对比/系统神秘化），零命中 = 荒漠章。连续 ≥3 章零爽点 = 沙漠段。

章节若硬性要求约 2200 字，还要检查内容密度：每 500 字是否发生局势、利益、关系或信息变化。不能因为“有转折”就给节奏高分；必须检查转折间隔、重复信息、静态动作和爽点兑现链。

追回策略（破坏性从小到大）

策略 1：系统被动数据对比（破坏最小，≈150 字）

章末系统面板后插入一次性数据对比。系统不说话，只报数。灰色小字。

示例（仅作参考）：

码头日均收虾一百七。大城市水产公司日均收虾八百六。收购价差百分之十二。

策略 2：算牌内心独白（≈400 字）

主角过资源/牌面 + 对手的牌。必须算完→行动暗示，不能算了就完。

示例：码头底座 / 冷库合伙人 / 系统日结 →「对手看不到第三张牌」。

策略 3：外部视角验证（≈300 字）

旁观者/对手的眼睛看主角成长。从别人嘴里说出来比主角自己说有力。

示例：旁观者/对手的视角——「这个码头跟以前不一样了」「照实说」。

策略 4：章末强钩子（破坏较大，≈150 字）

新信息打破平衡：电话/短信/突然出现的人/系统数据跳变。仅在章末钩子虚弱时用。

执行规则

• 优先策略 1-3（不动主线）
• 每章 ≤2 注入点，每个 ≤300 字
• 追回后必须跑 review_scan
• 补字数必须合理不水；若作品明确要求约 2200 字，必须同时满足 2200—2400 字与有效内容密度，不能用“差一点可接受”绕过硬要求

二、弧线空洞修复：三节点植入法

适用场景

• 角色有功能但无独立生活（每次出场都帮主角）
• 角色无 Want/Need、无背景冲突、无独处场景
• MILESTONE 反复标记「弧线空洞」但未处理

方法

在角色早期出场的三个关键章中各植入一个 100-150 字的独立瞬间——不是帮主角，是她自己的生活：

节点	时机	内容方向
节点 1	首次出场后	她去哪？她有什么习惯？她有什么从来不去的？
节点 2	决策/签约后	她停了一下的瞬间在想什么？在看什么？
节点 3	独处场景	她一个人的时候做什么？什么东西她拿在手里没放下？

示例（配角弧线植入）

• 首次出场后：骑电动车经过某人病房楼下——不停。
• 决策签约后：窗外病号服老人让她停了一秒——不是她亲人，但体型差不多。
• 独处场景：黑暗冷库里掏口袋里的纸条——在外打拼多年。冻虾拿在手里，没拆。

串联：不停→停一秒→一个人黑暗中握着冻虾。不是一场大戏，是背景噪音。读者回头看时会自己连起来。

三、B 线注入法：单线章转双线章

适用场景

• 章节是纯人情/支线章，拖节奏但核心情感又不能砍
• 读者审查反馈「想弃」

方法

保留 A 线（核心情感），注入一条平行 B 线（主线压力）。B 线视角从外部切入——对手/旁观者。

示例：A 线 = 人情/家庭线。B 线 = 主线压力（对手的视角）——他们看到主角地盘变了，报告「无异常」得到回复「继续盯着」。

效果：人情不砍、压迫感注入、章末双线收束。

四、章节质量修复全流程

自动扫描 → 诊断报告 → 文档修复(delegate_task) → 
字数补全(Claude Code CLI sonnet) → 爽点注入(Claude Code CLI sonnet) → 
读者审查(Claude Code CLI sonnet) → 验证扫描

分工铁律：

• 文档修复（伏笔表/系统状态/人物总表）→ delegate_task
• 文字创作（补字数/爽点注入/弧线植入）→ Claude Code CLI sonnet
• 读者审查 → Claude Code CLI sonnet
• 验证扫描 → 主 Agent 直接执行

五、MILESTONE 数字纪律

• 禁止自创进度百分比。分卷细纲说第一卷 1-60 章 = 25/60 (42%)，不能说 25/30 (83%)。
• 禁止自创卷数划分。所有章段划分以 分卷细纲/ 为准。
• MILESTONE 报告的进度数字必须可追溯到分卷细纲。
• 不要用章节规划的行数当成卷总章数。

六、字数铁律

• 默认按番茄显示字数验收：去除标题、空格与换行，保留标点、数字和字母
• 章节要求约 2200 字时：目标 2250，合格区间 2200—2400
• 字数不足不得直接扩写环境、五感、动作、等待、回忆或重复确认
• 删除注水后不足 2200 字，必须补有效剧情回合，具体标准见 references/2200-effective-content-standard.md
• “差一点可接受”只适用于用户未设定硬字数要求的作品；用户明确要求 2200 字时不适用

删减纪律：只删字，不动句子

用户要求「控字数」「轻微删改」时，必须严格遵循以下规则：

1. 只删个别冗余修饰词，不改变任何句子结构、不删对话、不改粤语台词
2. 不删对白 — 对话是网文灵魂，删字从叙述语下手
3. 不允许合并/重构句子 — 删字就像删柴，不能改房子的骨架
4. 不影响叙述节奏 — 删完读一遍，不要破坏段落的气口
5. 如需要删超过20字才能达标，优先考虑删一整句次要描写，比每句各删几个字更干净
6. 绝不动用户未指定修改的章节 — 哪怕发现了明显的错字/设定不一致，只要用户没提到那章就不要碰

实战信号：用户说「为什么改那么多」「这样不行吧」= 已经越界。立即恢复原版重新来过，减少删减量。

番茄字数计算验证

番茄后台显示字数为纯正文无空格字符数（含标点、数字、字母，不含空格/换行）：

import re
lines = open('第N章.md').read().strip().split('\n')
body = '\n'.join(lines[2:])
text = re.sub(r'\s', '', body)
print(f'番茄字数≈{len(text)}')

七、流程纪律：novel_step.sh 防跳步

问题

连续创作时，助理会跳过 novel-main 7 步流程中的步骤（跳 PLOT、缩 REVIEW、跳 TRACK）。纸面约束挡不住势头压力。

解决

~/.hermes/skills/novel/scripts/novel_step.sh — 状态锁。每步执行前 check，完成后 done。

novel_step.sh check DRAFT   # ⚠️ BLOCKED 如果缺 PLOT
novel_step.sh done DRAFT    # 标记完成

详见 novel-writing → references/general/workflow-lock.md

跳步信号

• 连续两章之间的步骤越来越少
• REVIEW 只跑 review_scan 不做爽点/OOC/读者审查
• TRACK 被完全跳过
• 用户问「有按照流程来吗？」= 已经跳了

八、跨章一致性扫描流程

来源：实战项目中行政层级错误（虚构市/县/镇层级不一致）+ 同名实体地理位置冲突排查。

核心规则

发现一个错误 → 先全局搜索，再修复。

不要只改发现的那一处。用 search_files 以错误关键词在所有章节中搜索同类模式。只有确认「仅此一处」才能只改一处。

扫描维度与执行顺序

执行顺序	扫描维度	搜索策略	示例
1	错误关键词级联	用发现的错误词搜全部章节	发现层级用词错误→搜所有相关行政区名
2	同类模式	思考错误属于哪类模式，搜同类	行政层级错误→搜所有上级+下级行政区名
3	关联实体	与错误相关的其他实体是否也有问题	某区错→检查其他区/镇是否正确

真实案例

案例1：行政层级错误

发现：某个虚构行政区的层级使用不一致（如将「市」误写为「县」，或将「镇」误写为「县」）。

扫描：

1. 搜索错误的层级用词 → 定位出错章节
2. 搜索同类模式 → 检查全书是否还有类似错误
3. 搜索关联实体 → 确认上下级行政区名称是否正确

案例2：地名位置逻辑

发现：不同章对同一地点的地理定位矛盾（同一实体在不同章节出现在不同位置）。

扫描：

1. 搜索矛盾地点名 → 定位所有出现位置
2. 核对每章场景的地理位置（角色在哪、能看见什么、能听见什么）
3. 分类：在正确场景的→保留；在错误场景的→修正

结论：跨章同名实体存在位置冲突。

地理位置铁律

修改地点参照时，必须核验角色的当前位置：

• 角色在某地 → 不能「看」到远方城市的市场（间距数百公里）
• 角色在某地 → 不能「听到」远方城市的声音
• 角色在本地说话 → 不能拿远方城市举例（逻辑不通）

⚠️ 常见推理陷阱： 当发现某个地点参照错误时，不要只换地名，要重建场景的物理可行性。例如角色站在本地码头，距离大城市500km，不可能「看」到那边。正确做法是替换成本地可感知的参照物，同时更换视角动词。

核验方法：

• 先读章首，确认场景设定在哪
• 再读角色出现的段落，确认角色当前位置
• 再判断地点引用是否在合理距离内

跨章同名实体通则

一个命名实体（市场/机构/店面/大楼）在全书中只能有一个地理位置。如果它在不同章节出现在不同地方，处理方式：

1. 场景位置与实体位置一致→保留
2. 场景位置与实体位置不一致且角色在本地→改为本地实体或通用描述
3. 场景位置与实体位置不一致但角色在远处→改为纯方向性描述（如「往大城市方向」而非指名具体地点），不能有看/听/去的具体动作

九、读者审查方法论（深度逐章版）

来源：2026-07-27 1-30章全量逐章深度审查实践。用户三个纠正信号：

1. 「你不会找？」= 不要问文件路径，主动 find
2. 「怎么都是好话？」= 诚实审查，不要心软，不能说假话
3. 「有没有逻辑问题 有没有坑 有没有上下剧情对不上的问题」= 三线检查：时间线一致性/人物行为一致性/线索闭环

核心规则

诚实优先，具体优先，对抗心软。 用户花钱花时间，说假话就是浪费用户的钱。

每章三问必答：弃点？爽点？想看下一章？

四维审查框架

维度	检查内容	输出要求
开头吸引力	前300字能不能抓住人？第一句有没有信息量？	评级+理由
弃书点排查	哪里想划走？具体到段落	评级+具体段落原因
爽点落实	至少1个实爽点，连续3章零爽点=沙漠段	评级+具体爽点描述
章尾钩子	看完想不想点下一章	评级+钩子类型

逻辑与连续性检查（用户特别要求）

每次全量审查必须额外检查：

1. 时间线一致性：前后时间衔接是否合理
2. 人物行为一致性：性格/能力/人设是否前后一致
3. 线索闭环：前文伏笔有没有回收，挖坑有没有填
4. 系统设定一致性：系统是否始终遵守初始规则
5. 数字连续性：金钱/人口/系数/产量是否前后对齐

阅读型审查可疑信号

出现以下任意一条，立即停止，重新逐字阅读：

• 每章评价几乎一样（「节奏好」「爽点足」循环使用）
• 没有引用具体段落或具体台词
• 字数直接从机器读取，没有主观感受
• 无法回答「这章主角做了什么」
• 评语套话化（「张力够」「推进自然」循环）

完整参考文档

见 references/case-studies/读者审查标准.md——包含审查人设、四维框架、全量审查输出格式、评审纪律、对抗心软检查清单、分批审查策略。

十、深度审查→修复执行流水线

来源：2026-07-27 全量审查修复（14项，12章，约1800字增补）。

三阶段修复

深度审查报告产出后，按以下顺序分阶段执行：

阶段	内容	派发方式	典型件数
S级（紧急）	机械清洁（删残留/补标题/修格式）+ 关键爽点注入	机械→主Agent patch；创作→Claude Code (sonnet)	3-5项
A级（核心）	结构性重写（拆PPT式独白/压缩科普/加爆点尾钩）	Claude Code (sonnet)（≥100字创作）	2-4项
A级（核心）	结构性重写（拆PPT式独白/压缩科普/加爆点尾钩）	Claude Code (sonnet)（≥100字创作）	2-4项

执行纪律：每项独立执行→验证→下一项。同阶段不可并行的项串行。

2. 独立章节可并行：不同章之间的 B 级微调可批量读取+批量 patch。
3. 每项有明确 success criteria：字数目标/具体行号/注入位置。
4. opus 产出后必须验证：review_scan + 确认是完整章节（非摘要）。
5. 引号格式统一检查：全书使用「」成对引号。修改后必须检查新增/修改的对话是否用了 ""，统一改成「」。
6. 人物情绪落点补全：B级微调中，给配角加一句话收尾（如「某人在此蹲了十五年，今天总算摆在明面上了」）是低破坏高回报的修复模式。优先在配角有高光时刻的章节末尾补一句——不是解释剧情，是让配角自己开口点一下自己的情绪。

模型摘要陷阱

问题：当 prompt 较长/复杂时，模型可能只输出变更摘要（"三个修改完成"），而非完整章节。

症状：终端输出以描述性文字开头，如「三个修改已全部完成。修改1…修改2…」，没有以 ## 第X章 开头的完整正文。

防御：

1. 检查终端输出第一行是否以章节标题开头（## 第 或 # 第）。如果不是 → 摘要模式。
2. 摘要模式下，检查输出中是否有完整章节代码块（```包裹），有则提取。
3. 若 opus 声称「已将文件写入…」，用 read_file 验证文件确实被更新。
4. 若以上均不成立 → 回退到主 Agent patch（适用于 ≤100 字的简单修改）或重新派发 Claude Code 并强化「直接输出完整章节。不要解释。」指令。

修改前置：备份

任何对 01-正文存稿/ 的修改必须先行备份：

python3 ~/.hermes/skills/novel/scripts/backup_chapter.py <path>

多章可批量：

for f in 第17章 第18章; do
  python3 ~/.hermes/skills/novel/scripts/backup_chapter.py \
    ~/novels/books/<书名>/01-正文存稿/$f.md
done

验证清单（全阶段完成后）

• consistency_check.py --book <书名> → 7/7
• review_scan.py 各章 → 零 Level 2
• 各章字数 ≥2000 汉字
• 系统面板格式合规（无标题、固定三行+可选≤2行）
• 新增字数合理不水

十一、批量语言风格审计（方言标准化实战模式）

来源：实战项目中方言过量（每章15-22行→3-5处）系统性修正经验。适用于任何方言类型。

触发条件

审查清单中「方言检查」连续多章不通过，或用户指出「滥用方言」。

审计流程

扫描 → 分类 → 决定保留/替换 → 批量patch → 验证 → 更新书配置

第1步：扫描

# 通用方言特征字扫描（以粤语为例，其他方言替换特征字即可）
canto_chars = ['嘅','唔','佢','咗','喺','哋','冇','咩','睇','啲','嘢','嚟','乜','係','俾','咁']
# 按章节统计含方言行数，标准由书配置定义（如≤5行/章）

第2步：保留/替换决策框架

类型	保留条件	替换条件
该地域角色对话（有方言背景的角色）	身份标识，1-2句/章	长段叙述或非角色特质对话
地域风味（当地老渔民/老居民）	极简一两句地域风味	连续多句、信息性对话
情感动敌高潮	关键时刻1句	普通汇报/分析性对话
主角对话 永不保留	—	主角说方言破坏叙事视角一致性
叙述性文字 永不保留	—	叙述混方言不伦不类

第3步：批量执行

# 1. 备份所有要改的章
python3 ~/.hermes/skills/novel/scripts/backup_chapter.py 第20章.md
# ...（可并行多个）

# 2. 逐章patch：先读完整上下文，再决定保留哪些
#    核心方法：保留的句子整句不动，其他全部替换为普通话等效表达

# 3. 验证：重新扫描确认粤语行数≤5

第4步：同步更新生成约束

修完正文后，必须更新opus prompt/书配置中的方言规则，防止新章节重复犯同样的错。具体做法：

• 在DRAFT prompt铁律中把模糊的「方言N处」替换为明确的禁止清单+字符数上限
• 在审查清单中增加量化检查项
• 更新书配置中的方言设置

纪律要点

1. 先备份再改：多章可并行备份
2. 每句单独决定：不批量替换，逐句评估是保留还是转普通话
3. 保留的句子整句不动：不把方言句子改成「半方言半普通话」——要么整句保留，要么整句转普通话
4. 主角/叙述零容忍：主角、叙述性文字中出现方言，直接转标准语
5. 改完更新书配置：这是最重要的——只修正文不修配置，新章还会犯

十二、Markdown语法清理（番茄平台不渲染Markdown）

来源：2026-07-28 第10-30章全量扫描发现38处---分割线+1处反引号代码块，跨11个章节。

问题

opus在生成正文时倾向用---做场景分隔线。番茄小说平台不渲染Markdown，---会直接显示为三个减号，破坏阅读体验。同理**加粗**、`代码块`、> 引用也不应出现在正文中。

扫描与清理

# 扫描所有章节
grep -rn '^---$' ~/novels/books/<书名>/01-正文存稿/
grep -rn '\*\*' ~/novels/books/<书名>/01-正文存稿/
grep -rn '`' ~/novels/books/<书名>/01-正文存稿/

清理方式：直接删除---行（场景之间空行衔接即可），删除反引号（保留文字内容），删除**（保留文字内容）。

预防

DRAFT prompt铁律第3条已增加「禁止任何Markdown语法」明确禁止。REVIEW审查清单第6项已增加Markdown残留检查。新章节产出后扫描确认零残留。

十三、Claude Code 超时与主 Agent 接管策略

来源：2026-08-04 第34章创作。opus 连续两次超时（300s+180s）零输出，用户发出 frustrateion 信号「怎么这么久，很不正常」。

问题

单章 DRAFT 派发 claude -p --model sonnet 时，有时 模型会卡住完全无输出。background 重试不是解决方案——只是让用户多等一次。用户对等待时间极度敏感。

规则

1. Claude Code 连续失败2次（超时/零产出）→ 停止重试，主 Agent 直接接管
2. 不解释、不等——用户说「怎么这么久」时流程已经出问题，立刻切换
3. 主 Agent 接管时：严格按骨架场景顺序填肉，每场景写够骨架标注字数
4. 主 Agent 写初稿通常偏短（~2000-2100字 vs Claude Code 的 2300+）。必须在 POLISH 阶段补有效剧情到 2200+
5. 补字数只加有效剧情回合（渔民群体反应、搬货细节、账目具体化、新角色与旧角色互动），不加环境描写
6. DRAFT/POLISH 用 --model sonnet（deepseek-v4-pro），不用 opus（glm-5.2 长prompt卡死）

补字数技巧（有效剧情注入，约 150-200字）

• 群体反应：不只写「有人搬回来了」，写具体几个人的动作和表情
• 财务具体化：不只写「刘芳核账」，写她桌上多了什么具体数字
• 新角色落地：新角色学干活的具体动作细节（怎么码泡沫箱、怎么扛货）
• 对抗余波：花衬衫走后，被收走的渔民的具体反应——谁低头、谁走开

十四、review_scan.py 地点误报识别

每次扫描都产生 15-25 条 level1 误报，浪费审查时间。

模式

review_scan.py 把白名单内地名与相邻标点/引号拼在一起，整个字符串去白名单匹配，自然不中。如 「码头、，穗城、。码头、色，穗城 都报 level1。

快速过滤方法

# 扫描后过滤：去掉首尾标点/引号后，检查剩余词是否在白名单内
hits = [h for h in scan_result['hits'] 
        if h['type'] == '地名白名单外: 疑似地名']
false_positives = [h for h in hits 
                   if h['word'].strip('「」。，；：！？、…— \n') in PLACE_WHITELIST]
real_issues = [h for h in hits if h not in false_positives]

判断规则

• 误报：命中词去掉标点后 = 白名单内地名 → 忽略
• 真报：命中词去掉标点后 仍不在白名单 → 必须修复
• 其他 level1（禁用词、字数不合格）→ 全部为真，必须处理

十五、claude_runner.py 产出回收与 POLISH 字数控制

来源：2026-08-07 第43章创作。两个独立问题连续出现。

问题 A：claude_runner.py --target-file 不落盘

现象：claude_runner.py 执行成功（exit_code=0），但 --target-file 指定的路径下没有文件。正文内容只在 JSON 的 result 字段中。

原因：claude_runner 的 --target-file 参数在 claude_code 未调用 Write 工具时（模型直接输出文本而非调用工具写文件）不会自动落盘。

防御：

1. claude_runner 进程结束后，检查 --target-file 路径是否存在
2. 若不存在，从 --output-file 的 JSON 中提取 result 字段，手动写入目标文件：

import json, os
with open(output_json_path) as f:
    r = json.load(f)
content = r.get('result', '')
if content and not os.path.exists(target_path):
    with open(target_path, 'w') as f:
        f.write(content)

3. 这不是错误——是 claude_runner 的已知行为。不要把缺少文件当成 claude_runner 崩溃去调试。

问题 B：POLISH 压缩过度

现象：DRAFT 产出 3200+ 字（超标），POLISH prompt 要求压缩到 2200-2400，结果压到 ~1800 字（低于下限）。

原因：Claude Code 在收到「压缩到 N 字」指令时倾向激进删减——删掉所有描写层、合并对话回合、砍过渡段。

防御：

1. POLISH prompt 中不要只给「压缩到 2200-2400」，要同时给出保留清单：哪些对话回合不能删、哪些角色互动必须保留
2. POLISH 完成后立即跑 review_scan 检查字数
3. 若 POLISH 压过头（<2200），不要重新派发 Claude Code——直接用 patch 逐处补有效剧情（对话回合、配角反应、动作细节）。主 Agent patch 比 Claude Code 全文重写更可控
4. 补字数的有效内容类型（已在 §13 补字数技巧中列出）：
   • 角色互动余波（陈伯问候家人、细虾多一层试探）
   • 财务操作细节（签字、数钱、交接）
   • 场景过渡中的信息增量
   • 不要补环境描写或内心独白

通用教训：Claude Code 字数指令偏差模式

指令	实际产出	偏差方向	补救
「写 2200-2400 字」	2800-3300 字	偏长 20-40%	POLISH 压缩（可能压过头）
「压缩到 2200-2400 字」	1700-1900 字	压过头 15-25%	主 Agent patch 补有效剧情
「补字数到 2200」	2100-2200 字	略短	1-2 处 patch 微调

结论：Claude Code 对字数目标的控制不稳定。主 Agent 必须在 Claude Code 产出后跑 review_scan 验证，并准备好直接 patch 修正——不要反复派发 Claude Code 调字数。

字数振荡止损阶梯

出现“偏短→扩写过长→精简仍略超”的振荡时，按剩余偏差切换工具，禁止继续全文重写：

与合格区间的偏差	处理方式
≥300 字	Claude Code 仅恢复/删除骨架中已列明的有效回合；prompt 同时给保留清单、禁增清单和目标窄区间
50—299 字	先备份，用段落级定点 Edit；每处指定原文、替换方向和不可动项
<50 字	停止创作式 POLISH；只做 1—3 个精确替换，优先删重复解释或冗余修饰，不碰核心对白

每轮都必须：备份 → review_scan.py → 对话占比 → diff 对照授权范围。若目标文件已修改但 runner 非零退出，先读 result/events 和文件 diff；确认修改完整落盘时，不因退出码盲目重跑。

跨章时间窗口核验

涉及“满两周、连续若干月、N 天后”等结果型章节，PREP 前必须做锚点算术：

1. 找到真正开始日（交付、上架、签约、首次发生），不能拿上一章日期代替。
2. 计算最早兑现日，并核对中间章钩子；例如 D92 开始，满两周最早 D106。
3. 对“已发生两天、再约若干天后”复算总时长，避免把 2+10 当 14。
4. 若旧细纲或已归档钩子提前宣告结果，先修前章；同步 REVIEW、TRACK、章节规划、PREP/PLOT 和新归档版本，再开始下一章。
5. 历史设计文档中的旧钩子也要同步，否则后续回读会再次污染时间线。

细节见 references/timeline-and-wordcount-repair.md。

十七、指标修复与条件性例外

对话占比修复：替换，不叠加

• 先独立统计有效字数与「」内对话占比，标出最长说明段。
• 优先把说明段改成能改变信息、利益或局势的交锋；不要在原稿上追加机械问答。
• 每轮前备份，轮后统计净字数变化与对话占比。若“比例提高但字数超限”，用备份 diff 定位新增冗余，下一轮执行“删叙述、换对话”，禁止继续叠加。
• 重复确认、逐项复述、无局势变化的问答属于注水，即使比例达标也不能通过。
• 达到 REVIEW↔POLISH 上限后停下，不为机械抬高少量百分点无限消耗 token。

用户条件性放行

当用户明确说「如果只有 X 问题，可以通过」时：

1. 用最新正文排他核验字数、剧情逻辑、时间线、人物、设定、系统权限、授权数字、编码/格式、扫描命中、注水和读者体验；
2. 扫描误报必须定位具体行并人工解释；后台退出码 0 不能替代正文和审查结果；
3. 若有只读读者审查，必须读取结果正文，确认一级问题为 0、结论与 TRACK 放行状态；
4. 仅当 X 确为唯一未达项时，按用户授权作为该章节、该数值的局部例外；不得外推到其他章节或指标；
5. 在审查报告和进度状态中记录实测值、授权范围及例外原因，供 TRACK/MILESTONE 复核。

十八、Claude Code 产物、权限与模型审计

Claude Code 的退出码、status=success、target_file_modified=true、stdout 自述和 --allowed-tools 都不能单独证明任务合规完成。DRAFT/POLISH 后必须同时验收：目标文件、events JSONL、result JSON、正文指标和写入范围。

• 解析 events，列出实际模型与全部工具调用；出现 Agent/Bash/未授权模型或目标外写入，记录为执行过程越权。
• 过程越权但目标文件已修改时，先保护并独立验收现稿，不盲目重跑覆盖；产物合格可保留，但审查报告必须记录越权。
• review_scan.py 零命中后仍须人工审计隐性数量/时长、系统数据来源和法律/资本结论来源。
• backup_chapter.py 的时间戳文件仅是修改前保护副本；正式归档仍须生成 第N章_vK.md、设定快照、备份日志并校验哈希。

完整检查表与判断矩阵见 references/claude-code-artifact-audit.md。

十九、章节修复工具速查

工具	用途
review_scan.py	零容忍扫描（地名/系统词/禁用词）
novel_scan.py --book <名> --chapters N	违禁词扫描
consistency_check.py --book <路径>	7维跨文档一致性
backup_chapter.py <路径>	修改前备份
novel_step.sh check <步骤>	流程锁——进入步骤前校验
claude --model sonnet --max-turns N -p \"...\"	创作派发
delegate_task	文档维护（非创作）