翻译公司术语库管理与初译校对流程：用 Claude Code 减少返工

周五傍晚，一份已经交付的产品手册译稿被客户挑了刺：“产品名的写法，跟上一期不一样吧？”

我一查，确实不一样。上期写的是“客户账户”，这期变成了“用户账户”。术语库里明明写着“客户账户”，可赶进度的译员看漏了，校对也没拦住。我做翻译公司协调员这三年，遇到最多的返工就是这一类。

这事谁都不能全怪。术语库是一张两百多行的 Excel，每个项目还会零星往里加几条。译员被截稿日追着跑，校对要逐字盯完整篇。光靠人的注意力把所有写法不统一都拦下来，本来就不现实。

于是我让 Claude Code 来做“术语检查的第一道过滤”。判断仍然留给人，机器先把那些一眼能看出来的错挑出来。效果比我预想的好，所以我从翻译公司协调员的角度，把整套做法整理出来。

本文要点

写法不统一、译词不一致，大多是“机器能看出来的错”，Claude Code 的第一道检查就能拾起大半。
术语库别直接拿 Excel 用，转成 CSV 或纯文本、当成“规则清单”交给 AI，准确率会更高。
初译和校对流程，把“AI 来挑 / 人来定”分开，返工就会变少。
客户原文和术语库里有专有名词和未公开信息，发送范围必须管起来。
每个项目校对前处理省下 30 到 60 分钟，一个月跑 10 单，就能省出几个小时到十几个小时。

翻译公司现场到底在出什么问题

先把读者画像对齐。这篇文章设想的对象，是在翻译公司里跑项目的协调员：你不一定亲自译完全文，而是站在译员和校对之间，管着术语库，被交期和质量两头夹着。编程经验几乎没有，最多碰过一点宏。

翻译公司常见的业务流程，大致是这样：

从客户那里拿到原文、过往译稿和术语库。
把初译派给译员。
校对（审校员）检查译文。
协调员做最终确认后交付。

返工最容易出在哪一段？凭经验看，绝大多数卡在第 2 步和第 3 步之间。

术语库里定好的译词，译员没用上（写法不统一）。
数字或单位跟原文对不上（“3.5kg”被写成“3.5g”之类）。
漏译（原文里有一句，译文里找不到）。
全角半角、括号种类跟项目规则不一样。

这些都是“看一眼就该发现”的错。可一旦要靠人眼逐字盯完整篇，项目越长越容易看漏。校对漏掉的，转到协调员手上，最后变成交付后的投诉。这段“人在找机器本该能看出来的错”的时间，就是翻译公司藏起来的成本。

交给 AI 的范围，和人必须自己判断的范围

这条线不先划清楚，迟早出事。Claude Code 很聪明，但绝不能让它给翻译质量下最终结论。界线是这样的：

工序	交给 Claude Code	人（校对、协调员）来判断
术语检查	把术语库和译文比对，列出不一致的地方	这处不一致是错，还是上下文里的例外
写法不统一	抽出全角半角、括号、词形的不一致	按客户偏好定下的最终写法
数字与单位	检出原文与译文数值的差异	单位换算对不对、含义是否合理
漏译	报告原文句数与译文句数的差距	是不是有意合并或拆分了句子
译文质量	（不交。最多辅助初译）	自然度、语气、误译的最终判断

关键是别让 AI“拍板定对错”。AI 做的只是“这里看着可疑”地贴张便签，撕不撕、留不留，由人来决定。这个分工一旦破掉，就会出现把 AI 的误判原样交付的事故。

不知道该怎么写“交给它的范围”，可以参考 claude-code-prompt-engineering-advanced 里的提示词设计。指令一旦含糊，AI 就会自作主张“帮你改了”，所以诀窍是连输出格式都一并指定清楚。

用例一：与术语库的比对

这一项最见效。把术语库和译文一起递给它，只让它用表格返回不一致的地方。

先把术语库从 Excel 转成 CSV。与其把 Excel 原样丢给 AI，不如做成“原词, 译词, 备注”三列的文本，AI 更容易把它当规则来读。准备阶段的提示词是这样：

你是翻译公司的校对助手。
请按以下术语库，只指出译文中的术语不一致之处。

# 规则
- 仅报告未使用术语库“译词”的地方
- 不判断是否为上下文中的改写，机械地把所有不一致全部列出
- 不要改。只指出
- 输出为表格：| 行号 | 原词 | 应有译词 | 实际译词 |

# 术语库（原词, 译词, 备注）
customer account, 客户账户, 全项目通用
sign in, 登录, 该客户统一用“登录”
delete, 删除, 不可用“清除”

# 译文
（把译文粘贴到这里）

返回的不是“修改稿”，而是“不一致清单”。校对从上往下看那张表，只决定改不改。这比从头重读全文快得多。

引入之前，校对要在另一个窗口里开着 Excel 术语库，跟译文逐处人工核对。引入之后，工作变成确认 AI 贴好的便签。同样是“确认”，从零开始找和看着候选去判断，负担完全是两回事。

用例二：初译的前处理检查清单

在派给译员之前，或者初译刚交上来时，先过一遍机器检查。检查项直接照搬这张清单就行：

术语库的译词是否在所有出现处都用上了
原文与译文的数字、单位是否一致
有没有漏译（原文有、译文没有的句子）
全角半角、括号种类是否符合项目规则
产品名、人名、专有名词的写法是否与过往译稿一致
有没有混入禁用表达（客户反感的措辞）

把这个检查放在初译阶段做，错误在递到校对手上之前就先减一批。校对就能在“机器能拾的部分已处理完”的前提下，专注于译文是否自然、有没有误译这类只有人能做的判断。

要让 AI 帮着做初译本身，也别一上来就把全文交出去，只让它产出“结合过往译稿和术语库的初译草稿”，最终译文还是人来打磨。团队刚开始用 AI 的话，先读一遍 claude-code-for-non-engineers，对“能交到哪一步”会有更清楚的感觉。

用例三：写法不统一的定期盘点

项目跑久了，术语库本身也会过时。“以前用删除，这一期开始改成清除也行了”这类变更口头传一传，没同步进术语库，现场就乱了。

所以每月做一次：把过往交付的稿子集中喂给 AI，找出“同一个概念被套上了多个译词”的地方，术语库维护漏掉的部分就浮出来了。把项目的通用规则汇成一个文件，AI 每次都会去参照它。按 claude-md-best-practices 的做法，把每个项目的约定收进一个文件里，运营起来会轻松很多。

可直接复制的提示词模板

放一个用于校对第一道检查的通用模板。只要替换项目名和术语库就能用。

# 角色
作为翻译公司校对第一道检查负责人，只报告机器能检出的错误。

# 输入
- 术语库（原词, 译词）
- 原文
- 译文

# 要做的（按此顺序）
1. 抽出术语不一致
2. 抽出数字、单位与原文的差异
3. 报告漏译嫌疑（原文句数 > 译文句数）
4. 抽出全角半角、括号的不统一

# 不做的
- 不改写译文
- 不评价译文好坏
- 不做例外判断（判断交给人）

# 输出格式
## 术语不一致
| 位置 | 应有译词 | 实际 |
## 数字与单位
| 原文 | 译文 | 差异 |
## 漏译嫌疑
- （位置）
## 写法不统一
- （位置）
若无问题，则在每节写上“无指出事项”。

可运行的检查脚本：用机器拾起数字不一致

在递给 AI 之前，先把那种机器一定能看出来的“数字偏差”单独处理掉，对 AI 的依赖就降下来了，也更稳妥。我准备了一个能在 Node.js 上跑的小脚本：把原文和译文以文本传入，它会列出只在一边出现的数字。

import { readFile } from "node:fs/promises";

// 通过命令行参数接收原文、译文文件路径
const [srcPath, tgtPath] = process.argv.slice(2);
if (!srcPath || !tgtPath) {
  console.error("用法: node check-numbers.mjs 原文.txt 译文.txt");
  process.exit(1);
}

const src = await readFile(srcPath, "utf8");
const tgt = await readFile(tgtPath, "utf8");

// 把所有数字（含小数、千分位逗号）都拾起来
const pick = (text) => (text.match(/\d[\d,.]*/g) || []).map((n) => n.replace(/,/g, ""));

const srcNums = pick(src);
const tgtNums = pick(tgt);

// 把只在一边出现的数字作为差异列出
const diff = (a, b) => a.filter((n) => !b.includes(n));

const onlyInSrc = diff(srcNums, tgtNums);
const onlyInTgt = diff(tgtNums, srcNums);

console.log("仅原文中有的数字:", onlyInSrc.length ? onlyInSrc.join(", ") : "无");
console.log("仅译文中有的数字:", onlyInTgt.length ? onlyInTgt.join(", ") : "无");

if (onlyInSrc.length || onlyInTgt.length) {
  console.log("→ 疑似数字偏差，请核对相应位置。");
  process.exit(2);
}
console.log("→ 数字一致。");

保存后直接运行即可。

node check-numbers.mjs source.txt target.txt

它不是完美检测。语序一变就可能误报。但像“3.5 从译文里消失了”这种致命偏差，它比人眼更快、更稳地找出来。在依赖 AI 判断之前，先放这种确定性的检查，是个诀窍。第一次上手 Claude Code 的话，照 claude-code-getting-started-guide 的步骤把环境配好再试。

安全与个人信息注意事项

对翻译公司来说，这一段关乎生死。原文里有未公开的产品信息、合同、个人姓名。处理失手，别说提效，连信誉都会丢。

务必确认客户的保密协议（NDA）是否允许把数据发送到外部 AI 服务。
没有许可的项目，先把专有名词、数值替换成假数据再做检查。
个人信息（姓名、地址、联系方式）在检查前做脱敏。
选择不会把发送数据用于训练的设置或合同形态。
用一张管理表逐项目记录“可用 AI / 不可用 AI”，在协调员之间共享。

拿不准时，“不发”就是正解。术语库比对，即便把专有名词遮掉，作为写法规则检查也照样管用。对个人信息处理没把握，可以对照中国《个人信息保护法》之类的官方依据，比如全国人大公布的个人信息保护法全文，确认自家做法没有偏出去，会更安心。

ROI 大致估算

只是粗略概算，分享个感觉。中等规模的产品手册一单（原文一万字左右）的校对，过去人在术语核对和数字检查这道前处理上，要花 30 到 60 分钟。

把第一道过滤交给 AI 和检查脚本后，这道前处理缩到 10 分钟上下。一进一出省了 20 到 50 分钟。一个月跑 10 单的翻译公司，每月就能省出几个小时到十几个小时。

省下的时间，校对可以转去做误译、语气这类只有人能做的判断。这不只是单纯提速，更重要的是把人手往质量的最后一道防线上靠。

常见问题

问：能不能让 AI 直接改译文？ 不建议。一旦把修改也交出去，AI 的误判会原样钻进译文，反而让校对变多。请守住 AI 只“指出”、修改由人来做的分工。

问：术语库超过 500 行，能全都传进去吗？ 现实做法是只传跟当前项目相关的范围。全都传进去准确率会下降。按项目类别把术语库拆开，运营起来更顺。

问：这跟机器翻译引擎有什么不同？ 角色不同。机器翻译是生成译文，这里介绍的是检查已生成译文的第一道过滤。两者搭配，就能把生成和检查这两端都覆盖住。

问：这会不会让校对没活干？ 正相反。校对从“找机器能看出来的错”里解放出来，去专注误译和语感这类只有人能做的判断。说的是把时间往更有价值的工序上靠。

问：想以公司名义引入，从哪里开始？ 先用一个项目试最稳。先把数字检查脚本放进去，熟了再扩到术语核对。需要为整个团队设计运营流程的话，可以在培训与咨询里一起把具体流程搭起来。

实际试过的结果

我用手头的模拟项目（一段产品手册，原文约 3000 字）实际跑了一遍。故意把“客户账户”在 3 处改成“用户账户”，又把一个数字从“3.5”改成“35”埋了进去。

数字检查脚本一下就把埋进去的“35”当作“仅译文中有的数字”拾了出来。术语核对的提示词，把 3 处写法不统一全列进了表里。另一方面，有一处是我按上下文有意改写的，它也当成“不一致”列了出来，这处就由人判断“这是例外”而保留。

我想确认的，是“AI 贴便签、人决定撕不撕”这个分工在实务里跑不跑得通。结论是：只要把流程改成机器拾候选、人来确认，从零开始找的那种心理负担就大幅减轻。不是追求完美自动化，而是在守住人做最终判断的前提下，让机器替你扛掉前处理。翻译公司的现场，跟这个距离感正好合得来。