前言¶
接到知識庫或 RAG 需求時，最常見的卡點不在模型，而在文檔：哪些文檔該進庫、進來之前要不要清洗、按什麼粒度切、切完怎麼證明檢索真的能命中。不少人的做法是把目錄裏所有文檔按固定字數一刀切，灌進向量庫就算完成，等上線才發現關鍵內容召回不到，只能回頭重新切。
下面介紹的這個 Skill 把前面這段整理工作拆成了一套有先後順序的流程，而不是一次性的腳本。
這是什麼¶
「知識庫搭建」（座標 @kunlungrowth/kunlun-kb-build）是崑崙增長髮布在 SkillHub 上的一個知識管理類 Skill，當前版本 1.3.0，來源企業（enterprise），分類 knowledge-management。
它面向的問題是知識庫建設的前期整理與持續維護：文檔盤點分級、清洗與結構化、切分粒度的選擇、元數據、檢索驗證、權限設計和後續運營。定位上同時覆蓋兩類產物——企業知識庫和 RAG 知識體。
按公開資料，它不需要 API Key（標籤 requires_api_key=false）。頁面顯示評分 100000，下載 1365 次，安裝數爲 0。
核心能力¶
依據其官方簡介，這個 Skill 的能力分成六個環節，順序上有先後：
- 文檔盤點分級。先把手上文檔按價值和時效分檔，決定哪些進庫、哪些只做索引、哪些歸檔。
- 清洗與結構化。去掉重複、失效、格式錯亂的頁面，把非標文檔整理成可入庫的結構。
- 按類型定切分粒度。切分長度不設全局統一值，按文檔類型分別確定。
- 元數據先行。入庫前先定義並寫入元數據，後續檢索和過濾依賴它。
- 檢索驗證。用固定題集檢驗召回效果，而不是靠主觀感覺判斷「搜得到」。
- 權限設計與持續運營。入庫之後還要考慮誰能看、內容過期後怎麼更新。
配套的方法包括四象限分級、30 題驗證法、stale 率閾值與召回驗收標準。這幾項的作用分別是：四象限分級給出文檔分檔的座標系，30 題驗證法提供統一的召回驗收題集，stale 率閾值用來判斷庫中內容過期的比例，召回驗收標準則定義「合格」的判定線。
爲什麼先分級再切分¶
這一步容易被跳過。如果不先分級，清洗和切分的工作量會攤在全部文檔上，其中相當一部分可能是一次性通知、過期公告或與業務無關的歸檔內容，投入產出比很低。先分檔再決定處理深度，後面每一層只面對真正需要入庫的那部分文檔。
元數據同樣如此。如果元數據是入庫後再補，往往會出現文檔已經切好、來源和生效日期對不上的情況，導致檢索結果無法過濾。按這個 Skill 的順序，元數據在寫入階段就確定下來。
典型用法¶
官方公開資料給出的是方法論與驗收標準，具體的調用命令、目錄結構和配置字段未在已覈實資料中列出，這裏不做推測。實際使用時需要打開官方頁面確認包內的說明文件，再按其給出的方式啓用。
如果按該 Skill 的流程推進，一個可行的落地順序是：
- 先盤點現有文檔，用四象限分級標註每份文檔的處理檔位。
- 對進入入庫範圍的文檔做清洗和結構化。
- 按文檔類型確定各自的切分粒度。
- 定義並寫入元數據字段。
- 準備 30 道驗證題，跑一遍召回，按召回驗收標準判定是否達標。
- 設定 stale 率閾值，把內容更新做成持續任務，同時補上權限配置。
適用場景與注意¶
適合的場景：企業內部知識庫的首次搭建，以及 RAG 應用上線前的語料整理和驗收。已經有一批散落文檔、但缺少統一分級和驗收標準的團隊，是主要適用對象。
需要注意的幾點：
- 評分和下載量反映的是頁面數據，不代表檢索效果，實際效果仍以自己的驗證題結果爲準。
- 官方簡介只承諾方法論和驗收標準，不承諾特定模型或特定向量庫，切分與檢索的實現需要自己落地。
- 安裝數顯示爲 0，說明公開可見的採納數據有限，團隊使用前建議先在小範圍文檔上跑通驗證環節。
結尾¶
這個 Skill 的價值在於把知識庫建設中最容易出錯的前期工作——文檔分級、切分粒度、元數據和驗收——整理成了一條有順序的流程，而不是零散的腳本。需要確認最新版本和安裝方式，可以看官方地址：https://api.skillhub.cn/kunlungrowth/kunlun-kb-build
