写在前面

继上篇自动化分析跑起来之后，我的 Token 额度很快就见底了，每天都在等重置，导致每次跑不了几小时自动化。在这等重置的一段时间里，我突然想知道每次分析的这十几分钟里，Claude 到底在做什么，哪些地方比较在耗时。
于是我就问 Claude 为什么每次分析这么慢？
我还以为它会告诉我它在搜索数据之类的原因。
没想到得到的回复竟然是它在调试代码。
=_=

我这才意识到它每次生成的脚本都不是复用的，并且生成的脚本有可能有 Bug，它需要测试并修改直到成功。虽然已经让它把流程固化在 SKILL 中，但是纯文字版的 SKILL.md 缺乏脚本层支撑, Claude 每次执行都要从 0 生成 Prompt, 这才是 Token 消耗的真正原因。而且 SKILL 本身就支持固化脚本在内部，只是我的第一版 SKILL 没有要求。
灵光一闪我又想到了 SDD 驱动开发的文章，它的流程是不写一行代码，只写规范。相当于 PRD，然后让 AI 完成代码的部分。感觉和我的场景很匹配，需求固化到 PRD，然后让 AI 把 PRD 解释成 SKILL，每一步生成对应的脚本，这样既能固化需求，又能节省 Token，这才是 AI 工作流的正确打开方式。

SDD 怎么落地

先聊聊 SDD 它是什么。 SDD（Spec-Driven Development，规范驱动开发） 的核心思路是: 先把规范（spec）写清楚，再让 AI 生成代码。
跟传统开发 先写代码 → 补文档 完全反过来。


具体到我这套读书工作流，SDD 落地的形式是这样的:

• PRD 决定「做什么」: 做什么和不做什么是大模型每次输出不一样的最根本问题，只有限制好 LLM，才能每次都得着想要的结果。
• SKILL.md 决定「顺序和陷阱」: 从 PRD 中拆解出来可重复的 SOP 的执行步骤、约束等固定操作。让流程规范化。
• 脚本 决定「确定性」: 每一条固化好的 SOP，在端上会形成经过验证的脚本以及确定性的结果。也避免每次大模型都在调试工具。
• 笔记模板 决定「结构和风格」: 整体的风格和结构，按照 PRD 提前生成对应的模板，LLM 就会使用固定的风格。

PRD 决定 schema，SKILL.md 决定流程，脚本决定确定性，笔记模板决定风格。每一层约束一个不同维度，缺一不可。
没脚本就输出不稳定，没模板就实体抽取风格随机，没 SKILL.md 执行顺序混乱，没 PRD 校验就缺依据。


跟之前纯提示词方案相比，整个流程的 LLM 部分从「全程」压缩到了「中间一环」，脚本化让「不确定」只发生在一个环节。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

阶段 1 (PRD 阶段): 跟 Claude 一起打磨 "规范文档"
  ├── 输出什么 (schema)
  ├── 怎么分类 (14 大类)
  ├── 怎么校验 (L1 13-POINT + L2 5 项 + s97 跨书检测)
  ├── 占位符规则 (12 类模式)
  └── D0 数据缺失约束 (禁止凭训练记忆填空)

阶段 2 (SKILL.md 阶段): PRD 定稿后让 AI 写 SKILL 描述
  ├── 10 步流程顺序
  ├── 哪些步骤" 跳过会失败"
  ├── 10+ 种常见错误的修复循环
  └── 跨书内容污染防控

阶段 3 (脚本阶段): 最后才写 Python 脚本 （仅 Mac）
  ├── s20/s30/s40: 数据层 (EPUB 抽取, 分类, 豆瓣)
  ├── s50: 构建层 (vault 多阶段)
  ├── s90/s95/s96/s97: 校验层 (L1 + 占位符 + L2 + 跨书)
  └── 脚本执行 ≠ LLM 重写

只有先 PRD → 后 SKILL → 再脚本，每一层都在上一层的约束下，才能保证稳定。
这套流程还有一个隐性收益，上层的修改下层自动生效，不会陷入改一行脚本就要全部重来的困境，这让整个工作流能快速迭代。

Skill 目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

~/.claude/skills/productivity/book-vault-analysis/
├── PRD.md                            需求文档
├── SKILL.md                          skill 说明
├── scripts/                          8 个 Python 脚本
│   ├── s20_extract_epub_spine.py
│   ├── s30_classify_book.py
│   ├── s40_fetch_douban_data.py
│   ├── s50_build_vault.py            4 阶段: scaffold / entities / mermaid / moc
│   ├── s90_validate_vault.py         L1 13-POINT 硬检查
│   ├── s95_check_placeholders.py
│   ├── s96_finalize_vault.py         L2 5 项软检查
│   └── s97_cross_book_validator.py
├── references/                       20 个参考文档
│   ├── 14-types-taxonomy.md          14 大类详细定义
│   ├── l1-l2-pitfalls.md            L1/L2 校验常见坑
│   ├── c1-c12-readability.md        C1-C12 易读性约束
│   ├── llm-inference-pitfall.md     LLM 推断陷阱
│   ├── golden-sample.md              完整示例
│   └── ... (15 个其它)
└── templates/                        14 个模板 (T1-T14)
    ├── T1_literary.json
    ├── T2_philosophy.json
    └── ... (12 个其它)

分析流程

下面是分析流程和上面的 SKILL 目录的对应关系：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

EPUB 文件
    ↓
脚本 1: s20_extract_epub_spine.py   抽取 spine（spine 字符数、章节标题、元数据）
    ↓
脚本 2: s30_classify_book.py        14 大类分类（T1-T14，置信度）
    ↓
脚本 3: s40_fetch_douban_data.py   抓取豆瓣数据（subject_id、评分、短评、内容简介）
    ↓
Claude: 实体抽取（概念、人物、主题、摘录）+ MOC + Mermaid    ← 整个流程中「唯一」的 LLM 环节
    ↓
脚本 4: s50_build_vault.py         vault 多阶段构建（scaffold, entities, mermaid, moc）
    ↓
脚本 5: s90_validate_vault.py      L1 13-POINT 硬检查
    ↓
脚本 6: s95_check_placeholders.py  占位符检测（exit 1 if unfilled）
    ↓
脚本 7: s96_finalize_vault.py      L2 5 项软检查
    ↓
脚本 8: s97_cross_book_validator.py 跨书内容污染检测

把这 8 步对照前面的 4 层固化，刚好一一对应：

最终结果

对比之前的纯提示词方案，每次分析一本书的时间从每本书 10-20 分钟，缩短到了 5 分钟左右。Token 也不用总是担心不够用了。