先建立一个小术语表
把产品名、职位、功能名称和不能翻译的词列出来，写明首选译法。例如 API 保留原缩写，某个按钮使用软件界面里的正式名称。词表不必很大，先收集最容易混淆的十个词。
同一项目中的多人翻译应共用版本，避免同一个功能在不同页面出现三种译法。
把上下文与正文区分开
说明这段文字出现在合同、帮助中心、营销页还是聊天消息中。上下文影响语气和术语，但不应该被混入译文。DeepL API 文档提供独立的 context 参数，是区分两者的一种实现方式。
使用聊天工具时，可以把要求写在“翻译规则”，正文写在另一个明确区域，并要求输出只包含译文和疑问。
一份可复用的请求
“将下文译成面向普通用户的简体中文。保留网址、变量和代码；产品名按术语表；数字与单位不得改写；有歧义的句子列在译文后，不自行补充原文未写的条件。”
翻译前先抽取关键数字，翻译后再比对一次。这比只让模型说“我已检查”更容易验证。
如何检查长文档
先用包含表格、链接和标题的一页做小样，验证导出格式。长文按结构分段，保留标题编号和术语表；不要把每段独立翻译到风格与名称都不同。
字幕翻译还要对齐时间轴，见AI 字幕教程。复杂排版文件应在原编辑器中复查，避免表格被挤到下一页。
何时需要人工复核
涉及重要合同、医疗或财务含义的文字，应交由具备相关能力的人复核。一般产品文档也要检查条件和例外，而不是只看语言顺滑。更多资料核对方法见AI 写作流程。