# Novel Finalization

> Use during Phase 2 novel writing end-of-draft stage - multi-round review, P0/P1/P2 triage, minimal edits, git batching, scaling up/down - activated when user says '全书校一遍' / '准备发布' / '定稿'

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

---


# 小说收口定稿阶段（Phase 2 · 最后一步）

## 激活条件

由 `novel-writer-workflow-guide` 路由激活，当：
- 所有章节初稿已写完（每章跑过 `novel-chapter-sop`）
- 用户说"全书校一遍" / "准备发布" / "定稿前再扫一遍" / "收口"
- 跨章一致性四表已维护到最新

## 收口阶段的核心心法

**定稿不是再写一遍，是挑问题改问题。**

90% 时间在**发现问题 + 分级**，10% 时间在**最小化修改**。这个比例反了，就会把稿子越改越烂。

## 一、多轮独立 review 的艺术

### 为什么要多轮

单次 review 会漏。尤其是**不同类型的问题需要不同视角**：
- 读者视角（情绪曲线、爽点、卡读点）
- 编辑视角（结构、伏笔回收、跨章一致性）
- 校对视角（错别字、标点、引号、数字）
- 法务/合理性视角（司法程序、行业术语、常识）

一个 agent 在一轮里顾不过来。**分轮 + 分视角**。

### 全书 review 的五轮推荐

| 轮次 | 视角 | 用哪个 agent | 重点 |
|---|---|---|---|
| 1 | 结构/伏笔 | general-purpose | 大纲对齐、伏笔是否都回收、情绪曲线 |
| 2 | 跨章一致性 | general-purpose | 对照四表（道具/时间/术语/数字）逐项核 |
| 3 | 语言/风格 | Explore | 引号、破折号、markdown、风格漂移 |
| 4 | 合理性/常识 | codex（如有）或 general-purpose | 司法/行业/地理/年代常识 |
| 5 | 终读（全文连贯） | 新开 general-purpose | 整本连读一遍，看节奏和读感 |

**硬性要求**：最后一轮必须是**新实例 agent**，不得复用前几轮看过全书的那个。

### 独立实例的重要性

看过全书的 agent 会有"上下文偏见"（记得你 Ch 10 的铺垫，自动脑补 Ch 30 的转折合理）。**新实例只看文字本身**，像读者第一次翻开。

定稿前至少**最后一轮终读**必须用新实例。

## 二、P0 / P1 / P2 分级

不是所有问题都要改。**分级 → 只改 P0 + P1**。

### 分级标准

| 级 | 定义 | 例子 | 必改？ |
|---|---|---|---|
| **P0** | 硬错误：逻辑矛盾、人物记错、事实错误 | 姓氏前后不一、司法程序倒错、年份不符 | 必改 |
| **P1** | 明显影响阅读：语病、钩子失效、伏笔漏回收 | 钩子强度不足、段落读不通、伏笔悬空 | 必改 |
| **P2** | 风格/逻辑可改进：可以更好但不算错 | 某句可以更精练、某个比喻可换、某段节奏稍松 | 择优改，改完重走 review |

### P2 的处理原则

P2 不是"坚决不改"，是"**择优改 + 改完必须重走一轮 review**"。

**该改的 P2**：
- 文风问题（某段语言明显粗糙、节奏断了）
- 逻辑可优化（不是逻辑错，但可以更顺、更清楚）
- 读感问题（某处读起来卡一下）

**不该改的 P2**：
- 纯主观偏好（"我觉得这句话可以再换个说法"，但不改也没问题）
- 风格洁癖（追求"每个比喻都要新鲜"这种完美主义）
- 同一轮 review 里反复 ping-pong 的（每次改又觉得上次更好）

### 改 P2 的纪律

**改 P2 必须满足三条**：

1. **不混着改**：一个 commit 只改 P2，不和 P0/P1 混一批（否则很难分辨是谁引入的新 bug）
2. **改完必须重跑**：机械扫描 + 一轮独立 agent review，确认没引入新 P0/P1
3. **一段只改一次**：同一段/同一句不要反复改，第一次改了觉得不够好就认了

### 为什么改 P2 要谨慎

每改一次 P2，引入新 P0/P1 的概率不低（手抖改错标点、复制粘贴带入 ASCII 引号、误删一个字、误破坏钩子节奏）。

**规矩不是"不改"，是"改了要付代价（重跑 review）"**。

如果一个 P2 你觉得改了读感会明显提升 → 改，重跑 review。
如果只是"可以更好但不改也挺好" → 放下。

### 分级记录模板

```markdown
## Review Round N · [视角]

### P0（必改）
- [ ] Ch 12: 主角年龄写成 29 岁，按人物卡是 28 岁
- [ ] Ch 25: 时间标注"冬末"，按时间锚应为"初春"

### P1（必改）
- [ ] Ch 07: 钩子强度 2,该章在情绪曲线应为 4 附近,强度不足
- [ ] Ch 18 伏笔"小灰猫"埋于 Ch 1,未见回收章

### P2（择优改，改了要重跑 review）
- [ ] Ch 03 某段比喻粗糙 —— **改**，改完重跑 Round N+1
- [ ] Ch 20 某段节奏略拖 —— **改**，和上一条一起
- [~] Ch 15 某句可以更短 —— **不改**（偏好，读着不卡）
```

## 三、最小必要改动原则

### 改 P0 / P1 时的纪律

**改最少的字、最少的行、最少的段。**

反面例子：
> P0 是"Ch 12 年龄写错成 29 岁"。
> 错误做法：把整章 Ch 12 重写，顺便"优化"人物描写。
> 正确做法：grep "29 岁" 所在段，只把"29"改成"28"。周围一个字都不动。

### 判断规则

每次改动前自问：
1. **这个改动能不能用 1 行 Edit 完成？** 能就只改 1 行。
2. **周围的段落有没有必要连带改？** 如果 P0 只是个数字错，周围段落不要动。
3. **改完会不会破坏附近的钩子/节奏？** 如果改了会连锁，先看连锁范围，决定是否还值得改。

### 例外：连锁型 P0

如果一个 P0 牵连多章（比如改了某件事的时间，后面三章的时间锚都要调），必须**连锁全改**。但改之前先**在修改清单里列出所有连锁点**，一次改完，不留半成品。

## 四、Git 分批提交节奏

### 按"问题性质"分 commit

不是按"第几轮 review"分 commit，是按**问题性质**分：

| commit 类型 | 包含 | 例子 |
|---|---|---|
| `fix: 跨章一致性` | 四表对齐的所有改动 | 道具状态、时间锚、术语统一 |
| `fix: 司法程序` | 合理性视角查出的硬错 | 一审终审、起诉书用词 |
| `fix: 引号/标点` | 机械扫描问题 | ASCII 引号、破折号超限 |
| `fix: 钩子强度` | P1 钩子失效 | 某章末尾加强钩子 |
| `fix: 伏笔回收` | 伏笔矩阵的漏收 | 补回收或明确删除伏笔 |

**一个 commit 只做一类事**。review 时很容易回滚单一类。

### 为什么不按轮次分

一次 review 会出各种问题，如果按轮次分 commit，后来回溯"这个字是什么时候改的"会看不清。按**问题性质**分，语义清晰。

### commit message 模板

```
fix(consistency): 统一关键旧档复印件的叫法

- Ch 16 / Ch 22 / Ch 30 / Ch 37 共 4 处
- 全部改为"父亲当年灭门那份旧档复印件"
- 消除"前世查封笔录复印件"的歧义叫法

Review: Round 2 · 跨章一致性
```

### 收口阶段频率

- 每改完一类问题就 commit（不要攒到最后）
- 一天最多 5-8 个 commit（再多说明改动太散）
- 每次 commit 前跑一遍脚本扫描确认没引入新 bug

## 五、扩写 vs 压缩

### 字数不硬加（反常识）

"还差 2 万字"这种字数焦虑是长篇大忌。**字数凑出来的章是最难读的章**。

**规则**：
- 如果全书字数比目标少，先检查**是不是某几章本该更厚（情节密度 / 情绪铺垫不够）**——在这些章自然扩展
- 不是在过渡章硬加场景凑字
- 不是在对话里加"他沉默了一会"式废话
- **字数不够不等于要扩写**，也可能是结构本来就紧凑，那就停在少一点的字数

### 压缩的优先级

如果某章字数过长（3000+）又情节薄：
1. **先看有没有重复信息**（前两章已说过的背景再说一遍）
2. **再看有没有节奏松**（三段对白能合成一段）
3. **最后看有没有多余的氛围描写**（单章氛围段 > 2 段通常过了）

**不压人物心理独白**——那是女频/男频情绪含金量最高的地方。

### 扩写的优先级

如果某章字数过短（< 1500）又情节分量重：
1. **先看有没有情绪段缺失**（角色做了重大决定但没内心戏）
2. **再看有没有细节缺失**（关键场景没有物理描写，读者想象不起来）
3. **最后看有没有 buff 段/爽段缺失**（对决赢了但没展开）

**不扩对话**——对话加水最容易水。

## 六、反常识经验

### 1. Review 越多不一定越好，但到 P2 层之后要停得住

有个**拐点**：前 3-5 轮 review 每轮都能抓出 P0/P1，第 6 轮开始大部分是 P2。**拐点之后不是不改**——P2 里是文风 / 逻辑问题的可以改，但改完必须重跑 review 确认没引入新 P0/P1。P2 里纯主观偏好的（"这个比喻还能更好"）就放下。

### 2. 破折号统计比"句子通顺"可测

正文每章破折号 ≤ 7 个。这是**数字可测**的指标，比"读起来顺不顺"这种主观判断稳。（`novel-consistency-guards` 里有脚本）

### 3. 最后一轮用新实例 agent 比用自己看一遍更有价值

自己读第三遍会跳读。新实例 agent 每个字都在看。发现的问题密度是自读的 3-5 倍。

### 4. "再读一遍觉得不好"90% 是 P2

写完一段时间后回头看，总会觉得"啊这段写得不够好"。这是作者的普遍焦虑。**要判断是"具体能说出问题"还是"模糊地觉得不够好"**：
- 能说出具体问题（文风粗糙 / 逻辑绕 / 节奏卡）→ 可以改，改完重跑 review
- 只是模糊觉得不够好，说不出具体哪里 → 放下，这是纯主观焦虑

### 5. 钩子强度全书均值比单章峰值更重要

没必要每章都 5 分爆点。但**全书均值 ≥ 3.5**，读者追得动。**均值低**（大量 2 分）比**峰值不够高**更致命。

### 6. 字数不硬加、字数也不硬删

不硬加见上。不硬删：如果某章自然写出来 4000 字，情节合理读感好，不要为"每章控制在 3200"人工砍。**章节字数有自然方差**。

## 七、发布前最终检查清单

全书 review 收口前，过一遍：

### 跨章一致性
- [ ] 所有关键道具的状态前后一致（道具链表对过）
- [ ] 所有时间锚对齐，钩子"N 个月后"和实际时间差一致
- [ ] 所有术语全书统一（术语表对过）
- [ ] 所有关键数字（年龄/年份/比分/金额）全书一致

### 伏笔
- [ ] 伏笔矩阵每个都有明确回收章
- [ ] 没有悬空伏笔（埋了没收）
- [ ] 回收章里伏笔的回收是明面的（不是脑补的）

### 硬约束
- [ ] `check_consistency.py chapters/*.md` 全部通过
- [ ] 没有 ASCII 引号 / markdown bold / meta "Ch N"
- [ ] 每章破折号 ≤ 7
- [ ] 姓氏锁通过

### 风格 / 节奏
- [ ] 钩子强度全书均值 ≥ 3.5
- [ ] 钩子曲线不是长时间 2 分（读者会掉）
- [ ] 每 3-5 章有一个强度 4+ 的爆点

### 合理性
- [ ] 司法/行业/年代常识视角过一轮（P0 级）
- [ ] 人物做的事和人物卡动机/能力对得上

### Review 轮次
- [ ] 至少 5 轮全书 review
- [ ] 最后一轮用新实例 agent
- [ ] 每轮 P0 + P1 全部处理
- [ ] P2 里文风 / 逻辑类的择优改，改过 P2 的轮次之后**加跑一轮 review** 确认没引入新 P0/P1
- [ ] 最后一轮 review 报告 0 P0 + 0 P1
- [ ] 每轮 review 记录已存档（可以放在 `reviews/` 目录下）

### Git 状态
- [ ] 所有改动分 commit 提交（按问题性质，不按轮次）
- [ ] 无未提交本地改动
- [ ] 如果有远程，已推送（用户授权后）

## 八、交付标准

全书定稿完成，交付物应该包括：

1. **章节文件**：`chapters/01.md` ... `chapters/N.md`
2. **框架文档**：大纲、人物卡、世界观、钩子矩阵、伏笔矩阵、任务分解
3. **一致性四表**：道具链、时间锚、术语、关键数字（更新到定稿版本）
4. **Review 记录**：`reviews/round1.md` ... `reviews/roundN.md`
5. **宪法和 specify**：保持最新版本
6. **Git 历史**：清晰的 commit 链，能追溯每次改动

## 与姐妹 skill 的关系

- **输入来源**：`novel-chapter-sop` 产出的所有初稿章节 + 框架文档
- **调用对象**：`novel-consistency-guards` 做全书机械扫描和跨章一致性核对
- **不做什么**：
  - 不负责单章写作流程（那是 chapter-sop）
  - 不负责跨章一致性四表的维护逻辑（那是 consistency-guards）
  - 不负责改框架层的大决策（改设定要回 `novel-ideation`）

## 用法速查

| 场景 | 动作 |
|---|---|
| 启动收口 | 跑一遍全书机械扫描，记录现状 |
| 安排 review | 5 轮 + 最后一轮新实例，按视角分 |
| 处理 review 结果 | 分 P0/P1/P2，只改 P0/P1 |
| 改一个 P0 | 最小改动，最好 1 行 Edit |
| 改完一类问题 | commit（按问题性质，不按轮次） |
| 准备发布 | 过"发布前最终检查清单" |

## 收口阶段的时间占比

一本小说总工时的分布（经验值）：

- 构思（Phase 1）：5%
- 框架（Phase 2 框架）：10%
- 写作（Phase 2 写作）：50%
- **定稿（Phase 2 收口）：35%**

**定稿占 1/3 以上的工时**是正常的。想在 5% 时间定稿的，最后稿子都有明显 bug。收口这一步最值钱也最无聊——但它决定了读者愿不愿意读完。