用Skills封装数字人文研究方法：从《红楼梦》共现分析实践看AI Agent技能包

这几年数字人文Digital Humanities在国内高校里很热但真正做起来的人都知道大部分时间根本不是坐在书斋里读文本而是在跟“脏数据”斗智斗勇清洗OCR错字、统一繁简、标注人名地名、计算共现关系、画关系图……每一步都要写代码、调参数、改格式换一个语料库所有工作又从头再来一遍。而最近AI Agent圈子里火起来的skills技能包我认为是解决这个问题最有潜力的一层抽象——它能把整套研究方法论打包成一个Agent可以直接调用的“技能”让数字人文研究从“每次手写流水线”变成“持续复用的研究资产”。这篇文章围绕一次具体的实践展开我把一套数字人文研究方法论写成可复用的skills并以一部古典小说的人物共现分析跑通了全流程。我会先讲清楚skills到底是什么、为什么它适合数字人文研究再给出技能拆解框架、一个完整的SKILL.md示例最后是落地过程中实际踩到的坑。如果你正在考虑给自己配一个“AI研究助手”这篇文章可以直接当模板抄作业。1. Skills不是提示词数字人文研究的底层协作方式变了1.1 从“手写流水线”到“调用研究技能”做过文本挖掘相关课题的人应该都有体会拿到一批古籍OCR文本先要清理错字、分句、分词然后用Python脚本做词频统计再调包做共现矩阵最后用Gephi或者ECharts画图。这套流程本身不算难难的是每个环节里的“判断标准”都散落在零散的脚本和笔记里。比如“人名怎么算同一个”“异体字怎么归并”“共现窗口到底取多大”这些决策换一个人、换一台电脑就全丢了。我一开始用大模型Agent来辅助处理语料以为能省事结果发现最大的痛点是“每次都要重新解释”。你用Claude或GPT分析一个文本得在提示词里把领域规范、处理步骤、输出格式全部写一遍下次换一个文本逻辑差不多但还是要重写一大段。直到我接触了skills这个概念才意识到问题不是Agent不够聪明而是我自己没有把研究方法“产品化”。Skills的出现改变了这个局面它把“分析方法论”本身变成一个目录、一组文件Agent在运行时会自动读取并执行。研究者的角色从“每次手写操作指令的人”变成了“方法论的设计者和维护者”。这是底层协作方式的变化不是省几分钟提示词的小事。1.2 Skills到底是什么一份“岗位说明书操作手册示范案例”Skills不是一个模糊概念。在Claude Code、OpenCode、Codex这些AI编程助手的生态里skill通常是一个独立目录里面有SKILL.md带YAML frontmatter的技能定义文件包含name和descriptionAgent靠这个判断何时调用该技能assets/参考资源比如别名表、领域术语表、标注规则scripts/辅助脚本比如负责把结果转换成特定格式的Python程序examples/示例输入与输出给模型一个“照着做”的样本skill和普通prompt提示词关键差异在于普通提示词是一次性指令用完就没了skill是结构化、带元数据、带参考资源、可持久化的“能力单元”。用大白话比喻提示词是你喊一句“把灯打开”而skill是给AI一套完整的“电工岗位培训手册工具包验收标准”让它能稳定完成一整类相关任务而不是只会开这一盏灯。在数字人文领域这种持久化能力尤其重要。因为人文学科的知识体系高度依赖“约定”和“规范”比如你用什么标准判定实体类别、用什么原则处理版本异文、用什么指标衡量文本相似度这些约定如果能写进skillAgent的输出就会一直在同一套方法论框架内。1.3 为什么数字人文研究特别适合Skills化数字人文研究有三个显著特点。第一方法高度重复。清洗、标注、统计、可视化这些步骤几乎每个项目都要过一遍差别只是语料箱子和研究问题。第二领域知识密集。通用模型能认出“贾宝玉”是人名但认不出“颦颦”也是林黛玉、“二爷”在某些语境下指贾宝玉。这种领域知识需要额外的参考资料支撑。第三任务链特别长。一个研究问题往往要经过“语料获取→清洗→标注→建库→分析→可视化→解释”多个环节才能回答中间任何一个环节的规则变了结果都要重跑。这三个特点正好都是skills的强项。拿实体识别来说你可以在skill里放入人物别名表、语境判定规则和预期输出格式Agent就能稳定执行。这就不是简单的“工具调用”而是一种“方法论内化”——方法不再存在于研究者的脑子里或草稿纸上而是存在于一个可以被复用、被分享、被版本管理的技能包里。2. 把研究流程拆成技能包数字人文任务如何分解2.1 数字人文研究的典型工作流一个标准数字人文项目无论研究对象是什么大体都会经过下面这一串环节语料获取OCR扫描件、网页爬取、数据库导出、手写稿转录语料清洗错字校正、繁简转换、去页眉页脚、分句分段、去除批注混排内容标注命名实体识别、词性标注、事件标注、情感判定、版本校勘量化分析词频、TF-IDF、共现分析、主题建模、网络指标、文体计量可视化呈现词云、关系网络图、时空分布图、热度地图学术解释回到人文问题本身结合定量结果形成论证与结论你会发现这个流程里的每一步都适合做成一个或者一组技能包。但难点在于怎么切分粒度才合理“语料清洗”是一个技能还是拆成“OCR校正”“繁简转换”“分句”三个技能这没有标准答案取决于你手头项目的重复频次。如果你的课题组常年处理明清方志那么“方志文本清洗”值得做一个单独技能如果只是临时跑一次完全可以把清洗逻辑塞进分析技能里。2.2 按方法论粒度划分技能包我建议采用下面这张表来规划和设计自己的技能库。这里的方法论粒度是“研究环节”每个环节对应一个可独立验证的技能包。研究阶段典型任务技能包设计思路语料清洗OCR错字校正、繁简统一、分句分段内置常见错字映射表、异体字规范表输出标准化纯文本文献整理书目信息抽取、引文格式化内置TEI/CSL规范识别书名、作者、版本、页码内容标注人名/地名/官职/时间实体识别内置别名表、语境规则、示例输出社会网络人物共现、关系强度计算定义共现窗口输出共现矩阵或边表文本挖掘主题建模、情感分析、意象统计封装LDA或词频算法输出主题词表与指标可视化网络图、时序图、地理分布生成ECharts或Gephi可导入的数据格式知识图谱实体关系三元组抽取规定SPO格式、去重规则、置信度标注这张表不是让你一次做完而是帮助你有针对性地为课题定制技能。比如你要研究“明清通俗小说中的空间书写”只需要清洗、地名识别、地理可视化三个技能就够了而研究“历代笔记小说的历史人物网络”则需要清洗、人名实体识别、共现网络、网络可视化四个技能。2.3 方法论层面以“问题”为中心而不是以“工具”为中心做数字人文容易犯一个毛病手上有个锤子看什么都像钉子。很多研究者先选定了一个工具或模型再去找问题做最后产出的往往是“我会用这个工具”的展示而不是回答了某个有价值的人文问题。方法论层面的正确拆解应该是自上而下的先定义研究问题想明白需要什么证据来支撑论点再确定要用哪些算法或模型最后考虑哪些环节适合固化进skill。举个例子你想研究《红楼梦》前八十回与后四十回在语言风格上是否有差异。这个问题需要的证据是“文本中某些功能词的使用频率是否存在显著差异”于是你需要一个“文体计量skill”包含切分文本、统计功能词频率、做显著性检验、输出对比报告这一套方法。这个skill固化之后换一部照样能用而你始终是在为人文问题设计方法而不是被工具绑着走。另一个值得借鉴的数字人文方法论是“远读”distant reading。与传统的逐字细读不同远读强调通过统计和建模在大规模语料中发现模式。远读和skills的结合非常自然远读方法本身就是一套显式的、可编程的规则天然适合包装成技能包。3. 从零写一个可复用的数字人文SKILL目录、指令与内部语料3.1 标准目录结构别把技能写成一次性脚本我先直接给出一套我实际在用的目录结构然后再解释每个文件的作用。dh-ner-skill/ ├── SKILL.md # 技能入口Agent最先读取的文件 ├── assets/ │ ├── aliases.md # 人物别名与特殊称谓映射表 │ └── corpus_rules.md # 语料预处理规则分句、繁简、异体 ├── scripts/ │ └── build_network.py # 共现网络计算脚本可选 ├── examples/ │ ├── input.txt # 示例输入 │ └── output.json # 期望输出格式 └── README.md # 使用说明与版本记录SKILL.md是灵魂写法的好坏直接决定Agent能不能正确使用这个技能。它的YAML frontmatter至少要有name和descriptiondescription用来让Agent的“技能选择器”判断在什么时候启用这个技能。很多人忽略的是description里除了写“何时用”还要写清楚“何时不用”。这样可以显著降低误触发率减少上下文浪费。3.2 描述词怎么写直接决定技能会不会被调用我在实际测试中发现失败的技能包90%问题出在description写得不好。下面列举三种典型失败模式太宽泛写“用于人文研究分析”结果Agent在普通问答中也频繁调用白白消耗上下文窗口。太狭窄写“用于分析《红楼梦》前八十回”换一部小说就不会触发技能的可复用性为零。缺乏边界没写明“何时不用”Agent在输入是英文现代文献时也可能错误启用中文古籍技能。一个正确的description应该包含三部分触发条件、处理对象、输出承诺。参考写法如下--- name: classical-chinese-ner description: 当输入是中文古籍、古典小说、地方志、史料笔记的纯文本且研究目标 包含人物关系、叙事结构、人物空间分布时应使用本技能识别文本中的 人物、地点、官职、时间四类实体并进行别名归并。 ... ---3.3 在技能包里放“方法”而不是“死数据”这是我最想强调的一个设计原则技能包里的资源文件应该放方法、规范、映射表和示例精华而不是把整个语料库都塞进去。为什么首先上下文窗口有限如果你在assets/里放了一个几百KB的语料文件Agent每次调用技能都会把这个巨无霸读进上下文window很快就会被占满后面的分析任务质量急剧下降。其次语料是项目特定的而方法是通用的。技能包是方法论资产不该绑定到某一份具体数据上。举一个实际例子做《红楼梦》人名识别不需要把一百二十回全文放进assets只需要放一份“人物别名表判定规则5条精编示例”就够了。模型在推理时本身就已经读过大量古典文本skill要提供的不是语料而是“在这个课题里你要如何判断和归并”的规则。3.4 完整示例一个古籍人名实体识别Skill的SKILL.md下面是我实际用过的SKILL.md核心内容拿来简化后展示你可以直接参考这个骨架来写自己的技能。--- name: classical-chinese-ner description: 当输入是中文古籍、古典小说、地方志、史料笔记的纯文本且研究目标 包含人物关系、叙事结构、人物空间分布时应使用本技能识别文本中的 人物、地点、官职、时间四类实体并进行别名归并。 当输入不是中文古籍样本或现代文献时应忽略本技能。 --- # 古典文献命名实体识别 ## 1. 识别范围 - person: 人物包括名、字、号、别称、代称 - place: 地点包括行政区划、地名别名 - office: 官职、科举功名 - time: 纪年、干支、季节、节日 ## 2. 别名归并规则 - 优先查询 assets/aliases.md 中的映射表 - 若文本中出现未收录别名结合上下文推断并在实体对象中 增加 certainty: low 字段 - 同一人物的名、字、号统一归并到主名 ## 3. 输出格式 { entities: [ { name: 林黛玉, type: person, aliases: [颦颦, 黛玉, 林妹妹], mentions: 42, first_chapter: 1, chapters: [1, 2, 3] } ] } ## 4. 处理流程 1. 对输入文本按回/卷/章分块 2. 逐块识别实体并归并 3. 合并结果并去重 4. 输出JSON你会发现这个skill已经把“识别范围”“归并规则”“输出格式”“处理流程”全部界定清楚。这样Agent执行出来的结果就稳定得多不会每次给你不同结构的数据。对于研究方法论来说输出的稳定性本身就是一种非常重要的学术价值。4. 一次完整的数字人文闭环以《红楼梦》人物共现分析为例4.1 研究问题与实验准备理论讲了那么多还是得跑一次真实项目才能看出skills到底值不值。我选的实验题目是《红楼梦》前八十回主要人物关系网络的结构分析。研究问题很简单贾宝玉、林黛玉、薛宝钗、王熙凤、贾母等主要人物之间的互动关系在共现数据上呈现出什么样的结构特征黛玉和宝钗各自与宝玉的互动强度差异有多少王熙凤在关系网络里处于什么位置实验环境方面我用Claude Code作为Agent运行环境把上一节那个NER skill放进了~/.claude/skills目录。语料使用公共领域的古籍纯文本提前统一了标点为全角分开了正文和批语存成UTF-8编码。这一步看起来简单但非常重要——如果语料混杂繁简或带OCR脏字符后面所有分析都会出问题。4.2 让Agent按技能步骤执行在Claude Code里我只需要发出非常简洁的指令使用classical-chinese-ner技能处理data/hongloumeng.txt识别所有人物实体并输出JSON然后基于同回共现关系构建边表。因为skill的description写得很明确Agent会自动找到并读取技能文件再根据assets/aliases.md里的别名表对人物进行归并。实际操作中Agent不会一口气读完整部小说而是按回目分块处理再合并多批结果避免上下文溢出导致输出截断。共现的定义在skill里已经预先约定同一回中两个人物在相邻三个自然句同时出现记一次共现如果只是出现在同一回但距离很远不计入。之所以选择“窗口共现”而不是“全回共现”是因为窗口共现能更好地反映人物之间的直接互动而非单纯的地理同场关系。这个决策看起来小实际上直接决定了网络结构的长相也是方法论里值得写进论文的一个细节。4.3 输出结果与网络结构解读跑完以后Agent生成的边表大致长这样sourcetargetweightprimary_chapters贾宝玉林黛玉5817,19,20,23,30贾宝玉薛宝钗4628,37,42,48贾宝玉王熙凤2112,14,20贾母王熙凤3320,22,29,40林黛玉薛宝钗98,42,45把这份边表导入Gephi或者用ECharts的graph类型渲染会看到一个以贾宝玉为中心的星形网络周围还有贾母-王熙凤-王夫人形成的第二核心圈。黛玉和宝钗虽然与宝玉的共现值都很高但黛玉与宝钗直接共现的次数却非常低。这个定量结果与红学研究中“木石前盟”和“金玉良缘”两条线索并行不悖的常识判断是吻合的说明共现网络虽然只是一个简单指标也能在一定程度上反映叙事结构的内在逻辑。这一步给我最大的触动不是数据本身而是整个流程的可复现性我的方法论已经封装在skill里了换一个人、换一台电脑执行同一份语料会得到一模一样的数据结构。这就是数字人文区别于传统主观印象式判断的核心价值——可验证、可复核、可传播。4.4 这套流程的可复用性做完《红楼梦》以后我又把同一套技能用在了另一部世情小说上。我只换了语料文件重新跑了一遍就得到另一组人物共现数据。中间遇到的问题几乎为零因为每个环节的判断标准都封装在skill里了我不需要反复告诉Agent该怎么处理。后续如果想把个人研究方法沉淀成一个体系可以设计一套更细粒度的技能组合base-text-processing通用语料清洗classical-chinese-ner古籍实体识别与别名归并cooccurrence-network共现网络与边表构建topic-modeling主题建模literary-visualization文学数据可视化输出这些技能就像乐高积木可以按研究问题自由拼接。比如研究“明清小说中的地方书写”时我只调用清洗地名识别地理可视化三个技能即可完全不需要重复造轮子。5. Skill落地避坑清单哪些问题我实际跑过才明白5.1 技能描述太模糊Agent根本不触发或乱触发这是我个人踩过的最深的坑。最初版本给description写的是“用于分析古典小说”结果在跑普通文档时它频繁跳出来抢任务白白浪费大量上下文我又试过把描述写得特别窄结果真正需要的时候Agent反而不触发完全装死。最终解决办法是description里同时写明“何时用”和“何时不用”。比如“当输入不是中文古籍或古代文献时应忽略本技能”这样误触发率明显下降。不要觉得这句话多余它就是技能选择器的开关。5.2 技能包塞太多参考语料上下文直接爆掉第二个坑是我想要“增强”技能结果适得其反。我给技能包加了一个几百KB的“常用古籍信息一览表”希望模型能参考更多背景知识。结果每次调用该技能都会把这个文件读进上下文上下文窗口很快被塞满后面的分析质量断崖式下降。教训非常明确技能包内任何资源文件都必须小而精。单个文件超过10到20KB就要冷静思考一下是否是必要的。一个真正合理的设计是——不要把语料库放进去而是把“如何读取和处理语料”的方法放进去。需要大字典时应该通过脚本按需读取而不是直接驻留在技能包里。5.3 中文学术语料的编码与繁简转换古籍语料里繁体字、异体字、旧字形很常见。早期我直接把原始OCR文本交给Agent分析结果大量人名漏识别。后来我在corpus_rules.md里强制约定任何输入文本必须先经过一个标准化步骤——统一转成简体、规范异体字、统一标点还需要保留原始字符集信息作为版本记录。这一步必须放在预处理阶段完成不能指望Agent在分析过程中自行纠正。因为大模型虽然认识繁体字但在长文本中会频繁出现前后不一的处理结果。预先标准化可以大幅提高后续实体识别和统计的稳定性。5.4 Skills与MCP工具的分工工具箱与操作手册接触过AI Agent开发的人都会问一个问题skill既然能调用MCP工具那它是不是会取代MCP协议我实际用下来的体会是这两者的定位完全不同。MCP是“工具箱”提供了一组可供Agent调用外部能力比如浏览器、数据库、文件系统的标准接口skill是“操作手册”定义了在这个研究领域里应该按什么顺序、用什么规则去使用工具、处理数据、输出结果。仍然用前面的类比MCP是“电工包里的螺丝刀和电笔”skill是“电工操作手册”。没有工具手册写得再漂亮也没法作业没有手册工具只会乱用。在实际技能包里我在SKILL.md的处理流程中会显式地写“调用MCP的fetch工具抓取书目页”“调用MCP的database工具存储实体表”这样Agent在执行时就能自然地协调两套体系。5.5 技能也是代码版本管理与迭代日志最后一个建议可能听起来最不像人文研究者该干的事但恰恰是最重要的技能包本身就是代码需要版本管理。我现在的做法是每个技能包配一个README.md记录版本号、变更记录和验证案例。当我调整了某个识别规则或增加了别名映射时我会用同一份测试语料重新跑一遍对比前后输出diff确认没有引入回归性错误。没有版本管理你永远不会知道是哪条规则改动导致结果变了有了版本管理和回归测试技能包的演进才是可持续的。这套经验同样适用于跨人协作。如果你正在帮导师或课题组搭建共享研究环境技能包加版本管理就是一个非常好用的知识传递载体。团队里的新同学拿到技能库不需要重新从零理解全部方法只要照着技能说明执行就能产出一致的数据结果。最后分享一个实际体会skills真正给我带来的远不止“省时间”这么简单。它把研究过程本身变成了可以被查看、被讨论、被继承的显性资产。传统人文研究里方法往往是个人化、隐性化的同一个课题换个人做结果可能大相径庭而把方法论写成skill等于强制把自己的研究操作透明化了。以后无论你是研究唐宋文学、近代报刊还是地方志只要方法可以拆解都可以沉淀成自己的“研究技能库”。这个方向在我看来才是数字人文研究方法论在AI时代最值得投入的地方。