贫血王子1. 先说明白：卷2附录A到底是个什么文档，为什么值得折腾
1.1 附录A的真实身份：一本纯用十六进制说话的操作码地图册
先说结论：当我们说"Intel白皮书卷2"的时候，基本可以默认是Intel架构软件开发手册（Intel Architecture Software Developer's Manual）那一套文档里的第二卷，也就是指令集参考手册。而附录A，在这卷书里的身份是操作码映射表（Opcode Map），很多年资浅一点的开发人员可能翻了半年卷2都没正眼看过它一眼——因为太太太枯燥了，整节内容几乎就是一张接一张的大表格，横标、纵标，全是十六进制字节加指令助记符。
如果你上手翻过原文，你会看到类似这样的布局：横轴是操作码的低半字节，纵轴是高半字节，表格中间某个位置填着"ADD"、"MOV"、"PXOR"这类助记符，有的格子右下角还有小标号，表示这条指令有额外的MODRM或者立即数参与编码。这个表重要到什么程度？你做反汇编器、写指令级模拟器、调JIT编译器、做二进制分析，所有需要把字节流还原成指令的活儿，最终都要回到这张表上来。可以说，卷1跟你讲指令的"语义"，卷2跟你讲指令的"长相连"，而附录A就是这张"长相大全"的索引。
我当时决定用AI把附录A翻译成中文，其实不是没事找事。团队里新来的年轻人普遍英文手册啃不动，翻到操作码表这种"格子文档"，更是直接放弃。但实际做二进制审计的时候，你盯着一个 C7 /0 的字节流，心里得快速反应出"这是MOV r/m32, imm32，而且 /0 表示MODRM.reg字段必须是0"，这一步慢下来，效率就没了。所以把操作码表翻译成可快速查阅的中文版本，对组里的新人来说，确实是刚需。
1.2 做好心理准备：这张表不是"字面翻译"能收场的
很多人第一次看到附录A，会觉得这就是个查表文档，词量不大，翻译起来应该很轻松。真上手了才会意识到，它跟正文不一样，正文是一行一行连续叙述，翻译时顺着句子走就行；附录A是结构化到极致的表格，里面塞满了缩写、符号、交叉引用、后缀标记，翻译的难点完全不在"英文看不懂"，而在"怎么把结构化信息无损地搬运到另一种语言里还不破坏格式"。
举几个具体的坑：
- 助记符不能翻。
MOV、ADD、CMPXCHG16B这类指令名，翻译成"移动""加""比较并交换"在知识普及层面没毛病，但在操作码表里，它们是API级别的标识符，程序员查手册、写汇编、看反汇编输出，认的就是这几个大写字符串。你把它翻译成中文，表就没法用了。 - 表格格式不能乱。附录A的一行一列，是有对应关系的。操作码字节、MODRM字段、默认操作数大小、是否加前缀，这些信息分布在不同的列，排版错一位，整个查表逻辑就崩了。
- 后缀标记一堆。比如
/r、/0、/1、cb、cw、cd、cp、ct、ib、iw、id、io、+rb、+rw、+rd、+ro，每一个符号都有精确含义，翻译的时候如果不解释清楚，读者看到C7 /0后面只跟一个"移"字，等于没翻。
所以这篇东西我干脆把整个翻译过程的思路、踩坑、最终落地的方法全部整理出来。我做技术文档翻译的经验大概十年，之前是纯人工翻，最近两年开始走AI辅助翻译的路子，踩过的坑足够写几篇长文了。这篇是专门针对"硬件白皮书、特别是操作码表格"这类高结构化文档的，如果你翻的是软件类API文档，思路可以部分复用，但侧重点会不一样。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. AI翻译硬件文档的强项与硬伤：我的三个亲测结论
2.1 让人惊喜的部分：AI对"标准技术句式"的翻译确实稳
先给AI正个名。我最早试翻译的是附录A前面几页的说明文字，也就是关于"怎么读懂这张操作码表"的那部分。那部分虽然不长，但句式非常密集，而且充满了"the following conventions are used"、"must be aligned on a word boundary"、"reserved"、"undefined"这类标准技术英文。这类句子的好处是：结构固定、词汇固定、上下文依赖弱，AI见过的同类型句子极其多，翻译出来几乎是零失误。
比如最典型的一句："The instruction is only available in 64-bit mode." 我让AI翻，它给的是"该指令仅在64位模式下可用"，没毛病，而且逐字抠都是准的。还有 "This instruction is not supported in real-address mode." 这类否定式表述，AI对"real-address mode"（实地址模式）的翻译也能稳定保持术语一致，不会一会儿译成"实模式"，一会儿译成"真实地址模式"。
我当时做了一个小实验：拿附录A里30句纯说明性文字，人工翻译和AI翻译各做一份，然后让组里资深的同事盲评。结果AI的版本在"句子通顺度"上拿的分数反而不低，甚至在个别句子的简洁度上还胜出人工版。这说明什么？说明AI在翻译"规范化的英文技术文本"时，下限已经非常高，远超五年前的水平。只要内容不涉及复杂的领域逻辑推演，你基本可以放心让它先跑一遍初稿。
2.2 真正翻车的地方：上下文、指代、以及表格里的"格子语义"
问题出在更进阶的内容上。附录A并不全是查表，它还包含大量的"指令编码规则说明"，这些说明里经常出现跨句指代，比如一句话里说"the third byte is the opcode modifer"（第三个字节是操作码修饰符），紧接着下一句说"its high-order 3 bits are used as an opcode extension"。这里的"its"到底指代的是"third byte"还是"opcode modifier"？人一眼就能通过语义判断——修饰符的高3位，指的就是第三个字节的高3位——但AI在有的时候会搞混，直接翻成"它的高阶3位被用作操作码扩展"，看着没错，但丢了"第三个字节"这个关键主词，读起来语义就悬空了。
表格里的"格子语义"是更大的坑。附录A的每一个格子里，填的是一个简短的指令描述，比如"MOV r64 to/from control register"，AI很可能翻成"把r64移动到/从控制寄存器"，结构上对，但读中文的人看到"to/from"就会卡一下，因为中文里没有这种介词堆叠的习惯，正常表述应该是"在r64与控制寄存器之间移动"，更稳的表述是"将控制寄存器加载到r64，或将r64存储到控制寄存器"。这种需要把英文介词的逻辑关系做本地化重组的句子，AI常给你一个半生不熟的直译。
2.3 我给自己定的三条翻译红线
踩过这些坑之后，我给自己定了三条铁律，后来的效果也证明，这三条红线能极大避免AI翻译变成"看起来都懂、用起来全错"的伪翻译：
- 专业术语必须走术语表，不允许AI自由发挥。 所有指令助记符、寄存器名、标志位名称、十六进制进制相关词，全部锁定，不做任何改动。
- 表格结构是第一优先级，宁可放弃个别字眼的精美表达，也要保证行列对应关系不变。 一个格子翻错可以接受，整行错位不可接受。
- 所有AI译文必须经过"反向单测"。 把译文表格里的助记符和操作码重新跟原文比对一遍，宁可慢，不能错。
这三条红线听起来像废话，但实际操作里，是跟AI长期协作必须建立的肌肉记忆。你只要放松一次，让AI"稍微润色一下助记符"，后面整个表格的一致性就失控了。
3. 附录A翻译的完整工作流：从分块到指令模板
3.1 文档预处理：先把PDF或HTML变成AI能处理的结构
拿到Intel官方发的PDF之后，你不能直接把整个PDF丢给AI，那会把准确率吃掉一大截。原因有两个：一是PDF的排版信息混乱，特别是表格区域，在纯文本抽取后经常乱序，AI拿到这种乱序文本，再强也没法正确还原表格语义；二是附录A篇幅本身就长，一次性输入还会触发上下文理解衰减，AI容易在后面部分"失忆"。
我采用的预处理流程是：先用工具把PDF转成HTML，再从HTML里把表格单独抽取成Markdown格式，表格之外的总述、脚注、注意事项单独成段。因为附录A的表格结构非常规则，用脚本按 <table> 标签拆行拆列基本不出错。拆分完之后，把每个表格独立保存成一个文件，这样后面给AI的输入内容就非常干净——一张表、一个翻译任务、一份术语表，信息边界极其清晰。
这一步听着琐碎，但非常重要。我第一次偷懒没拆表，直接把整卷PDF的文本丢给AI，结果AI把操作码表里某个单元格的内容串到了下一行，整个 3A 50 /r 编码的描述错位，要不是最后校验发现，这张表发出去就误人子弟了。
3.2 术语表先行：先把"硬骨头"啃下来再动手
AI翻译最怕的是前后不一致，术语表就是解决这个问题的锚点。我在动手之前，专门花半天时间把附录A里出现的术语全量过了一遍，做成一张中英文对照表。这里不是说"看一遍记住"就行，是真的建立一个计算机可读的术语表，比如CSV格式，翻译的时候让AI跟着这张表走。
术语表的内容大概分成几类：
- 助记符类：一律不翻。
MOV、ADD、SUB、XOR、PXOR、VZEROUPPER，原样保留。 - 寄存器类：
EAX、CR0、XMM0、MM0，原样保留。 - 通用技术词：
byte（字节）、word（字）、doubleword（双字）、quadword（四字）、opcode（操作码）、modifier（修饰符）、immediate（立即数）、displacement（偏移量，这里我用的是"偏移量"而非"位移"，因为中文汇编界习惯用偏移量）。 - 易混词：
r/m8（8位寄存器/内存操作数）、r32（32位寄存器）、m64（64位内存操作数）。这类标记其实不是给人翻译的，是给解码逻辑看的，所以在译文里保留原文标记，但在脚注或括注里加中文说明。
大家不要小看这个"术语表先行"的步骤。实际操作中，AI在没有术语表约束的时候，同一个 undefined，它在第一页译成"未定义"，在第三页译成"未定的"，第五页译成"没有定义"。如果你手工翻，你自己会注意这个；但AI在长文本里很容易发生这种"无意识漂移"。有了术语表，我在指令里加一句"严格使用以下对照表，不得换用同义词"，这个问题基本就消失了。
3.3 翻译执行：给AI写一套"能吃透表格"的翻译指令
有了预处理好的表格和术语表，接下来就是核心环节：怎么让AI把一张Markdown表格翻译到位。我这里直接分享一套我迭代了很多版、最终稳定可用的指令模板。
我的做法是把指令分为两部分：第一部分是"角色与总规则"，第二部分是"具体任务"。
角色与总规则部分大致这样写：
你是一名拥有15年经验的x86汇编技术文档翻译专家，擅长Intel架构手册的中文化工作。以下是一段来自Intel架构软件开发手册卷2附录A（操作码映射表）的Markdown表格内容。请将其翻译成简体中文，并严格遵守以下规则：
- 所有指令助记符、寄存器名、标志位名称、十六进制数一律保留原文，不得翻译、不得转写、不得加注音。
- 表格行数、列数、单元格数量必须与原文完全一致，不得合并、拆分单元格，不得改变表格结构。
- 术语严格使用我提供的对照表，不得使用同义词替换。
- 单元格内如包含"to/from"、"and"、"or"等连接词，按中文习惯调整语序，但不得改变技术含义。
- 单元格内如包含保留字"Reserved"、"Undefined"、"N.E."，分别译为"保留"、"未定义"、"无效果"，并保留原始英文缩写作为括注。
具体任务部分则直接贴入术语表以及待翻译的Markdown表格。这个指令我用下来，发现有两个好处：一是AI的输出结构基本稳定，不会自己跑偏去写一段解说文字；二是出错的模式从"乱翻"变成"可控的局部错误"，比如某几个特定单元格的语序不对，这种错误后期人工校验时很容易抓出来。
这里顺便说一句，指令里的"严格使用术语对照表"这句话，不建议省略。你如果不写，AI大概率还是会按自己的语言习惯来，术语表形同虚设。我试过几次不带术语表的版本，效果就是前面说的"同义词漂移"，搞得后期校对非常痛苦。
4. 附录A里最容易翻车的内容类型：实操盘点
4.1 助记符与伪代码标记：比"不要翻"更难的是"别乱加解释"
第一个翻车高发区，就是助记符和伪代码标记。你以为你说了"助记符不要翻译"，AI就不会动，但它偶尔在个别格子里会犯"手痒"的毛病，比如把 MOV 翻译成"移动"，或者在后面加一个括注"（移动指令）"。这两种做法在我看来都不合适，因为在操作码表这个场景里，助记符就是指令的唯一标识，跟二进制字节一一对应，任何额外解释都会干扰查表过程。
更隐蔽的问题是伪代码标记。附录A里有一些关于指令行为的伪代码描述，比如 IF (condition) THEN ... ELSE ... FI，这种结构里大量使用大写关键字，AI遇到这些内容，有时会忍不住"翻译"成中文的"如果...那么...否则..."。这种翻译，单看语义没错，但伪代码跟自然语言不一样，它是要被工程师当代码阅读的，翻译成中文反而失去了原有的格式语义，而且和其他保留英文的代码片段混在一起，非常违和。
我的处理方式是：在指令里明确加一条"伪代码块内的所有保留关键字、变量名、标号必须原样保留，仅允许翻译注释部分"。这样才能保证翻译出来的文档既是中文的，又保留原始文档的可读性和可检索性。
4.2 标志位（Flags）描述：最容易出现"过度翻译"的重灾区
标志位是附录A里非常高频的一个内容块。每条涉及状态影响的指令，都会对应一段标志位变化的描述，常用的有 OF、SF、ZF、AF、PF、CF，以及 TF、IF、DF、NT、RF、VM、AC、VIF、VIP、ID。这些标志位名称在文档里是以缩写形式出现的，翻译时绝不建议把它们改成中文名，读惯了"CF"的人，你给他写"进位标志"，他反应速度反而慢。
但要注意，AI特别容易在"描述标志位影响"的句子里翻错或翻糊。比如下面这句原文：
"The OF and CF flags are cleared; SF, ZF, AF, and PF are updated based on the result."
如果让AI直接翻，可能得到"OF和CF标志被清除；SF、ZF、AF和PF根据结果更新"。这个译文本身没错，但"根据结果更新"有点含糊，原文里的"updated based on the result"在技术语境里其实说的就是"按结果置位或清零"。更稳妥的译法是"根据结果设置或清零"。我后来在术语表里专门给"cleared"、"set"、"updated"这几个动词做了对照：cleared——清除（清0），set——置1，updated——按结果更新（可能置1也可能清0）。有了这层规范，AI就没法用歧义表达糊弄过去了。
4.3 异常（Exceptions）章节：小心AI把"#UD"这类标记当乱码
附录A并非只有操作码表本身，很多地方还涉及指令的异常行为描述，比如经典的五类异常 #SS、#GP、#PF、#UD、#NM。这些"井号+缩写"格式在AI眼里非常奇怪，它有时会误判为格式错误或者乱码，进而做出两种危险操作：一是把它们原样保留（这其实是对的），二是把它们当成"错误的哈希标签"强行改写成文字，比如把 #GP 改成"通用保护异常"。
从翻译准确性上讲，你可以在第一次出现某个异常标记时写"#GP（通用保护异常）"，之后所有地方都用 "#GP"。但AI有时候会在后面某个异常重复出现时，再次展开成"通用保护异常"，导致术语不一致，表格里同一列字数也会被撑乱。
我的解决方案依然是术语表+指令约束。在翻译之前，我把所有要保留的异常标记全部列入白名单，并在指令中写明"所有以#开头的异常助记符必须原样保留，不得展开，不得删除，不得加注释"。这样处理下来，AI在整个附录A范围内的异常标记一致性可以达到100%，一次翻车都没有。
5. 格式与排版保真：翻译操作码表最大的隐形工作量
5.1 行列表格的转换：Markdown表格并不是万能保险柜
前面说了预处理阶段要把表格转成Markdown，但Markdown表格本身也有坑。附录A的原始表格可不是简单的行列等宽矩阵，它有很多跨行、跨列、单元格合并的地方，比如操作码映射表的第一行（高位半字节）会跨多列，而某些大格子（比如"保留"区）会横跨好几个行列。
Markdown表格对这种合并单元格的支撑是零。你在转换的时候，只能通过重复填充值来模拟合并效果。这个"模拟"过程很容易出错——单元格数量对不齐、值填错了列、视觉上看起来正常但语义错位。我一开始用自动转换工具，转出来的表格Markdown源码看起来整整齐齐，但渲染后一比对，好几个格子错位了。后来我改成半自动方式：自动转换后，再用一个脚本对表格每个单元格做校验，检查行数、列数、以及每个格子里的十六进制字符格式是否符合规范。遇到不符合规范的单元格，说明转换错了，人工修。这样虽然麻烦，但能保证进入AI流程的表格，结构上是准确的。
5.2 交叉引用与页码：附录A里大量出现的"See"是AI的翻译盲区
附录A的表格里经常出现"See Section 3-7"这类交叉引用。AI对于这种引用的处理，经常出现两种极端：一种是把"See"翻译成"参见"，保留后面的章节号；另一种是把整个"See Section 3-7"自行重写成"见第3-7节"，却把原文的页码或章节编号弄丢。
这种交叉引用丢失，对普通文档可能无所谓，但对技术手册是致命的。因为读者看的是中文，实际要翻回原文的对应位置，你给的信息不精确，他等于没有指引。我的做法是在指令里规定："所有交叉引用必须完整保留，格式为'参见 原章节号 （原页码）'，不得丢失任何数字编号。"同时我要求AI在交叉引用后面保留原始英文的"Section x.x"作为括注。这样即使中文读者不熟悉英文编号体系，也能通过原始编号精确定位到原文。
5.3 高亮、脚注和格式符号：翻译完成后的还原清单
如果你的目标输出格式是HTML或者PDF，翻译完成后的格式还原也是一项重要工作。AI翻译输出的Markdown丢失了字体、颜色、下划线等视觉信息，而操作码表的很多信息恰恰是靠视觉符号辅助的。例如"保留"字段通常用灰色底纹表示，某些指令的新增版本会用上标标注，而这些在Markdown里都很难表达。
我在实际操作中的做法是：AI翻译阶段完全不追求视觉格式，只求文字和结构对的；翻译完之后，用一个脚本把原文PDF里的格式信息（如背景色、字体粗细）映射回译文的HTML中。这个映射脚本是我自己写的，核心逻辑很简单，就是按位置匹配——表格结构不变、行数不变，每个单元格的格式属性就能按索引复制过来。这个做法听起来有点笨，但确实有效，最终的HTML版本跟原版PDF的视觉体验几乎一致。
6. 校对与验证：把AI翻译的可靠性补到最后一步
6.1 术语一致性自动检查：用脚本替代肉眼
翻译完之后，最痛苦的是校对。几千个单元格，如果靠肉眼一个个看，估计看两三次就想吐。我强烈建议把术语一致性检查做成自动化脚本。具体做法是：把原文和译文做成对齐表格（原文一个单元格对应译文一个单元格），然后跑一个简单的脚本，检查原文中出现的所有助记符、寄存器名、十六进制值，是否原样出现在了译文的对应单元格中。
这里有一个细节：不能简单做"字符串包含"检查，因为原文单元格里可能有多个助记符，译文单元格也可能因为语序调整，把助记符的位置挪了。所以脚本要做的不是检查位置，而是检查"原文单元格中的每个白名单词，是否都出现在译文单元格中"。这个检查跑了三遍，每次都能抓出几个漏网之鱼，比如某个 XMM1 在翻译过程中被AI手滑删掉了，脚本一眼就定位到。
6.2 抽样人工复核：哪些地方必须看、哪些地方不用看
自动检查做粗筛，人工复核做精筛。我一般把复核流程分为两类：一类是随机抽样，看整体翻译质量；一类是重点检查，锁定那些AI最容易出错的内容类型，比如包含"to/from"的单元格、带异常标记的单元格、以及带操作数宽度后缀（字节/字/双字）的单元格。
我的抽样策略是：每张表格抽取10%的单元格，必须覆盖表格的上、中、下三个区域。因为AI的注意力在很长表格里是有"衰减曲线"的，开头和结尾通常更准，中段偶尔会出现莫名其妙的失手。所以中段的抽样比例我会稍微提高一点，甚至到15%到20%。
重点检查则更细。比如凡是原文里有 /r 标记的单元格，我要确认译文保留了 /r；凡是原文里有 +rb 或 +rd 的，我要确认译文也保留了。因为这些后缀标记长得很像乱码，AI在润色的时候最容易把它们吞掉。
6.3 验证的最后一关：让二进制数据说话
在所有静态检查完成之后，我还会做一次"动态验证"，这才是最有说服力的环节。我构建了一个小的验证集——从操作码表中随机抽取50条指令，用汇编器生成对应的机器码，然后用反汇编器反汇编，再把反汇编结果与翻译后的操作码表条目做比对。如果全部对得上，说明翻译后的文档不光是语言通顺，而且在"可用来对照字节流"的层面，也没有丢失任何信息。
这步验证听起来很"重"，有人可能会觉得匪夷所思：翻译文档而已，至于上汇编器吗？但我的经验是，硬件文档翻译最终目的是给工程师查，不是给读者陶冶情操。如果你翻译出来的文档，不能支撑一个新手对着字节流完成指令识别，那翻译得再美也没用。用汇编器和反汇编器做双向校验，是检验"技术完整性"最直接的方式，任何格式错位、术语丢失、助记符漏译，都会在这个环节暴露出来。
7. 写在最后的个人体会
翻译Intel卷2附录A这事情，断断续续搞了几周。回过头看，最深的感受是：AI翻译确实把技术文档翻译的门槛拉低了很多，以前一个熟练译员翻几十页才敢交付的活儿，现在配合AI可以几个人一两天完成初版，但代价是——AI把"语言转换"这个环节变得非常廉价的同时，把"校验逻辑"的责任全部推给了人。
我现在每做一个类似的AI翻译项目，都默认"AI只是初稿生成器"，真正的核心工作永远在术语表、指令设计、格式保真和验证校对这四件事上。你在这四件事上花的时间，远远超过AI生成的时间。但如果哪次你觉得"AI生成完了直接发出去"也行，那踩坑的概率几乎是百分之百。
最后分享一个实用小技巧：在给AI的指令里，每次都要求它输出"翻译完成后再次检查助记符是否与原文一致"这句回顾。虽然AI的"自我检查"不一定真的有效，但实践下来，加了这步回顾后，助记符丢失的概率会明显降低，可能是因为这会让AI在生成时提高对助记符的注意力权重。如果你也在翻类似的高结构化技术文档，可以试试这个方法，成本很低，效果还挺值得的。