TEI |

tei-mcp v0.3：编码TEI，不动源文本一字

Tue, 05 May 2026 00:00:00 +0000

我时，目标是阻止AI助手幻觉出TEI标记。模式锚定解决了一部分问题：有了对P5规范的直接、基于工具的访问，模型不必再猜一个元素是什么意思、能带哪些属性。输出能通过验证。

但在TEI编码里，幻觉有两副面孔，模式只抓得住一副。依规范验证，只能告诉您标记是否合式；至于标记包裹的文本，它一言不发。而破坏性更大的幻觉，恰恰就藏在文本本身里。v0.3的头号新功能——区间锁定合成（span-locked composition）——正是专为防范这类幻觉而设计的。

模式抓不住的幻觉

让模型编码一封十六世纪的法文信，您往往会拿到一份看上去无可挑剔的TEI文档：头部填得满满当当，<persName>标签放得恰到好处，<dateline>合式规整。用validate_document跑一遍，通过。

然后拿正文和源文本比一比。

mesme变成了même。一个逗号挪了窝。luy被悄悄现代化成了lui。手稿里一处难以辨认的分句，被“修正”成了更通顺的样子。这些改动没有一处是您要求的，也没有一处被标出来。文档在模式上有效，却错得悄无声息。

对档案工作流来说——编码后的文本将成为永久记录，下游的读者、检索索引和引用都要倚赖它——这才是最要命的失效方式。标签格式不对，不过是烦人；一处五年没人发现的现代化拼写，就是讹误。

区间锁定合成

新版本（v0.3）带来了一套直指这一失效方式的幻觉防范机制。设计目标是让正文幻觉从构造上就不可能发生，而不只是不大可能。

思路很简单：模型从不键入正文。

取而代之的工作流是这样的：

模型调用get_source("letter_001")，取得源纯文本，一个不可变的字符串。
每想施加一个标签，它就调用tag_span("letter_001", start, end, element_path, attrs)——在源文本的某个字符区间上登记一个TEI元素。
完事后，它调用compose("letter_001")。服务器把登记的标签与原始纯文本交织起来，渲染出最终的TEI，再逐字节核验：渲染文档的扁平文本内容必须与源文本相等。

字节相符，文档就返回。若不相符——哪怕模型的标签只是隐含了一个与源文本差一个字符的正文——compose()便抛出异常，绝不返回一份已经走样的文档。

在这条工作流里，不存在任何一条路径能让模型产出正文与源文本不同的TEI文档。这个不变量是机械的，不是行为的。您不必信任模型不会幻觉，只需信任两个字节串之间的一次==比较。

它是什么，不是什么

区间锁定合成是对模式锚定的补充，不是替代。模式锚定工具（validate_document、lookup_element、valid_children，以及最初十六个工具中的其余部分）帮模型产出有效的TEI；区间锁定合成则保证TEI里的正文忠于源文本。一条可以投入使用的编码工作流必须同时满足这两个维度，如今两者由同一个服务器一并覆盖。

它也不是包治百病的灵丹。compose()还不会检查登记的标签是否为已加载的ODD定制所允许——这是后续工作。登记的标签存在进程内存里，重启即失。源文件也必须能从服务器运行的地方读到。这些都有办法解决，没有一项动摇核心不变量。

为什么意义不止于TEI

这个模式可以推而广之。凡是让模型去注释、转换或包裹一段文本，而底层文本的完整性又比模型“改进”它的本事更要紧，同样形态的解法都适用：别让模型重打一遍文本；让它在文本之上生成指令，再由一个确定性的合成器在相等性不变量的约束下执行。

具体到数字版本，这改变了您可以放心交给模型去做的事。编码忽然成了一项可以委托的任务，不必再手动把每份输出与源文本逐一比对。机器走枯燥的那条路；校勘者审的是标记，不是拼写。

获取更新

已经装了tei-mcp的话：

uvx tei-mcp@latest

或者全新安装：

pip install tei-mcp

要使用区间锁定合成，请把服务器指向存放源纯文本文件的目录：

export TEI_MCP_SPAN_SOURCE_ROOT=/path/to/sources
uvx tei-mcp

每个文件的主名即为其文档ID（letter_001.txt → letter_001）。

源代码、完整文档以及该不变量的设计说明：

tei-mcp

Sun, 15 Mar 2026 00:00:00 +0000

tei-mcp：给AI智能体用的TEI P5

tei-mcp是一个开源服务器，让AI编程助手直接访问规范。AI不必再倚赖记忆中的训练数据——那往往产出貌似合理、实则错误的标记——而可以实时查询规范。

功能

服务器解析TEI P5的ODD，提供16个工具：

按名称查询任何元素、类、宏或模块，不区分大小写，拼错了还会给出建议
沿完整的TEI类层次解析属性（本地＋继承）
把内容模型展开成结构化的树，并解析类与宏
验证嵌套——直接的父子关系，或带路径追踪的递归可达性
依据TEI P5验证文档：内容模型、属性、封闭取值列表、引用完整性、弃用警告
验证单个元素，适用于增量编辑的工作流
加载ODD定制，把模式约束到项目特定的子集
用正则表达式在所有实体类型中搜索

安装

pip install tei-mcp

或直接运行：

uvx tei-mcp

用法

加入任何兼容MCP的客户端（Claude、Cursor、Windsurf等）：

{
 "mcpServers": {
 "tei": {
 "command": "uvx",
 "args": ["tei-mcp"]
 }
 }
}

源代码与文档见。

tei-mcp：给AI智能体用的TEI P5

Sun, 15 Mar 2026 00:00:00 +0000

如果您用AI编程助手写过TEI XML，大概已经领教过它的错误：元素放错地方，属性凭空捏造，嵌套规则视若无睹。模型对TEI长什么样有个大概印象，对规范本身却没有可靠的知识。

tei-mcp的解法，是让AI智能体通过工具直接访问TEI P5指南。

MCP是什么？

（Model Context Protocol，MCP）是一项开放标准，让AI应用能接上外部数据源和工具。不妨把它看作AI的USB接口：一套协议，任何兼容的客户端——Claude、Cursor、Windsurf等等——都能借此接入专门的服务。

MCP服务器对外提供工具，AI在对话中可以随时调用。模型不必再靠记忆里的训练数据，而可以查询一个实时的、权威的来源。

tei-mcp做什么

tei-mcp解析TEI P5的ODD规范，提供16个工具，涵盖校勘者或编码者最常问的问题：

这个元素是什么？ 按名称查询任何元素、类、宏或模块，不区分大小写，拼错了还会给出建议。
它能带哪些属性？ 沿完整的类层次解析属性——先列本地属性，再依次列出继承的属性。
它里面能放什么？ 把内容模型展开成结构化的树，或列出有效子元素的平面清单。
这个元素能放在这儿吗？ 检查父子嵌套关系，或在完整的元素层次中追踪可达性。
我的文档有效吗？ 依据规范验证TEI XML文件：内容模型、属性值、封闭取值列表、引用完整性、弃用警告。
我的项目模式呢？ 加载ODD定制文件，把上述一切约束到您项目特定的TEI子集。

为什么要紧

TEI编码离不开时时翻查指南。老手把最常见的模式记在心里，可遇到生僻元素或复杂的内容模型，照样得查规范。AI助手没有这种内化的知识，问题更严重：它们会幻觉出看似合理、实则错误的标记。

有了tei-mcp，AI就不必猜了。写下第一个尖括号之前，它可以先去规范里查答案。结果便是符合TEI P5——或符合您项目ODD定制——的标记。

上手

从PyPI安装：

pip install tei-mcp

然后加入您MCP客户端的配置：

{
 "mcpServers": {
 "tei": {
 "command": "uvx",
 "args": ["tei-mcp"]
 }
 }
}

服务器首次运行时下载TEI规范，可配合任何兼容MCP的客户端使用。

源代码与完整文档：

Multi-Saxon

Fri, 28 Mar 2025 00:00:00 +0000

Multi-Saxon：大型TEI语料库的并行XSLT处理

Multi-Saxon填补了XML处理工具的一处要害空白：LXML（一个流行的Python XML库）处理不了的XSLT 2.0和3.0转换，它能并行执行。它专为大型XML TEI文档集合而设计，凭高效的并行执行大幅缩短处理时间。

主要特性

高级XSLT支持：处理LXML力所不及的XSLT 2.0和3.0转换
并行处理：借并行化大幅缩短大型文档集合的转换时间
为TEI优化：专为文本编码倡议（TEI）XML文档打造
性能可扩展：从数百到数千份文档的语料库，均可高效处理
跨平台：可在不同操作系统和环境下运行

Multi-Saxon解决什么问题

使用TEI的数字人文学者常常面临两大难题：

LXML（常用的Python XML处理库）只支持XSLT 1.0，XSLT 2.0/3.0的高级特性无从使用
大型TEI语料库若逐份顺序处理，耗时可能长到令人却步

Multi-Saxon一举解决这两个问题：借用Saxon的高级XSLT能力，同时把处理分摊到多个核心，性能因此大增。

实现

Multi-Saxon把Python与Java的Saxon处理器结合起来，构成一条高性能的转换流水线：

用Java的Saxon库稳健地处理XSLT 2.0/3.0
以多进程把转换分摊到可用的CPU核心
高效管理处理器池，以求吞吐量最大化
为批量处理TEI文档提供简洁的接口

用法示例

from multi_saxon import MultiSaxon

# Initialize with your XSLT stylesheet
transformer = MultiSaxon("transform.xsl")

# Transform a single document
transformer.transform("input.xml", "output.xml")

# Transform an entire directory in parallel
transformer.transform_directory("input_dir", "output_dir")

对数字人文的意义

对处理大型TEI文档集合的数字人文项目，Multi-Saxon让以下成为可能：

LXML无法完成的复杂全语料库转换
大幅缩短处理时间（多核系统上常可提速5至10倍）
借助XSLT 2.0/3.0的高级特性做更精细的分析
简化整个文档集合的处理流程

源代码与文档见。

persNamer

Fri, 28 Mar 2025 00:00:00 +0000

persNamer：把TEI接上虚拟国际规范文档

persNamer是一个专门的Python工具，简化把VIAF（虚拟国际规范文档，Virtual International Authority File）中的规范人物数据整合进TEI XML文档的流程。它把VIAF标识符转成可直接使用的TEI标记，为数字学术版本创建结构化人物条目的手工劳动因此大减。

TEI中规范控制的难处

数字学术版本往往需要精确识别历史人物，包括规范化的姓名和生卒年月。要在整个项目里保持一致的规范控制，需要：

识别历史文本中的人物
查找他们的规范数据
创建格式正确的TEI条目
确保全项目引用一致

这些步骤通常靠手工，费时，还容易前后不一。

persNamer如何工作

persNamer把这套流程自动化：

获取VIAF数据：给定一个VIAF标识符，工具通过HTTP内容协商取回RDF数据
提取关键信息：解析RDF，提取首选姓名、出生日期和死亡日期
生成TEI标记：创建两段基本的XML片段：
- 一条规范文档条目（<person>元素，带生成的xml:id、<persName>、<birth>、<death>和<idno type="VIAF">）
- 一个独立的标注标签（<persName>，其ref属性指向规范条目）

这样双管齐下，校勘者既能维护一份集中的规范文档，又能把标注标签轻松插入TEI文本。

主要特性

标准化ID生成：按pers-[familyname]-[givenname initial]格式生成一致的XML ID（如pers-deteligny-c）
RDF解析：用rdflib从各种RDF属性（如rdfs:label、schema:name、viaf:mainHead）中提取信息
命令行界面：只需一个VIAF编号作为必要参数即可运行
详细输出：除最终XML外，还提供详细的处理信息

用法示例

python persNamer.py 314802260

这条命令生成：

<person xml:id="pers-deteligny-c">
 <persName>Charles deTéligny</persName>
 <birth>1535</birth>
 <death>1572-08-24</death>
 <idno type="VIAF">314802260</idno>
</person>

<persName ref="#pers-deteligny-c">Charles deTéligny</persName>

在数字人文中的应用

persNamer对以下情形尤其有用：

需要规范控制的数字学术版本
涉及历史人物的TEI编码项目
把文献与规范记录相连的关联数据项目
保证大型TEI语料库的一致性
在数字人文课程中讲授规范控制概念

实现

persNamer用Python实现，依赖：

requests：HTTP请求
rdflib：RDF解析
lxml：XML处理

源代码与文档见。