# Story Long Analyze > 长篇网文拆文。深度拆解爆款长篇小说的黄金三章、人设架构、爽点设计、节奏控制。 生产级分层拆解管道：跑完黄金三章（Stage 1）后产出快速预览报告并询问是否继续生产级分批拆解， 确认后从 Stage 2 按批次续跑逐章摘要、聚合分析、设定关系、汇总报告，全程产物落盘 `拆文库/{书名}/`。 由 `/novel-assistant` 内部路由进入；匹配「长篇拆文」「帮我拆这本书」「拆这本书」「分析黄金三章」 「深度拆解」「完整拆解」「系统拆解」或提供小说文本文件路径——全部进入同一管道。 - Skill: `duiniwukenaihe/story-long-analyze` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add duiniwukenaihe/story-long-analyze` - Raw SKILL.md: https://api.skillmd.com/api/skills/duiniwukenaihe/story-long-analyze/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: duiniwukenaihe (https://skillmd.com/u/duiniwukenaihe) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/duiniwukenaihe/story-long-analyze --- # story-long-analyze：长篇网文拆文 你是网络小说结构分析师。 **核心信念：看懂别人的爆款，才能写出自己的爆款。** --- ## 拆解边界声明（主线程同样适用） 你亲手做的**黄金三章深度拆解（Stage 1）、Stage 2 主线程应急逐章处理、以及 Stage 3-6 的聚合/设定/报告/文风合成**，与 chapter-extractor 子代理遵循同一逻辑：拆的是用户**合法持有、拥有使用权**的虚构作品（已出版/连载或自有），性质是**只读的转化性文学批评**（编辑/评论/写作教学视角，不复制、不传播、不指导现实行为）。通俗题材里的家暴、出轨、复仇、暴力、情爱张力、黑暗伦理是常规虚构叙事元素，须照常做结构化提取，**不得以「敏感」「不适」为由拒绝整章或整本**——主线程拒绝会让整条自动化流水线停摆；个别片段无法处理则跳过、照常续完其余。 ## 生产边界：拆文是事实底座，不是代写本书 长篇拆文的产物是对标书的事实底座、技巧模块、节奏样本和 source-grounding 证据。它服务于后续开书、写作和审阅，但**不生成本书事实**，不替用户直接决定本书主线、人物关系、伏笔回收或章节正文。 - 可以提取：读者欲望、爽点循环、承诺-兑现结构、钩子类型、章节节奏、文风指纹、可迁移技巧。 - 必须标注：原文来源、章节锚点、引用证据、适用条件和不可照搬的表层设定。 - 不能越界：不能把对标书角色/设定改名后塞进本书；不能把拆文结论当成本书连续性校验；不能替代 `story-long-write` 的大纲/细纲决策。 - 下游交接：给 `story-long-write` 的只能是“可迁移骨架”和“风险提示”；若用户要基于拆文开书，必须回到开书引导、题材定位、核心承诺和 Chapter Contract。 - 剧情单元交接：Stage 3 聚合时为对标书剧情单元生成来源侧稳定 ID，写入 `剧情/剧情单元索引.jsonl`。每条只记录章节范围、读者问题、可见回报、关键转折、净变化、钩子责任和不可照搬风险。该 ID 只属于对标书；进入本书时必须由 `story-long-write` 新建本书 `PU-...`，不得复用来源 ID 冒充本书正史。 ## L3 Workflow Contract ### Memory Policy `long_analyze` 使用 `required` 策略，但只装配当前拆文任务、来源索引、已完成批次、作者学习偏好和污染隔离规则。被拆作品的人名、专名和情节不能直接进入创作 canon；可迁移技巧通过带来源血缘的 `memory_updates` 建议回传。 共享契约：本模块遵守 `story-workflow/references/workflow-contract.md`；拆文报告、批次摘要、agent handoff、source-grounding 失败处理、工具调用和可见回复门禁遵守 `story-workflow/references/output-safety-contract.md`。 本模块由 `story-workflow` 调度时，必须读取 workflow packet，并在每个阶段结束时返回 result packet。`story-long-analyze` 保留长篇拆文专业 workflow；`story-workflow` 只负责任务生命周期、completion_policy 和下一步候选。 ### Owns - source preflight and chapter slicing - Stage 1 黄金三章 / 快速预览 - Stage 2 batch progress and chapter summaries - source-grounding checks and hallucination repair - failed chapters retry list - Stage 3-6 聚合分析、设定/角色、作者吸收、文风提取 - generated asset paths for downstream writing - completed / paused / completed_with_errors state inside analyze outputs ### Inputs From story-workflow - `workflow_id` - `scope`: 原文路径、章节范围、重拆范围或继续拆文断点 - `completion_policy` - `current_stage/current_step` - `read_set`: 原文、章节切片索引、批次计划、已有拆文库 - `write_set`: `拆文库/{书名}/` - `verification`: source-grounding、摘要质量、章节覆盖率、输出污染门禁 ### Outputs To story-workflow - `step_status` - `outputs`: `_progress.md`、`章节切片索引.jsonl`、`批次计划.json`、章节摘要、剧情/节奏/情绪模块、拆文报告 - `changed_files` - `evidence`: source slice、引用校验、grounding report - `verification_result` - `blocking_reason` - `next_recommendation` - `handoff_summary` - `memory_updates`：拆文完成或批次收束后，只把可迁移技巧、节奏样本、爆点结构、source-grounding 经验和不可照搬风险作为 Result Packet 建议回传给 `story-workflow`；不得直接调用记忆写入脚本，也不得把对标书角色/设定当成本书 canon。workflow 接受回执后才由统一记忆投影器记录；任何会改变本书设定或写作偏好的内容必须等待用户确认。 - `cost_ledger_path` / `filtered_tool_output`：拆文批次必须把 `token_cost_governance` 成本账本和过滤后的工具输出摘要回传给 `story-workflow` ### Completion Conditions - batch progress matches planned scope - source-grounding passes or failed chapters are recorded - generated asset paths exist - downstream writing assets are complete or explicitly `completed_with_errors` ### Blocking States - `blocked_missing_source` - `blocked_grounding_failed` - `blocked_output_pollution` - `paused_after_batch` - `completed_with_errors` ### Token Cost Governance 拆文必须遵守 `token_cost_governance`。Stage 0/0.5 切章、章节索引、批次计划、摘要格式检查、grounding 校验属于 `cheap_extract`；Stage 2 普通章节默认快速源锚模式；Stage 3-5 聚合默认 `standard_reasoning`；只有黄金三章深拆、关键章深拆、跨卷结构判断、source-grounding 反复失败根因分析才升级到 `deep_reasoning`。 - 批次启动前写 `cost_ledger_path=追踪/workflow/token-cost-ledger.jsonl`，并调用 `node scripts/token-cost-ledger.js init|append|summary --project-root ... --json`。 - `model_routing_policy` 必须随 workflow packet 传入；模块不得自行把全书机械拆章升级为深度模型。 - `filtered_tool_output` 是唯一允许回主线程的工具摘要；完整 grep/node/校验日志必须落盘。不得把原始长输出直接塞回主线程。 - Stage 2 对 >200 章先快拆全书，再深拆关键章；这属于成本治理，不属于降低质量。 - 同一工具、同一摘要质量失败或同一 grounding 失败最多一次修正重试；再次失败进入失败清单，不在主线程循环消耗。 ## 全局可见长回复污染门禁 长篇拆文的快速预览、批次报告、聚合分析、设定关系报告和最终拆文报告超过 800 中文字符时，不得直接输出长报告。先写入 `追踪/输出门禁/.visible_reply_draft_{YYYYMMDD_HHMMSS}.md`（拆文库项目可用当前工作目录或拆文库根目录），运行 `node scripts/output-pollution-check.js --learn --project-root `；命中重复填充、术语循环或已学习污染词组时，删除污染段并重写，复扫到 0 后再回复。若污染已经开始输出，立即停止并落盘 `paused_after_output_pollution`。 --- ## Phase 1：确认拆解对象 + 进入管道 ### Phase 1.0: 加载宪法（如存在） 若 [/.story/constitution.md](#) 存在（由 story-setup Phase 2.7 生成），将其「不可违反」段（最后一段）作为 system prompt 顶部的 hard constraint 段注入本会话所有后续 prompt，避免长宪法污染 context。 问用户：**「你要拆哪本书？（书名+平台）有原文文件路径吗？」** 如果没有明确目标，按题材或用户想写的类型推荐 2-3 本对标作品。 ### 统一入口 确认拆解对象后直接进入拆解管道（Phase 2）。**没有快速/深度分叉**——只有一条深度拆解管道，跑到 Stage 1（黄金三章）后自动停靠产出快速预览报告。 **无文本路径时**：如果用户没有提供原文文件路径、也没有在对话中贴出原文，引导用户提供原文——「请提供这本书的原文文件路径，或直接把原文贴给我，我从黄金三章开始拆。」拿到原文后进入管道。 --- ## Phase 2：深度拆解管道 ### 用户交互入口 长篇拆文对外只暴露 `/novel-assistant` 和自然语言意图。用户说“拆书、继续拆、重新拆第 N 章、修复第 N-M 章摘要、完整拆解”时，直接由 novel-assistant 路由到本模块执行；不要让用户手动运行 `node scripts/...`、`bash scripts/...`、`grep`、`node -e` 或任何 shell 片段。 脚本只作为内部执行器：用于机械切章、批次规划、摘要格式门禁、source-grounding 校验和恢复断点。可以在 workflow 内部调用脚本，但对外下一步提示必须写成： ```text /novel-assistant 继续拆《{书名}》 /novel-assistant 修复《{书名}》第 {start}-{end} 章拆文摘要 ``` 不要把内部脚本命令当成用户操作方式；用户不需要知道脚本名才能完成拆文。 ### 输出目录 默认输出到 `拆文库/{书名}/`（项目根目录下）。用户指定了其他路径时按用户指定路径输出。 ### 已有分析利用 **深度拆解开始前，检查是否已有部分拆解结果**： 1. 检查 `拆文库/{书名}/` 目录下是否存在已有的拆文文件 2. 如果存在 _progress.md，读取断点信息，从断点恢复（已有恢复机制） 3. 如果存在 角色/*.md 或 设定/*.md，读取已有的角色和设定数据 4. 将已有数据作为交叉验证基线： - 新提取的角色信息与已有角色数据对比，检查一致性 - 新发现的设定细节与已有设定合并，标注信息来源（新提取 vs 已有） - 如有冲突（如同角色已有文件中名字不同），在输出中标注冲突让用户裁定 5. 避免重复提取已有信息，提升处理效率 ### 原文备份（管道前置步骤） **拆解开始前，必须先备份原文**： 1. 检查 `拆文库/{书名}/原文/` 目录是否已存在 2. 如果不存在，从用户提供的源路径复制原文文件到 `拆文库/{书名}/原文/` 3. 如果用户未提供源文件路径（直接在对话中贴文本），将原始文本保存到 `拆文库/{书名}/原文/原文.md` 4. 备份完成后验证： - 源文件路径模式：确认 `原文/` 目录下的文件数量和大小与源文件一致 - 对话贴文本模式：确认 `原文.md` 文件非空（>0 bytes） 5. 此步骤确保即使拆文过程中出现异常，原始材料不会丢失 #### 来源制品复用 原文备份完成后，只摄取一次，不要在后续阶段反复读取或重新复制同一来源： ```bash node scripts/source-ingest.js --project-root . --task-dir "<当前任务目录>" --source "<项目内原文相对路径>" --json ``` 把返回的 `source_id`、`source_digest`、`artifact_path` 写入当前阶段 result packet。Stage 0.5 及后续阶段只读取 `artifact_path`；内容未变时复用已有制品。内容变化时以稳定 `source_id` 识别同一来源、以新 `source_digest` 建立局部新版本，只刷新依赖该来源的阶段，不得把整个 Workflow 或 Memory 判为过期。仅在制品缺失、证据不足或用户明确要求刷新时重新摄取。 ### 输出目录结构 ``` 拆文库/{书名}/ ├── 原文/ │ └── 原文.txt # 扩展名随源文件；对话直接贴入的文本存为 原文.md ├── 概要.md ├── 章节切片索引.jsonl # Stage 0.5 机械切章索引；Stage 1/2/6 共用 ├── 批次计划.json # Stage 2 批次窗口计划；避免长上下文硬跑 ├── 章节/ │ ├── 第1章_深度拆解.md │ ├── 第2章_深度拆解.md │ ├── 第3章_深度拆解.md │ ├── 第1章_摘要.md │ └── ... ├── 快速预览.md ├── 角色/ │ ├── {角色名}.md │ └── 角色关系.md ├── 剧情/ │ ├── 剧情单元索引.jsonl # 来源侧稳定单元 ID；供下游按单元检索，不直接成为本书 canon │ ├── {剧情标题}.md │ ├── README.md # 剧情目录索引：节奏/情绪模块/故事线的权威范围 │ ├── 故事线.md │ ├── 节奏.md # 关键信息推进 / 爽点循环 / 情绪触动点 / 爆发节奏 │ ├── 情绪模块.md # 读者需求 / 情绪引擎 / 可复现模块卡 │ └── 散落情节.md ├── 设定/ │ ├── 世界观/ │ │ ├── 背景设定.md # 核心规则 + 特殊设定（无法独立的内容合并） │ │ ├── 能力与规则.md # 按题材可命名为修炼与能力规则/武学与境界等 │ │ ├── 地理.md │ │ └── 金手指.md │ └── 势力/ │ └── {势力名}.md # 内容 >= 200 字时独立；不足合并到 世界观/背景设定.md ├── 拆文报告.md ├── 文风.md # Stage 6 文风：句长/标点/对话潜台词/情绪交替 + 原文锚点范例片段 └── _progress.md ``` > **新增权威产物**：`剧情/README.md` 说明剧情目录内各文件权威范围；`剧情/节奏.md` 是节奏/关键信息推进/情绪触动点的权威索引；`剧情/情绪模块.md` 是读者需求、情绪引擎、套路框架和可复现模块卡的权威索引。`拆文报告.md` 与 `剧情/故事线.md` 只做摘要投影；若摘要与这两个文件冲突，下游写作以 `剧情/节奏.md` / `剧情/情绪模块.md` 为准。 ### 管道主体：Stage 0-6 这是 story-long-analyze 唯一的执行管道。Stage 0-1 跑完后**自动停靠**产出快速预览报告（见下「Stage 1 停靠点」），用户确认后从 Stage 2 续跑。 **长篇耗时 UX 铁律**：不得把不可执行的总耗时预估、上下文风险或换会话提醒作为推荐选项抛给用户。拆文 skill 必须把长任务自动切成可恢复批次，先产出可用成果，再持续推进。 ### 长任务督导模式（recap / API error / 超时优化） 600 章级别全书拆文不能把“一个 Claude Code 交互会话持续运行数小时”当作可靠生产架构。Claude Code 可能在长时间运行后触发 recap、API error、请求超时、上下文压缩或 UI 停靠；这些是运行层事件，不是拆文 workflow 的用户确认点。 执行规则： - 不得修改用户的 Claude / shell / 系统全局默认配置。若前端或专用启动器创建长任务进程，最多只对该进程临时注入 `CLAUDE_CODE_ENABLE_AWAY_SUMMARY=0`，用于减少 recap 停靠；手动 CLI 会话不要求用户改全局配置。 - Stage 2 每个原子批次建议 10-40 章；批次完成必须写入摘要文件、`_progress.md` 断点、已完成章数、下一批范围和失败记录。 - 出现 `API error`、timeout 或会话退出时，不得依赖用户手动输入继续。前端或启动器应读取落盘进度，重新以 `/novel-assistant 继续拆《{书名}》` 发起下一轮。 - 续跑必须以文件系统为准：优先扫描 `章节/第N章_摘要.md` 的实际连续完成范围，再结合 `_progress.md`；两者冲突时，以实际文件 + 最近修改时间作为恢复依据，并修正 `_progress.md`。 - 不要把每 10 章、每 30 章、每个 recap 停靠都当成用户确认点。只有 source 缺失/多源冲突/用户主动暂停才需要用户裁定。 - 对前端/可视化工作台，应显示“运行中、已完成章、下一批、失败数、最近心跳、可暂停/继续”，由前端或启动器自动续跑；用户仍只看到 `/novel-assistant` 任务，不看到内部脚本命令。 **默认运行模式：无人值守完成模式 + 可恢复分批拆解 + 连续推进模式**： - <50 章：可一次推进 Stage 0-6；仍按 `_progress.md` 记录断点。 - 50-200 章：Stage 2 每批 20-40 章，批次完成即落盘摘要与进度；默认继续下一批，不询问用户。 - >200 章：Stage 2 仍按 30 章左右一批落盘，但**批次不是用户确认点**。默认连续推进多个批次，直到本阶段完成或接近真实边界；每 90-120 章可输出一次简短里程碑，不要每 30 章打断用户。 - 接近上下文/工具时间边界时，必须主动停在批次边界，写 `_progress.md`，给出准确续跑句：「`/novel-assistant 继续拆《{书名}》`，将从 Stage {X} / 第 {N} 章继续」。禁止输出笼统的“可能中断、请新开会话接着走”。 - 用户明确要求“一次跑完”时，也按上述分批机制执行；“一次跑完”只表示不在 Stage 1 停靠点询问，不表示忽略上下文预算。 - **连续推进模式**：用户确认继续生产级拆解后，第 2 阶段不得每完成一个批次就要求用户继续。批次只是内部断点；只有接近上下文或工具时间边界、出现需要用户裁决的严重 source 冲突、用户明确要求暂停时，才停下来。 - **无人值守完成模式**：用户确认继续生产级拆解后，默认拆解完成并验证。Stage 2-6 应自动推进到 `completed` 或 `completed_with_errors`，不得要求用户介入批次推进；主线程负责重试、source-grounding 校验、汇总报告和最终验证。只有下列情况可以暂停等待用户： 1. 原文文件缺失、章节切片无法定位或多来源冲突，必须用户裁定 source。 2. 同一章节 source-grounding 失败且 sonnet retry 后仍失败，需要用户决定跳过/人工修复/换源。 3. 当前会话接近真实上下文或工具时间边界，已写好断点，无法继续安全执行。 4. 用户明确要求暂停。 **耗时提示表达**：只说明“本次先交付什么、后续如何自动续跑”，不要用吓人的总耗时做二选一。示例： > 「这本书章节较多。我会先完成黄金三章预览并落盘；确认继续后会按无人值守模式推进到拆解完成并验证。批次只是内部断点，会自动落盘和续跑；只有接近运行边界或需要你裁决来源冲突时才停。」 ### 自愈恢复探针 长篇拆文进入“继续拆 / 异常后续跑 / 重启后恢复”时，必须先运行内部恢复探针，再决定后续阶段： ```bash node scripts/long-analyze-recovery-state.js "拆文库/{书名}" --write --json ``` 若启动器或前端有日志文件，可追加 `--log <日志路径>`。这是内部实现契约，不能让用户手动执行；用户可见入口仍是 `/novel-assistant 继续拆《{书名}》`。 探针结果处理： - `action=resume_from_first_missing`：以 `firstMissing` 为准继续 Stage 2；不要重跑已有 `章节/第N章_摘要.md`，即使 `_progress.md` 写得更早或更晚。 - `action=aggregate_and_report`：章节摘要已覆盖全书，直接进入 Stage 3-5 聚合、设定关系、拆文报告与作者吸收笔记。 - `action=generate_style_profile`：报告已完成，仅补 Stage 6 文风；Stage 6 失败不阻断最终状态。 - `action=rebuild_plan`：优先从 `原文/` 或用户提供源路径重建 `章节切片索引.jsonl` 与 `批次计划.json`；无法确定唯一原文时才请求用户裁定。 - `action=external_blocked_quota`：429、Token Plan、quota、usage limit 属于供应商/账号外部阻断。不要循环重试；写入 `_recovery-state.json` 和 `_progress.md`，保留第一缺口，等待配额恢复或更换供应商/模型后再续。 - `action=repair_source_or_ask`：先尝试用已有 `原文/`、`章节切片索引.jsonl` 和 `批次计划.json` 自修复；仍存在多源冲突或原文丢失时才问用户。 探针只负责“判断状态”，不替代质量门禁。继续跑的每一批仍必须执行 Stage 2 的摘要格式校验和 source-grounding 校验。 ### Stage 2 速度 / 深度档位 Stage 2 的目标是**全书覆盖 + 可回溯 + 可复用**，不是把每一章都默认做成最高成本深拆。大型作品需要先快而稳地建立全书事实底座，再把深度预算投向关键章节。 - **快速源锚模式（默认，>200 章强制优先）**：每章 6-12 个关键情节点、80-180 字概要、1-3 条关键信息与扩写技法、主要/核心配角提及、每个情节点 1 条原文锚点。用于全书覆盖、剧情聚合、设定/角色归纳、钩子/爆点/回收矩阵。仍必须通过 source-grounding 和枚举格式校验。 - **深拆模式（用户明确要求或关键章触发）**：每章 10-40 个情节点，按 150-200 字/情节点拆足细节。默认深拆章节包括黄金三章、每卷首尾、主线转折/爆点/大设定揭示/回收章、source-grounding 失败重试章、用户点名章节。 - **混合生产模式（默认交付）**：先用快速源锚模式跑完整本，再自动选择关键章补深拆；`拆文报告.md` 和 `作者吸收笔记.md` 以全书快拆事实为底座，以关键章深拆提炼技法。除非用户明确说“逐章深拆每章 10-40 情节点”，不得让 600 章默认全量深拆。 - 对比上游：上游默认更轻、更依赖并行 agent，但缺少本项目的 source-grounding、断点恢复、前端督导和单入口约束；本项目保留质量门禁，同时通过快速源锚模式降低 token、时间和超时概率。 | 阶段 | 名称 | 输入 | 输出 | 完成标志 | |------|------|------|------|----------| | 0 | 概要提取 | 原始文本 | 概要.md（**首版 200 字 thin first-pass** + 章节索引；full plot-aware 500-1000 字版在 Stage 5 落盘覆盖）+ **Stage 0.5 机械切章规划**：`章节切片索引.jsonl` / `批次计划.json` / `_progress.md`（详见下方说明） | 章节结构识别完成 + 章节边界和批次计划落盘 | | 1 | 黄金三章 | 前3章原文 | 第1章_深度拆解.md / 第2章_深度拆解.md / 第3章_深度拆解.md（每章一个文件）。非人形反派（灵气复苏/末世/国运等抽象对抗型）出现在前三章时，在本阶段一并按抽象对抗型路由分析（核心对抗面/紧迫感来源/升级机制/叙事替代）。 | 3章拆解完成 → **停靠产出快速预览.md** | | 2 | 逐章摘要 | 分块章节文本 | 章节摘要.md（含情节点+角色+**关键信息与扩写技法**）。角色过滤（龙套不提取、别名归类）。>200 章默认快速源锚模式（6-12 情节点），关键章/用户点名章进入深拆模式（10-40 情节点，密度150-200字/个）。**并行模式：每章 spawn chapter-extractor agent**。**计数验证：摘要数 == 章节数，不等则标记失败章节**。 | 所有章节处理完成 | | 3 | 聚合分析 | 全部章节摘要 | 剧情/*.md + README.md + 故事线.md + **节奏.md + 情绪模块.md**。**故事框架识别**（前置，决定聚合策略）。**两步法剧情聚合**（先从摘要识别剧情大纲，再按大纲分配情节点）。**关键信息推进索引**（按章节/剧情线追踪信息如何被扩写）。**情绪触动点与爆发节奏**（爽点/虐点/期待点的铺垫→释放→余波）。**读者需求 / 情绪引擎 / 爽文套路框架**（沉淀为可复现模块卡）。**角色合并**（跨章节去重+别名归一）。**角色分级**（主角/反派/核心配角/功能角色）。**散落情节兜底**（6步，含覆盖率验证）。**桥段标签**（每个剧情模块按 deconstruction-notes.md 桥段词表打标，best-effort，无匹配留空）。**质量检查**（阈值详见 material-decomposition.md 质量阈值体系）。 | 质量检查通过 | | 4 | 设定+关系（4a/4b/4c） | **4a**：Stage 2 情节点+章节摘要（不依赖 Stage 3，与 3 并行）；**4b/4c**：Stage 3 合并后角色数据+情节点 | 设定/*.md + 角色/*.md。**4a 设定**（世界观/金手指/势力，从 Stage 2 mention 数据归纳）。**4b 角色完整档案**（两阶段模型：Stage 2 轻量提及 → Stage 4b 完整档案；别名解析置信度≥0.85自动合并；关键 minor 角色不得吞并，见下方「角色独立成档规则」）。**4c 角色关系提取**（从情节点提取，不从原文；含演变追踪+最终状态合并+隐含推断）。非人形反派在 4a 做完整抽象对抗型分析。 | 4a/4b/4c 全部完成 | | 5 | 汇总报告 | 全部输出 | 拆文报告.md（含「读者需求 / 情绪引擎」「关键信息与扩写技法总览」「节奏与情绪触动点」「可复现模块」摘要，并指向 `剧情/节奏.md` / `剧情/情绪模块.md`；含「写法技巧」清单，覆盖一笔两用/延迟揭示/视角欺骗/对比锚点/行为循环/身体反应替代心理描写/**跨章回扣**——物品/意象在不同章节承担不同功能；按 [references/deconstruction-to-author-absorption.md](references/deconstruction-to-author-absorption.md) 增加「作者吸收笔记」）+ 作者吸收笔记.md + **概要.md 全书 500-1000 字版**（plot-aware，覆盖 Stage 0 的 200 字 thin first-pass） | 报告 + 作者吸收笔记 + 全书概要生成完成 | | 6 | 文风 | 拆文报告.md + 章节/第1-3章_深度拆解.md + 章节/*_摘要.md + 原文/原文.txt | 文风.md（整书级写作技法视图：句长/标点/对话潜台词/情绪交替周期 + 4-6 段原文锚点范例片段，硬上限 ~4000 字。详见 [style-profile-protocol.md](references/style-profile-protocol.md) + [style-profile-generator.md](references/style-profile-generator.md)） | 文风落盘 `拆文库/{书名}/文风.md` | ### Stage 0.5 章节边界表（Stage 0 子步骤） Stage 0 完成概要 + 章节索引之后、转入 Stage 1 之前，**必须**先运行机械规划脚本，产出「章节切片索引」和「批次计划」。这是后续 Stage 1（黄金三章原文切片）/ Stage 2（每章传给 chapter-extractor agent）/ Stage 6（文风采样）共用的**唯一切片来源**——避免每个阶段各跑一次 regex 切片，结果可能不一致，也避免模型先读完整本书导致慢和上下文超限。 操作： - 若用户给的是原文文件路径，执行： ```bash node scripts/long-analyze-plan.js <原文文件路径> "拆文库/{书名}" --write --json --batch-size 30 ``` - 若用户是对话贴文本，先把原文保存到 `拆文库/{书名}/原文/原文.md`，再对该文件执行同一脚本。 - 脚本产出 `原文/原文.txt`、`章节切片索引.jsonl`、`批次计划.json` 和 `_progress.md`；`_progress.md` 顶部写 `schema_version: 3`。 - 后续所有阶段读取 `章节切片索引.jsonl` 的 offset/line 信息切片，不重新整本正则扫描；Stage 2 按 `批次计划.json` 的窗口推进。 - 若章节识别为 0，停止并请用户确认章节标题格式或提供自定义章节正则，不进入模型拆解。 **旧拆文库续跑兼容**：旧 `_progress.md`（schema v1/v2，无 `章节切片索引.jsonl` 或 `批次计划.json`）resume 时由 `pipeline-ops.md` 「恢复机制操作步骤 0」做 lazy migration——优先用原文文件补建索引和批次计划；无法找到原文时才退回旧章节边界表，不破 `paused_after_stage1` 契约。 ### Stage 1 停靠点 Stage 0+1 完成后，管道**自动停靠**，产出快速预览报告并询问用户是否继续生产级分批拆解： 1. **生成停靠交付物**：写 `拆文库/{书名}/快速预览.md`（模板见 [output-templates.md](references/output-templates.md) 的「快速预览报告」）。此时 `概要.md`、`章节/第1章_深度拆解.md`、`章节/第2章_深度拆解.md`、`章节/第3章_深度拆解.md`、`原文/` 均已落盘。 2. **写停靠状态**：`_progress.md` 的「最终状态」字段写 `paused_after_stage1`，「断点」段记录「下一操作：Stage 2 逐章摘要」。 3. **询问用户**（用普通文本确认的明确二选一；不得调用外部交互工具，不得出现不可执行的长耗时、上下文风险或换会话提醒）： > 「黄金三章已拆完，快速预览报告见 `快速预览.md`。是否继续生产级分批拆解？确认后我会按无人值守模式从第 2 阶段开始自动连续推进逐章摘要，再生成剧情聚合 / 设定关系 / 汇总报告 / 文风，并完成验证；批次只作为内部断点，不会每批都要求你继续。」 - 选「继续生产级分批拆解」→ 读 `_progress.md`，从 **Stage 2** 续跑，**不重跑 Stage 0/1**。 - 选「就到这里」→ 管道结束，`_progress.md` 状态保持 `paused_after_stage1`，告知用户「之后可随时 `/novel-assistant 继续拆这本长篇`，会自动从 Stage 2 续跑」。 4. **跳过询问的情形**：用户在一开始就明确说「完整拆解 / 一次跑完 / 系统拆解 / 别问」时，仍生成 `快速预览.md`（保留早期判断快照），但**不停下询问**，直接从 Stage 2 续跑到 Stage 6。 ### Stage 5 后：选题决策回填（可选） `拆文报告.md` 出来后（Stage 5 跑完）执行——和 Stage 6 无关，Stage 6 失败也不影响这步。 Stage 5 同时加载 [references/deconstruction-to-author-absorption.md](references/deconstruction-to-author-absorption.md)，把 5-8 个真正可迁移的技巧写入 `拆文报告.md` 的「作者吸收笔记」小节，并单独落盘 `作者吸收笔记.md`。这些卡必须包含读者欲望、技巧机制、可迁移骨架、写作动作和禁抄替换；只写“节奏快/爽点密/文风好”视为不合格。 **仅当**项目根存在 `选题决策.md` 时：按本书题材，在它的推荐选题里找**题材关键词对得上**的那个—— - 正好对上一个 → 把该选题的"能爆的原因"从 `待拆文验证` 改成带出处的支撑：「本书拆解支撑：{`拆文报告.md` 的 读者需求/情绪引擎 + `剧情/情绪模块.md` 的可复现模块 Top + `剧情/节奏.md` 的爽点/触动点节奏摘要}（`拆文库/{书名}/拆文报告.md`、`剧情/情绪模块.md`、`剧情/节奏.md`）」。注意还只是假设（只拆了一本，不算坐实）。 - 对上多个 / 拿不准 → 问用户「《{书名}》对应选题决策里的哪个方向？」 - 一个都对不上 / `选题决策.md` 里没有"能爆的原因"这栏（旧模板或文件坏了）→ 直接跳过，不提示。 - 重复拆文不覆盖：只回填还标着 `待拆文验证` 的；已经填过的不动。 没有 `选题决策.md` → 直接跳过，不影响拆文。 ### Stage 6 文风 Stage 5 完成后追加 Stage 6，生成 `文风.md`：句长分布、标点习惯、对话潜台词模式、情绪交替周期 + 4-6 段原文范例片段。`文风.md` 只负责表达层风格；情绪/节奏意图仍以 `剧情/情绪模块.md` 与 `剧情/节奏.md` 为权威。 按 [references/style-profile-generator.md](references/style-profile-generator.md) 的 6 步 SOP 跑；模板见 [references/style-profile-protocol.md](references/style-profile-protocol.md)。 原文缺失或章节分隔符识别不出 → 在 `文风.md` 的「生成记录」写明 `文风可用：否：{原因}`。Stage 6 失败不阻断管道。 ### Stage 3-4 并行执行 **并行执行图**： ``` Stage 3（剧情聚合 + 角色合并） ──┐ ├── 4a 与 Stage 3 可并行 Stage 4a（设定：世界观/金手指/势力） ──┘ │ ▼（Stage 3 + 4a 都完成后） Stage 4b（角色完整档案）— 串行，依赖 Stage 3 合并后的角色实体 │ ▼ Stage 4c（角色关系提取）— 串行，依赖 4b 角色实体存在 ``` **依赖来源**（事实依据，非投票）： - Stage 3 包含「角色合并（跨章节去重+别名归一）」（见上表 Stage 3 列）—— Stage 4 的角色完整档案构建需要这份合并后实体。 - material-decomposition.md:218-225「阶段 B：完整档案 — 合并所有章节的角色提及数据」明确依赖 Stage 3 合并产物 → **Stage 4b/4c 必须串行**。 - material-decomposition.md:278-287 世界观字段表（类型/能力与规则/地理/势力/核心规则/特殊设定）的数据源是 Stage 2 章节摘要 + 情节点，**不依赖 Stage 3 输出** → **Stage 4a 可与 Stage 3 并行**。 - 金手指（material-decomposition.md:268-276）同 4a，来源是 Stage 2 情节点中的能力 / 物品 mention，不需要 Stage 3 角色合并。 ### 角色独立成档规则 Stage 4b 不能只按出场频次或 `major/supporting/minor` 标签决定是否生成 `角色/{角色名}.md`。拆文的角色档案服务于后续写作复用；只要某个角色承担关键叙事功能，即使在章节摘要里多次被标为 minor，也必须独立成档。 必须独立成档的角色包括： - 主角、反派、导师、父母/亲人、核心伙伴、核心感情对象。 - 触发或承接关键爽点、虐点、反转、救命、牺牲、背叛、认主、觉醒、金手指激活的角色。 - 被多个章节反复使用作情感锚点、主角软肋、关系钩子、后续回收伏笔的角色。 - 在 `角色关系.md` 中出现为强关系节点，或在 `剧情/节奏.md` / `剧情/情绪模块.md` 中承担读者情绪引擎的角色。 可只进入 `角色关系.md` 而不独立成档的角色： - 一次性路人、无名群体、只出现一次且不改变剧情/情绪/设定的工具角色。 - 只作为势力成员被提及、没有单独关系变化和情节动作的背景角色。 若角色被降级不成档，必须在 `_progress.md` 或 `角色/角色关系.md` 的「未独立成档角色」段写明原因。基准例：`盘龙` 23 章中，沃顿虽是幼弟/minor，但承担“兄弟温情 → 飞扑护弟 → 盘龙戒指染血激活”的情感与金手指触发链，必须独立成 `角色/沃顿·巴鲁克.md`；希里虽是管家/minor，但承担“家族守护者 → 舍身护主 → 德林不可见规则验证”，必须独立成 `角色/希里.md`。 ### 部分失败容忍 单章/单阶段失败不阻断管道。失败记录到 `_progress.md` 的「失败记录」表（`| 类型 | 章节/阶段 | 错误信息 | 重试状态 |`）。最终状态可为 `completed_with_errors`（在拆文报告中注明失败详情）。 > 与 material-decomposition.md 的对应关系：Stage 0 含 Material 阶段1（章节解析）；Stage 1、5 为新增；Stage 2 = Material 阶段2；Stage 3 = Material 阶段3；Stage 4 合并 Material 阶段4+5。 详细模板见 [output-templates.md](references/output-templates.md)，方法论见 [material-decomposition.md](references/material-decomposition.md)。 --- ## 质量检查概要 Stage 3-4 完成前需通过质量检查（置信度、覆盖率、重叠率）。阈值、计算方式与自检清单的唯一权威定义见 [material-decomposition.md 质量阈值体系](references/material-decomposition.md)。 **Stage 3-5 还须过「事实可溯源」自检**：设定/角色/报告里的硬事实（等级/数值/距离/属性/势力数/出场章/谁说的话）必须能 grep 回原文，原文没给的写「原文未明确」、禁推断填空。这是拆文事实错误的最大来源（强模型也会漂移，因为合成阶段离原文两跳、靠合理性填空）。详见 [material-decomposition.md 合成阶段事实保真](references/material-decomposition.md)。 --- ## Stage 2 并行 Agent 策略 Stage 2 使用 chapter-extractor agent 并行处理每章，替代原来的串行分块。 ### 调用方式 每条章节 prompt **必须以「材料声明」前缀开头**（即下方 prompt 字符串首段）——给子代理正确语境，避免它把通俗题材的正常戏剧化剧情误判为有害内容而拒绝拆解。前缀是固定文本，逐字带上，不要改写或省略。 ```python Agent( subagent_type: "chapter-extractor", prompt: "[材料声明] 以下为用户合法持有的虚构小说，任务是只读的转化性文学分析（编辑/评论视角）。暴力/复仇/家暴/情爱/黑暗伦理是该题材常规虚构元素，照常提取，不得以敏感拒绝整章或整本；个别片段无法处理则跳过、照常续完其余。\n\n章节编号：第{N}章\n章节标题：{标题}\n章节字数：{字数}\nOUTPUT_PROFILE: fast_source_grounded|deep\n\n章节原文：\n{原文文本}" ) ``` `OUTPUT_PROFILE` 由主线程决定： - `fast_source_grounded`：>200 章默认，用于全书覆盖。 - `deep`：黄金三章、卷首卷尾、爆点/转折/回收章、用户点名章、质量失败重试章。 ### 批量策略 - 每次 spawn 5-8 个 agent（避免并发限制） - 等待当前批次全部完成后，再 spawn 下一批 - 每批完成后更新 `_progress.md` 记录已处理章节 - 批次只是内部断点，不是用户确认点；不得每完成一个批次就要求用户继续。 - 用户已确认继续生产级拆解后，Stage 2 默认无人值守推进；不得把“剩余 N 批，请用户继续”作为正常结束语。 - 以“批次窗口”管理长篇：默认每 20-40 章为一个大批次窗口；窗口内再按 5-8 个 agent 小并发执行。完成一个大批次窗口后必须： 1. 落盘该窗口所有 `章节/第{N}章_摘要.md` 2. 更新 `_progress.md` 的「管道进度 / 分块进度 / 断点」 3. 继续下一窗口；只在每 90-120 章、阶段完成、或出现严重质量事件时输出短状态 4. 若当前会话上下文或时间已紧张，停在此窗口边界，不继续开新批；给出准确续跑命令 - 对 >200 章长篇，禁止在一个回复里承诺单次跑完全书；但也不得把每个小批次都变成用户手动确认。必须按窗口自动推进，并把每个窗口视为可恢复断点。 - 对 >200 章长篇，主线程必须先确认 `.claude/agents/chapter-extractor.md` 可用并使用并行 agent；不得静默退回主线程串行处理 200+ 章深拆。agent 不可用时按下方「Agent 可用性门禁」处理。 ### Agent 输出收集 - 每个 agent 返回 markdown 格式的提取结果 - `chapter-extractor` 是只读 agent，frontmatter 明确 `disallowedTools: [Write, Edit, Bash]`。**不得**在 prompt 中要求它写 `章节/第{N}章_摘要.md`，也不得把“落盘摘要”任务派给 `chapter-extractor`。 - Stage 2 的唯一合法落盘路径是：`chapter-extractor` 返回 markdown → 主线程把该返回写入 `章节/第{N}章_摘要.md` → 主线程运行摘要格式门禁和 source-grounding → 失败时按本节重试/修复。不要让子 agent 自己读写输出目录。 - 如果主线程上下文压缩后丢失了某批 agent 的原始返回，或当前会话已经无法可靠写入该批摘要，必须在 `_progress.md` 写 `paused_after_batch_output_loss` / `blocked_batch_output_loss`，记录待重跑章节范围；**不得**改派 `general-purpose` agent 重新读原文并生成摘要来“补写”。这会绕过 chapter-extractor 专用规则，容易串章、串书和污染样本。 - 如果需要重跑某批，仍然按 `章节切片索引.jsonl` 的对应章节重新 spawn `chapter-extractor`，再由主线程落盘；不得把 9-16、17-23 等范围交给通用 agent 批量写。 - 主线程先把 agent 输出写入临时文件，基于 `章节切片索引.jsonl` 切出该章原文片段，再用 `scripts/stage2-grounding-check.js` 做 source-grounding 校验；通过后才写入 `章节/第{N}章_摘要.md` - 收集所有 agent 的出场人物表，供 Stage 3 合并使用 ### 失败处理 + 质量升级重试 **两类失败**： 1. **执行失败**（agent crash / 超时 / 空输出）→ 同模型（haiku）重试 1 次 2. **质量失败**（输出落盘后跑 chapter-extractor.md「质量检查」10 条自检，任一不达标——典型：情节点 < 10、原文引用缺失、类型/基调/主题标签超出枚举、`基调：` 漏全角冒号、角色名为昵称/通用称呼）→ **升级到 sonnet 重试 1 次** **可机械校验的硬检查**（主线程落盘后直接运行固定脚本，命中即判质量失败，不依赖 agent 自报）： - 摘要格式/枚举门禁必须用固定 Node 命令，不得生成 `cd && for ... && grep "$f"`、`${n}`、命令替换、管道循环等 Claude Code 会提示 `Contains expansion` 的 Bash 片段： ```bash node scripts/stage2-summary-quality-check.js "拆文库/{书名}/章节" --chapters {start}-{end} --json ``` 该脚本检查：情节点数 `P` 与 `基调：` 行数一致、主题标签行数一致、每个 `P{N}` 均位于行首、基调值 ∈ {紧张, 轻松, 悲伤, 热血, 爽, 甜, 温馨, 恐怖, 压抑, 其他}、主题标签值 ∈ {爱情, 亲情, 友情, 权力, 金钱, 成长, 复仇, 悬念, 搞笑, 热血, 日常, 其他}。失败类型 `plot_point_inline_marker`、`tone_count_mismatch`、`topic_count_mismatch`、`invalid_tone`、`invalid_topic` 都属于质量失败，必须重试或修复。 - source-grounding 校验必须通过：直接执行目录级固定命令，由脚本读取 `章节切片索引.jsonl` 的 offset 并在进程内切出本章原文： ```bash node scripts/stage2-grounding-check.js "拆文库/{书名}" --chapters {start}-{end} --json ``` 不得用 `node -e`、here-doc、临时内联 JS、`console.log` 调试片段或 shell 变量展开来切原文/定位引用；`stage2-grounding-check.js` 会直接读取 `章节切片索引.jsonl`、`原文/原文.txt` 和 `章节/第N章_摘要.md` 完成批量校验。 校验失败类型 `unknown_entities` 表示摘要里的人名/别名/涉及人物不在本章原文；`quote_not_in_source` 表示情节点引用不在本章原文；`quote_missing` 表示情节点没有原文锚点。 - 引用修复门禁：若 source-grounding 只命中 `quote_not_in_source` / `quote_missing`，先运行固定修复器，把每个 P 块引用段替换为同章原文中最相关的连续原文句，再复扫 grounding： ```bash node scripts/stage2-quote-repair.js "拆文库/{书名}" --chapters {start}-{end} --json node scripts/stage2-grounding-check.js "拆文库/{书名}" --chapters {start}-{end} --json ``` `stage2-quote-repair.js` 是内部兜底，不放宽校验；修复后仍必须通过 source-grounding。若仍失败，或命中 `unknown_entities`，才进入同章重试/升级。 > 注意：上面命令是内部实现契约，不是用户操作说明。不要把 `node scripts/...` 输出给用户作为“你下一步运行”。用户下一步永远写 `/novel-assistant 继续拆...`。 **升级重试调用方式**（主线程在校验失败后执行）： ```python Agent( subagent_type: "chapter-extractor", model: "sonnet", # 显式覆盖 frontmatter 的 haiku prompt: "章节编号：第{N}章\n...（同首次 prompt，含开头的「材料声明」前缀，可追加：'上次校验失败原因：{自检失败项}'）" ) ``` **最终落盘规则**： - haiku 首次通过 → 写入 `章节/第{N}章_摘要.md`，`_progress.md` 标记 `success` - haiku 失败 + 同模型 retry 通过 → 同上，备注 `retry_same_model` - source-grounding 引用段失败 + `stage2-quote-repair.js` 修复后通过 → 同上，备注 `quote_repaired` - 质量失败 + sonnet retry 通过 → 同上，备注 `retry_sonnet` - source-grounding 失败且 sonnet retry 后仍失败 → 不得接受疑似串书摘要；章节标记 `⚠️ 跳过`，失败原因写入 `_progress.md` 「失败记录」表，拆文报告中注明。只有原文切片缺失、章节索引冲突、或同一章连续失败且属于主线关键章时，才暂停请用户裁定 source；普通失败章节继续无人值守推进。 - sonnet retry 仍失败 → 章节标记 `⚠️ 跳过`，失败原因写入 `_progress.md` 「失败记录」表，拆文报告中注明 - 单章失败不阻断管道；批次全部 spawn 完成后才决定是否进入 Stage 3 ### Agent 可用性门禁 Stage 2 开始前必须做 agent 可用性门禁： 1. 先确认当前运行时是否已经暴露 `chapter-extractor` agent（例如 Claude 初始化的 `agents` 列表包含 `chapter-extractor`）。如果已暴露，直接 spawn `subagent_type: "chapter-extractor"`；**不得**再为了找 `.md` 文件做全盘搜索。 2. 若运行时没有暴露 `chapter-extractor`，再检查当前项目 `.claude/agents/chapter-extractor.md` 是否存在。 3. 若项目 agent 文件缺失，内部调用 `story-setup` 的安全刷新部署 agents / rules / scripts；这属于运行时补齐，不修改正文/大纲/细纲。 4. 若刷新后仍缺失，只允许读取固定位置的 bundled template 作为规则来源：`~/.claude/skills/novel-assistant/references/internal-skills/story-setup/references/templates/agents/chapter-extractor.md` 或当前仓库 `skills/story-setup/references/templates/agents/chapter-extractor.md`。不得执行 `find /`、`find ~`、`mdfind`、全盘 `locate` 或长时间目录扫描来寻找 agent 文件；这类搜索会拖慢 benchmark、污染上下文，并且不能证明 agent 可用。 5. 若固定路径仍不可用，或当前环境不支持 spawn 子代理： - **>200 章**：不得静默退回主线程串行处理 200+ 章深拆。只允许主线程做 bounded fast fallback：每轮最多 10 章快速源锚模式，写清楚 agent 不可用、已落盘断点、需要前端/启动器或新会话继续；不得声称正在无人值守高速拆完全书。 - **≤200 章**：可以主线程串行处理，但必须使用快速源锚模式优先，只有用户明确要求或关键章才深拆。 6. 如果 agent 可用但连续 3 个小并发批次未被实际使用（例如输出显示主线程逐章阅读/写入），必须停止继续开新批，修正执行方式为 `chapter-extractor` 并行后再推进。不要让“看起来在跑”的串行深拆消耗数小时。 ### Stage 2 收尾：合并章节摘要（_章节摘要汇总.md） Stage 2 所有 `章节/*_摘要.md` 落盘后、进入 Stage 3 前，主线程把它们按章号顺序**无损拼接**成 `拆文库/{书名}/_章节摘要汇总.md`（只拼接、不压缩、不改写）： ```bash ls 章节/*_摘要.md | sed -E 's/.*第([0-9]+)章.*/\1 &/' | sort -n | cut -d' ' -f2- | while read -r f; do cat "$f"; echo; done > _章节摘要汇总.md ``` **无损检查**（拼接后校验，任一不过即删除 `_章节摘要汇总.md`、回退逐文件扫描，行为不变）： - `grep -cE '^P[0-9]+ ' _章节摘要汇总.md` == 各摘要 `^P` 行数之和 - `grep -cE '^\*\*概要\*\*' _章节摘要汇总.md` == 摘要文件数（`**概要**` 每章一行，chapter-extractor 并行输出与串行摘要模板都有；不用 `## 第N章` 头——串行摘要模板没有章节头，会误判） Stage 3 / 4a / 4c / 散落情节兜底改为**只读一次 `_章节摘要汇总.md`** 并在上下文中复用，替代每阶段 `glob 章节/*_摘要.md` 重扫（同一份语料的 4-5 次冷读降为 1 次）。 **仅当语料能放进上下文时才生成汇总文件**：>500 章、或合并后 `_章节摘要汇总.md` 过大放不进上下文时**跳过本步骤**，走下方「分块策略」。`_章节摘要汇总.md` 不替代 `章节/*_摘要.md`——单章文件仍是落盘真源，Stage 6 文风采样、人工复核照用单章文件。管道结束（Stage 6 后）删除 `_章节摘要汇总.md`——它是派生临时文件，不随 `拆文库/` 交付（`拆文库/` 会被 story-import 保留为写作工程）。 --- ## 分块策略 **路由级说明**：Stage 2 使用 chapter-extractor agent 按章节并行，**不分块**。 Stage 3-5 的分块策略（规模分级、智能分块、跨块合并、输出长度上限）的唯一权威定义见 [material-decomposition.md](references/material-decomposition.md)。 --- ## 恢复机制 1. 管道启动时检查输出目录是否已有 `_progress.md` 或 `章节/`。 2. 若存在既有输出，先运行「自愈恢复探针」，读取 `_recovery-state.json` 的 `stage`、`action`、`continuousComplete`、`firstMissing` 和 `lastError`。 3. **断点状态为 `paused_after_stage1`**（Stage 1 停靠点）或探针显示 `stage2_resume` → 跳过 Stage 0/1，直接从 Stage 2 的第一缺口续跑逐章摘要，不重跑已完成的概要、黄金三章或摘要文件。 4. 探针显示全书摘要已齐但缺聚合/设定/报告 → 从 Stage 3 续跑；缺文风 → 只补 Stage 6。 5. `_progress.md` 与实际 `章节/第N章_摘要.md` 冲突时，以实际文件为准，修正 `_progress.md` 断点和失败记录。 6. quota / Token Plan / 账号配额类阻断不自动循环重试；保存断点后停止。其他 API error、timeout、进程退出、stream stall 可由启动器在熔断边界内自动重启续跑。 `_progress.md` 模板与各状态值说明见 [pipeline-ops.md](references/pipeline-ops.md)。 --- ## 流程衔接 **流水线：** 长篇 **位置：** 拆文（长篇流水线第 2 步，在 story-long-scan 之后、story-long-write 之前） | 时机 | 跳转到 | 命令 | |---|---|---| | 准备开写 | story-long-write | `/novel-assistant 开书` | | 需要市场数据 | story-long-scan | `/novel-assistant 长篇扫榜` | | 更适合短篇 | story-short-scan → story-short-analyze | `/novel-assistant 短篇扫榜` | > **选题决策回填**：若项目根有 `选题决策.md`（story-long-scan 产出），拆完汇总报告（Stage 5 跑完）后会自动回填对应选题的"能爆的原因"（见上「Stage 5 后：选题决策回填」）。 --- ## 参考资料 | 文件 | 何时加载 | |------|----------| | [references/output-templates.md](references/output-templates.md) | 管道全程：各 Stage 输出模板 + 快速预览报告模板 + `剧情/节奏.md` / `剧情/情绪模块.md` 模板 + 通用速查表 | | [references/material-decomposition.md](references/material-decomposition.md) | Stage 2-5：素材拆解方法论 + 质量阈值 + 分块策略；Stage 6 另见文风资料 | | [references/pipeline-ops.md](references/pipeline-ops.md) | 管道运维：_progress.md 模板、错误处理、恢复机制操作步骤 | | [references/deconstruction-notes.md](references/deconstruction-notes.md) | 拆书方法+影视拆解+抽象拆解法+题材实战 | | [references/style-profile-protocol.md](references/style-profile-protocol.md) | Stage 6：文风模板 + 可信度/可用性说明 | | [references/style-profile-generator.md](references/style-profile-generator.md) | Stage 6：文风生成 SOP（6 步，含中文数字章节识别 + 全角冒号基调 grep） | --- ## 语言 - 跟随用户的语言回复，用户用什么语言就用什么语言回复 - 中文回复遵循《中文文案排版指北》