企业官网建设流程全解析

这几年数字人文（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和description，Agent靠这个判断何时调用该技能
• assets/：参考资源，比如别名表、领域术语表、标注规则
• scripts/：辅助脚本，比如负责把结果转换成特定格式的Python程序
• examples/：示例输入与输出，给模型一个“照着做”的样本

skill和普通prompt（提示词）关键差异在于：普通提示词是一次性指令，用完就没了；skill是结构化、带元数据、带参考资源、可持久化的“能力单元”。用大白话比喻，提示词是你喊一句“把灯打开”，而skill是给AI一套完整的“电工岗位培训手册+工具包+验收标准”，让它能稳定完成一整类相关任务，而不是只会开这一盏灯。

在数字人文领域，这种持久化能力尤其重要。因为人文学科的知识体系高度依赖“约定”和“规范”，比如你用什么标准判定实体类别、用什么原则处理版本异文、用什么指标衡量文本相似度，这些约定如果能写进skill，Agent的输出就会一直在同一套方法论框架内。

1.3 为什么数字人文研究特别适合Skills化

数字人文研究有三个显著特点。

第一，方法高度重复。清洗、标注、统计、可视化这些步骤，几乎每个项目都要过一遍，差别只是语料箱子和研究问题。

第二，领域知识密集。通用模型能认出“贾宝玉”是人名，但认不出“颦颦”也是林黛玉、“二爷”在某些语境下指贾宝玉。这种领域知识需要额外的参考资料支撑。

第三，任务链特别长。一个研究问题往往要经过“语料获取→清洗→标注→建库→分析→可视化→解释”多个环节才能回答，中间任何一个环节的规则变了，结果都要重跑。

这三个特点正好都是skills的强项。拿实体识别来说，你可以在skill里放入人物别名表、语境判定规则和预期输出格式，Agent就能稳定执行。这就不是简单的“工具调用”，而是一种“方法论内化”——方法不再存在于研究者的脑子里或草稿纸上，而是存在于一个可以被复用、被分享、被版本管理的技能包里。

2. 把研究流程拆成技能包：数字人文任务如何分解

2.1 数字人文研究的典型工作流

一个标准数字人文项目，无论研究对象是什么，大体都会经过下面这一串环节：

1. 语料获取：OCR扫描件、网页爬取、数据库导出、手写稿转录
2. 语料清洗：错字校正、繁简转换、去页眉页脚、分句分段、去除批注混排
3. 内容标注：命名实体识别、词性标注、事件标注、情感判定、版本校勘
4. 量化分析：词频、TF-IDF、共现分析、主题建模、网络指标、文体计量
5. 可视化呈现：词云、关系网络图、时空分布图、热度地图
6. 学术解释：回到人文问题本身，结合定量结果形成论证与结论

你会发现，这个流程里的每一步，都适合做成一个或者一组技能包。但难点在于：怎么切分粒度才合理？“语料清洗”是一个技能，还是拆成“OCR校正”“繁简转换”“分句”三个技能？这没有标准答案，取决于你手头项目的重复频次。如果你的课题组常年处理明清方志，那么“方志文本清洗”值得做一个单独技能；如果只是临时跑一次，完全可以把清洗逻辑塞进分析技能里。

2.2 按方法论粒度划分技能包

我建议采用下面这张表来规划和设计自己的技能库。这里的方法论粒度是“研究环节”，每个环节对应一个可独立验证的技能包。

这张表不是让你一次做完，而是帮助你有针对性地为课题定制技能。比如你要研究“明清通俗小说中的空间书写”，只需要清洗、地名识别、地理可视化三个技能就够了；而研究“历代笔记小说的历史人物网络”，则需要清洗、人名实体识别、共现网络、网络可视化四个技能。

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和description，description用来让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生成的边表大致长这样：

把这份边表导入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时代最值得投入的地方。