AGENTS.md@skills/dbs-content-system/scaffold/root git:20260928.9ff7fc2A

Immutable. This exact content never changes and is served at /api/v1/blob/086efd98dbba1358.

# 内容结构化系统

## 语言与排版

- 始终使用中文沟通
- 遵循《中文文案排版指北》：中英文之间加空格，中文与数字之间加空格，中文标点使用全角，数字使用半角，专有名词大小写正确
- 写作、改写、总结、输出文案时，中文引号默认使用全角直角引号「」

## 系统定位

本工程用于管理本地内容相关资产。

核心目标不是归档文稿，而是把原始文稿加工为可复用、可追溯、可重组的「内容单元」，并支持后续按选题装配为文章、视频稿、标题方案与系列内容。

## 目录职责

- `00-规则与索引/`：系统规则、字段规范、关系规则、去重规则、模板规范
- `01-原始素材区/`：从旧目录复制而来的原始内容副本，只做来源保留，不在这里直接做结构化沉淀
- `02-内容单元库/`：结构化结果，按内容单元类型管理
- `03-处理状态/`：处理进度、样本计划、冲突记录、抽取日志
- `04-模板/`：内容单元模板
- `05-主题地图/`：主题层组织文件
- `06-选题装配/`：面向选题输出的重组稿
- `07-脚本与工具/`：索引、校验、补链、草稿生成脚本

## 基本对象

本工程的基本对象统一称为「内容单元」。

第一期只保留 5 类：

- 问题单元
- 概念单元
- 观点单元
- 案例单元
- 方案单元

证据不作为独立类型，先挂在观点单元或案例单元内部。

## 存储规则

- 每个内容单元必须是一个独立的 Markdown 文件
- 每个文件开头必须使用 YAML frontmatter
- 文件名统一为 `ID_标题.md`
- 当前文件始终代表当前有效版本，历史变化交给 Git
- `frontmatter` 内的 `id`、`relationships.target` 一律保留结构化 ID，不写 `Obsidian` 链接
- 正文里凡是引用其他内容单元、主题地图、选题装配，统一写为 `[[文件名]]`，不要只写文件编号
- 批量新增或迁移正文引用后，运行 `node 07-脚本与工具/补全Obsidian链接.js`
- `内容单元` 的正文 `## 关联单元` 必须覆盖 `frontmatter.relationships.target` 对应的文件链接；允许额外补充手工关联，但不能漏掉已声明关系

## 处理流程

处理新文稿时，按以下顺序执行：

1. 判断素材是否进入本系统边界
2. 为原始素材建立来源位置与来源 ID
3. 判断应抽取哪些内容单元
4. 判断是否与现有内容单元重复
5. 需要合并时指定主单元
6. 不合并时建立必要关系
7. 更新处理状态与抽取日志

完整操作说明见 `00-规则与索引/新增文稿进入系统流程.md`。

## 关系规则

第一期只允许 4 种关系：

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

关系明细见 `00-规则与索引/内容单元关系规则.md`。

## 去重与版本规则

- 重复只分为：完全重复、同义重复、近似重复、重复讲述
- 只有完全重复与同义重复默认合并
- 合并后必须指定主单元
- 只有语义或适用边界发生变化，才提升 `version`

规则明细见 `00-规则与索引/内容单元去重与版本规则.md`。

## Source of Truth

当需要定位原始素材、判断版本、确认处理状态或解决冲突时，先读 `SOURCE_OF_TRUTH.md`。

进入正式处理链的原始素材，必须先登记 `03-处理状态/来源注册表.csv`，再引用到内容单元的 `source_documents` 字段。

## 禁止事项

- 不得直接修改 `01-原始素材区/` 中的原始副本内容
- 不得把长篇整稿直接塞进 `02-内容单元库/`
- 不得只建立 `related_units` 这类泛关联而不写明确关系类型
- 不得在未判断重复前批量新建同类内容单元