Leo
bc0fe3f01c
1.6.0「禁止自創」措辭過嚴，碰到新軸會逼 AI 硬塞或偷創。改成： 禁的是繞過字典直接冒新標籤，不是禁新增——遇裝不下的內容先查重 （非同義詞？）、確認是新軸才登記進該 repo 的 TAXONOMY.md 再用。 字典 per-repo，跨 repo 不共用。新增領域軸要慎，形態軸較安全。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
51 lines
2.5 KiB
Markdown
51 lines
2.5 KiB
Markdown
# TAXONOMY.md — 標籤字典（本 repo 專屬）
|
|
|
|
> wiki 卡片的 frontmatter `tags:` **只能用這裡列出的標籤**。
|
|
> 這不是凍結——字典**可以擴充**，只是**禁止繞過字典在卡片裡直接冒新標籤**。
|
|
> 維護者：CC（由 /wiki-init 初始化、隨 wiki 演進受控擴充）。
|
|
>
|
|
> **遇到現有軸都裝不下的內容時，照這個流程（先查、後擴、登記）**：
|
|
> 1. **先查既有**：現有標籤真的都不合，還是只是同義詞？（`知識管理` vs `KM` vs `筆記管理` 是同一軸，別重造）
|
|
> 2. **確實是新軸** → 把新標籤加進本檔（附一句定義），再用。不必停下來問人，但「先登記再使用」這道查核不能省。
|
|
> 3. 自由增生才是要防的——同義標籤散開會讓同類卡片分散、下游聚類失準。受控擴充（先查重、再登記）不會。
|
|
>
|
|
> **字典是每個 repo 各自的**：跨 repo 引擎靠各 repo 自己一致的 taxonomy 接合，不是逼所有 repo 共用一份。
|
|
> 知識型 vault 的領域軸（知識管理／學習認知）和開發 repo（子系統／基礎設施）本來就該不同。
|
|
|
|
---
|
|
|
|
## 分類採雙軸（一張卡可多重歸屬）
|
|
|
|
分類由 **frontmatter `tags:`** 承載，不靠資料夾、不靠行內 `#tag`。
|
|
一張卡同時掛「領域 1-3 個 + 形態 0-2 個」，可從任一軸過濾。
|
|
|
|
### 領域（主軸，每卡 1-3 個）
|
|
|
|
> 由 /wiki-init 依專案性質提出。以下為 PKM / 知識型 vault 的實證一組，請按你的專案調整：
|
|
|
|
- `知識管理`
|
|
- `學習認知`
|
|
- `AI協作`
|
|
- `生產力`
|
|
- `系統設計`
|
|
- `工具教學`
|
|
|
|
（一般開發專案的領域軸可能是：`子系統A` / `子系統B` / `基礎設施` / `前端` / `後端` …）
|
|
|
|
### 形態（副軸，每卡 0-2 個）
|
|
|
|
- `方法論`
|
|
- `工具實作`
|
|
- `觀點主張`
|
|
- `架構設計`
|
|
- `案例經驗`
|
|
|
|
---
|
|
|
|
## 規則
|
|
|
|
1. **先查重、再登記、才使用**：禁止繞過字典在卡片直接冒新標籤；新標籤先確認非現有同義詞，加進本檔（附定義）再用。
|
|
2. **領域 vs 形態分開**：領域是「講什麼主題」，形態是「以什麼形式呈現」，不要混。
|
|
3. **頂層 INDEX.md 的標籤視圖依本字典的軸聚類**——字典改了，INDEX 視圖跟著更新。
|
|
4. **新增領域軸要慎**：領域是檢索骨架，動它影響全庫聚類；形態軸（呈現形式）擴充較安全。不確定就先用現有最接近的，並在卡片或本檔註記「待人類複核此分類」。
|