外语 · 科技英语：读文档与论文

概念

科技英语（technical English）是技术手册、API 文档、论文、标准（RFC/ISO）、变更日志这类文本的统称。它的特点是：术语密度高、句子长、修饰层层嵌套，但歧义要求极低。

$$\text{科技英语的难点}=\text{长句结构}+\text{术语密度}+\text{隐含的惯例}(\text{词汇本身并不难})$$

一个反直觉的结论：技术文档里的生词大多不是"难词"，而是"专有词"。真正挡住人的是句子结构和隐含约定（谁必须做、谁可选做、默认值是什么）。所以读文档的正确姿势不是查词，是找结构。

原理

一、五种常见文本，五种读法

文本类型	目的	读法
教程 / Getting Started	让你跑通最小示例	正序读，务必动手跑一遍
API / 参考手册	查具体接口	倒着用：先找签名与参数表，再看示例，最后看说明
规范 / 标准（RFC、ISO）	规定"必须怎么做"	逐条读情态动词，把 MUST / SHOULD / MAY 分清
论文	论证一个新方法	三遍读法：摘要+结论 → 图与表 → 方法与细节
变更日志 / Release Notes	判断升级风险	只看 Breaking Changes、Deprecations、Security 三段

API 文档不要当书读。它的正确用法是"先找到函数名 → 看参数表与返回值 → 复制示例 → 回头补说明"，因为说明文字里七成的信息已经在签名和示例里了。

二、科技英语的四个句法特征

特征	例子	后果
名词化	the implementation of the parser 而非 we implemented the parser	主语被藏起来，句子变长
被动语态	the token is consumed by the scanner	施动者常省略
长定语链	a high-throughput, low-latency, fault-tolerant messaging layer	修饰词堆叠，看不出中心词
前置修饰 + 后置从句	the buffer that the writer allocated before the lock was released	嵌套从句使主谓被隔开

应对方法统一：划掉修饰、还原主谓宾。具体三步：

1. 找谓语动词（有时态的动词，不是 -ing、-ed 形式）
2. 谓语左边找主语，右边找宾语——中间的 which/that/who 从句整体划掉
3. 把划掉的从句逐块贴回去

三、规范的隐含约定：情态动词是有法律意义的

技术标准里，情态动词不是语气问题，而是强制等级。RFC 2119 定义了一套通行用法：

词	等级	含义
MUST / SHALL	绝对要求	实现必须如此，否则不合规
MUST NOT / SHALL NOT	绝对禁止	不得如此
SHOULD	推荐	除非有充分理由，否则应当照做
SHOULD NOT	不推荐	特殊情况下可偏离，但要理解后果
MAY / OPTIONAL	可选	实现者自行决定

读协议文档时，只有 MUST 与 MUST NOT 是硬约束。把 SHOULD 当成 MUST 去实现会白做功；把 MUST 当成 SHOULD 会导致互操作失败。

四、术语与缩略语的处理

• 缩略语首次出现必给全称：TLS (Transport Layer Security)
• 区分同形不同义：buffer（缓冲区）vs buffer（缓冲动作）；cache（名词/动词）
• 注意通名与专名：the kernel 指操作系统内核；Kernel 大写可能是某个产品名
• 建立个人术语表：读同一领域的文档时，把反复出现的 20–30 个词记成一张对照表，比逐篇查词省时间

示例

例 1：拆一个典型长句

原句：

The configuration file, which is read once at startup and cached in memory for the lifetime of the process, specifies the list of directories that the loader searches, in the order given, when resolving a module specifier that is not an absolute path.

三步拆：

步骤 1  找谓语：specifies
步骤 2  找主宾：The configuration file specifies the list of directories
步骤 3  贴回修饰：
        ① which is read once at startup and cached in memory …
           → 启动时读一次，之后常驻内存
        ② that the loader searches, in the order given
           → 加载器按给定顺序搜索的（这些目录）
        ③ when resolving a module specifier that is not an absolute path
           → 在解析非绝对路径的模块标识符时

还原：

配置文件（启动时读一次、常驻内存）指定了一组目录；
加载器在解析非绝对路径的模块标识符时，按给定顺序在这组目录中搜索。

例 2：读一段 API 文档，先看签名

parse(source, options?)
  source  : string              —— 必填，待解析的源码文本
  options : ParseOptions        —— 可选
      .tolerant : boolean       —— 默认 false；为 true 时遇错不抛异常
      .filename : string        —— 默认 '<anonymous>'，仅用于报错定位
  returns : ASTNode             —— 失败时抛 SyntaxError（tolerant 为 true 时返回 ErrorNode）

Throws:
  SyntaxError  当源码不符合语法且 tolerant 为 false

读这份文档要提走的四件事，顺序固定：

问题	答案
必填参数是什么	source
默认行为是什么	遇错即抛（tolerant 默认 false）
返回什么、失败怎么表现	返回 AST；失败抛 SyntaxError
有没有坑	filename 只影响报错信息，不影响解析结果

默认值是文档里最容易被忽略、也最容易出错的一栏——"不传参数会怎样"决定了一半以上的集成 bug。

例 3：读报错信息

TypeError: Cannot read properties of undefined (reading 'map')
    at renderList (src/components/List.tsx:42:18)
    at renderWithHooks (node_modules/react-dom/cjs/react-dom.development.js:14985:18)

系统性读法（四步）：

① 错误类型：TypeError        —— 类型问题，不是逻辑问题
② 直接原因：读 undefined 的 'map' —— 某个数组在运行时是 undefined
③ 第一处业务代码：List.tsx:42 —— 从这里开始查，忽略 node_modules 里的帧
④ 推断：props.items 未传或为 undefined —— 需检查调用处或加默认值 []

关键纪律：只看第一处属于自己代码的栈帧，网络库与框架内部的帧 99% 是噪声。

例 4：读 Release Notes，只看三段

## 2.4.0 (2026-09-20)

### Breaking Changes          ← 必读：升级前评估
- Dropped support for Node 16.
- `parse()` no longer accepts a string for `options`.

### Deprecations              ← 必读：为下次升级做准备
- `parseSync()` is deprecated; use `parse()` with `{ sync: true }`.

### Security                  ← 必读：决定是否紧急升级
- Fixed a prototype-pollution issue in the option merger.

### Features / Bug Fixes      ← 扫读
- Added `tolerant` option. Fixed a crash on empty input.

判据：新版一升，先看 Breaking Changes 有没有动到你正在用的 API；没有就可以放心升，有就先留出迁移时间。

要点

要点与常见误区

1. 读文档不是读课文：API 文档用"查"，教程才用"读"。把参考手册从头读到尾是效率最低的方式。
2. MUST ≠ SHOULD：标准文档里只有 MUST/MUST NOT 是硬约束，把 SHOULD 当强制会做无用功。
3. 默认值是第一风险点：集成 bug 多数来自"没传参数时行为与预期不同"。
4. 不要逐词翻译长句：先找谓语动词，再找主谓宾，修饰整体划掉——顺序反过来必然读丢。
5. 被动语态不代表省略了重要信息：the file is read at startup 中"谁读"通常不重要，重要的是"什么时候读"。
6. 术语在同一文档内保持一致：如果文档一会儿说 handler 一会儿说 callback，先查是不是两个不同概念，别急着当同义词。
7. 缩略语先查再猜：CDN、LRU、TTL 这类词一旦猜错，后面整段理解都会偏。
8. 版本号别忽略：网上的答案与文档常常对应不同大版本，看到 API 不存在时先查版本。
9. 栈帧只看自己的代码：node_modules 与框架内部的帧基本是噪声。
10. 论文三遍读法：第一遍摘要+结论+图，第二遍方法与实验，第三遍才逐式推导——别一开始就抠公式。

小结

• 科技英语的难度在长句结构和隐含约定，不在词汇量。
• 五种文本五种读法：教程正序读、参考手册当字典查、标准逐条抠情态动词、论文三遍读、变更日志只看三段。
• 长句切分固定三步：找谓语 → 找主谓宾 → 贴回修饰。
• 情态动词有强制等级：MUST > SHOULD > MAY；只有前两者是硬约束。
• 读 API 的四问：必填参数、默认行为、返回与失败、隐藏的坑。

下一篇：外语 · 语法精讲