涉外合同越来越多法务和合同管理岗隔三差五要出英文版。这篇按问答体讲一套我们跑得比较顺的流程术语表先行、逐段对照插译文、人工定稿。工具是察元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/mcpStreamable HTTP。Claude Code 一行注册claude mcpadd--transporthttp chayuan-wps-mcp http://127.0.0.1:62588/mcpCursor、Codex CLI 填同一个地址即可。连上后 46 个文档工具里读取、插入document_insert 的 after 方式、保存document_save 支持另存为都能串进翻译流程。问译文的定稿责任在谁答在人。AI 译文是高质量初稿不是定稿——尤其责任限额、赔偿、担保这类条款一个介词的差别都可能改变风险分配。我们的流程是 AI 出对照稿法务加外部 counsel 逐段审改完用 document_save 另存定稿版归档对照稿留档备查。工具把翻译周期从按周压到按天但责任边界没变机器出稿人拍板AI 译文不构成法律意见也不替代专业译者的审校。一句收束涉外合同翻译这件事术语表是纪律逐段对照是效率人工定稿是底线——三样凑齐译文才敢往外发。