同样几个大写字母，可能是部门简称、产品系列，也可能只是内部编号。把它直接展开成一个看起来熟悉的词，再交给翻译工具，后面的句子即使流畅，也可能从一开始就理解错了。使用CC翻译处理消息或资料时，缩写和专名值得单独核对。
下面提供一套人工查证流程，适合日常消息、产品介绍和团队资料。术语记录可以放在普通文档或表格中，不假设客户端必然提供自动术语锁定或专名识别功能。
一、先收集上下文，不急于展开字母
把待核对内容连同所在句子、前后段落和资料主题一起看。单独出现的缩写很难判断；旁边若有“负责人”“交付版本”“设备型号”等线索，才能缩小含义范围。还要区分它指一个对象，还是描述一种操作。
例如“请把AC交给同事”本身信息不足。这里的AC只是虚构示例，不能仅凭常见缩写表替它选一个解释。可以问：“本句AC指哪份文件或哪个产品？是否有完整名称？”得到明确答复前，先标记待确认。
带有数字、连字符或特定大小写的字符串，也可能是需要原样保留的型号。不要为了让译文更自然，把“AC-02”拆成普通单词，或把数字、大小写和连接符随意改写。
图示：上下文决定查证方向，单靠字母形状不能确定含义。
二、按来源确认含义与官方写法
先看原资料是否已经给出全称、术语表或首次出现时的解释；再检查发布方的产品页面、手册或当前项目认可的资料。内部简称应向提供者确认，公开词典不一定包含本团队约定的意思。
搜索结果只能作为线索。若网页讲的是另一行业、旧型号或不同地区的产品，即使字母相同，也不能直接套用。记录所依据的页面、资料版本和确认日期，方便后来复查。
多个翻译通道给出相同结果，并不能单独证明缩写已被正确理解。微软的缩写写作指南也提示，像RAM这样可能与普通英语词形重合的缩写，在机器翻译中需要留意误译。这个提醒用于说明风险，不代表应把所有缩写都自动展开。
三、区分解释含义和改动名称
确认一个名称是什么意思，不等于可以把名称本身改掉。品牌、组织、产品、功能入口和型号各有使用范围：有经确认的目标语言名称时采用对应写法；没有时，可以保留原名，并在需要的地方补一句简短说明。
例如虚构品牌“North Pine”在介绍中可保留为名称，另写“本次资料中的设计工作室”。不要把字面译法直接当作它已经采用的中文品牌名。需要读者在网页或界面中找到原对象时，保留原文尤其有帮助。
对于读者不熟悉且会重复出现的缩写，可在首次出现时补充经核实的全称或中文解释，后面统一使用约定写法。只出现一次的普通概念，可以直接写清含义，避免再制造一个需要读者记忆的简称。
图示：解释帮助理解，名称帮助找到同一个对象，两者应分开处理。
四、建立一份小而明确的术语记录
每个条目写清原文、确定含义、采用写法、适用场景、依据和状态。比如“AC｜本项目某份文件的内部简称｜保留AC并附文件全名｜仅本项目消息｜经资料提供者确认”。示例仍需替换成真实核实结果，不能照搬虚构解释。
把“已确认”和“待确认”分开。一个词在产品手册中有固定含义，不表示在客户的另一段消息中也一定相同。若同形词存在多个义项，给每项补充使用条件，不用一个全局替换覆盖全部文本。
术语记录只保留查证所需信息，不必把整段私人对话复制进去。团队交接时说明哪些条目已经有依据，哪些仍需询问，而不是只交出一列看似确定的译名。
五、发送前回到全文检查一次
查找原缩写及其可能变体，逐一核对上下文，确认没有同一对象多种写法、不同对象被合并成同一名称，或型号字符被误改。再看首次解释是否足够，后文是否仍能对应原资料。
仍未解决的内容可以保留原文，并明确写出具体问题，例如“此处AC的全称待提供者确认”。需要对外正式发送时，先让相关人员核实，不让疑问在润色过程中悄悄消失。
图示：一致性检查建立在含义核实之后，不能替代查证。
功能场景参考：CC翻译首页。涉及软件入口与名称，可继续阅读多语言软件操作说明校对指南；智能建议的事实核对可参看人工复核方法。