你的词，每一次都一样：陪读蛙的术语库

同一个词，三种译法

你在读一篇讲语言模型的长文。第一段里 prompt 被译成「提示」，第四段变成「提示语」，读到最后它已经成了「命令」。

严格说来哪一处都不算错。每个段落都是单独翻译的，每次模型都挑了一个合理的词。但把整篇文章串起来的人是你，而它一直在你脚下改主意。

名字上也一样。论坛帖子里的用户名被「贴心地」翻译成了一个不再是用户名的东西；游戏 wiki 里的一个角色在同一页上出现了三种写法；代码标识符变成了散文。

陪读蛙 1.47.0 带来了术语库。 告诉它一次这个词该是什么，从此以后每一次 AI 翻译都会按你的写法来。

一份清单，然后它就稳住了

打开设置，进入 高级 → 术语库，添加一份术语库。然后添加术语：词，以及你想让它变成的样子。

就这么简单。prompt 从现在起就是「提示词」——在这一段，在下一段，在你明天读的每一个页面上。

有些词根本不该翻

把术语的译文 留空，这一行会显示 保持原文。陪读蛙会要求模型原样复现它：相同的字符、相同的文字系统、相同的大小写，不转写、不音译，也不会悄悄给它套上引号。

名字需要的正是这个。用户名、handle、产品名、库名、游戏里的道具——这些东西一旦被翻译就失去了用处。

而且因为「别动这个词」无论翻译到哪种语言都成立，这类术语默认归入 所有语言。你把目标语言从中文切到日语，它们照样生效——这本来就是你预期的行为，也正是「按语言分表」的做法做不到的。

工作一份，那个 wiki 一份

工作词汇不该跟着你跑到游戏 wiki 上。所以术语存放在术语库里，每份术语库有自己的网站列表。

网站列表留空，术语库在所有网站生效；填了条目，它就只在那里生效。

*.example.com 包含该网站及其子域名；只写 example.com 则仅匹配这一个地址。* 也不是只能放在前面：example.com/novel/12345/* 能把术语库限定到小说站上的某一本书，而不是整个站点。想让某份术语库暂时靠边站，用它的开关关掉就行——术语原封不动地留在那里。

用不到的地方，它不花一分钱

术语库很容易做成对每次翻译的一笔税：不管有没有命中，都往每个请求里塞一大堆词。

它不是这么做的。陪读蛙会先扫描段落，只把真正出现在其中的术语发出去。一份 5000 条的术语库，在一条都没用到的页面上不会给请求增加任何内容——发出去的提示词和「完全没有术语库」逐字节完全一致，所以你的翻译缓存也毫发无损。

匹配这件事对「什么才算一个词」很讲究，而且在我们支持的每种文字系统里都讲究。cat 不会匹配到 category 里面，caf 不会匹配到 café 里面。中文、日文、韩文、泰文和高棉文的术语不需要两边有空格也能匹配，因为这些语言本来就不在那里放空格。C++ 挨着标点也能匹配。如果你的列表里同时有 Chort 和 Chort Bay，长的那个会在它适用的地方胜出，同时不会在它不适用的地方挡住短的那个。

这次还有什么

• 就地编辑术语。 点某一行的铅笔，这一行会变成输入框——术语、译文、目标语言，以及大小写匹配。改一个错别字，不再意味着删掉整行重新输入一遍。
• 区分大小写。 让 IT 表示「信息技术」，而不会顺带命中文章里每一个普通的 "it"。
• 术语库随 Google Drive 同步，和你的设置放在一起，但存在自己的独立文件里。它们是合并而不是覆盖：两台机器上各自新增的术语会汇成一份列表，在一台设备上删掉的术语不会自己回来。两边确实有分歧时，会把两个版本都摆给你选；任何一次同步都可以从它留下的提示条里撤销。
• CSV 导入导出，并且现在把设置导出成文件时也会一并带上术语库。

从五个词开始

你不需要专门坐下来建一个术语数据库。先建一份术语库，之后每当某次翻译里有个词让你顿了一下，就把它加进去。五条术语，就足以让一篇长文读起来像是一个人翻的，而不是四十个人。

完整细节——网站写法、目标语言、CSV 格式，以及两份术语库冲突时怎么裁决——都在术语库指南里。