# Novel QA

> 小说质量检测工具。对小说章节或整篇内容进行多维度一致性检查，输出带问题等级的缺陷清单，支持回归测试与问题追踪。检查维度包括人设一致性、时间线、对话呼应、伏笔闭环、空间布置（对照 novel-studio 的 spaces.md）等。支持 ke-novel-continuation、novel-studio 管理的项目及用户直接粘贴文本。触发句式：「检查一下第X章」「QA一下」「回归测试」「QA-003忽略」等。

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

---


# Novel QA（小说测试）

像互联网产品测试一样，对小说进行系统性质量检测。核心价值：**发现问题、分级记录、追踪闭环**。

## 1. 触发条件

- **首次检查**：「检查一下第 X 章」「帮我测试这篇小说」「QA 一下」「检查 ke-novel-continuation 卷二第 5 章」
- **回归测试**：「回归测试」「复核上次的问题」「回归一下」
- **问题管理**：「这个不是问题」「QA-003 忽略」「关闭 QA-005」

## 2. 检查维度（10 大维度）

| 维度 | 说明 |
|------|------|
| 人设一致性 | 性格、口头禅、行为习惯、年龄、外貌是否前后矛盾 |
| 时间线一致性 | 日期/时间顺序、事件先后、角色年龄与时间对应，角色籍贯/成长地与\"来/去某城市\"的表述是否自洽（如本地人与外地人的视角差异） |
| 情节逻辑 | 因果关系、动机合理性、行为逻辑（包括生活常识与空间逻辑，例如同住夫妻是否反复通过聊天软件沟通等），以及同一关键事件在不同章节多次出现时，细节描述是否前后一致，避免出现两套互相冲突的版本（如分手场景 A 和分手场景 B 讲成两种剧情）。**同一场景内空间逻辑自洽**：人物位置、房间布局、进出路线是否前后一致，避免"旁边有人睡"后又"走出隔壁房间"这类矛盾；场景切换是否清晰，读者能否判断人物在哪个空间。 |
| 对话合理性 | 说话方式是否符合人设、引用过往事件是否准确、对话能否前后呼应，是否有足够铺垫避免角色"忽然知情"式的突兀对话，以及是否存在明显违和的语境/社交语感（例如把日常消费说得像高奢待遇） |
| 伏笔闭环 | 已埋伏笔是否有回收，是否有悬而未决的线索 |
| 称呼/称谓一致性 | 角色之间的称呼方式是否前后统一 |
| 场景/环境一致性 | 地点描述、空间布局、天气/时间段是否矛盾；**对 novel-studio 项目须对照该项目的 spaces.md（空间布置）检查**——同一房间/学校/村庄/公司等在不同章节的描写是否与预设一致；日常场景是否符合常识（如校园作息、上下课节奏），城市内多景点串联时路线是否大体合理（避免明显来回折返） |
| 物品/道具一致性 | 关键物品的出现、转移、消失是否合理 |
| 情感逻辑 | 角色情绪反应是否符合其性格和当前情境 |
| 世界观/设定一致性 | 小说内在规则是否自洽（如游戏机制、时代背景） |
| 文风自然度 | 是否存在明显"AI 味"写法：机械罗列事件节点代替具体场景（如简单把分手、搬家、加班、空窗期串成一长串名词）、反复使用模板化句型，或在不同章节对同一情绪点反复复制几乎一模一样的句子/段落，而不是通过画面和细节来承载情绪。**跨章或跨段自我复制**：检查是否出现整句或整段在不同时段、不同章节里几乎原封不动重复（如同一组动作细节在第9章出现一次，又在第11章再完整说一遍），但只是在"重复证明同一个结论"而没有新增信息，这类应视为 AI 式复用，建议在后文只保留结论，不再重新展开细节。**过度使用破折号（——）进行解释说明**：中文写作中破折号用于解释、补充、话题转换等是正常的，但如果一篇小说中破折号密度过高（如平均每章超过5-6个），或大量使用"……是……——……"的固定句式来"解释前文"，则属于典型AI味——真实人类作者会用更自然的表达方式（如重新组织句子、用"也就是""换句话说"等过渡词、或直接用冒号/逗号/句号断开），而非反复依赖破折号来"标注"自己的意思。**同一意思反复表达**：同一个人物特征、情绪状态或情境描述，在短时间内（同一章或相邻章节）被反复提及，但每次表述几乎相同或高度相似，缺乏新的信息增量。典型表现：第六章多次说"她太干净了""她太安静了"；多章反复说某个角色"不懂这里的规则"；反复强调"她是因为没有选择才答应的"。真实人类作者会在首次描写后默认读者已知晓，后续提及时会用不同角度或细节深化，而非机械重复同一句话。**特定词汇/表达过度使用**：某个词汇或表达方式在全文或某章节内出现频率过高，呈现机械重复感。典型表现："罩着"一词出现十几次、同一句式"她不知道……"反复使用、"忽然觉得"作为心理描写触发词高频出现。真实人类作者会通过同义词替换、句式变换、或不同角度切入来避免词汇贫乏的观感。检查时可统计关键词出现次数，若单一表达超过5-6次且分布集中，应建议替换。**结构化输出问题**：AI写作时过度使用工整的排比结构、编号式表达或模板化句式，呈现出"列举清单"而非"讲故事"的感觉。典型表现：（1）"三连排比"——"有时候...有时候...有时候...""有人...有人...有人...""不再...不再...不再...""她不知道...她不知道...她不知道..."等同一句式重复三次以上；（2）刻意追求对称——"一个未知，一个被拉走，一个被安排"这类过度工整的短句；（3）逻辑过渡词滥用——"首先...其次...最后...""一方面...另一方面""一来...二来"等议论文式表达出现在小说叙述中。真实人类作者的排比通常服务于情感递进或节奏感，而非为了结构工整而工整。**场景切入方式单一重复**：同一篇小说中，多个场景/段落的开场方式高度雷同，缺乏变化。典型表现：（1）反复使用"时间状语+主句"结构——"有一天...""再后来...""那天...""第二天...""之后几天..."接连出现；（2）反复使用"当...的时候"句式——"周野找到林晓的时候""林晓终于发现的那天""阿浪回到宿舍的时候"；（3）反复使用"人物+地点+动作"三要素开场——"阿浪在宿舍里跟阿瓜聊天""林晓在校门口等阿浪""周野约林晓去书店"。真实人类作者会在不同场景使用不同的切入方式，如：感官切入（从声音、气味、光线开始）、动作直接切入（省略时间定位）、内心独白切入（从思绪开始）、对话跳入（直接从对话开始）、环境氛围切入（先写环境人物再入场）。检查时若发现同一章节内有3处以上相同结构的开场，应标记并建议多样化改写。 |

更详细的检查要点与示例见 [references/check-dimensions.md](references/check-dimensions.md)。

## 3. 问题等级定义

| 等级 | 标签 | 含义 | 示例 |
|------|------|------|------|
| 致命 | BLOCKER | 完全破坏故事逻辑，读者无法继续 | 已死角色无故出现；主线剧情自相矛盾 |
| 严重 | CRITICAL | 认真读者必然发现的重大不一致 | 人设崩塌；关键时间线错乱 |
| 一般 | MAJOR | 可感知但不破坏阅读的问题 | 次要角色细节前后不一；情感反应略显突兀 |
| 轻微 | MINOR | 瑕疵级别，不影响阅读体验 | 称呼偶尔不统一；环境描写小矛盾 |

## 4. 首次检查流程

1. **确定检查范围**：用户指定章节文件路径或直接粘贴文本
2. **加载参考设定**（项目模式）：
   - `ke-novel-continuation`：读取 `references/characters.md`、`timeline.md`、`outline.md`
   - `novel-studio`：读取对应小说项目的 `meta.md`、`characters.md`、`timeline.md`、`outline.md`、**`spaces.md`（空间布置；若不存在则用 `setting-layout.md`）**
   - 独立文本：跳过此步，仅基于文本内部逻辑检查
3. **逐维度检查**：按 10 大维度逐一审查，记录发现的问题
4. **输出缺陷清单**：按等级从高到低排列（BLOCKER → CRITICAL → MAJOR → MINOR）
5. **保存报告**：写入本 Skill 的 `reports/[项目名]-[日期].md`

## 5. 回归测试流程

1. 读取最近一次的 QA 报告（`reports/` 下对应项目的报告）
2. 对状态为 OPEN 的问题逐一复核：
   - 已修复 → 标记 `FIXED`
   - 未修复 → 保持 `OPEN`
   - 用户明确说不是问题 → 标记 `WONT_FIX`（仅用户明确声明后）
3. 检查修复过程中是否引入新问题
4. 更新报告文件

## 6. 问题追踪规则

- 每个问题有唯一编号（如 `QA-001`）
- 状态流转：`OPEN` → `FIXED` / `WONT_FIX`
- **除非用户明确说「这个不是问题」或「忽略」，否则每次回归都必须继续反馈 OPEN 状态的问题**
- `WONT_FIX` 的问题后续不再反馈

## 7. 报告输出模板

```markdown
# QA 报告：《小说名》第 X 章

**检查日期**：YYYY-MM-DD
**检查范围**：第 X 章 / 全文
**参考设定**：characters.md, timeline.md, outline.md, spaces.md（novel-studio 项目含空间布置；或「无」）

## 缺陷清单

### BLOCKER（致命）
| 编号 | 维度 | 问题描述 | 位置 | 状态 |
|------|------|----------|------|------|
| QA-001 | 时间线一致性 | 第5章写张三2003年大学毕业，但第8章变成2005年 | 第8章第3段 | OPEN |

### CRITICAL（严重）
（无则省略）

### MAJOR（一般）
（无则省略）

### MINOR（轻微）
（无则省略）

## 统计
- 致命：X 个
- 严重：X 个
- 一般：X 个
- 轻微：X 个
- 总计：X 个
```

## 8. 报告存放

所有 QA 报告存放在本 Skill 的 `reports/` 目录下，文件名格式：`[项目名]-[YYYYMMDD].md`。例如：`ke-novel-vol2-20260209.md`、`ganxiang-20260209.md`、`standalone-20260209.md`。

## 9. 与现有 Skill 的协作

本 Skill 只读取其他小说 Skill 的设定文件（`characters.md` 等），**不修改**它们。发现问题后由用户决定是否交给写作 Skill 修改。