Story Multi-Perspective Review

内置审查基准包（路径不可读时必用）

如果上述参考文件在当前项目中不可读，不要把审查降级为无 rubric，也不要在报告里说“无法加载具体 rubric”后停止使用标准。必须使用本节内置基准包，技术备注行的 Rubric 来源写 embedded。

通用网文内容 rubric：

• 核心卖点：本章是否围绕明确卖点推进；看不出卖点至少 S2。
• 冲突推进：本章是否有阻碍、选择、代价或关系变化；只解释/闲聊/总结至少 S2。
• 任务卡点：角色办事被卡住时，是否卡出信息、关系、代价、选择或伏笔变化；卡点只剩流程细节、删掉不影响故事至少 S3。
• 情绪曲线：是否有铺垫、升温、释放或反转；情绪平直或突兀至少 S2/S3。
• 钩子与期待：开头或结尾是否制造后续问题；没有悬念或未完成期待至少 S2。
• 开头新鲜度（仅开篇/前 3 章）：开局有具体人物/处境切口，还是同题材默认套路（能整体换到任意同类书）？"有钩子/非天气开场"不豁免同质化；套路化开局即使有钩子也至少 S3，整体撞同题材模板 S2。
• 角色动机：行为是否符合目标、性格、处境和关系压力；为剧情服务而失真是 S1/S2。
• 对话质量：是否有潜台词、信息控制、角色差异；说明书式对话至少 S2。
• 设定一致性：不违背已写规则、时间线、角色属性；明确事实冲突通常 S1。
• 文字自然度：具体、可感、动作承载信息；AI 腔、陈词滥调、总结体按影响定 S2/S3。
• 句长节奏：叙述默认是逗号长句（一句用逗号串起 2-4 件事再落句号）；碎句和电报体（逗号之间连着都是 ≤5 字、通篇超短句像提纲）与 AI 腔同级，按影响定 S3/S2，不因「短=网文节奏」放行。
• 标点节奏：标点是否服务语气/人物声线；通篇句号化、随机堆砌问号/感叹号，或残留 ……/—— 硬造停顿，按影响定 S3/S2。
• 具体字数表达校验：正文用“这五个字 / 短短四字 / 三个字一落 / 八个字砸下去”等具体字数表达评价台词、题字、信件、念头或弹幕时，必须能确认统计口径、机器核对结果和叙事必要；不能确保字数计算正确时，按文字自然度问题处理，建议改成“这句话一落”“那几个字”“话音落下”等非具体数字表达。
• 格式可读性：段落短、对话独立、无多余空行；格式阻碍阅读按 S3，严重混乱按 S2。
• 剧情循环：目标 → 阻碍 → 行动 → 代价/反馈 → 新期待；缺少目标/阻碍/反馈通常至少 S2。
• 高潮构建：蓄能 → 假胜 → 崩解 → 反转/兑现；高潮直接平铺、无代价或无兑现通常 S2/S3。
• 关系进展：互动尺度必须匹配当前关系阶段；越界亲密、突然信任、突然敌对都需要铺垫，否则按影响定 S1/S2。
• 伏笔状态：伏笔状态需可追踪；伏笔密度只作为结构风险提示，除非直接造成理解混乱，否则不升级到 S2+。

AI 味 / 禁用词 fallback 速查：

• 高频套话：命运的齿轮开始转动、心猛地一沉、眼神复杂、深刻变化、踏上新的旅程。
• 章末总结体：这一切都说明...、他终于明白...、新的篇章开始了...。
• 信息倾倒：角色直接说“我要解释世界观/规则/关系变化”。
• 论文体/万能结论：过度使用“然而、与此同时、不可否认、这意味着”。
• 处理原则：有原文证据才输出 finding；给出可执行替换方向，不只评价“AI 味重”。修法方向不默认「拆短 / 删虚词 / 剥标点」：把正常的逗号长句拆成碎句，与 AI 腔同样是问题。

平台 fallback 摘要：

• 番茄：强开局、强冲突、高频爽点/情绪反馈、低理解门槛。
• 起点：设定自洽、升级路径、长线期待、世界观承载力。
• 知乎盐言：短篇钩子、反转密度、情绪兑现、信息差推进。

Phase 1：收集待审查内容

1. 确定审查范围：
   • 用户指定了章节/文件 → 只审查指定内容。
   • 用户未指定 → 优先审查最近修改的正文文件（git diff --name-only 中的正文/设定/大纲相关文件），否则审查当前书的当前章节。
2. 范围传递策略：
   • 优先把文件路径、章节名、行号范围传给 reviewer，不要把整本或大量章节完整复制进每个 prompt。
   • 单文件或短片段可附 300-1200 字关键摘录。
   • 多章/整卷/整本审查必须分批：按章节或文件组拆分，每批输出独立 findings，再综合；分批前先完整读 references/batch-review.md（跨批状态、连续性、乱序提醒）。
3. 读取相关支撑材料：正文、相关设定、角色档案、大纲、追踪/上下文、伏笔文件；缺失时在报告中标记证据不足。
4. 识别目标平台并加载 rubric：
   • 优先使用用户显式指定的平台。
   • 其次读取项目文档里的 目标平台 / 平台 字段，例如 设定/题材定位.md、大纲/、拆文报告 等。
   • 不要把 .active-book 当作平台来源；它只能辅助定位当前书名目录。
   • 番茄小说 → 优先读取 story-review/references/rubrics/fanqie.md；不可读时使用内置番茄 fallback 摘要。
   • 起点 → 优先读取 story-review/references/rubrics/qidian.md；不可读时使用内置起点 fallback 摘要。
   • 知乎盐言 → 优先读取 story-review/references/rubrics/zhihu.md；不可读时使用内置知乎 fallback 摘要。
   • 未识别平台 → 优先读取 story-review/references/quality-rubric.md；不可读时使用内置通用网文内容 rubric；技术备注行写 generic 与 file | embedded。
5. 形成审查基准包摘要：把已加载的文件内容或内置 fallback 摘要压缩为 5-12 条审查标准，后续 solo 和子 Agent 都必须使用这份摘要。摘要必须保留一条句长标准：叙述默认是逗号长句，碎句和电报体与 AI 腔同级处理，不因「短」放行。
6. 确定性预检（只报告，不修改）：当审查范围包含本地正文文件路径时，运行本 skill 自带脚本：

   node scripts/normalize-punctuation.js --check <正文文件...>
   node scripts/check-ai-patterns.js --check --fail-on=blocking <正文文件...>
   node scripts/check-degeneration.js --check <正文文件...>

   • 将 ellipsis、double-hyphen、markdown-divider 结果作为 format findings 合并进报告。em-dash 破折号只采用 check-ai-patterns.js 的语义改写建议（见下条）；normalize-punctuation.js 报的同一位置 em-dash 在合并时去重丢弃，避免同处出现「机械替换」与「按功能改写」两条相互冲突的 finding。另外人工检查标点节奏是否通篇句号化或随机堆砌，脚本不替代语气判断。
   • check-ai-patterns.js 的 findings 合并进 prose：severity=blocking 的类别一律按 S2（当前为 not-is-comparison / em-dash / voice-contrast / negation-parade / reverse-not-is / trailer-ending / trailer-summary），修法直接采用检测器输出的建议（删否定铺垫/反差腔/排比否定/章尾预告腔/章尾状态总结句，直接写后项或具体动作；破折号按功能改成动作/短句/逗号/冒号）。
   • 其余 prose findings（advisory）统一按 S3：只指出读感风险，不替代人工判断；功能性写法标 [需复核] 并保留。完整类别和修法见 anti-ai-writing.md。
   • check-degeneration.js 报告模型退化（逐字复读/截断/占位符/工程词泄漏），每条带 severity: blocking|advisory：blocking（复读/截断/tier1 工程词）作为 S1/S2 prose findings，修复建议是「重新生成该段，不是改写」；advisory（tier2 章节/歧义词）作为 S3。
   • 这三个预检脚本只读；story-review 不修改正文、设定或大纲文件，需要自动修复正文时建议转 /story-deslop。full / lean 模式只有下方「追踪文件维护」允许修改 追踪/；分批审查的所有模式都可按 batch-review.md 写 .story-review/state.md，solo 除该状态外不写项目内容。
   • 默认 --quote-mode keep，不把知乎盐言短篇的 「」 当作问题；只有项目明确指定引号风格时才检查对应转换建议。

统一 Findings Schema（所有模式必须使用）

所有 reviewer（包括 solo）输出问题时必须使用统一结构，方便综合排序；它只在 reviewer 与综合裁决之间流转，给作者的报告按 Phase 4 或 solo 模板转写。location 必须使用工具读取结果显示的原始文件行号；不要删除空行后重新编号。

对 consistency / factual / causal / rule_boundary 类 finding，fix 字段只写事实统一方向（例如“统一为左臂旧伤，并同步正文/设定中冲突处”或“需在 A/B 时间线中裁定一个来源”），不要写文学创作建议。

- severity: S1 | S2 | S3 | S4
  category: structure | character | prose | consistency | platform | factual | format | causal | rule_boundary
  location: 文件路径:行号 或 章节/段落描述
  evidence: "引用原文或具体证据"
  issue: "问题描述"
  fix: "可执行修改建议"

严重度定义（与长篇写作、检测器同一刻度：S1/S2＝必须修，S3＝建议看，S4＝仅提示）：

• S1：会破坏主线、角色动机、世界规则或读者信任，需优先修。
• S2：明显影响章节效果、留存、节奏、人物可信度，本轮要修。
• S3：局部质量问题，如措辞、轻微格式、局部节奏，可排期修。
• S4：建议项或风格微调，不阻塞发布。

Phase 2：并行 Spawn Agent（full/lean 模式）

执行 Phase 0 后实际模式仍是 full/lean 时，读 references/agent-prompts.md 按其中的调用规则与四个 prompt 并行 spawn，综合裁决与报告模板也在其中；不 spawn 缺失的 Agent。每个 Agent 不继承父对话上下文，prompt 自包含路径、范围与统一 Findings Schema。

Phase 3：综合裁决（full / lean 模式）

收齐 reviewer 结果后按 agent-prompts.md「综合裁决」合并、去重、呈现分歧。

Phase 4：输出报告（full / lean 模式）

实际模式确为 full/lean 时用 agent-prompts.md 的报告模板；降级 solo 时改用 solo.md 模板。

solo 模式

降级或指定 solo 时读 references/solo.md，按其中流程与输出格式执行。

追踪文件维护

长篇工程且 full/lean 审查收尾时读 references/review-tracking.md。

流程衔接

流水线： 通用 位置： 审查（写作之后）

语言

• 跟随用户的语言回复，用户用什么语言就用什么语言回复。
• 中文回复遵循《中文文案排版指北》。