菜单
小说质量检测工具。对小说章节或整篇内容进行多维度一致性检查，输出带问题等级的缺陷清单，支持回归测试与问题追踪。检查维度包括人设一致性、时间线、对话呼应、伏笔闭环、空间布置（对照 novel-studio 的 spaces.md）等。支持 ke-novel-continuation、novel-studio 管理的项目及用户直接粘贴文本。触发句式：「检查一下第X章」「QA一下」「回归测试」「QA-003忽略」等。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
维护可配置 Markdown 知识库（sources_dir→wiki→output）：源材料抽取预处理、定向归集、摄入编译、主题命名、知识点五段结构、源材料总结、写盘前 wiki 查重（A/B/C）、Q&A、编译/健康报告、索引与维护日志；也支持第二大脑核心页、自我模型、表达风格、使用反馈回写、多模态资料入库、对象型页面编译、人物事实与我的判断分离、项目当前结论、已废弃观点管理；支持半自动书本镜像/方法论镜像。在用户提到初始化/编译 wiki、人物/项目档案、对象页、多模态资料、先总结再入库、查重、归集知识点、问知识库、书本镜像、方法论镜像、按我的方法论输出、Obsidian 式互链或 AGENTS 契约驱动的工作流时使用；完整触发词与模板见 references/reference.md。
产品规划总控 skill。用于做产品规划、从需求调研到功能清单再到开发/原型规划的轻量编排；根据用户目标决定调用 product-requirements-researcher、project-feature-list-generator、project-development-planner 等产品规划相关 skill。统一要求产物保存到当前项目的“项目管理”目录，不单独创建 projects 工作目录；不做调研统计文档，只在必要时保存调用报告和功能清单。Use when the user wants lightweight product planning orchestration, deciding which planning skills to use, coordinating requirement research, feature lists, prototypes, PRD, or development planning.
通过深度、迭代式访谈收集软件需求并生成正式调研报告。Use when the user wants 需求调研、需求访谈、澄清需求、产品规划、写 PRD、设计产品、需求分析、生成调研报告；也用于 AI 开发前的 0-1 项目/产品/模块建设启动，当用户只给出模糊想法而要求开始开发时，先用 AskUserQuestion 访谈澄清，判断是 AI 直接开发还是实地调研考察，再形成足以转化为功能的需求调研报告。
辅助编程与原型规划 skill。读取 product-requirements-researcher 的需求调研报告和 project-feature-list-generator 的功能清单，规划开发内容、推荐并确认技术框架、把功能清单做成可视化页面；当用户要求做原型时，聚焦前端界面、交互和设计，不强调真实数据、后端和接口实现。Use when the user wants development planning, coding preparation, feature visualization, prototype creation, or turning feature lists into an implementation plan.
根据调研报告、对话上下文、解决方案或原有功能清单进行需求功能化，生成能指导开发的项目功能清单。适用于 product-requirements-researcher 完成需求挖掘后，把需求转成功能点，并补充为支撑业务闭环所需的系统功能。先生成 MD 供确认，确认后导出为 XLSX。Use when the user wants to convert requirements into development-ready feature points from research reports, current context, solution documents, or existing feature lists.
生成中文历史类短文的 Skill。当用户提任何与历史相关的问题、话题或需求时使用，包括但不限于：帮我生成一篇关于XX的历史类内容、写一段关于XX的历史背景介绍、生成一篇历史故事、问XX是怎么回事、问某个历史人物/事件/制度的情况、问某段历史的来龙去脉等。输出300-600字的大白话历史短文，语言自然平实客观，可用少量生动比喻但不堆砌，减少结构化输出、夸张词汇、引号和破折号，内容需符合主流史学共识。当用户说 学习history-writer的新作品、更新history-writer Skill、帮我优化历史类内容的写法 时，触发学习流程，读取samples文件夹里的作品并更新本Skill。
| name | novel-qa |
| description | 小说质量检测工具。对小说章节或整篇内容进行多维度一致性检查，输出带问题等级的缺陷清单，支持回归测试与问题追踪。检查维度包括人设一致性、时间线、对话呼应、伏笔闭环、空间布置（对照 novel-studio 的 spaces.md）等。支持 ke-novel-continuation、novel-studio 管理的项目及用户直接粘贴文本。触发句式：「检查一下第X章」「QA一下」「回归测试」「QA-003忽略」等。 |
像互联网产品测试一样，对小说进行系统性质量检测。核心价值：发现问题、分级记录、追踪闭环。
| 维度 | 说明 |
|---|---|
| 人设一致性 | 性格、口头禅、行为习惯、年龄、外貌是否前后矛盾 |
| 时间线一致性 | 日期/时间顺序、事件先后、角色年龄与时间对应，角色籍贯/成长地与"来/去某城市"的表述是否自洽（如本地人与外地人的视角差异） |
| 情节逻辑 | 因果关系、动机合理性、行为逻辑（包括生活常识与空间逻辑，例如同住夫妻是否反复通过聊天软件沟通等），以及同一关键事件在不同章节多次出现时，细节描述是否前后一致，避免出现两套互相冲突的版本（如分手场景 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。
| 等级 | 标签 | 含义 | 示例 |
|---|---|---|---|
| 致命 | BLOCKER | 完全破坏故事逻辑，读者无法继续 | 已死角色无故出现；主线剧情自相矛盾 |
| 严重 | CRITICAL | 认真读者必然发现的重大不一致 | 人设崩塌；关键时间线错乱 |
| 一般 | MAJOR | 可感知但不破坏阅读的问题 | 次要角色细节前后不一；情感反应略显突兀 |
| 轻微 | MINOR | 瑕疵级别，不影响阅读体验 | 称呼偶尔不统一；环境描写小矛盾 |
ke-novel-continuation：读取 references/characters.md、timeline.md、outline.mdnovel-studio：读取对应小说项目的 meta.md、characters.md、timeline.md、outline.md、spaces.md（空间布置；若不存在则用 setting-layout.md）reports/[项目名]-[日期].mdreports/ 下对应项目的报告）FIXEDOPENWONT_FIX（仅用户明确声明后）QA-001）OPEN → FIXED / WONT_FIXWONT_FIX 的问题后续不再反馈# 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 个
所有 QA 报告存放在本 Skill 的 reports/ 目录下，文件名格式：[项目名]-[YYYYMMDD].md。例如：ke-novel-vol2-20260209.md、ganxiang-20260209.md、standalone-20260209.md。
本 Skill 只读取其他小说 Skill 的设定文件（characters.md 等），不修改它们。发现问题后由用户决定是否交给写作 Skill 修改。