1. 这份词表真正要解决的是词典查不到的那几个瞬间计算机专业英语词汇翻译这件事最容易被低估。很多人第一反应是不就是把英文翻成中文吗查个词典的事。真到用的时候才知道通用词典在技术文本面前几乎帮不上忙。我做过几年技术文档的翻译和审校也帮不少人改过投出去的论文见过太多每个单词都认识连起来就是不说人话的句子。计算机专业英语词汇翻译的难点从来不在词汇量而在于一个词在技术语境里被赋予了完全不同的义项而你手上那本词典根本没收录这个义项。举个最直观的例子bus。通用词典排在第一位的是公共汽车。可你在体系结构文档里看到memory bus、bus bandwidth、bus contention它就只能是总线。再比如port在网络语境里是端口在编译器语境里port the code to another platform变成了动词移植在硬件语境里还能指端口/接口。一个词、三种译法、三个领域哪个都不能算错可你一旦用错整段话的可信度就没了。这份词表之所以值得单独整理是因为它要解决三个具体问题。第一是义项锁定帮你在特定领域里快速找到唯一正确的中文对应词而不是给出一堆让你自己猜的选项。第二是搭配还原技术英语大量使用固定搭配cache hit是缓存命中cache miss是缓存未命中单独查hit和miss你永远组不出这个说法。第三是反向检索很多人的真实需求不是英译中而是写着中文突然想不起英文该怎么说这份表得支持双向查。适合谁来认真啃这个东西刚入行、需要读第一手英文文档的开发者要写英文摘要和投稿的技术写作者做技术文档本地化的译者还有准备读研、要啃英文教材的学生。有经验的人也别急着跳过下面讲到的词表结构设计和翻译决策原则很多人做了五六年仍然是凭语感在翻一旦遇到没见过的词就露馅。1.1 通用词典在技术文本面前的三个失灵点第一个失灵点是义项缺失。技术领域每年都在造新词词典的更新周期根本追不上。像sharding、idempotent、observability这类词早几年的词典要么不收要么收了个跟实际用法对不上的解释。你只能靠上下文硬猜猜错的概率还不低。第二个失灵点是语域错配。同一个词在通用英语里是中性词在技术语境里带上了特定含义。fault在日常生活里是过错在存储系统里page fault是缺页在可靠性工程里fault tolerance是容错。你要是按日常语义去理解整个技术描述就跑偏了。第三个失灵点是词性漂移。技术英语特别喜欢把名词直接当动词用to interface with、to host a service、to mirror a disk、to scale out。词典里这些词的动词义项往往标注不全或者干脆不标。翻译的时候如果不敢还原成动词写出来的中文就会非常僵硬比如把the system hosts multiple services翻成系统有多个服务的宿主读起来像机器翻译。提示判断一个词是不是技术义项最快的办法是看它前后有没有同领域的专业名词做搭配。孤立出现的词按日常义项处理一旦进了术语集群立刻切到专业义项。1.2 2013年前后那批词表留下的骨架与它的局限2013年前后国内不少教材和配套词表形成了一个相对固定的结构按章节走每章末尾列十几个专业词汇给出英文、音标、中文释义偶尔加一句例句。这套骨架放到今天依然有价值——它至少完成了领域切分这件最难的事把词汇按硬件、操作系统、网络、数据库、软件工程分好了堆。但它的问题也很明显。第一只给单一译名不处理多义。比如thread只写线程可你在图形学里遇到thread指的是渲染线程在纺织业的比喻用法里还有别的意思词表不管。第二不做搭配标注导致学习者认识每个词却组不出短语。第三没有反向索引中文找英文基本靠翻。第四例句脱离真实语料很多例句是造出来的语法正确但没人这么说话。所以正确的做法不是推倒重来而是把这套骨架留下来在字段和检索方式上补齐。骨架是好的血肉得自己长。2. 词表结构怎么设计才经得起天天用一份能天天用的词表和一份看起来很全的词表差距全在字段设计上。我见过太多人用 Excel 两列一拉英文一列中文一列做完成就感满满一个月后再也没打开过。原因很简单查不到、查不准、查了不敢用。要让它活下来每一行记录得装够信息。2.1 一行记录到底该装哪些字段我的建议是七个必备字段加三个可选字段。必备的是英文词条、词性、所属领域、首选译名、备选译名、典型搭配、易混提示。可选的是音标、真实例句出处、首次收录日期。词性这一栏千万别省。abstract作形容词是抽象的作名词是摘要作动词是提取/抽象出。三个词性三个译法不标词性等于埋雷。所属领域用来做筛选一个人同时在看网络和数据库的文档靠领域标签能立刻把干扰项过滤掉。首选译名和备选译名要分开这个设计是有讲究的。首选译名是你在正式文档里应该用的那个备选译名是口语、内部讨论、旧文档里可能出现的说法。比如daemon首选守护进程备选后台服务进程legacy system首选遗留系统备选老旧系统。分开标你就知道正式场合该用哪个读旧文档时也不会被备选译名卡住。典型搭配这一栏是整张表价值最高的部分。commit单看是提交配上commit a transaction是提交事务配上commit changes是提交变更配上commit to memory又变成写入内存。搭配写全了你才知道这个词在句子里怎么活。2.2 按领域分层别按字母排序按字母排序的词表只适合背单词不适合查词。真实使用场景是你正在读一段讲虚拟内存的文字遇到不认识的词你希望看到的是内存管理这一组里的所有相关词而不是跑去 H 字母下面找hierarchy。我的做法是两级分类。一级按大领域分成硬件与体系结构、操作系统、网络、数据存储、算法与数据结构、软件工程、图形与多媒体、人工智能八个组。二级在每个组内部再按主题聚类比如内存管理下面聚paging、swapping、page fault、thrashing、working set、resident set这一串它们本来就是一起出现的概念放一起查一个就带出一片。这样组织还有个额外好处同组词汇的译名风格容易统一。同一个组里你要么全用页要么全用页面不会出现一会儿分页一会儿页面调度的混乱。2.3 一份可以直接抄的CSV表头下面这个表头我用了很久字段不多但够用导入任何表格软件或者写脚本处理都很方便term,pos,domain,primary_zh,alt_zh,collocations,pitfall,example,source,added_date bus,n,hardware,总线,,memory bus;bus bandwidth;bus contention,日常义为公共汽车技术语境一律译总线,The memory bus runs at 3200 MT/s.,manual,2013-09-01 port,n/v,network,端口,移植,port number;port the code,名词译端口动词译移植,We ported the service to a new runtime.,manual,2013-09-01字段名用英文不是崇洋是为了后面写脚本处理时不用处理中文列名带来的编码麻烦。pitfall这一列是我最看重的它记录的是这个词最容易翻错的地方属于踩坑经验的沉淀比任何词典释义都值钱。注意别一开始就追求大而全。先收录你最近一个月真实遇到过的词一百条左右就能形成正反馈。贪多求全做出来的五千条大表最后通常只用了前五十条。3. 翻译决策的核心原则为什么这么翻而不是那么翻词表填到一定量你会发现真正难的不是这个词什么意思而是这个词该翻成哪个中文。同一个英文词三种译法都有文献在用你选哪个这里面有一套可以复用的判断逻辑不是纯靠语感。3.1 约定俗成优先于字面准确技术译名的第一原则是跟随社区习惯而不是追求字面对应。firewall字面是防火墙这个译法既准确又形象皆大欢喜。但middleware译中间件就纯粹是约定俗成——按字面该是中间的软件可没人这么说。framework译框架也是同理直译骨架结构反而没人认。判断一个译名是否已经约定俗成最靠谱的办法是看它在中文技术文献里的出现频率而不是看它翻得漂不漂亮。一个翻得更好但没人用的译名写进文档只会让读者多绕一道弯。我的经验是如果某个译名在主流中文技术资料里已经稳定出现五年以上就跟着用别创新。反过来有些词至今没有稳定的中文译名比如serialization有人译序列化有人译串行化container在虚拟化语境下是容器。这类词的处理办法是首次出现时中英并列后文统一用其中一个。这样既照顾了可读性也避免了歧义。3.2 一词多义必须按语境锁定义项不能含糊前面提过port的三重身份这类词在技术英语里占比不低。我的处理方式是在词表里拆成多行而不是一行写多个义项。一行一个义项配上各自的领域标签和搭配检索的时候才不会串。举个更典型的例子interface领域词性译名典型搭配面向对象n接口implement an interface; interface segregation硬件n接口hardware interface; interface card通用v对接、交互interface with the backend人机交互n界面user interface四行四个义项互不干扰。你要是压成一行写接口/界面/对接查的时候还得自己判断等于没帮上忙。再比如scale。作名词在分布式系统里是规模at scale是大规模地作动词scale up是纵向扩容scale out是横向扩容scale down是缩容。这三个方向词一旦译混整个架构描述就错了。我在词表里专门给scale建了一个子组把vertical scaling、horizontal scaling、autoscaling全放一起对比着记。3.3 缩写、全称与那些确实没法翻的词技术文本里缩写密度极高处理原则有三条。第一条首次出现给全称加缩写格式是中文全称英文全称缩写比如内容分发网络Content Delivery NetworkCDN。第二条行业内高度共识的缩写直接用不必展开比如 CPU、HTTP、SQL 这类展开了反而累赘。第三条有歧义的缩写必须在词表里标出来比如GC可能是垃圾回收也可能是图形上下文VM可能是虚拟机也可能是虚拟内存遇到就靠上下文判断词表里两个义项都留着。至于那些确实没法翻的词处理方式要坦率一点。bug译缺陷或故障都行但工程口语里大家就说bug硬翻反而别扭。patch译补丁已经固定。deploy译部署也稳了。真正难的是robustness这类抽象词译健壮性是主流也有人用鲁棒性音译两种都有人用词表里两个都收注明使用场景正式文档用健壮性口语交流用哪个都行。还有一类是文化负载词比如hack。它在不同语境下可以是巧妙实现褒义、临时凑合的方案中性、非授权入侵贬义。这个词我是坚决主张保留英文原词的翻成中文无论选哪个都丢信息。4. 从零整理自己词表的完整流程光讲原则不动手词表永远是别人的。下面这套流程我自己跑过好几轮从零到能用大概两三个晚上之后是持续的小幅维护。流程不复杂但每一步都有容易翻车的地方。4.1 素材采集从你真实读过的文本里捞词最忌讳的做法是去网上找一份计算机专业英语词汇大全直接导入。那种表八成是拼凑的词条之间没有语境关联导入之后你也不知道哪些该优先学。正确的做法是从自己的阅读材料里捞。具体操作把你最近在读的英文文档、论文、源码注释攒起来用脚本统计词频按领域分开看。下面这段 Python 是我常用的粗筛脚本功能是把文本切成词、去掉停用词、统计高频import re from collections import Counter STOPWORDS set(the a an of to in for on with and or is are was were be been being this that these those it its as at by from into than then so such we you they he she i not no if when which who whom whose what how.split()) def tokenize(text: str): # 只保留字母和连字符连字符是为了保住 real-time、read-only 这类复合词 words re.findall(r[A-Za-z][A-Za-z\-]*, text.lower()) return [w for w in words if w not in STOPWORDS and len(w) 2] def rank(text: str, topn: int 200): counter Counter(tokenize(text)) return counter.most_common(topn) if __name__ __main__: with open(sample.txt, encodingutf-8) as f: content f.read() for word, freq in rank(content): print(f{word}\t{freq})跑完你会得到一长串词。接下来是关键一步人工过一遍只留下技术术语和技术语境下义项漂移的普通词。像system、data这种虽然高频但译名固定的可以不进表像fault、handle、mount这种一词多义的必须进表。这一步没有捷径但一篇文章过下来也就几十个词不累。4.2 去重、归并与版本管理多个来源捞出来的词一定会重复而且重复的方式很讨厌大小写不同、单复数不同、连字符写法不同。cache和caches、read-only和readonly在表里得归并成一条。归并规则我定得很简单词条统一用小写、单数形式动词保留原形复合词保留连字符。然后在备注里记下变体形式。这样检索的时候只需要查一种写法不用猜。版本管理这块别用词表_v1_final_最终版.xlsx这种命名。用 Git 管 CSV 文件每次改动提交一次写清楚这次加了哪些词、修了哪些译名。好处是出问题能回滚而且你能清楚看到自己的翻译判断是怎么演变的——我翻回去看三年前的记录发现好几个词当初译错了这种复盘价值很高。# 初始化 git init wordlist cd wordlist cp ~/Desktop/terms.csv ./terms.csv git add terms.csv git commit -m 初始导入硬件与操作系统两组共 136 条 # 后续每次增补 git add terms.csv git commit -m 新增网络组 42 条修正 socket 译名为套接字4.3 用脚本做批量校验和双向检索表建起来之后最实用的两个功能是一致性校验和双向检索。一致性校验解决的是同一个英文词在不同行写了不同译名的问题。这种错误人工很难查出来写几行代码就搞定了import csv from collections import defaultdict def check_consistency(path: str): mapping defaultdict(set) with open(path, encodingutf-8) as f: for row in csv.DictReader(f): mapping[row[term].strip().lower()].add(row[primary_zh].strip()) problems {k: v for k, v in mapping.items() if len(v) 1} if not problems: print(无冲突) return for term, names in problems.items(): print(f[冲突] {term} - { / .join(sorted(names))}) if __name__ __main__: check_consistency(terms.csv)双向检索更简单直接写个函数把中文和英文都建索引def build_index(path: str): idx {en: {}, zh: {}} with open(path, encodingutf-8) as f: for i, row in enumerate(csv.DictReader(f)): idx[en].setdefault(row[term].lower(), []).append(i) idx[zh].setdefault(row[primary_zh], []).append(i) if row.get(alt_zh): for name in row[alt_zh].split(/): idx[zh].setdefault(name.strip(), []).append(i) return idx有了这个索引你写中文想不起英文的时候直接查中文就能拿到候选词比翻整个表快得多。5. 高频词逐条拆解那些年年考、年年错的地方下面这几组词是我在改稿和答疑里被问到次数最多的。它们的共同特点不是难而是看着简单、实际有坑。逐条拆一下顺便把搭配和易错点标出来。5.1 硬件与体系结构组bus和channel经常被混。bus是总线指多个部件共享的传输通路channel在体系结构里常译通道指的是独立于 CPU 的 I/O 处理通路两者层次不同别混用。word这个词在通用英语里是单词在体系结构里是字指的是 CPU 一次能处理的位数单位。word size、word length、32-bit word全是这个意思。这个词翻错的后果很严重因为字长和单词长度在中文里完全是两个概念。register译寄存器但作动词register是注册两者在不同语境下出现频率都很高。cache译缓存但要注意cache既是名词也是动词cache the result是缓存结果。pipeline译流水线这个没什么争议。但pipeline stall是流水线停顿pipeline hazard是流水线冒险这两个术语的中文译法在教材里不统一有的教材把 hazard 译冲突。我的建议是首次出现时加英文原文避免读者按自己熟悉的教材理解。5.2 操作系统与并发组这一组是重灾区因为并发概念本身抽象中文译名又很接近。mutex和semaphore常被一起提但不是一个东西。mutex译互斥量本质是一把锁只有加锁和解锁两种状态。semaphore译信号量是一个计数器可以有多个许可。把semaphore也译成互斥量就完全错了——这是新手最常见的错误之一词表里必须把两者放在相邻两行对比着标。deadlock、livelock、starvation三个一起记。deadlock是死锁所有参与者互相等待谁也动不了。livelock是活锁大家都在动但状态反复变化业务没有任何推进。starvation是饥饿某个参与者始终拿不到资源。这三个词的中文译名都很形象记概念比记词更重要。page fault译缺页但要注意它和segmentation fault段错误不是一回事。前者是正常的虚拟内存机制后者是程序崩溃。我见过有人把page fault翻成页面错误虽然不算错但社区里九成的人都用缺页用不常用的译法会让读者愣一下。volatile这个词在并发语境里译易失的在 Java 语境里是个关键字通常保留英文不翻。atomic译原子的atomic operation是原子操作。primitive译原语synchronization primitive是同步原语。5.3 网络与数据存储组socket译套接字这个译名很怪但已经固定别自己另创。handshake译握手three-way handshake是三次握手。throughput和bandwidth经常被混为一谈。bandwidth是带宽指理论上的最大传输能力throughput是吞吐量指实际跑出来的数据量。这两个词在网络性能描述里反复出现混了会直接导致性能分析结论错误。latency译延迟但要注意latency和delay在中文里都译延迟。区别在于latency更偏系统固有的响应时间delay更偏人为或过程造成的推后。技术文档里end-to-end latency是标准说法端到端延迟。数据库这组里transaction译事务commit译提交rollback译回滚。index译索引。view译视图。join在 SQL 语境里译连接但join在关系代数里也有人译联接两种都行同一份文档里统一就好。sharding译分片replica译副本replication译复制。normalization译规范化但数据库教材里也常用范式化词表里两个都收。idempotent译幂等的这个词在分布式系统里出现频率极高指同一个操作执行多次和执行一次结果一致。这个译名是音译加意译的混合但已经固定别改。6. 常见问题与排查速查词表用了一段时间之后问题主要集中在查不到和查到了不敢用这两类。下面这些是我自己被坑过、也被别人问过的典型情况整理成表方便对照。6.1 六类高频问题与处理方式问题现象可能原因排查方式处理建议查一个词表里没有词条被归并成单数形式查单数形式或者用模糊匹配检索时统一转小写、去复数同一个词查到两个译名一词多义但没拆行看领域标签是否不同拆成多行各配领域中文能查到英文查不到只建了英到中的索引检查备选译名是否入索引备选译名也要进中文索引译名正确但句子不通只记了词没记搭配查 collocations 字段补上典型搭配同一份文档前后译法不一致没有一致性校验跑一遍冲突检测脚本定首选译名其余降为备选老文档里的译名看不懂社区译法已经演进查备选译名和历史记录保留旧译名并标注旧称6.2 几个我踩过的具体坑坑一用一个词的全部义项去覆盖语境。早期我把handle写成句柄/处理一行搞定。结果查的时候只知道有这两个意思不知道哪个场合用哪个。后来拆成两行handle作名词在操作系统里是句柄作动词在业务流程里是处理问题才解决。坑二忽略了缩写的大小写。DB和db、OS和os在检索时是两回事。解决办法是索引构建时统一转小写但显示时保留原大小写。坑三拿不准的词就空着。这个习惯很要命。空着的词永远想不起来补最后变成永久的窟窿。我的做法是拿不准的先填一个待定然后在pitfall字段写一句待核实每周复盘的时候专门清这类记录。坑四只收词不收例句。没有例句的词隔两周就忘了它怎么用。哪怕例句是从原文里抄的一小段也比没有强。注意词表的价值不在于条数多而在于每一条都能直接拿去用。一条记录如果缺失搭配或易混提示它实际上只有半条的价值。7. 怎么把词表用进日常而不是背完就忘词表最大的浪费是建完就供起来。我见过太多人花了两个通宵做出一份漂亮的表然后一周之后再也没打开。要让这东西真正起作用得把它嵌进日常动作里而不是当成一个需要额外花时间的任务。7.1 三个不需要额外时间的复习场景场景一是读文档的时候顺手查。把词表做成一个可以快速检索的形式最简单的就是 CSV 加一个文本编辑器的全文搜索好一点的做法是写个小命令行工具。关键是查词这个动作要足够快超过五秒你就会放弃直接靠猜。场景二是翻译完之后回头核对。每次动手翻一段技术文档翻完花五分钟把这次用到的术语过一遍看看和表里记的是否一致。这五分钟的收益比专门背半小时高得多因为它是带着语境记的。场景三是写英文时反向确认。这个方向最容易被忽略但实际上需求很大。你写英文摘要想表达该方案在大规模场景下具有较好的可扩展性卡在可扩展性的英文上查一下中文索引就能拿到scalability还能顺带看到at scale这个搭配。这一下省的时间比自己想半天多得多。7.2 一个能长期维持的维护习惯我的习惯是每周固定花二十分钟做三件事。第一把这一周新遇到的词补进去通常十到二十条。第二跑一遍一致性校验把冲突清掉。第三随机抽十条做一次自测看看中文能不能立刻说出英文英文能不能立刻说出中文。抽到答不上来的说明这条记录的信息不够得回去补搭配或补例句。这套习惯跑下来一年能积累四五百条高质量记录。数量不算多但这四五百条都是你自己真实用过、验证过的比网上随便下载的五千条管用得多。而且因为这个过程里你反复在判断这个译名对不对你对术语的敏感度本身也在涨——这个能力比词表本身值钱。最后分享一个我自己一直在用的小技巧碰到一个拿不准的译名别急着定先在搜索引擎里把英文原词 中文候选译名两个词一起搜看看有没有专业文献这么用。有文献支撑的译名哪怕你觉得它翻得不好也跟着用一条文献都搜不到的多半是你自己想出来的慎用。技术翻译这件事准确性和共识度往往比文采重要得多。