有大量本地内容资产时，用内容结构化系统把库存变成可复用…

当本地已有大量文稿、推文、公众号文章、选题草稿、案例素材、课程稿、录音转写或历史爆款，且需要系统整理、主题地图、选题装配和可持续复用资产时使用。

适用场景

解决思路

1. 先审计，再建工程：判断用户本地内容量够不够、内容边界清不清楚；不满足就直接指出，不进入重工程。
2. 默认目标不是全量处理完，而是把系统推进到可用态：工程骨架完整、规则层完整、状态层完整、原始素材副本已建立、首批内容单元已抽取、主题地图和装配稿已出现、关系与去重索引已跑通。
3. 结构先于规模：先验证内容单元边界、关系方向、去重规则、来源登记规则；不稳定就全量推进只会制造返工；必须按模式逐档升级，不假装一开始就适合全量跑库。
4. 原始素材不改写，只复制副本：原目录原文件不碰；所有正式处理都在新工程里进行；原始素材统一复制到 `01-原始素材区/完整副本/`，只用于保留来源和回溯依据。
5. 对象不是文件，而是内容单元：把内容拆成可复用的最小语义对象；首期只保留 5 类内容单元：`QST` 问题单元、`CON` 概念单元、`OPI` 观点单元、`CAS` 案例单元、`SOL` 方案单元。
6. 审计数量门槛：可处理文本文件不少于 `50` 个，或可提取正文总字数不少于 `80000` 字。
7. 审计来源维度门槛：至少命中以下 2 类：本人内容、外部研究素材、多作者内容、多平台内容。
8. 审计边界门槛：用户必须至少说明哪些目录是这次要纳入的、哪些目录明确不纳入、当前优先处理什么类型内容；默认优先顺序为用户本人已发布内容、用户本人未发布但较成熟的稿件、外部研究素材。
9. 不满足门槛时：不创建完整工程；输出一份审计结论；说明为什么当前不适合做重工程；给出降级路径：轻量索引、先做小样本或先收缩边界。
10. 默认输出位置：用户明确指定新目录则用用户指定目录；用户只给内容根目录、未给输出位置则在当前工作目录下新建；当前目录明显不适合建工程则要求用户指定位置。
11. 工程命名：默认目录名 `内容结构化系统`；如果用户明确给了项目名则沿用；如果重名则追加日期后缀 `内容结构化系统_YYYYMMDD`。
12. 审计通过后固定建立标准工程结构：根级 `AGENTS.md`、`CLAUDE.md`、`SOURCE_OF_TRUTH.md`、`README.md`，以及 `00-规则与索引/`、`01-原始素材区/`、`02-内容单元库/`、`03-处理状态/`、`04-模板/`、`05-主题地图/`、`06-选题装配/`、`07-脚本与工具/`。
13. 根级固定文件职责：`AGENTS.md` 写跨宿主规则、目录职责、处理纪律；`CLAUDE.md` 写 Claude Code 侧说明；`SOURCE_OF_TRUTH.md` 写权威定位与冲突规则；`README.md` 写对外说明当前系统做到了什么。
14. 确保随 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`；`tools/summarize-system.js`；如果安装后缺这些文件，视为交付不完整。
15. 内容单元文件规则：每个内容单元必须是独立 Markdown 文件；文件名固定为 `ID_标题.md`；文件开头必须有 YAML frontmatter；当前文件代表当前有效版本，历史变化交给 Git。
16. 内容单元最小字段：每个内容单元至少包含 `id`、`type`、`title`、`canonical`、`version`、`source_documents`、`relationships`。
17. 第一期关系类型只允许 4 类：`回应`、`解释`、`证明`、`冲突`。
18. 第一期去重类型只允许 4 类：`完全重复`、`同义重复`、`近似重复`、`重复讲述`；只有 `完全重复` 与 `同义重复` 默认合并。
19. 链接规则：frontmatter 中的 `id`、`relationships.target` 保留结构化 ID；正文里引用其他内容单元、主题地图、装配稿时统一写 `[[文件名]]`。
20. 固定 4 个运行模式：`审计模式`、`样本模式`、`批量模式`、`全量模式`；默认永远从 `审计模式` 进入；只有前一档闸门全部通过才允许进入下一档，少一条都不升档。
21. Phase 1 审计输入目录：读取用户指定的内容目录；统计可处理文件数；估算文本规模；识别主要内容类型；判断哪些目录应纳入、哪些应排除；判断是否满足数量门槛与边界门槛。
22. 审计输出必须明确：当前素材规模、可纳入范围、明确排除项、是否达标、如果达标建议输出目录、如果不达标应该降级做什么。
23. `审计模式 → 样本模式` 升档闸门必须同时满足：输入目录已经锁定并把纳入哪些目录、排除哪些目录写进状态文件；数量门槛达标；来源维度不少于 2 类；输出目录已确定且不直接在旧目录里动手；只要有一条不成立就停在审计模式，不进入样本处理。
24. Phase 2 建立工程骨架：只有审计通过才执行；新建工程目录；运行 `tools/init-content-system.js`；写入 `AGENTS.md`；写入 `CLAUDE.md`；写入 `SOURCE_OF_TRUTH.md`；写入 `README.md`；建立 `00-07` 目录；建立模板、规则、状态文件。
25. Phase 3 复制原始素材：把纳入范围的源目录复制到 `01-原始素材区/完整副本/`；同时建立原始素材索引、待处理清单、来源注册表；原始副本不得改写。
26. 复制完成后立即运行 `node 07-脚本与工具/generate-source-registry.js` 以及 `node 07-脚本与工具/rebuild-processing-ledger.js`。
27. Phase 4 首批样本处理：默认先处理小样本，不一口气全量抽；处理顺序为用户本人内容优先、先挑高价值代表性强的内容、按文稿逐步抽取内容单元、同步判断重复/关系与来源。
28. 首批样本自动抽取协议：不是写虚假的全自动语义脚本批量乱拆，而是让 skill 直接按固定协议从用户指定的 `3` 到 `5` 篇样本文稿里产出第一批内容单元。
29. 从已纳入目录中选 `3` 到 `5` 篇代表性样本文稿；样本文稿优先顺序为用户本人已发布内容、用户本人未发布但结构成熟的稿件、高密度方法论文稿。
30. 对每篇样本文稿强制抽取：`1` 个主问题单元 `QST`、`1` 个主观点单元 `OPI`；如文中有稳定定义再抽 `CON`；如文中有具体事件、数据或案例再抽 `CAS`；如文中有明确动作路径再抽 `SOL`。
31. 每个新单元都必须补齐 `source_documents`、`themes`、`keywords`、`relationships`。
32. 抽完后立即做 3 件事：判断是否与现有单元重复；判断是否需要建立 `回应 / 解释 / 证明 / 冲突`；更新来源注册表、已处理清单与处理状态总览。
33. 如果当前工程已有 `07-脚本与工具/generate-unit-draft.js`，优先用它落草稿文件，不要手工从零写空文件。
34. 如果当前工程已有 `07-脚本与工具/extract-sample-units.js`，优先使用该脚本直接从样本文稿生成第一批单元草稿、主题地图和装配稿。
35. 如果当前工程已有 `07-脚本与工具/assemble-topic-from-units.js`，需要验证系统能不能真正重组内容时，优先用它从现有真实单元生成新的选题装配稿，不要回退到直接重读原文再手写装配。
36. 首批样本阶段禁止做法：不要假装可以一次把文稿里的所有语义对象抽全；不要不经判断就把每段话都拆成节点；不要在首批样本阶段为了追求数量制造大量低价值单元。
37. 首批样本抽取目标不是覆盖全部语义，而是验证这套结构是否可维护。
38. `样本模式 → 批量模式` 升档闸门必须同时满足：样本覆盖至少 `3` 类来源；样本覆盖至少 `20` 篇原始文稿，或至少 `3` 个主题簇；`QST / CON / OPI / CAS / SOL` 的判断口径已经稳定；`回应 / 解释 / 证明 / 冲突` 的关系口径已经稳定；`完全重复 / 同义重复 / 近似重复 / 重复讲述` 的去重口径已经稳定；关系校验通过且目标缺失数必须为 `0`；样本节点的来源追溯必须完整；至少已经跑出一轮主题地图和装配稿；状态层文件可重建（原始素材索引、待处理清单、已处理清单、来源注册表、关系索引、去重候选都能重新生成）。
39. 如果这组闸门没全过，就继续留在样本模式，不进入批量推进。
40. 默认可用态最小目标：至少产出 `15` 个内容单元；如不足，则继续到最多 `20` 篇样本。
41. Phase 5 建立主题地图与装配稿：在首批内容单元出来后，建立至少 `3` 张主题地图、至少 `2` 份选题装配稿；主题地图的职责是聚合同主题节点；选题装配稿的职责是把节点进一步变成可发布的表达骨架。
42. Phase 6 关系、去重、总览校验：必须生成关系索引、关系总览、去重候选索引、去重与冲突总览、处理状态总览；如果这些索引没有跑通，不算交付完成。
43. 至少要能直接运行以下命令：`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`。
44. Phase 7 批量推进与全量推进：只有样本模式闸门通过，才进入这里。
45. 批量模式：按批次推进，不是一口气吃完整库；每批处理固定数量素材；每批素材先过来源分类器，再决定是跳过、归一化还是进入抽取；每批结束后必须复盘字段是否改动、关系是否改动、去重是否失控、返工量是否异常。
46. `批量模式 → 全量模式` 升档闸门必须同时满足：连续 `2` 个批次处理后没有改字段规范；连续 `2` 个批次处理后没有改关系规则；连续 `2` 个批次处理后没有改去重规则；连续 `2` 个批次处理后没有出现大面积返工；每批处理结束后都能直接续跑下一批且不需要重建工程；人工抽查 `30` 个内容单元，重大误判不超过 `3` 个；去重候选没有失控堆积。
47. 只有上述条件全部成立，才允许进入全量模式。
48. 全量模式：对剩余待处理库存持续推进；以既有规则滚动扩展覆盖率；全量推进也必须保留「分类 → 归一化 → 抽取」链路，不得把所有文件重新降级成统一抽取入口；不得在全量模式里重新发明字段、关系或去重类型。
49. 可用态判定：只有同时满足完整工程骨架已建立、规则文件已写入、原始素材副本已复制、来源注册表/原始素材索引/待处理清单已存在、已抽取首批内容单元、已出现主题地图、已出现选题装配稿、已生成关系与去重索引、`03-处理状态/处理状态总览.md` 已明确当前范围/未处理量/下一步入口，才可以说系统能用了。
50. 默认交付到可用态即可，不承诺首次全量结构化完成。
51. 对话与执行要求：不要停留在建议层；不要只给目录结构草图；用户已授权执行时直接动手；每做完一个阶段都要告诉用户当前完成到了哪一层；发现素材规模不足就直接指出，不要假装可以靠方法论弥补素材量；发现输入边界混乱就先收缩边界再继续。
52. 与其他 skill 的关系：`/dbs-good-question` 已把问题说明书写清楚且适合自动化执行时可转入本 skill；`/dbs-agent-migration` 已把 Agent 工作台迁好且下一步要搭内容工程时可转入本 skill；用户明确需要本地内容资产长期工程化时可转入本 skill。
53. 完成当前任务后直接结束；只有用户明确询问下一步，且当前环境已经安装 `/dbs` 时，简短提示：「下一步不确定时，可以输入 `/dbs`。」。
54. 本 skill 必须自包含：不要假设用户安装后还能读取仓库里的知识包、参考文档或额外支持文件；只要拿到这一个 `SKILL.md`，也必须能完整执行。
55. 本 skill 不是轻量 prompt，而是单目录重型 skill：`SKILL.md`、脚手架、模板、脚本、文档都固定留在 `skills/dbs-content-system/` 目录内部，不依赖共享目录。

适用边界 · 注意事项

• 只想改一篇内容、润色单篇文案、优化标题或短视频开头、处理少量零散素材时，不适用本内容工程。
• 没有内容积累（不满足 >=50 个可处理文本文件或 >=80000 字，且来源维度不足 2 类）时，不适用重工程；应降级为轻量索引、小样本或收缩边界。
• 输入边界不清、输出目录未定、或用户未授权执行时，不适用直接建完整工程；先停在审计模式并收缩边界。