前言¶
處理古籍數字化項目時，常見痛點是：影印版掃描圖識別率低、斷句靠人工、識別出的錯字沒有記錄、實體和關係抽出來之後沒有地方沉澱，最後只留下一堆散文件。這個 Skill 把這條鏈路整理成了一套可複用的流程。
這是什麼¶
古籍OCR與知識庫構建v1.1.2（座標 @user_df439908/ancient-book-kb）是 SkillHub 上由社區開發者 user_df439908 發佈的技能，分類爲 knowledge-management，方法論源自 github.com/baojie/shiji-kb。它面向兩類輸入：影印版掃描圖（需要 OCR）和已數字化的古籍文本（直接進入句讀與標註環節），目標是把一頁古籍從圖片變成帶句讀、帶錯字記錄、帶實體標註的結構化數據，並能導出爲知識庫或三元組。
SkillHub 頁面顯示：評分 100000，下載 1055 次，安裝 0 次，標籤 requires_api_key=true。頁面登記的版本字段爲 1.0.3，Skill 名稱中帶有 v1.1.2 字樣。
核心功能¶
按官方簡介，能力覆蓋以下幾塊：
- OCR 獲取全鏈路：按「查數字化庫 → 本地 VLM → 雲端 API → 回退校正」的順序取文本，優先用已有的數字化成果，其次才走識別，識別失敗時有回退與校正環節。
- 句讀排版：對識別或已有的文本做斷句與排版整理。
- 錯字標註：記錄 OCR 結果中疑似識別錯誤的位置，而不是直接覆蓋原文。
- 實體標註：覆蓋 18 類實體，屬於命名實體識別（NER）範疇。
- 知識庫導出：將標註結果整理爲知識庫或三元組格式，供後續檢索或圖譜使用。
觸發方式上，當用戶提到古書、古籍、影印本、OCR、句讀、實體標註、NER、知識庫、知識圖譜、人物關係等關鍵詞，或直接提供古籍文本/圖片時使用；也可以顯式要求「用 ancient-book-kb 處理」手動調用。
安裝與啓用¶
官方資料中沒有給出具體的安裝命令，且該技能帶 requires_api_key=true 標籤，意味着雲端 OCR 環節需要自行配置 API key。實際安裝與配置方式以技能包內的 SKILL.md 和 SkillHub 頁面說明爲準，本文不做轉述猜測。
需要注意：本地 VLM 與雲端 API 兩條識別路徑對模型和密鑰的要求不同，跑之前先把這兩條路徑各自要依賴的資源確認清楚，避免在識別環節才發現缺 key。
典型處理流程¶
按簡介描述的鏈路，一條典型的處理流程是：
- 先查數字化庫，確認這頁古籍是否已有可用文本，有就直接進入下一步，避免重複識別。
- 沒有現成文本時，先用本地 VLM 識別掃描圖；本地結果不可靠或不可用時，轉雲端 API。
- 對識別結果做回退校正，把明顯錯字標註出來而不是直接改正。
- 對校正後的文本做句讀與排版。
- 執行 18 類實體標註，識別人物、地點、職官等命名實體。
- 將實體與關係導出爲知識庫或三元組，落到知識庫文件裏。
各步驟的具體命令、參數和輸出文件格式以技能包內文檔爲準，本文不逐條轉寫，避免給出未經覈實的用法。
適用場景與注意¶
適合的場景：影印本掃描圖批量轉文本、已有數字化古籍的句讀與校對、從古籍中抽實體和人物關係建庫、需要把標註結果導成三元組的圖譜前期工作。
需要注意的地方：
- 識別質量受掃描質量影響，影印版頁面的版式、印章、批註都會增加識別難度，校正環節不能省。
- 18 類實體的具體類別清單以技能包文檔爲準，本文不逐一羅列。
- 雲端 API 路徑會產生費用並依賴密鑰配置，批量處理前先在小樣本上驗證一輪。
- 方法論源自 shiji-kb 項目，如果需要深入理解設計思路，可以直接讀該項目源碼。
小結¶
這個 Skill 的價值在於把古籍數字化中「識別—校正—句讀—標註—入庫」的散裝環節串成一條有順序的鏈路，特別是先查數字化庫、再走本地和雲端識別的降級順序，以及錯字標註而非直接改字的做法，適合需要長期維護古籍知識庫的開發者。
官方地址：https://api.skillhub.cn/user_df439908/ancient-book-kb
