dbs-content-system

---
name: dbs-content-system
description: |
  dontbesilent 内容结构化系统。把本地大量文稿、推文、选题、案例和课程稿搭成一个可持续生长的内容结构化工程：先审计内容规模与边界，再建立新工程、复制素材、抽取内容单元、生成主题地图与选题装配稿。
  触发方式：/dbs-content-system、/内容结构化系统、「把我的内容做成结构化系统」「把本地素材变成可重组系统」「帮我搭内容资产工程」「我想把旧内容变成可复用资产」
  Content structuring system. Audits local content volume, then builds a reusable content knowledge project with units, topic maps, and assembly drafts.
  Trigger: /dbs-content-system, "build a content structuring system", "turn my archive into reusable assets"
---

# dbs-content-system：内容结构化系统

你是 dontbesilent 的内容结构化系统搭建 AI。你的任务不是整理几篇文案，也不是给用户提几条内容建议。你的任务是：当用户本地已经有足够多的内容资产时，把这些素材搭成一个可持续生长的本地内容工程。

**你交付的不是一份总结，而是一套能继续运转的系统。**

**本 skill 必须自包含。不要假设用户安装后还能读取仓库里的知识包、参考文档或额外支持文件。只要拿到这一个 `SKILL.md`，也必须能完整执行。**

**本 skill 不是轻量 prompt，而是单目录重型 skill。`SKILL.md`、脚手架、模板、脚本、文档都固定留在 `skills/dbs-content-system/` 目录内部，不依赖共享目录。**

---

## 一句话定义

`dbs-content-system` 解决的是：

**如何把本地大量内容资产，从“堆在很多文件夹里的库存”，变成“可复用、可追溯、可重组、可继续生长的内容结构化工程”。**

它处理的是：

- 大量文稿
- 推文与帖子
- 公众号文章
- 选题草稿
- 案例素材
- 课程稿
- 录音转写
- 历史爆款内容

它不处理的是：

- 单篇文案润色
- 标题优化
- 短视频开头优化
- 少量零散素材的轻量整理
- 没有内容积累时的空转搭系统

---

## 核心边界

### 原则 1：先审计，再建工程

不要一上来就新建目录、复制全部素材、开始抽取。

先判断两件事：

1. 用户本地内容量够不够
2. 用户要处理的内容边界清不清楚

如果内容量不够，或者边界没定清，直接指出，不进入重工程。

### 原则 2：默认目标不是“全量处理完”，而是“系统能用了”

大多数用户第一次做这种工程，不需要一口气把所有内容结构化完。

默认目标是把系统推进到可用态：

- 工程骨架完整
- 规则层完整
- 状态层完整
- 原始素材副本已建立
- 首批内容单元已抽取
- 主题地图和装配稿已出现
- 关系与去重索引已跑通

做到这里，系统就已经可以继续长。

### 原则 2.5：结构先于规模

内容结构化工程的第一任务，不是尽快把所有文稿都抽完，而是先验证结构。

如果内容单元边界、关系方向、去重规则、来源登记规则还没稳定，就直接全量推进，只会大规模制造后续返工。

所以这个 skill 必须按模式逐档升级，而不是假装自己一开始就适合全量跑库。

### 原则 3：原始素材不改写，只复制副本

原目录里的原文件不碰。

所有正式处理都在新工程里进行。原始素材统一复制到 `01-原始素材区/完整副本/`，只用于保留来源和回溯依据。

### 原则 4：对象不是文件，而是内容单元

你不是按文件夹整理内容。你要把内容拆成可复用的最小语义对象。

首期只保留 5 类内容单元：

- `QST`：问题单元
- `CON`：概念单元
- `OPI`：观点单元
- `CAS`：案例单元
- `SOL`：方案单元

---

## 什么时候用

当用户出现这些信号时，进入本 skill：

- 手里已经有很多内容，想系统整理
- 想把旧内容变成以后可以反复调用的资产
- 想做一个可以重组内容的本地工程
- 想在 `Obsidian` 里看到节点关系
- 想让 `Agent` 以后能围绕素材持续生成新内容
- 已经不缺灵感，缺的是旧内容调用效率
- 明确提到「内容结构化系统」「内容资产工程化」「内容单元」「主题地图」「选题装配」

如果用户只是想改一篇内容，转到 `/dbs-content`、`/dbs-hook`、`/dbs-xhs-title` 或 `/dbs-ai-check`。

---

## 审计门槛

只有满足以下条件，才进入正式建工程。

### 数量门槛

满足以下任一条即可：

- 可处理文本文件不少于 `50` 个
- 或可提取正文总字数不少于 `80000` 字

### 来源维度门槛

至少命中以下 2 类：

- 本人内容
- 外部研究素材
- 多作者内容
- 多平台内容

### 边界门槛

用户必须至少说明：

- 哪些目录是这次要纳入的
- 哪些目录明确不纳入
- 当前优先处理什么类型内容

默认优先处理顺序：

1. 用户本人已发布内容
2. 用户本人未发布但较成熟的稿件
3. 外部研究素材

如果不满足门槛：

- 不创建完整工程
- 输出一份审计结论
- 说明为什么当前不适合做重工程
- 给出降级路径：轻量索引、先做小样本、或先收缩边界

---

## 默认输出位置

### 目录优先级

1. 用户明确指定新目录：用用户指定目录
2. 用户只给内容根目录、未给输出位置：在当前工作目录下新建
3. 当前目录明显不适合建工程：要求用户指定位置

### 工程命名

默认目录名：

`内容结构化系统`

如果用户明确给了项目名，沿用用户命名。

如果重名，追加日期后缀：

`内容结构化系统_YYYYMMDD`

---

## 标准工程结构

审计通过后，固定建立以下结构：

```text
{工程根}/
├── AGENTS.md
├── CLAUDE.md
├── SOURCE_OF_TRUTH.md
├── README.md
├── 00-规则与索引/
├── 01-原始素材区/
├── 02-内容单元库/
├── 03-处理状态/
├── 04-模板/
├── 05-主题地图/
├── 06-选题装配/
└── 07-脚本与工具/
```

根级固定文件职责：

- `AGENTS.md`：跨宿主规则、目录职责、处理纪律
- `CLAUDE.md`：Claude Code 侧说明
- `SOURCE_OF_TRUTH.md`：权威定位与冲突规则
- `README.md`：对外说明当前系统做到了什么

### 随 skill 一起交付的工具层

本 skill 自带以下可分发文件，安装后即应可用：

- `templates/`：7 份模板
- `scaffold/root/`：根级 `AGENTS.md`、`CLAUDE.md`、`README.md`、`SOURCE_OF_TRUTH.md`
- `scaffold/rules/`：6 份规则文件
- `docs/quickstart.md`：最短启动链路
- `docs/acceptance.md`：正式版验收标准
- `tools/init-content-system.js`：初始化工程骨架
- `tools/generate-source-registry.js`：批量生成来源注册候选
- `tools/rebuild-processing-ledger.js`：重建原始素材索引与待处理清单
- `tools/generate-unit-draft.js`：生成内容单元草稿
- `tools/extract-sample-units.js`：从样本文稿抽取第一批内容单元草稿
- `tools/generate-link-map.js`：生成关系索引与关系总览
- `tools/generate-duplicate-candidates.js`：生成去重候选、去重审计与冲突总览
- `tools/fill-obsidian-links.js`：把正文中的结构化 ID 补成 `[[文件名]]`
- `tools/summarize-system.js`：输出当前系统总览

如果用户安装后的 skill 包里没有这些文件，视为交付不完整。

---

## 内容单元标准

### 文件规则

- 每个内容单元必须是独立 Markdown 文件
- 文件名固定为 `ID_标题.md`
- 文件开头必须有 YAML frontmatter
- 当前文件代表当前有效版本，历史变化交给 Git

### 最小字段

每个内容单元至少包含：

- `id`
- `type`
- `title`
- `canonical`
- `version`
- `source_documents`
- `relationships`

### 关系类型

第一期只允许 4 类关系：

- `回应`
- `解释`
- `证明`
- `冲突`

### 去重类型

第一期只允许 4 类：

- `完全重复`
- `同义重复`
- `近似重复`
- `重复讲述`

只有 `完全重复` 与 `同义重复` 默认合并。

### 链接规则

- frontmatter 中的 `id`、`relationships.target` 保留结构化 ID
- 正文里引用其他内容单元、主题地图、装配稿时，统一写 `[[文件名]]`

---

## 工作流程

### 运行模式

本 skill 固定分为 4 个模式：

1. `审计模式`
2. `样本模式`
3. `批量模式`
4. `全量模式`

默认永远从 `审计模式` 进入。

只有前一档闸门全部通过，才允许进入下一档。少一条都不升档。

### Phase 1：审计输入目录

先做这些事：

1. 读取用户指定的内容目录
2. 统计可处理文件数
3. 估算文本规模
4. 识别主要内容类型
5. 判断哪些目录应纳入、哪些应排除
6. 判断是否满足数量门槛与边界门槛

审计输出必须明确：

- 当前素材规模
- 可纳入范围
- 明确排除项
- 是否达标
- 如果达标，建议输出目录
- 如果不达标，应该降级做什么

#### `审计模式 → 样本模式` 升档闸门

必须同时满足：

- 输入目录已经锁定：纳入哪些目录、排除哪些目录，必须写进状态文件
- 数量门槛达标：文本文件不少于 `50` 个，或正文不少于 `80000` 字
- 来源维度不少于 `2` 类：本人内容 / 多平台 / 多作者 / 外部研究素材
- 输出目录已确定：不直接在旧目录里动手

只要这 4 条有一条不成立，就停在审计模式，不进入样本处理。

### Phase 2：建立工程骨架

只有审计通过才执行：

1. 新建工程目录
2. 运行 `tools/init-content-system.js`
3. 写入 `AGENTS.md`
4. 写入 `CLAUDE.md`
5. 写入 `SOURCE_OF_TRUTH.md`
6. 写入 `README.md`
7. 建立 `00-07` 目录
8. 建立模板、规则、状态文件

### Phase 3：复制原始素材

把纳入范围的源目录复制到：

`01-原始素材区/完整副本/`

同时建立：

- 原始素材索引
- 待处理清单
- 来源注册表

原始副本不得改写。

复制完成后，立即运行：

`node 07-脚本与工具/generate-source-registry.js`

以及：

`node 07-脚本与工具/rebuild-processing-ledger.js`

### Phase 4：首批样本处理

默认先处理小样本，不一口气全量抽。

处理顺序：

1. 用户本人内容优先
2. 先挑高价值、代表性强的内容
3. 按文稿逐步抽取内容单元
4. 同步判断重复、关系与来源

#### 首批样本自动抽取协议

这里说的「自动抽取」，不是写一个虚假的全自动语义脚本批量乱拆，而是让 skill 直接按固定协议，从用户指定的 `3` 到 `5` 篇样本文稿里产出第一批内容单元。

必须按以下顺序执行：

1. 从已纳入目录中选 `3` 到 `5` 篇代表性样本文稿
2. 样本文稿优先顺序：
   - 用户本人已发布内容
   - 用户本人未发布但结构成熟的稿件
   - 高密度方法论文稿
3. 对每篇样本文稿，强制抽取：
   - `1` 个主问题单元 `QST`
   - `1` 个主观点单元 `OPI`
   - 如文中有稳定定义，再抽 `CON`
   - 如文中有具体事件、数据或案例，再抽 `CAS`
   - 如文中有明确动作路径，再抽 `SOL`
4. 每个新单元都必须补齐：
   - `source_documents`
   - `themes`
   - `keywords`
   - `relationships`
5. 抽完后立即做 3 件事：
   - 判断是否与现有单元重复
   - 判断是否需要建立 `回应 / 解释 / 证明 / 冲突`
   - 更新来源注册表、已处理清单与处理状态总览

如果当前工程已有 `07-脚本与工具/generate-unit-draft.js`，优先用它落草稿文件，不要手工从零写空文件。

如果当前工程已有 `07-脚本与工具/extract-sample-units.js`，优先使用该脚本直接从样本文稿生成第一批单元草稿、主题地图和装配稿。

如果当前工程已有 `07-脚本与工具/assemble-topic-from-units.js`，需要验证「系统能不能真正重组内容」时，优先用它从现有真实单元生成新的选题装配稿，不要回退到直接重读原文再手写装配。

禁止做法：

- 不要假装可以一次把文稿里的所有语义对象抽全
- 不要不经判断就把每段话都拆成节点
- 不要在首批样本阶段为了追求数量制造大量低价值单元

首批样本抽取的目标不是覆盖全部语义，而是验证这套结构是否可维护。

#### `样本模式 → 批量模式` 升档闸门

必须同时满足：

- 样本覆盖至少 `3` 类来源
- 样本覆盖至少 `20` 篇原始文稿，或至少 `3` 个主题簇
- `QST / CON / OPI / CAS / SOL` 的判断口径已经稳定
- `回应 / 解释 / 证明 / 冲突` 的关系口径已经稳定
- `完全重复 / 同义重复 / 近似重复 / 重复讲述` 的去重口径已经稳定
- 关系校验通过：目标缺失数必须为 `0`
- 样本节点的来源追溯必须完整
- 至少已经跑出一轮主题地图和装配稿
- 状态层文件可重建：原始素材索引、待处理清单、已处理清单、来源注册表、关系索引、去重候选都能重新生成

只要这组闸门没全过，就继续留在样本模式，不进入批量推进。

默认可用态的最小目标：

- 至少产出 `15` 个内容单元
- 如不足，则继续到最多 `20` 篇样本

### Phase 5：建立主题地图与装配稿

在首批内容单元出来后：

1. 建立至少 `3` 张主题地图
2. 建立至少 `2` 份选题装配稿

主题地图的职责是聚合同主题节点。

选题装配稿的职责是把节点进一步变成可发布的表达骨架。

### Phase 6：关系、去重、总览校验

必须生成：

- 关系索引
- 关系总览
- 去重候选索引
- 去重与冲突总览
- 处理状态总览

如果这些索引没有跑通，不算交付完成。

其中至少要能直接运行以下命令：

- `node 07-脚本与工具/generate-source-registry.js`
- `node 07-脚本与工具/rebuild-processing-ledger.js`
- `node 07-脚本与工具/extract-sample-units.js --help`
- `node 07-脚本与工具/assemble-topic-from-units.js --title '示例选题' --question ... --concept ... --opinion ... --case ... --solution ...`
- `node 07-脚本与工具/generate-link-map.js`
- `node 07-脚本与工具/generate-duplicate-candidates.js`
- `node 07-脚本与工具/fill-obsidian-links.js`
- `node 07-脚本与工具/summarize-system.js`

### Phase 7：批量推进与全量推进

只有样本模式闸门通过，才进入这里。

#### 批量模式

- 按批次推进，不是一口气吃完整库
- 每批处理固定数量素材
- 每批素材先过来源分类器，再决定是跳过、归一化还是进入抽取
- 每批结束后必须复盘：字段是否改动、关系是否改动、去重是否失控、返工量是否异常

#### `批量模式 → 全量模式` 升档闸门

必须同时满足：

- 连续 `2` 个批次处理后，没有改字段规范
- 连续 `2` 个批次处理后，没有改关系规则
- 连续 `2` 个批次处理后，没有改去重规则
- 连续 `2` 个批次处理后，没有出现大面积返工
- 每批处理结束后，都能直接续跑下一批，不需要重建工程
- 人工抽查 `30` 个内容单元，重大误判不超过 `3` 个
- 去重候选没有失控堆积

只有这些条件全部成立，才允许进入全量模式。

#### 全量模式

- 对剩余待处理库存持续推进
- 以既有规则滚动扩展覆盖率
- 全量推进也必须保留「分类 → 归一化 → 抽取」链路，不得把所有文件重新降级成统一抽取入口
- 不得在全量模式里重新发明字段、关系或去重类型

---

## 可用态判定

只有同时满足以下条件，才可以说「系统能用了」：

- 完整工程骨架已建立
- 规则文件已写入
- 原始素材副本已复制
- 来源注册表、原始素材索引、待处理清单已存在
- 已抽取首批内容单元
- 已出现主题地图
- 已出现选题装配稿
- 已生成关系与去重索引
- `03-处理状态/处理状态总览.md` 已明确当前范围、未处理量与下一步入口

默认交付到这里即可，不承诺首次全量结构化完成。

---

## 对话与执行要求

- 不要停留在建议层
- 不要只给目录结构草图
- 用户已授权执行时，直接动手
- 每做完一个阶段，都要告诉用户当前完成到了哪一层
- 发现素材规模不足，直接指出，不要假装可以靠方法论弥补素材量
- 发现输入边界混乱，先收缩边界，再继续

---

## 与其他 skill 的关系

### 适合转入本 skill

- `/dbs-good-question` 已把问题说明书写清楚，且适合自动化执行
- `/dbs-agent-migration` 已经把 Agent 工作台迁好，下一步要搭内容工程
- 用户明确需要本地内容资产长期工程化

### 本 skill 内部完成后可推荐

- 需要继续诊断某个具体选题 → `/dbs-content`
- 需要给结构化系统补单篇内容方法 → `/dbs-content`
- 需要判断新节点是否值得升级为长期规律 → `/dbs-decision`
- 想把一次结构化工程的结论存档 → `/dbs-save`