dbs-content-system

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

---

標準工程結構

審計通過後，固定建立以下結構：

{工程根}/
├── 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。

這是商業工具箱的導覽入口。它會讀取剛才的具體結論，選擇當前最值得處理的一個方向，並直接路由到對應 Skill。

你也可以直接說你想做什麼——比如「我想找對標」「這個概念幫我拆一下」——/dbs 會路由到對應的 Skill。

不熟悉所有 Skill 沒關係，迷路了就回 /dbs。