合同译英文：术语表先行，每段后面插译文

涉外合同越来越多，法务和合同管理岗隔三差五要出英文版。这篇按问答体讲一套我们跑得比较顺的流程：术语表先行、逐段对照插译文、人工定稿。工具是察元AI文档助手，WPS 加载项加本机 MCP 服务，整条链路的重点只有一个——合同不出域。

问：为什么不直接丢给在线翻译？

答：两个理由。一是安全：合同是最敏感的文件类型，上传到翻译网页等于主动出域，多数保密制度直接禁止；察元的模型端可以接 Ollama、LM Studio 等本地端点，加载项和服务只在本机（127.0.0.1）通信，从文档到模型全程不出这台电脑。二是质量：整篇直译最大的问题是术语漂移——"违约金"前文译 liquidated damages，后文变成 penalty，这两个词在英文合同里的法律含义差别很大，一旦发生争议，术语不一致本身就是对方的攻击点。

问："术语表先行"具体怎么做？

答：动笔翻译之前，先把关键术语的中英对照定死：主体名称、合同标的、违约金、不可抗力、争议解决、保密义务、责任限额。中文侧先用内置的"术语统一"助手确认全文表述一致（"违约金"和"违约赔偿金"不能混用），英文侧由法务或专业译者定稿。这份术语表同时约束整个翻译过程。有知识库的团队还可以用 kb_retrieve 检索历史项目定过的译法，保持跨项目一致——译过一次的术语，第二次不该再议。

问：为什么是"每段后面插译文"，不是整篇另出一份？

答：审校效率差别很大。整篇另出一份，审校时两个窗口来回切、来回找段落；逐段对照——原文段后紧跟译文段——视线不用跳，术语漂移一眼就能看出来。察元的写回方式里正好有"插入到每段后面"这一式，内置翻译助手（目标语言可配置）跑完按这个方式写回，原文不动、格式保留。给一份提示词参考：

按以下术语表把本文档逐段译成英文，译文插入到每个原段落后面：违约金=liquidated damages；不可抗力=force majeure；保密义务=confidentiality obligations。术语表以外的表述自行斟酌，不确定处插入【待确认】标记而不是硬译。

问：长合同怎么处理？

答：分块。走 MCP 的话先 document_meta 看是否建议分块，超长文本（约 80k 阈值）用 document_chunks 分页读，逐块翻译逐块插回。用智能体编排时提醒它"按分块处理，不要试图一次整读"，能少走弯路。表格多的合同还有个省事的做法：用表格的 header_read、column_read 按列读，付款表、价格表里的数字和币种逐列核对，比按行扫靠谱得多。

问：审校阶段还能配合什么？

答：英文稿初翻完，先用内置"术语统一"助手把英文侧也过一遍——核对 liquidated damages 是不是全文只有一种写法，有没有哪段又冒出 penalty；发现不一致处用批注钉住，改不改由人定。定稿前再跑一遍双语对照稿的终检：

帮我做发布前终检：错别字、标点、数字前后一致性、表格与正文是否一致；全部用批注输出；最后给我一份问题分级摘要（严重/一般/建议）。

中英对照稿里数字一致性尤其要紧：中文段写一百二十八万，英文段写成 1.28 million 还是 12.8 million，肉眼对很容易花，机器逐位比一次就安心。

问：MCP 智能体怎么接？

答：服务地址 http://127.0.0.1:62588/mcp（Streamable HTTP）。Claude Code 一行注册：

claude mcpadd--transporthttp chayuan-wps-mcp http://127.0.0.1:62588/mcp

Cursor、Codex CLI 填同一个地址即可。连上后 46 个文档工具里，读取、插入（document_insert 的 after 方式）、保存（document_save 支持另存为）都能串进翻译流程。

问：译文的定稿责任在谁？

答：在人。AI 译文是高质量初稿，不是定稿——尤其责任限额、赔偿、担保这类条款，一个介词的差别都可能改变风险分配。我们的流程是 AI 出对照稿，法务加外部 counsel 逐段审，改完用 document_save 另存定稿版归档，对照稿留档备查。工具把翻译周期从按周压到按天，但责任边界没变：机器出稿，人拍板，AI 译文不构成法律意见，也不替代专业译者的审校。

一句收束：涉外合同翻译这件事，术语表是纪律，逐段对照是效率，人工定稿是底线——三样凑齐，译文才敢往外发。