# Novel Editing Patterns

> 网文章节修复与质量提升模式——爽点追回、弧线植入、节奏调整、字数补全

- Skill: `cwjdong-design/novel-editing-patterns` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add cwjdong-design/novel-editing-patterns`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cwjdong-design/novel-editing-patterns/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cwjdong-design (https://skillmd.com/u/cwjdong-design)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cwjdong-design/novel-editing-patterns

---


# 网文编辑模式

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

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

当章节硬性要求约 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. **绝不动用户未指定修改的章节** — 哪怕发现了明显的错字/设定不一致，只要用户没提到那章就不要碰

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

### 番茄字数计算验证

番茄后台显示字数为纯正文无空格字符数（含标点、数字、字母，不含空格/换行）：
```python
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。

```bash
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-正文存稿/` 的修改必须先行备份：

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

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

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

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

### 第3步：批量执行

```bash
# 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，`---`会直接显示为三个减号，破坏阅读体验。同理`**加粗**`、`` `代码块` ``、`> 引用`也不应出现在正文中。

### 扫描与清理
```bash
# 扫描所有章节
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。

### 快速过滤方法
```python
# 扫描后过滤：去掉首尾标点/引号后，检查剩余词是否在白名单内
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` 字段，手动写入目标文件：
```python
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` | 文档维护（非创作） |