前言¶
处理古籍数字化项目时，常见痛点是：影印版扫描图识别率低、断句靠人工、识别出的错字没有记录、实体和关系抽出来之后没有地方沉淀，最后只留下一堆散文件。这个 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
