Skip to main content
ClaudeWave
Skill2.4k estrellas del repoactualizado 2d ago

story-long-analyze

story-long-analyze is a Claude Code skill for decomposing web novels into structured components through a six-stage pipeline. It extracts plot summaries, analyzes the first three chapters in depth, catalogs characters and worldbuilding elements, maps story arcs, and documents writing style patterns, outputting organized markdown files to a project directory with checkpoint recovery for multi-session analysis of lengthy narratives.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/worldwonderer/oh-story-claudecode /tmp/story-long-analyze && cp -r /tmp/story-long-analyze/skills/story-long-analyze ~/.claude/skills/story-long-analyze
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# story-long-analyze:长篇网文拆文

你是网络小说结构分析师。

**核心信念:看懂别人的爆款,才能写出自己的爆款。**

---

## Phase 1:确认拆解对象 + 进入管道

问用户:**「你要拆哪本书?(书名+平台)有原文文件路径吗?」**

如果没有明确目标,按题材或用户想写的类型推荐 2-3 本对标作品。

### 统一入口

确认拆解对象后直接进入拆解管道(Phase 2)。**没有快速/深度分叉**——只有一条深度拆解管道,跑到 Stage 1(黄金三章)后自动停靠产出快速预览报告。

**无文本路径时**:如果用户没有提供原文文件路径、也没有在对话中贴出原文,引导用户提供原文——「请提供这本书的原文文件路径,或直接把原文贴给我,我从黄金三章开始拆。」拿到原文后进入管道。

---

## Phase 2:深度拆解管道

### 输出目录

默认输出到 `拆文库/{书名}/`(项目根目录下)。用户指定了其他路径时按用户指定路径输出。

### 已有分析利用

**深度拆解开始前,检查是否已有部分拆解结果**:

1. 检查 `拆文库/{书名}/` 目录下是否存在已有的拆文文件
2. 如果存在 _progress.md,读取断点信息,从断点恢复(已有恢复机制)
3. 如果存在 角色/*.md 或 设定/*.md,读取已有的角色和设定数据
4. 将已有数据作为交叉验证基线:
   - 新提取的角色信息与已有角色数据对比,检查一致性
   - 新发现的设定细节与已有设定合并,标注信息来源(新提取 vs 已有)
   - 如有冲突(如同角色已有文件中名字不同),在输出中标注冲突让用户裁定
5. 避免重复提取已有信息,提升处理效率

### 原文备份(管道前置步骤)

**拆解开始前,必须先备份原文**:

1. 检查 `拆文库/{书名}/原文/` 目录是否已存在
2. 如果不存在,从用户提供的源路径复制原文文件到 `拆文库/{书名}/原文/`
3. 如果用户未提供源文件路径(直接在对话中贴文本),将原始文本保存到 `拆文库/{书名}/原文/原文.md`
4. 备份完成后验证:
   - 源文件路径模式:确认 `原文/` 目录下的文件数量和大小与源文件一致
   - 对话贴文本模式:确认 `原文.md` 文件非空(>0 bytes)
5. 此步骤确保即使拆文过程中出现异常,原始材料不会丢失

### 输出目录结构

```
拆文库/{书名}/
├── 原文/
│   └── 原文.txt          # 扩展名随源文件;对话直接贴入的文本存为 原文.md
├── 概要.md
├── 章节/
│   ├── 第1章_深度拆解.md
│   ├── 第2章_深度拆解.md
│   ├── 第3章_深度拆解.md
│   ├── 第1章_摘要.md
│   └── ...
├── 快速预览.md
├── 角色/
│   ├── {角色名}.md
│   └── 角色关系.md
├── 剧情/
│   ├── {剧情标题}.md
│   ├── 故事线.md
│   └── 散落情节.md
├── 设定/
│   ├── 世界观/
│   │   ├── 背景设定.md   # 核心规则 + 特殊设定(无法独立的内容合并)
│   │   ├── 力量体系.md
│   │   ├── 地理.md
│   │   └── 金手指.md
│   └── 势力/
│       └── {势力名}.md   # 内容 >= 200 字时独立;不足合并到 世界观/背景设定.md
├── 拆文报告.md
├── 文风.md          # Stage 6 文风:句长/标点/对话潜台词/情绪交替 + 原文锚点 few-shot
└── _progress.md
```

> **预留产物(当前不写)**:`剧情/节奏.md`(爽点密度 / 章节情绪曲线)和 `剧情/时间线.md`(全书时间标记聚合)是 Stage 3 的预留输出,**当前管道不产出这两个文件**——等 story-long-write 日更循环加入对应读取逻辑后再启动。不要把这两份文件当作既有契约。

### 管道主体:Stage 0-5

这是 story-long-analyze 唯一的执行管道。Stage 0-1 跑完后**自动停靠**产出快速预览报告(见下「Stage 1 停靠点」),用户确认后从 Stage 2 续跑。

**预期耗时提示**:开始前根据章节数给用户一个粗估:<50 章通常 30-60 分钟;50-200 章通常 1-3 小时;>200 章可能需要多轮会话。Stage 2 可并行提取,但 Stage 3-6 仍依赖前序产物,需按阶段推进。


| 阶段 | 名称 | 输入 | 输出 | 完成标志 |
|------|------|------|------|----------|
| 0 | 概要提取 | 原始文本 | 概要.md(**首版 200 字 thin first-pass** + 章节索引;full plot-aware 500-1000 字版在 Stage 5 落盘覆盖)+ **Stage 0.5 章节边界表写入 `_progress.md`**(详见下方说明) | 章节结构识别完成 + 章节边界落盘 |
| 1 | 黄金三章 | 前3章原文 | 第1章_深度拆解.md / 第2章_深度拆解.md / 第3章_深度拆解.md(每章一个文件)。非人形反派(灵气复苏/末世/国运等抽象对抗型)出现在前三章时,在本阶段一并按抽象对抗型路由分析(核心对抗面/紧迫感来源/升级机制/叙事替代)。 | 3章拆解完成 → **停靠产出快速预览.md** |
| 2 | 逐章摘要 | 分块章节文本 | 章节摘要.md(含情节点+角色)。角色过滤(龙套不提取、别名归类)。每章10-40情节点(密度150-200字/个,按字数动态调节;公式低于10时仍按硬下限10拆足关键步骤)。**并行模式:每章 spawn chapter-extractor agent**。**计数验证:摘要数 == 章节数,不等则标记失败章节**。 | 所有章节处理完成 |
| 3 | 聚合分析 | 全部章节摘要 | 剧情/*.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自动合并)。**4c 角色关系提取**(从情节点提取,不从原文;含演变追踪+最终状态合并+隐含推断)。非人形反派在 4a 做完整抽象对抗型分析。 | 4a/4b/4c 全部完成 |
| 5 | 汇总报告 | 全部输出 | 拆文报告.md(含「写法技巧」清单,覆盖一笔两用/延迟揭示/视角欺骗/对比锚点/行为循环/身体反应替代心理描写/**跨章回扣**——物品/意象在不同章节承担不同功能)+ **概要.md 全书 500-1000 字版**(plot-aware,覆盖 Stage 0 的 200 字 thin first-pass) | 报告 + 全书概要生成完成 |
| 6 | 文风 | 拆文报告.md + 章节/第1-3章_深度拆解.md + 章节/*_摘要.md + 原文/原文.txt | 文风.md(整书级写作技法视图:句长/标点/对话潜台词/情绪交替周期 + 4-6 段原文锚点 few-shot 片段,硬上限 ~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 之前,**必须**额外产出一份「章节边界」表写入 `_progress.md`。这是后续 Stage 1(黄金三章原文切片)/ Stage 2(每章传给 chapter-extractor agent)/ Stage 6(文风采样)共用的**唯一切片来源**——避免每个阶段各跑一次 regex 切片,结果可能不一致。

操作:
- 用 `style-profile-generator.md` Step 4 的章节正则(已含 `千` / `两`,覆盖 1000+ 章长篇)grep 出全部章节行号
- 按 `| 章号 | 标题 | 起始行 | 字数 |` 四列写入 `_progress.md` 的「章节边界」section(见 [pipeline-ops.md](references/pipeline-ops.md) 模板)
- `_progress.md` 顶部 `schema_version: 2` 同时落盘

**旧拆文库续跑兼容**:旧 `_progress.md`(schema v1,无 `章节边界` 表)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. **询问用户**(用 AskUserQuestion 风格的明确二选一):
   > 「黄金三章已拆完,快速预览报告见 `快速预览.md`。是否继续全量拆解(Stage 2-6:逐章摘要 / 聚合分析 / 设定关系 / 汇总报告 / 文风)?预计耗时 {基于章节数粗估}。」
   - 选「继续全量拆解」→ 读 `_progress.md`,从 **Stage 2** 续跑,**不重跑 Stage 0/1**。
   - 选「就到这里」→ 管道结束,`_progress.md` 状态保持 `paused_after_stage1`,告知用户「之后可随时 `/story-long-analyze` 同一本书,会自动从 Stage 2 续跑」。
4. **跳过询问的情形**:用户在一开始就明确说「完整拆解 / 一次跑完 / 系统拆解 / 别问」时,仍生成 `快速预览.md`(保留早期判断快照),但**不停下询问**,直接从 Stage 2 续跑到 Stage 6。

### Stage 5 后:选题决策回填(可选)

`拆文报告.md` 出来后(Stage 5 跑完)执行——和 Stage 6 无关,Stage 6 失败也不影响这步。

**仅当**项目根存在 `选题决策.md` 时:按本书题材,在它的推荐选题里找**题材关键词对得上**的那个——
- 正好对上一个 → 把该选题的"能爆的原因"从 `待拆文验证` 改成带出处的支撑:「本书拆解支撑:{`拆文报告.md` 的 写法技巧 Top + 可借鉴套路 + 核心机制 摘要}(`拆文库/{书名}/拆文报告.md`)」。注意还只是假设(只拆了一本,不算坐实)。
- 对上多个 / 拿不准 → 问用户「《{书名}》对应选题决策里的哪个方向?」
- 一个都对不上 / `选题决策.md` 里没有"能爆的原因"这栏(旧模板或文件坏了)→ 直接跳过,不提示。
- 重复拆文不覆盖:只回填还标着 `待拆文验证` 的;已经填过的不动。

没有 `选题决策.md` → 直接跳过,不影响拆文。

### Stage 6 文风

Stage 5 完成后追加 Stage 6,生成 `文风.md`:句长分布、标点习惯、对话潜台词模式、情绪交替周期 + 4-6 段原文 few-shot 片段。

按 [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(剧情聚合 + 角色合并)       ──┐