古籍整理这个行当我混了不少年头。前阵子有个年轻人来问我说手头一部明刻本的影印件里头有个职官名查不到问我怎么办。我给他翻了半天《历代职官表》最后发现是避讳字改了写法。这种事儿在古籍工作里边太常见了——真正耗时间的从来不是“认字”而是“翻书”。也正是这些零碎却磨人的活儿让我动了心思能不能把这些年积累下来的查考方法做成一个个能复用的“古籍 skill”让AI替我跑掉那些机械的部分我专心做判断这个打算就是这个系列全记录的第一篇缘起。1. 古籍工作最耗时的环节是散落在各处的“查证”古籍整理、校勘、注释这一路做下来我越来越清楚一件事专业知识固然重要但整个工作链条里真正吃掉大把时间的是一连串“查东西”的动作。书名要知道异称人要知道字号年号要核对纪元避讳要分辨是哪个帝王讳异体字要还原成通行字形这些动作如果全靠手工一份几万字的底本就能耗掉好几天。1.1 校勘、注释、辑佚这些功课底色其实很“体力活”很多人以为做古籍是纯天赋活读得懂就能做。真进去了才发现哪有什么玄学全是体力活。我举个例子你在《说文解字注》里查到某个字段玉裁说“某本作某”你就要去翻那个“某本”到底是不是真的这么写。这本原书在哪个图书馆、哪个版本、哪一页、钤过谁的印都要一一落实。这个过程中你的眼睛在扫影印本手里在做比对表脑子里还要记着异文出现的版本次序。这些步骤高度重复却要求极度细心稍一走神就是一条错误校记。1.2 一个搜索框解决不了的难题现在的人习惯有不懂就搜索。但古籍领域不一样搜索框给不了你完整的答案。比如“天官”这个词在《周礼》里是官制在《史记·天官书》里是天文在道教文献里又是一个意思。同一个词条脱离上下文没法判断。再比如避讳字“玄”字在康熙朝要写成“元”但你不能一看到“元”就说是避讳可能人家本来就写“元”。这类判断需要一套完整的推理链单纯靠关键词检索完全推不出来。1.3 我为什么开始折腾AI读古籍最早我也觉得AI在古籍面前就是玩具。但后来试了几次发现它的强项恰好补我的短板记忆量大检索快组合能力好。我给它的材料足够多、规则足够清楚的时候它能把几条线索揉在一起给出一个“可能的答案集”我再人肉验证效率一下就上来了。可这种用法很快遇到了瓶颈每次都要把一大堆规则、术语、背景重新讲一遍反复调累还容易漏。当时我就想要是能把一段完整的古籍查证流程像插件一样“装”到模型脑子里让它一进入某个任务就自动按照这套方法论干活该多好。2. skill这东西凭什么能承载一套古籍方法论“skill”这个词这两年在大模型生态里风头很盛。我在豆包的技能广场、Codex的技能目录、还有SpringAI这些框架里都看到类似的东西冒出来。它听起来玄拆开看其实没那么复杂。2.1 从“提示词”到“技能包”一个形态上的跨越早先我们调AI靠的是提示词一大段话甩过去告诉它“你是个古籍专家你要做什么”。这种方式的毛病很直接规则全混在对话里用过一次就忘了下次还得重新来而且提示词一旦长了语气容易乱前后自相矛盾的情况经常发生。skill的出现是把这些规则打包了。一个skill本质上是一个有结构的文件夹里面有一个主描述文件比如SKILL.md、若干个参考材料、一些示例甚至可能带一点数据表。模型在对话前读一遍这个文件包就知道自己现在是什么角色、要执行什么流程、判断标准是什么、输出格式是什么。这样一来“能力”不再依赖我每次即兴发挥而是被固化下来了。2.2 不同生态里的skill长得不完全一样我现在观察到的skill生态挺分裂的但内核相通。像Codex里的skill就是项目目录下的一个子目录主要靠文本描述驱动适合程序员场景豆包那类偏向C端的技能广场更注重“用户能直接调用的功能”封装度更高还有一些像workbuddy这种工具链里skill其实是把多个自动化动作串联在一起。SpringAI框架里也有类似概念给开发者在Java侧做agent技能扩展用。说白了万变不离其宗都是“任务定义规则说明输出约束”的组合只是打包格式和运行环境不同而已。2.3 一份合格的古籍skill该装些什么按我自己试验下来的理解古籍类skill至少要包含四样东西。角色约束告诉模型它现在是一个具备目录学、校勘学基础的助手不是万能聊天机器人要在自己不懂的时候明说。任务流程把“给定一段古籍文本/书影信息”到“给出校勘意见/注释考证”中间的过程拆成固定步骤比如第一步析出版本信息第二步比对异文第三步查避讳第四步判断正误第五步输出校记。领域规则把古籍工作中那些硬规则写进去。比如避讳字的分朝代规则、职官年号的规范写法、异体字的常见对应表。这些不一定写得很全但要让模型知道“存在这些规则”并且知道遇到不确定时该去哪里查。输出格式古籍工作有它自己的文体校勘记怎么写、注释怎么列、考证怎么缀都有约定俗成的格式。我会要求模型严格按这个格式输出方便我直接粘进文稿。3. 用“版本校勘”当试验田为什么第一站选它确定了要做skill接下来就是选哪个领域先动手。我没挑看起来更有趣的“训诂”或者“辑佚”而是选了版本校勘。原因很简单校勘里大量的动作够机械、够规则化适合先试验。3.1 校勘工作中真正可以预编译的环节校勘的核心动作之一是对校拿底本和参校本逐字比对把异文一个个摘出来。这个过程里找异文这件事本身非常机械。一个模型只要识字认字能力够给它两段文本它就能把差异标记出来。但传统做法里这一步是要靠人一行行眼睛瞪的。做了古籍工作的人都知道比较一页书超过半小时眼睛就开始“滑字”漏掉的异文比找出来的还多。AI来做这个几乎没有疲劳问题。3.2 规则化判断和“人味判断”的分界线校勘不能全交给AI。异文找出来之后哪些是版刻讹误哪些是通假字哪些是避讳改字哪些是异体字——这些判断一部分可以规则化。比如避讳改字每个朝代避谁、怎么避是有谱系的能写进skill里。再比如“以”“巳”“已”混刻这种底层字形问题也能通过字形规范做初步甄别。但理校的时候——也就是没有版本依据、只能靠理据推理的那个环节——AI不能替我做决定。我看到很多AI校勘演示直接给出“应改作某字”看着很专业其实很危险。古籍校勘最忌讳的就是无据妄改。所以我做skill时特意规定理校判断只能给出“建议”和“理由”不能直接下结论。这条边界是我认为古籍skill里最重要的设计原则。3.3 一个最小可行的版本异文skill长什么样我第一版捣鼓出来的东西结构上大概是这样的技能名称版本异文勘录助手 角色具备版本目录学与校勘学基础的助理 触发用户提供底本文字、参校本文字及版本信息时启动 步骤 1. 读取底本与参校本文字标记所有差异点 2. 对每个差异点判断差异类型 - 形近讹误 - 异体字 - 避讳改字 - 通假字 - 虚词增减 - 无法判断 3. 对避讳改字类调用避讳资料表给出讳字原字、避讳年代、证据来源 4. 对无法判断的内容标记为“待人工复核”禁止自动推断 5. 输出《异文对照表》序号、底本用字、参校本用字、差异类型、判断依据、处理建议 输出要求校勘记格式注明各本出处行文简洁不用浮夸修饰语这个结构很简陋但重要的是它把“什么事让模型干”“什么事不让它干”说清楚了。后面我在实测中发现当我把这条边界写死之后模型给出的判断明显收敛了不再瞎给结论。4. 缘起之年的项目边界第一期我不打算贪多做古籍skill最容易犯的毛病是想一步到位把所有古籍任务全部包装成技能。这既不可能也没必要。我给这个“古籍 skill 项目”定下的第一条规矩就是模块化一个小任务一个skill若干个小skill再考虑怎么组合。4.1 第一期任务清单与验收标准第一期我给自己划了三个目标版本异文自动勘录能对校本和底本产出可用、待复核的异文对照表。避讳字查考与标注给一段繁体文本标出可能的讳字并给出讳所自、对应原字。职官年号快速查考从一部书里抽出职官名和年号按要求转换成规范名称不规范的给出依据。验收标准也很朴素异文对照表查全率不低于95%漏掉一个我人工扫一眼能发现就行避讳字判断准确率不追求百分百但给出的判断必须有文献依据可供复核职官年号查考结果整理出来不能有硬伤。4.2 数据、状态和工具链的选择我做技能的过程中试用过不少环境。豆包那种轻量技能市场适合快速验证想法Codex技能目录适合挂在agent工作流里跑文件SpringAI那种则更适合以后做真正的应用服务。不同环境各有长处没必要拉踩反正底层逻辑一样把任务流程描述清楚把规则打包好剩下的是适配问题。倒是有一点要注意部署环境。我看很多人用本地模型跑这类技能因为古籍材料不少会涉及一些文本敏感问题其实不是核心原因是古籍扫描件的识别成本高、版权限制严不太方便随便传到在线平台。所以也有人问我“deepseek harness附带skill怎么部署到内网服务器”这个我后面会专门写一篇简单说就是先把技能文件包和模型权重放到内网机器再在harness的配置里指定技能路径然后通过本地接口调用原理不复杂。4.3 三类测试文本的选择测试skill的时候不能拿干净整齐的文本喂它那样测不出问题。我准备了三类古典文本做自测第一类是宋元刻本的简体影印涉及异体字和俗字第二类是明清方志的整理稿原本有标点但我要测试它去掉标点后能不能恢复断句第三类是经部文献的注疏本里头充满了双行夹注、校语和引文结构极其复杂。这三类文本代表了古籍阅读中的典型场景断句难、异体多、结构乱。第一期我不会要求模型全套做对但每类至少要能跑通流程产出可复核的结果。5. 为什么要写“全记录”给同在折腾的人留一套路标现在网上讲skill的教程不少写小说有写小说的skill备课有备课的skill做短剧有做短剧的skill。但大部分教程上来就是给一个成品文件告诉你复制粘贴就能用。这种帖子看着爽用起来问题很多因为你不知道它背后的取舍什么环节是人工兜底、什么规则是拍脑袋加的、为什么这样切分任务边界。等你想改一改适配自己的资料时无从下手。5.1 大部分skill教程只讲“怎么写”不讲“怎么想”我自己写这个系列最想避开的坑就是这个。我想记下来的不只是最终的skill文件而是每一步里“我怎么判断该这么做”的过程。比如我为什么把理校判断设为禁区因为我吃过无据妄改的亏。以前我让AI帮我做一次文献比对它“体贴”地帮我把明显讹误改正了结果我复核时发现那个“讹误”其实是另一个版本的异文有文献依据只是看起来不合情理。从那时起我就笃定技能设计必须保留人工复核的位置这是底线。这个教训我认为比skill文件本身值钱。所以全记录里我会把这类决策背后的实际案例写出来。5.2 我给自己定的记录规则写这个系列我给自己定了三条记录规则一是不写空话凡是提到方法必须有对应的实际案例说明用在哪里、效果如何二是写失败我不能只报喜不报忧那些试了没用、被模型带偏的案例反而最值得记录三是给出路标每篇文章末尾提一下下一步准备做什么这样系列文章之间可以衔接上。5.3 这个系列接下来的走向按照现在的计划这一系列分为几篇往下写第一篇讲缘起就是本篇第二篇写版本异文skill的实际制作过程包括我在试错中踩的坑第三篇写避讳字查考skill这个对古籍安全影响最大第四篇打算写组合使用怎么让多个skill协同工作跑通一个完整的校勘流程再做的话可能是部署问题包括离线环境、内网环境的配置。第一篇“缘起”能落到纸面本身就是一种推动。我见过太多人起手式就是“让AI理解古籍”结果半年过去了还在原地打转。我觉得不如反过来先从最不起眼的小环节开始把一个“查异文”的动作做扎实再做下一个。技术的价值不体现在口号里体现在那些被省下来的翻书时间里。这份全记录就是给我自己也给同在这条路上折腾的人的一份约定咱们一步一步来慢就慢点只要每一步都能拿出来复核。 
长河君 · 2026/10/7 4:44:33 · 阅读 1.2k 古籍AI技能化实践：从版本校勘到避讳查考的全记录
古籍整理这个行当我混了不少年头。前阵子有个年轻人来问我说手头一部明刻本的影印件里头有个职官名查不到问我怎么办。我给他翻了半天《历代职官表》最后发现是避讳字改了写法。这种事儿在古籍工作里边太常见了——真正耗时间的从来不是“认字”而是“翻书”。也正是这些零碎却磨人的活儿让我动了心思能不能把这些年积累下来的查考方法做成一个个能复用的“古籍 skill”让AI替我跑掉那些机械的部分我专心做判断这个打算就是这个系列全记录的第一篇缘起。1. 古籍工作最耗时的环节是散落在各处的“查证”古籍整理、校勘、注释这一路做下来我越来越清楚一件事专业知识固然重要但整个工作链条里真正吃掉大把时间的是一连串“查东西”的动作。书名要知道异称人要知道字号年号要核对纪元避讳要分辨是哪个帝王讳异体字要还原成通行字形这些动作如果全靠手工一份几万字的底本就能耗掉好几天。1.1 校勘、注释、辑佚这些功课底色其实很“体力活”很多人以为做古籍是纯天赋活读得懂就能做。真进去了才发现哪有什么玄学全是体力活。我举个例子你在《说文解字注》里查到某个字段玉裁说“某本作某”你就要去翻那个“某本”到底是不是真的这么写。这本原书在哪个图书馆、哪个版本、哪一页、钤过谁的印都要一一落实。这个过程中你的眼睛在扫影印本手里在做比对表脑子里还要记着异文出现的版本次序。这些步骤高度重复却要求极度细心稍一走神就是一条错误校记。1.2 一个搜索框解决不了的难题现在的人习惯有不懂就搜索。但古籍领域不一样搜索框给不了你完整的答案。比如“天官”这个词在《周礼》里是官制在《史记·天官书》里是天文在道教文献里又是一个意思。同一个词条脱离上下文没法判断。再比如避讳字“玄”字在康熙朝要写成“元”但你不能一看到“元”就说是避讳可能人家本来就写“元”。这类判断需要一套完整的推理链单纯靠关键词检索完全推不出来。1.3 我为什么开始折腾AI读古籍最早我也觉得AI在古籍面前就是玩具。但后来试了几次发现它的强项恰好补我的短板记忆量大检索快组合能力好。我给它的材料足够多、规则足够清楚的时候它能把几条线索揉在一起给出一个“可能的答案集”我再人肉验证效率一下就上来了。可这种用法很快遇到了瓶颈每次都要把一大堆规则、术语、背景重新讲一遍反复调累还容易漏。当时我就想要是能把一段完整的古籍查证流程像插件一样“装”到模型脑子里让它一进入某个任务就自动按照这套方法论干活该多好。2. skill这东西凭什么能承载一套古籍方法论“skill”这个词这两年在大模型生态里风头很盛。我在豆包的技能广场、Codex的技能目录、还有SpringAI这些框架里都看到类似的东西冒出来。它听起来玄拆开看其实没那么复杂。2.1 从“提示词”到“技能包”一个形态上的跨越早先我们调AI靠的是提示词一大段话甩过去告诉它“你是个古籍专家你要做什么”。这种方式的毛病很直接规则全混在对话里用过一次就忘了下次还得重新来而且提示词一旦长了语气容易乱前后自相矛盾的情况经常发生。skill的出现是把这些规则打包了。一个skill本质上是一个有结构的文件夹里面有一个主描述文件比如SKILL.md、若干个参考材料、一些示例甚至可能带一点数据表。模型在对话前读一遍这个文件包就知道自己现在是什么角色、要执行什么流程、判断标准是什么、输出格式是什么。这样一来“能力”不再依赖我每次即兴发挥而是被固化下来了。2.2 不同生态里的skill长得不完全一样我现在观察到的skill生态挺分裂的但内核相通。像Codex里的skill就是项目目录下的一个子目录主要靠文本描述驱动适合程序员场景豆包那类偏向C端的技能广场更注重“用户能直接调用的功能”封装度更高还有一些像workbuddy这种工具链里skill其实是把多个自动化动作串联在一起。SpringAI框架里也有类似概念给开发者在Java侧做agent技能扩展用。说白了万变不离其宗都是“任务定义规则说明输出约束”的组合只是打包格式和运行环境不同而已。2.3 一份合格的古籍skill该装些什么按我自己试验下来的理解古籍类skill至少要包含四样东西。角色约束告诉模型它现在是一个具备目录学、校勘学基础的助手不是万能聊天机器人要在自己不懂的时候明说。任务流程把“给定一段古籍文本/书影信息”到“给出校勘意见/注释考证”中间的过程拆成固定步骤比如第一步析出版本信息第二步比对异文第三步查避讳第四步判断正误第五步输出校记。领域规则把古籍工作中那些硬规则写进去。比如避讳字的分朝代规则、职官年号的规范写法、异体字的常见对应表。这些不一定写得很全但要让模型知道“存在这些规则”并且知道遇到不确定时该去哪里查。输出格式古籍工作有它自己的文体校勘记怎么写、注释怎么列、考证怎么缀都有约定俗成的格式。我会要求模型严格按这个格式输出方便我直接粘进文稿。3. 用“版本校勘”当试验田为什么第一站选它确定了要做skill接下来就是选哪个领域先动手。我没挑看起来更有趣的“训诂”或者“辑佚”而是选了版本校勘。原因很简单校勘里大量的动作够机械、够规则化适合先试验。3.1 校勘工作中真正可以预编译的环节校勘的核心动作之一是对校拿底本和参校本逐字比对把异文一个个摘出来。这个过程里找异文这件事本身非常机械。一个模型只要识字认字能力够给它两段文本它就能把差异标记出来。但传统做法里这一步是要靠人一行行眼睛瞪的。做了古籍工作的人都知道比较一页书超过半小时眼睛就开始“滑字”漏掉的异文比找出来的还多。AI来做这个几乎没有疲劳问题。3.2 规则化判断和“人味判断”的分界线校勘不能全交给AI。异文找出来之后哪些是版刻讹误哪些是通假字哪些是避讳改字哪些是异体字——这些判断一部分可以规则化。比如避讳改字每个朝代避谁、怎么避是有谱系的能写进skill里。再比如“以”“巳”“已”混刻这种底层字形问题也能通过字形规范做初步甄别。但理校的时候——也就是没有版本依据、只能靠理据推理的那个环节——AI不能替我做决定。我看到很多AI校勘演示直接给出“应改作某字”看着很专业其实很危险。古籍校勘最忌讳的就是无据妄改。所以我做skill时特意规定理校判断只能给出“建议”和“理由”不能直接下结论。这条边界是我认为古籍skill里最重要的设计原则。3.3 一个最小可行的版本异文skill长什么样我第一版捣鼓出来的东西结构上大概是这样的技能名称版本异文勘录助手 角色具备版本目录学与校勘学基础的助理 触发用户提供底本文字、参校本文字及版本信息时启动 步骤 1. 读取底本与参校本文字标记所有差异点 2. 对每个差异点判断差异类型 - 形近讹误 - 异体字 - 避讳改字 - 通假字 - 虚词增减 - 无法判断 3. 对避讳改字类调用避讳资料表给出讳字原字、避讳年代、证据来源 4. 对无法判断的内容标记为“待人工复核”禁止自动推断 5. 输出《异文对照表》序号、底本用字、参校本用字、差异类型、判断依据、处理建议 输出要求校勘记格式注明各本出处行文简洁不用浮夸修饰语这个结构很简陋但重要的是它把“什么事让模型干”“什么事不让它干”说清楚了。后面我在实测中发现当我把这条边界写死之后模型给出的判断明显收敛了不再瞎给结论。4. 缘起之年的项目边界第一期我不打算贪多做古籍skill最容易犯的毛病是想一步到位把所有古籍任务全部包装成技能。这既不可能也没必要。我给这个“古籍 skill 项目”定下的第一条规矩就是模块化一个小任务一个skill若干个小skill再考虑怎么组合。4.1 第一期任务清单与验收标准第一期我给自己划了三个目标版本异文自动勘录能对校本和底本产出可用、待复核的异文对照表。避讳字查考与标注给一段繁体文本标出可能的讳字并给出讳所自、对应原字。职官年号快速查考从一部书里抽出职官名和年号按要求转换成规范名称不规范的给出依据。验收标准也很朴素异文对照表查全率不低于95%漏掉一个我人工扫一眼能发现就行避讳字判断准确率不追求百分百但给出的判断必须有文献依据可供复核职官年号查考结果整理出来不能有硬伤。4.2 数据、状态和工具链的选择我做技能的过程中试用过不少环境。豆包那种轻量技能市场适合快速验证想法Codex技能目录适合挂在agent工作流里跑文件SpringAI那种则更适合以后做真正的应用服务。不同环境各有长处没必要拉踩反正底层逻辑一样把任务流程描述清楚把规则打包好剩下的是适配问题。倒是有一点要注意部署环境。我看很多人用本地模型跑这类技能因为古籍材料不少会涉及一些文本敏感问题其实不是核心原因是古籍扫描件的识别成本高、版权限制严不太方便随便传到在线平台。所以也有人问我“deepseek harness附带skill怎么部署到内网服务器”这个我后面会专门写一篇简单说就是先把技能文件包和模型权重放到内网机器再在harness的配置里指定技能路径然后通过本地接口调用原理不复杂。4.3 三类测试文本的选择测试skill的时候不能拿干净整齐的文本喂它那样测不出问题。我准备了三类古典文本做自测第一类是宋元刻本的简体影印涉及异体字和俗字第二类是明清方志的整理稿原本有标点但我要测试它去掉标点后能不能恢复断句第三类是经部文献的注疏本里头充满了双行夹注、校语和引文结构极其复杂。这三类文本代表了古籍阅读中的典型场景断句难、异体多、结构乱。第一期我不会要求模型全套做对但每类至少要能跑通流程产出可复核的结果。5. 为什么要写“全记录”给同在折腾的人留一套路标现在网上讲skill的教程不少写小说有写小说的skill备课有备课的skill做短剧有做短剧的skill。但大部分教程上来就是给一个成品文件告诉你复制粘贴就能用。这种帖子看着爽用起来问题很多因为你不知道它背后的取舍什么环节是人工兜底、什么规则是拍脑袋加的、为什么这样切分任务边界。等你想改一改适配自己的资料时无从下手。5.1 大部分skill教程只讲“怎么写”不讲“怎么想”我自己写这个系列最想避开的坑就是这个。我想记下来的不只是最终的skill文件而是每一步里“我怎么判断该这么做”的过程。比如我为什么把理校判断设为禁区因为我吃过无据妄改的亏。以前我让AI帮我做一次文献比对它“体贴”地帮我把明显讹误改正了结果我复核时发现那个“讹误”其实是另一个版本的异文有文献依据只是看起来不合情理。从那时起我就笃定技能设计必须保留人工复核的位置这是底线。这个教训我认为比skill文件本身值钱。所以全记录里我会把这类决策背后的实际案例写出来。5.2 我给自己定的记录规则写这个系列我给自己定了三条记录规则一是不写空话凡是提到方法必须有对应的实际案例说明用在哪里、效果如何二是写失败我不能只报喜不报忧那些试了没用、被模型带偏的案例反而最值得记录三是给出路标每篇文章末尾提一下下一步准备做什么这样系列文章之间可以衔接上。5.3 这个系列接下来的走向按照现在的计划这一系列分为几篇往下写第一篇讲缘起就是本篇第二篇写版本异文skill的实际制作过程包括我在试错中踩的坑第三篇写避讳字查考skill这个对古籍安全影响最大第四篇打算写组合使用怎么让多个skill协同工作跑通一个完整的校勘流程再做的话可能是部署问题包括离线环境、内网环境的配置。第一篇“缘起”能落到纸面本身就是一种推动。我见过太多人起手式就是“让AI理解古籍”结果半年过去了还在原地打转。我觉得不如反过来先从最不起眼的小环节开始把一个“查异文”的动作做扎实再做下一个。技术的价值不体现在口号里体现在那些被省下来的翻书时间里。这份全记录就是给我自己也给同在这条路上折腾的人的一份约定咱们一步一步来慢就慢点只要每一步都能拿出来复核。