《列女传》里有一篇讲孟母三迁的原文我倒是记得大概可真要逐字逐句做校对麻烦就来了。我得对着影印本一个字一个字辨认繁体遇到异体字还得查字典确认断句更是要反复比对前后文。折腾了整整一个下午才勉强整理出两页纸而且我还不敢说自己的标点全对。那时候我就在想这事能不能让 AI 帮我干后来我接触到了「skill」这个概念——在大模型 agent 的工作流里skill 就是一组可复用的能力包把特定的任务拆成清晰的步骤、提示词和处理规则让模型能按标准流程干活。我当时的想法很简单如果能把古籍整理、校对、注译这一整套流程封装成一个「古籍 skill」那以后再做类似工作就不用每次从零开始调提示词了。这个念头就是我要记录的这个项目的缘起。这一篇是系列记录的第一篇我不会讲太多具体实现细节重点想说的是为什么想给古籍做一套 skill、我看到了哪些真问题、以及这个项目一开始是怎么在脑子里成型摆框架的。如果你平时也跟古籍打交道或者正在琢磨怎么给自己的专业领域做一套 skill这篇应该能给你一些参考。1. 古籍数字化的真实现状问题不在扫描在整理先说个背景。古籍数字化这事其实已经做了很多年了不是新鲜事物。国内外的图书馆、研究机构这些年扫了不少善本古籍做成了影印图像库像一些高校的图书馆数据库、公共文化机构的数字馆藏规模都不小。这些影像数据有一个好处——普通人不用跑到图书馆善本阅览室在网上就能看到珍贵的刻本、抄本的原始样貌。但这里有个很现实的问题扫描影印只是把纸上的字变成了图上的字机器能“看”到却读不懂。真正费工夫的是把图像里的内容转成可靠的文本再做标点、校勘、注释。这一步业内通常叫「整理」它恰恰是古籍数字化里最耗时、最依赖专业能力的环节。我之前试着用现成的大模型来跑这个流程结果并不理想。不是模型笨而是古籍整理这件事的门槛比大多数人想象的高得多它有四个绕不过去的坎第一是字。古籍里全是繁体字而且是不同时代的写刻风格俗体字、异体字、避讳字到处都是。比如“以”字的俗写、“日”与“曰”在字形上的微妙差别通用模型训练数据里这些样本不够多很容易认错或认不出来。第二是句读。古人写书不点标点断句靠的是对文义的理解。同一句话断在不同的位置意思可能完全相反。这事连专业学者都时有争议机器就更不用说了。第三是典故和名物。古书里大量用典涉及人名、地名、官职、器物、典章制度。要给出准确的注释模型需要足够的知识密度而通用模型在这块经常是“仿佛知道但说不准”。第四是版本异文。同一部书不同刻本之间文字有差异有的差异很小有的牵涉到文义。做校勘需要比对多个版本记录异文判断孰优孰劣这种“多文本比对”的工作对模型来说是一个结构性问题。所以你看古籍数字化真正的瓶颈根本不在拍照扫描设备多好、像素多高都没用卡在“识别—断句—校勘—注释”这一整条整理流水线上。而这条流水线恰好是我觉得 AI 最该帮上忙、也最有可能帮上忙的地方。2. 为什么是 skill而不是一条更长的提示词我最初也走过弯路一直在调提示词写得越来越长什么角色扮演、步骤拆解、输出格式都塞进去。效果有改善但问题也很明显提示词越长模型越容易在其中迷失重点尤其是开源小模型经常顾头不顾尾。同一套提示词换个任务场景就得重新调整完全没法复用。整理古籍是一个多步骤的协作流程不是一次问答能搞定的。先要做图像预处理再做文字识别接着处理异体字、断句然后注释、校勘最后还要按固定格式输出。这中间任何一个环节出错后面全乱。这不是提示词能解决的你需要的是把流程拆成可编排的模块。后来我接触了 agent、workflow 这些玩法再看 skill 这个概念就有点豁然开朗的感觉。在大模型 agent 的架构里skill 可以理解为一个「能力包」它把一个领域的任务拆成清晰的步骤每个步骤配置好对应的提示词、工具调用方式和处理规则然后做成一个可以被 agent 调用的模块。你用的时候不用再现场写一大段复杂的提示词只需要说“用古籍 skill 处理这份文献”agent 就知道该按什么顺序干什么。提示skill 和普通提示词本质的区别在于提示词是“一次性指令”skill 是“可复用的能力单元”。skill 内部可以包含多个提示词、多步处理逻辑甚至能调用外部工具。说白了提示词是一张菜谱skill 是一整套中央厨房。这里我用个生活化的类比。以前用 AI 做事等于你每次都把工具从工具箱里翻出来现场组装。做古籍整理我得先想一遍流程先 OCR、再清洗文本、再断句、再注释、再校勘……每次都重新写一遍又慢又容易漏。而 skill 就是把这些工具提前组装好、放在一个固定位置里你只需要按一下开关它自己流水线就转起来了。这个思路放到古籍领域尤其合适因为古籍整理的流程极度固定每一步该干什么几乎是行业共识。既然流程是固化的就完全值得把它沉淀成一套 skill让 AI 按标准流程干活。3. 这个 skill 要解决的问题到底是什么先做减法真正开始设计之前我让自己冷静了一下把所有想法都列出来然后做了一轮减法。因为古籍整理这件事能做的东西太多了如果不划清边界这个项目大概率会烂尾。我先列了一下可能的场景大概有这么几类古籍文本的 OCR 识别与清洗自动繁简转换和异体字标准化古籍自动断句、标点字词注释、典故溯源多版本比对和校勘记生成白话翻译辅助按固定体例排版输出整理稿每一项单拿出来都能做一个独立项目。要是全都要保证做不完。所以我给自己定了三个原则第一先服务自己最痛的点。我最常用的是“把一页古籍变成可引用的整理文本”包括识读、断句、简繁转换、基础注释。那我就优先解决这个。第二只做能自动化的环节。比如异体字标准化、繁简转换、固定格式输出这些规则相对清晰适合做成自动化模块。而真正需要学术判断的内容——比如校勘结论、注释准确性——我会让 AI 先给出一个“初稿”再由人确认不指望一次性到位。第三给 AI 划一个能力边界。古籍整理这个领域专家的价值在于判断AI 的价值在于速度和覆盖面。所以这个 skill 的目标不是取代专家而是把专家的时间从重复劳动里解放出来。想清楚这三点项目的边界就清晰了做一个面向“古籍文本整理”的 skill主要覆盖识别、断句、注释、格式化输出这几步。至于更深的校勘学问题后续可以迭代但第一期不做。注意做自己的项目最难的不是加功能是不加功能。每当你冒出一个新点子先问一句“这在我最常用的场景里排第几”。如果不是前三就写进 backlog 而不是当期规划。4. 项目的整体规划分四个模块而不是一个大杂烩边界定了之后我开始琢磨这个 skill 的内部结构。一个有生命力的 skill内部一定是模块化的这样才能单独调试、单独优化。我给这个项目规划了四个模块这四块就是后面几篇系列文章的主角。4.1 文本获取模块说白了就是把“图上的字”变成“可编辑的字”。这一块我会基于现成的 OCR 方案来搭但要做两层处理第一层是通用 OCR把影印本上的字先识别出来得到一个初步文本。第二层是古籍专项清洗针对 OCR 结果做后处理包括形近字纠错、异体字归一、疑似识别错误的标注。第二层是重点也是这个模块区别于“拿个 OCR 跑一遍”的核心价值。因为通用 OCR 模型在古籍上的准确率实测下来大概在 85% 到 92% 之间看起来不低但对于需要精确引用的古籍文本来说8% 的错字率已经是灾难级别了。所以后处理这层清洗至关重要。这一块的难点在于形近字的纠错需要结合上下文来判断不是简单的字库替换。4.2 文本理解模块这一步解决“读得懂”的问题包含三个子功能自动断句标点这是古籍整理里最费眼力的活。AI 可以根据句法结构、虚词使用习惯、上下文语义来推断断句位置。这个功能做完至少能帮我省掉 70% 的时间。字词注释对文中的生僻字、疑难词给出释义重点是提供“依据感”也就是告知这个释义出自什么字书或前人注疏。白话译释提供相对通顺的现代汉语翻译不做文学化处理追求语义准确。这个模块里断句标点我打算直接用模型的能力来做但要设计一个好的提示词模板把断句规则显式地告诉模型——比如“之乎者也”作为虚词时的处理、语气词前后的标点习惯、排偶句式里的对称断句等。4.3 版本比勘模块这一块放在第一期里做简化版本支持两到三个版本的同段文本对照自动标记文字差异生成初步的校勘记。真正学术意义上的版本源流考证先不做那不是靠 skill 能解决的。我对它的定位是“差异发现器”帮人快速找到不同版本之间哪里不一样至于哪个版本更好、为什么那是使用者自己的判断。说明版本校勘是古籍整理里学术含量最高的一环AI 目前只能做“机械比对”和“差异提示”。真正的判断比如“某处异文源于某本避讳”“某处脱文系刊刻失误”必须交给有专业背景的人。这个定位必须从一开始就摆正不然容易做出一个“外行觉得专业、内行觉得鸡肋”的东西。4.4 输出排版模块整理古籍是有固定体例的标点符号用全角、注释放页下还是文末、异体字要不要保留原形、校勘记用什么格式……这些都有惯例。我打算做一个模板系统让最终输出符合通用的古籍整理稿格式要求方便直接用于校对或者投稿。这个模块技术含量不高但体验影响很大。因为前面做了一堆工作最后输出格式一塌糊涂给专业用户的第一印象就是“不专业”。5. 技术选型的思考过程在李逵和李鬼之间做选择技术选型这块我主要是根据自己的实际条件做了几个取舍不一定是最优解但对我来说是可行的。模型层面我对比过通用大模型和专门微调的古籍模型。专门微调的古籍大模型在断句、命名实体识别这些单点任务上确实更好但维护成本高而且生态不成熟。我最终选择了通用大模型加精心设计的 skill 流程理由是通用模型社区活跃、迭代快而且我的 skill 流程本身就能弥补它在古籍专业性上的不足。说白了我用「流程设计」来换取「模型的通用性」。类比一下现成的古籍专用模型像一套定制西装合身是真合身但任何体形变化都得送回去改通用模型加 skill 流程像是买了一套合体商务装不是处处考究但换场合也能穿维护成本低。对我这种非专业机构的人来说后者更划算。OCR 这块我计划直接用开源或商业的成熟 OCR 引擎配上我自己写的古籍后处理脚本。这个选择没什么悬念从零训练古籍 OCR 模型不是一个人能干的事而且把精力花在清洗层见效更快。开发框架层面我会用一种基于标准 skill 机制的方式来实现确保这个 skill 能直接被常见的 agent 运行时加载调用。架构上不搞自研协议跟主流生态保持兼容这样以后生态里有新的工具、新的模型我可以随时替换。数据层面我准备了三类资源公开领域的古籍影印本和文本数据、异体字对照表、常见虚词和句读规则库。数据不需要一开始就全但至少要有第一批能用来调试的样本。6. 从缘起到起步一些写在前面的话最后说说这个系列文章的规划。既然标题写了“一-缘起”那后面自然会跟几篇。我大概想这么安排第二篇讲文本获取和清洗模块的具体实现第三篇讲断句和注释怎么做第四篇讲版本比勘和输出排版中间如果踩了什么大坑就插一篇番外。写这个系列不纯粹是记录项目也是想逼自己把思路理清楚。做技术项目有个毛病——动手很快复盘太少。过几个月回头看可能自己都忘了当初为什么做了某个决定。写下来既是给后来想做同类事情的人看也是给未来的自己留个参照。回到开头那个下午我对着影印本《列女传》一个字一个字地认累是累但那次经历反而给了我一个非常清晰的认知古籍整理不是一个“聪明”就能解决的事它需要的更多是“仔细”和“标准”。而仔细和标准恰好是 AI agent 最擅长的事情。skill 就是把这个“仔细”和“标准”固化下来的容器。我不敢说这个项目能做成什么大平台、大系统但它至少能解决我一个具体的问题让我以后再做古籍整理不再从零开始。这一点值得我投入时间和精力去试。这套 skill 目前还只是纸上谈兵但方向我已经想清楚了。下一篇我会从第一个模块开始动手把 OCR 和清洗层跑起来到时候再跟你分享第一手的实测数据和踩坑记录。