orthotomeo

orthotomeo

ὀρθοτομέω——“切直”，源自《提摩太后书》2:15：“你当竭力，在上帝面前作蒙认可的人，作无愧的工人，按正意分解真理的道。”

orthotomeo 是一款只读的经文研读引擎。它会将包含多个版本的圣经语料（希腊文新约、希伯来文旧约、七十士译本和公有领域的英文译本）导入衍生的 SQLite 数据库，然后通过 MCP 服务、命令行或 Go 库，提供逐字、带来源标记的查询，以及要么完整返回、要么失败的词语索引。

这是 Justin Rainsberger 的个人项目——与任何雇主均无关联，未获其赞助，也不代表任何雇主。

为什么这样构建

三段经文塑造了引擎的设计，而不仅仅是它的名称：

• 《罗马书》3:4——“上帝是真实的，人都是虚谎的。” 当人类来源——词典、语法书、注释、大模型自身的训练内容——与经文本身冲突时，应以经文为准。引擎没有按词典类别捷径来确定词义；它会返回原始文本，让每一处用例自己说话。
• 《彼得前书》4:11——“若有人讲道，要按着上帝的圣言讲；若有人服事，要按着上帝所赐的力量服事，叫上帝在凡事上因耶稣基督得荣耀。荣耀、权能归给他，直到永永远远。阿们。” 关于经文的言说，应当以经文本身为准则——而这节经文不止谈到问责，也明确指出了真正重要的事：叫上帝在凡事上得荣耀。 在成为软件之前，这个项目首先是一篇颂赞。引擎返回的每条引文，都必须能够追溯到真实源文件中的实际行——绝不能是摘要、释义或凭记忆作出的断言——因为轻率处理经文所危及的并非一个程序缺陷，而是人们处理上帝话语的方式能否荣耀上帝。
• 《提摩太后书》2:15——本项目以此为名，也以此为使命。“按正意分解”并非泛指认真阅读的比喻，而是明确要求以这种精确度处理经文——这也是引擎的核心操作采用要么完整返回、要么失败的词语索引（所有匹配的用例，否则报错——绝不悄悄返回部分结果），而不是尽力而为的搜索。

实际而言，这意味着：引擎负责提供证据，大模型追踪用法，你负责得出结论。 引擎从不阐释，也不为任何立场辩护，更不会引用未经自身数据库检索的原文。对于给定查询，它要么返回完整且带来源标记的结果集，要么报错——不会悄悄截断、猜测或改述。大模型会据此梳理不同用例中的模式，但不会对这些用例的含义作出最终定论。

设计原则

• 内容本身绝不由大模型筛选。 调用者收到的每个词、每节经文和词条，都直接来自已检入代码库的语料文件（STEPBible、Open Scriptures、公有领域译本），由确定性的 SQL 查询获取——没有模型会在内容送达之前筛选、概括、改写内容，也不会判断哪些内容“相关”。大模型客户端可以围绕引擎返回的内容进行推理，但绝不会触碰引擎本身。唯一会用到大模型自身判断的地方，是它在此基础上构建的显示格式（例如，如何使用返回的引文组织答案）；绝不会影响底层文本。设置这些工具，正是为了让这种判断可以依据真实数据进行核查，而不是让它单凭自身权威给出结论。
• 要么完整返回，要么报错，绝不悄悄返回部分结果。 索引查询会返回每一处匹配项，否则就会报错——绝不会截断、抽样，也不会猜测哪些内容“差不多就行”。
• 始终提供来源信息。 每条引文都能追溯到真实来源文件中的真实行（版本、许可证、署名、定位信息）——绝不是摘要、改写或凭记忆作出的断言。
• 读取时进行调和，绝不假定不同版本一一对应。 五种文本传统在诗节划分和正典范围上各不相同；跨版本的差异会在发现时作为数据（注意事项）呈现，绝不隐藏，也不会悄悄强行套用某个版本的编号。
• 默认忠于文本，而不是遵循现代惯例。 如果现代编辑惯例并不反映手稿本身的任何信息（例如字母大小写——古希腊语和希伯来语手稿根本没有这种区分），引擎默认不会将其视为重要依据；但如果该惯例确实能提供消歧信息（例如，专有名词除大小写外与普通名词拼写相同），就会通过注意事项标出。
• 只读，数据库可随时重建。 引擎从不写入数据；派生的 SQLite 数据库是可重新生成的构建产物，绝不会检入代码库，也不是事实来源——语料文件才是。数据库可以随时删除并从这些文件重新构建。

内容概览

• 从语料构建的派生 SQLite 数据库（cmd/build）——可重新生成的产物，不会检入代码库。语料文件才是事实来源；数据库只是其索引。
• Go 引擎包（唯一的只读接口），提供引用解析、逐字经文／段落查询、词条／短语索引、解析／词形还原、手稿见证查询以及引文渲染。
• 五种传输方式共用同一个引擎：供大模型聊天客户端使用的 MCP 服务（cmd/orthotomeo-mcp）、用于终端的 CLI（cmd/orthotomeo）、HTTP API + 本地 Web UI（httpapi，由 cmd/orthotomeo-web 提供服务）、启动 Web 服务并在浏览器中打开它的 桌面启动器（cmd/orthotomeo-desktop），以及可直接嵌入 Go 项目的引擎包本身。

完整设计请参阅 docs/PLAN.md（请先阅读其中的跨领域不变量），数据模型请参阅 docs/erd-v1.svg。docs/STATUS.md 提供了逐项任务的详细构建日志。

与大模型配合使用时，这个小巧的本地参考引擎就不再只是一个需要手动翻阅的工具：用自然语言提出后续问题，模型便会将其拆解为恰当的工具调用，并从结果中发现模式——这些交叉引用工作原本全都要由你自行完成。文本仍由引擎掌控；大模型负责对话式的后续交互，而不会触碰文本本身。请参阅下文的示例。

设置语料

（如果你是在评估项目，而不是安装项目？请跳转到示例，之后再回到这里。） 此仓库不包含语料库。 源文件是需要你自行提供的外部输入——每个文件都有独立的许可证；cmd/build 在未明确指定两个根目录时（没有默认路径）会拒绝运行。你需要准备：

版本	内容	格式	许可证／署名
TAGNT	Translators Amalgamated Greek New Testament	制表符分隔的 TSV，每行对应一个希腊语单词（词元、消歧后的 Strong's 编号、形态信息、手稿见证）	CC BY 4.0，STEPBible.org / Tyndale House Cambridge
TAHOT	Translators Amalgamated Hebrew Old Testament	相同的 TSV 结构，希伯来语／阿拉米语	CC BY 4.0，STEPBible.org / Tyndale House Cambridge
TEGMC / TEHMC	希腊语／希伯来语形态代码扩展表	纯 TSV	CC BY 4.0，STEPBible.org / Tyndale House Cambridge
TBESG / TBESH	Extended Strong's 简明词典（希腊语／希伯来语）	纯 TSV	CC BY 4.0（希伯来语释义使用前须核查相关术语——参见 sources/sources.json）
Swete	Swete 编订的 1909-1930 年剑桥七十士译本，希腊语正文	CSV	公有领域，来自 archive.org
OSS-LXX-lemma	Open Scriptures 七十士译本词元索引	JS 文件，每卷一个文件，每个单词对应 {key, lemma}	CC BY 4.0，Open Scriptures
KJV / ASV	King James（1769）／American Standard（1901）	单个 JSON 文件，books[].chapters[].verses[]	公有领域
WEB	World English Bible（2024）	USFM，每卷一个文件，内含 Strong's 编号	公有领域，eBible.org
BSB	Berean Standard Bible——基于批判文本的现代直译本	USFM，每卷一个文件	公有领域（于 2023-04-30 发布），Bible Hub / Berean Bible
Brenton	Brenton 编订的 1851 年英文七十士译本	HTML，每章一个文件	公有领域
OpenBible-xref	交叉引用（摘自 Treasury of Scripture Knowledge）	TSV	CC BY 4.0，OpenBible.info

每个来源的权威清单——包括准确的 source_file glob、格式、许可证和署名信息——已记录在 sources/sources.json 中；应以该文件为准，而非此表。

每个版本都保留自身的经节编号体系和正典（七十士译本对《诗篇》的编号不同，并包含次经书卷；五种文本传统对部分经文起始位置的记载也不一致）。引擎绝不假定不同版本之间存在一对一映射——参见 PLAN.md 中的跨领域不变量 #4。

cmd/build 所需的目录布局，分为两个根目录：

根目录	包含内容
--reference	STEPBible-Data/（TAGNT、TAHOT、词典、形态代码）、LXX-Swete-1930/
--corpus	bible-text/（KJV、ASV、WEB、BSB、Brenton、OSS-LXX-lemma）、cross_references.txt

每次运行时都无法单独配置各来源在根目录下的确切路径——路径按来源固定在 sources/sources.json 的 source_file 字段中，这是映射信息的唯一存放位置（没有加载器会自行硬编码路径；corpus.Locate 是整个导入器中唯一会处理路径的代码，它只会拼接 root + source_file 并执行 glob）。每个来源会依次尝试 --corpus 和 --reference，因此目录树可以放在任一根目录下——但在解析到该目录树的根目录下方，路径段都是字面路径而非模式（仅文件名部分在下文标明时才是 glob）：

来源	根目录下的路径
KJV	bible-text/KJV/KJV.json
ASV	bible-text/ASV/ASV.json
WEB	bible-text/WEB/*.usfm
BSB	bible-text/BSB/*.usfm
Brenton	bible-text/LXX/eng-Brenton_html/*.htm
OSS-LXX-lemma	bible-text/LXX/GreekResources-master/LxxLemmas/*.js
TAGNT	STEPBible-Data/Translators Amalgamated OT+NT/TAGNT*.txt
TAHOT	STEPBible-Data/Translators Amalgamated OT+NT/TAHOT*.txt
TBESG / TBESH	STEPBible-Data/Lexicons/TBESG*.txt / TBESH*.txt
TEGMC / TEHMC	STEPBible-Data/Morphology codes/TEGMC*.txt / TEHMC*.txt
TVTMS	STEPBible-Data/Versification/TVTMS*.txt
Swete	LXX-Swete-1930/*.csv
OpenBible-xref	cross_references.txt

将文件放在其他位置会立即失败，并显示 corpus tree missing: <path> under [...]，准确指出程序查找的路径。若要使用不同的目录结构，请编辑 sources/sources.json 中的 source_file 值——这是唯一需要更改的内容，因为所有加载器都会从该文件读取路径，而不会自行假定路径。

STEPBible-Data 由 STEPBible.org / Tyndale House Cambridge 发布；Swete CSV 是 archive.org 对 1930 年 Cambridge 版本的数字化存档；公有领域的英文译本和 Open Scriptures 词元文件由各自的发布方（eBible.org、Open Scriptures）提供。目前这些文件都不会自动获取——sources/sources.json 中的 fetch_url 字段只是预留占位，尚未实现。

阅读见证代码

每个 parse/attestation/interlinear 结果都包含两个值得了解其读取方式的字段：attestation（Type 代码，例如 "NKO"）和 manuscripts（具体出版版本，例如 "NA28+NA27+Tyn+SBL+WH+Treg+TR+Byz"）。这两项都作为中立的文本批判数据报告，遵循本项目自身的原则（参见设计原则）——绝不能用来支持或反对某种读法。

此图例仅适用于 TAGNT（希腊文新约）——内容直接摘自 TAGNT 自身的源文件头部，未经改写：

字母	传统	含义
N	“古代”	Nestle-Aland 中的希腊文，现代译本大多采用的底本
K	“传统”	KJV 所依据的希腊文，即 Scrivener 1894 年版的 Textus Receptus
O	“其他”	主要版本中出现的任何其他希腊文读法，很少被翻译

一个词的 Type 是所有见证该词的传统的拼接结果——"NKO"（占所有 TAGNT 词条的 94%）表示三种传统一致；"KO" 表示古代传统（Nestle-Aland）中完全没有这个词（著名的真实例子：Mark 16:9-20 标记为 KO——Nestle-Aland 底本中没有，但传统/KJV 文本及其他一些版本中有）。 大小写也有实际含义：当某种传统自身的异文“太轻微，不足以导致不同的翻译”（例如拼写、语序）时，该传统的字母写作小写（n/k/o）——"NKo" 表示三种传统都见证了该词，但其他版本的文本也有差异，只是差异小到不影响含义。括号（例如 "N(K)(O)"）表示某种传统中存在该词，但其读法是不同的异文，而非完全一致。

manuscripts 列出 Type 代码背后的实际出版版本：Byz（拜占庭文本/RP 2005）、NA27/NA28（Nestle-Aland）、TR（Scrivener 1894 年版 Textus Receptus）、SBL（Holmes 2010）、Treg（Tregelles）、WH（Westcott-Hort）、Tyn（Tyndale House GNT 2017）。

TAHOT（希伯来文旧约）使用的是完全不同的体系——希伯来文本批判并非围绕 Nestle-Aland 与 Textus Receptus 的区别展开。其 Type 字母用于标记《列宁格勒抄本》与马所拉文本 Qere/Ketiv 体系的对应关系（L=列宁格勒文本，Q=Qere 抄写修正，K=Ketiv/原始辅音文本，R=复原文本，X=取自 LXX 的文本），并采用相同的小写字母表示轻微异文的约定。不要用上方的 TAGNT 表格来解读 TAHOT 的 Type 值——它们虽然使用相同的字段名，但代表两套毫不相关的校勘体系。

构建数据库

go run ./cmd/build --corpus <path-to-bible-text-root> --reference <path-to-STEPBible-Data-root> --out data/orthotomeo.db --verify
go test ./...   # all green

也可以通过 Makefile 执行：make build-db CORPUS=<path> REFERENCE=<path>、 make build（全部四个传输二进制文件）、make lint（fmt-check + vet + test；这是本项目自己的会话在每次提交前运行的相同检查）。

--verify 会运行完整性自检（让不变量 #3 可强制验证）——检查源数据/FK 完整性、完整正典的书卷覆盖情况，以及已知的各版本词数；每项都会与实际构建结果进行核对。数据库可重新生成：随时删除后重新运行构建即可；事实来源是语料文件，而非数据库。

使用方法

作为 MCP 服务

构建二进制文件，并将其注册到 MCP 宿主（例如 Claude Desktop）：

go build -o orthotomeo-mcp ./cmd/orthotomeo-mcp

{
  "mcpServers": {
    "orthotomeo": {
      "command": "/path/to/orthotomeo-mcp",
      "args": ["--db", "/path/to/data/orthotomeo.db"]
    }
  }
}

该服务提供十二种工具：resolve_ref、get_verse、get_passage、 concord_lemma、concord_phrase、count、parse、lemmatize、 attestation、interlinear、lexicon_lookup、cite。每个 book 参数 都接受 USFM 代码或完整的英文书名，且不区分大小写（MAT、 mat、Matthew、MATTHEW 都会解析为同一卷书）。

这是 stdio 方式，适用于与数据库运行在同一台机器上的 MCP 宿主。

连接到托管实例

无需本地二进制文件、无需本地数据库，也无需构建——只需将 MCP 客户端的 远程服务配置指向托管实例：

{
  "mcpServers": {
    "orthotomeo": {
      "url": "https://orthotomeo.app/mcp"
    }
  }
}

具体配置格式（使用 url 字段还是 command/args 键值对）取决于 你的 MCP 客户端——请查阅其文档，了解对“远程 MCP 服务”或“Streamable HTTP”的支持。它提供的工具与上面的 stdio 服务相同，事实上，为了它，本项目才 采用云端部署。这是一个公开、无需身份验证、成本受限的实例——每个 IP 每小时 最多 60 次引擎查询，每天总计最多 2,000 次，且单次一致性查询结果最多返回 2,000 条出现记录。

只有实际到达引擎的请求才会占用配额：工具调用，或 REST 查询端点之一。页面加载、静态资源、/books 自动补全数据、MCP 握手（initialize、tools/list）和 404 探测均不计费， 而是由单独且宽松得多的流量防护机制处理。因此，为研究设置的配额不会被 存活探测器或浏览器获取 CSS 消耗。

这两项限制各司其职：速率限制限制你能多频繁地查询，结果上限限制单次查询可能 多耗费资源。如果匹配结果超过上限，查询会直接被拒绝，并在错误中提供精确的 匹配数量——不会静默截断，否则就会破坏完整成功或失败的原则。对于范围较大的查询， 请先调用 count；count 不设上限，因为它返回的是数字，而不是引文。

此上限仅适用于这个托管实例。CLI、桌面端和本地 Web 构建均不受限制，因此，如果研究确实需要 获取某个常见词的全部出现记录（TAGNT 中的 ὁ 匹配 20,705 条），请使用这些版本—— 或者与我们联系。

作为 CLI

go build -o orthotomeo ./cmd/orthotomeo
orthotomeo concord --corpus TAGNT G0859               # every occurrence of a lemma/Strong's number
orthotomeo concord --corpus TAGNT --phrase "εἰς,ἄφεσις" --adjacent
orthotomeo lookup --edition KJV,ASV,WEB,BSB MAT.26.28   # verbatim verse text
orthotomeo parse --corpus TAGNT --word 2 MRK.16.16     # dStrong + expanded morphology
orthotomeo attest --corpus TAGNT MRK.16.16             # manuscript attestation (Type/Editions)
orthotomeo define G0859                                # lexicon/Strong's lookup
orthotomeo interlinear --corpus TAGNT MRK.16.16         # row-aligned original/translit/gloss/grammar

每个子命令也都接受 --json，以输出机器可读的结果。引用中的书卷标记 （例如 MAT.26.28 中的 MAT）接受 USFM 代码或完整的英文书名，且不区分大小写。

作为 HTTP API + 本地 Web UI

go build -o orthotomeo-web ./cmd/orthotomeo-web
./orthotomeo-web --db data/orthotomeo.db   # loopback only, default port 8420

也可以通过 Dockerfile 运行（make docker-build && make docker-run DB=data/orthotomeo.db，或直接使用 docker build/docker run）——它只会将 cmd/orthotomeo-web 构建到一个精简、无需 cgo 的映像中；数据库不会被 打包进映像，而是挂载到 /data/orthotomeo.db（请先在主机上构建数据库， 参见上文“构建数据库”）。

打开 http://127.0.0.1:8420/ 访问首页，打开 /app/ 使用查询 工具；/docs 是 API 和 MCP 参考文档。也可以直接访问仅支持 GET 的 JSON 端点：/verse、/passage、/concord、/count、/parse、 /attest、/interlinear、/define、/books（规范的 66 卷书目 注册表，供 UI 的书卷字段自动补全使用）。

/count 会返回匹配 /concord 查询的出现次数统计——总数和各卷的数量。 它不会受到结果上限的限制，因为它返回的是数字，而非引文，因此适用于 结果过多、无法返回的查询。

curl "http://127.0.0.1:8420/verse?book=JHN&chapter=3&verse=16&editions=KJV"

{
  "citations": [
    {
      "ref": {"book": "JHN", "chapter": 3, "verse": 16},
      "edition": "KJV",
      "text": "For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.",
      "locator": "John 3:16",
      "confidence": "High"
    }
  ],
  "sources": {
    "KJV": {"file": "bible-text/KJV/KJV.json", "license": "Public Domain", "homepage_url": "https://github.com/scrollmapper/bible_databases"}
  }
}

curl "http://127.0.0.1:8420/concord?query=G0859&corpus=TAGNT"

{
  "citations": [
    {
      "ref": {"book": "MAT", "chapter": 26, "verse": 28},
      "edition": "TAGNT",
      "text": "ἄφεσιν",
      "locator": "Mat.26.28#16=NKO",
      "lemma": "ἄφεσις",
      "translit": "aphesin",
      "dstrong": "G0859",
      "grammar": "N-ASF",
      "attestation": "NKO",
      "manuscripts": "NA28+NA27+Tyn+SBL+WH+Treg+TR+Byz",
      "confidence": "High"
    },
    { "...": "16 more occurrences, one per real match - complete-or-fail, never a sample" }
  ],
  "sources": {
    "TAGNT": {"file": "STEPBible-Data/Translators Amalgamated OT+NT/TAGNT*.txt", "license": "CC BY 4.0", "attribution": "STEPBible.org / Tyndale House Cambridge", "homepage_url": "https://github.com/STEPBible/STEPBible-Data"}
  }
}

以上所有内容都仅限回环访问，这是有意为之（参见 cmd/orthotomeo-web 的文档 注释）。cmd/orthotomeo-web-cloud 是单独的、可公开访问的对应版本 （例如用于 Cloud Run）——它是不同的二进制文件和映像，并非此版本的一个标志； 差异请参见其自身包的文档注释。

作为桌面应用

go build -ldflags -H=windowsgui -o orthotomeo-desktop.exe ./cmd/orthotomeo-desktop

这是一个原生 GUI 外壳（本身不渲染经文），会在临时回环端口上启动 HTTP 服务，打开浏览器访问该服务，并在关闭时妥善关闭服务。

作为 Go 库

e, err := engine.Open("data/orthotomeo.db") // opens read-only
if err != nil { ... }
defer e.Close()

citations, err := e.ConcordLemma("G0859", "TAGNT", "") // by: "" (auto-detect), "lemma", "dstrong", or "surface"
fmt.Println(e.Cite(citations)) // Markdown-formatted, fully cited

示例

一段真实记录的对话（并非虚构）——一个注册了下方所示系统提示词 （以及 orthotomeo 的 MCP 工具）的 LLM 客户端，被询问项目名称所源自的 词语。之所以收录，是因为它实际展现了“引擎负责证据，LLM 追踪用法，你负责结论” 这一原则，而不只是描述它：每一项语法或见证声明都能追溯到工具结果；模型在自行 查阅 LXX 或希伯来语数据之前会停下来询问；并且会明确标注自己的跨语料综合结论 属于推断，而非经工具验证的事实。

我： 希腊词 ὀρθοτομέω 在新约中的哪些地方出现？结合上下文，它是什么意思？

词汇索引结果：ὀρθοτομέω（G3718）

针对 TAGNT 的完整匹配式词汇索引返回新约中恰好一处：提摩太后书 2:15。

• 希腊语形式：ὀρθοτομοῦντα - 现在时主动分词，宾格单数阳性 （V-PAP-ASM）
• 手稿见证：NKO - 在此语料涵盖的完整集合中均有见证（NA28、NA27、Tyndale House GNT、SBLGNT、WH、Tregelles、TR、 Byzantine）。此词没有标记任何异文。

完整经文（TAGNT）：σπούδασον σεαυτὸν δόκιμον παραστῆσαι τῷ θεῷ, ἐργάτην ἀνεπαίσχυντον, ὀρθοτομοῦντα τὸν λόγον τῆς ἀληθείας.

• KJV：“……无愧的工人，按正意分解真理的道。”
• ASV：“……正当地处理真理的道。”
• WEB：“……正确地处理真理的话语。”

由于这是新约中的 hapax legomenon（仅出现一次），词汇索引方法的核心做法—— 让明确无歧义的实例确定有歧义的实例——在此语料的新约数据中无其他依据可用。 我尚未搜索 LXX 中的这个词元——如果你想要，我可以单独进行后续搜索并明确标注， 因为那将涉及新约以外的数据。

我： 好的，请也搜索 LXX。

LXX 词汇索引结果：ὀρθοτομέω

搜索 OSS-LXX-lemma 得到两处出现，均在《箴言》中。Swete 表层文本语料完全不含 词元标签（已确认：每个词都标记为“Swete is surface-only, T12”），因此针对 Swete 的词元搜索正确地返回零处。

• 箴言 3:6 - ὀρθοτομῇ（现在虚拟语气）。Brenton 译文：“……使她能正当地引导你的道路。”宾语：τὰς ὁδούς σου（“你的道路”）。
• 箴言 11:5 - ὀρθοτομεῖ（现在直陈语气）。Brenton 译文：“公义开辟无可指摘的道路。”宾语：ὁδούς（“道路”），由 ἀμώμους（“无可指摘的”）修饰。

在全部三处可证实的出现中，这个动词在 LXX 中的宾语始终是表示“道路／路径”的名词，但在《提摩太后书》中，宾语是 τὸν λόγον τῆς ἀληθείας（“真理的道”），并非道路。这确实是一种值得权衡的语义延伸：跨越两位作者／两个时代的三个例证，不足以确定其含义；而且在已标注的语料中，任何地方都没有第四处例证可作为进一步佐证。

**我：**请与希伯来文交叉参照。

希伯来文交叉参照（TAHOT）

箴言这两节都翻译了同一个希伯来语动词：יָשַׁר（yashar），Piel 词干（H3474），并非表示“切割”的动词。

• 箴言 3:6：יְיַשֵּׁר（Piel 未完成时，第三人称阳性单数）——“他将使……变直／平坦”。宾语：אֹרְחֹתֶיךָ（“你的道路”）。
• 箴言 11:5：תְּיַשֵּׁר（Piel 未完成时，第三人称阴性单数）。宾语：דַּרְכּוֹ（“他的道路”）。

这改变了整个图景：“切割”的含义是希腊语译者的选择，并非源自希伯来文。 יָשַׁר 的意思是“使……变直／平坦／平滑”——这也是 יָשָׁר（“正直的、笔直的”）背后的同一词根——其词义中没有切割或刻划的成分。LXX 译者用一个以 τέμνω（“切”）为基础构成的希腊语复合词，来翻译一个表示“使……变直／平坦”的动词；这是译者自行采用的意象，叠加在希伯来文之上，而非从希伯来文照搬而来。对于《提摩太后书》2:15 来说，这意味着“使真理的道保持笔直／平坦的轨迹”这一释义，至少与“开辟一条笔直的道路”同样站得住脚——希伯来文数据并不支持仅凭“切”这一词源来建立解释。

（同义词索引数据所能支持的结论仅止于此——三个希腊语例证、两个底层希伯来语例证，在已标注的语料中没有任何第四例。以上综合分析是从模式中推断得出的；在整个实际对话中，我们明确区分了这种推断与引文直接陈述的内容。）

示例提示词

生成上述对话的系统提示词——这类提示词可用于注册了 orthotomeo MCP 工具的大模型客户端：

你可以通过真实的圣经文本语料使用 orthotomeo MCP 工具。 我询问经文问题时，请使用同义词索引方法作答：通过 concord_lemma/concord_phrase 提取所有相关例证，而不是依赖记忆中的示例；并用含义明确的例证来确定含义模糊的例证。 请以工具返回的内容为依据，而非凭记忆作答；如果某个语法或词汇主张无法通过返回的引文加以佐证，就请说明，而不要断言。即使是你自行推导语法形式的情况，也适用这条要求——例如，对不含词元字段的 Swete 版本这类仅含词形的版本进行词元化：这样做没有问题，但要明确说明这是你自行完成的，并与工具直接核实的引文区分开来。严格限于圣经文本本身——不要使用注释书、现代神学论证或古代／圣经以外的资料，除非我明确要求将这些内容作为单独且标注清楚的后续内容。请通过 attestation 中性地报告抄本见证——文本异文应由我权衡，而不是由你加以辩护或反驳。请提供一份带有简短词汇说明的参考列表，供我用于自己的研读，而不是给出最终结论。

许可证

代码：MIT。本项目不会重新授权数据——每个来源均保留其自身许可证，具体记录在 sources/sources.json 中（包括 CC BY 4.0 和公有领域数据；确切条款及各来源的署名要求见该文件）。不可再分发的来源（例如之后若添加 CCAT 衍生的 Rahlfs LXX）将由用户自行获取，绝不会捆绑提供。