English
Technical reading is a way to answer a question using a document whose purpose and evidence you must understand. A research paper argues for a contribution; a specification defines required or permitted behavior; documentation helps someone understand or use an implementation. Read each according to what it can establish.
Before reading, state the decision you need to make. You might be checking whether an algorithm’s assumptions fit your data, whether a protocol allows a particular response, or how to call an API in a specific version. The question determines which parts deserve close reading and what evidence would be sufficient.
Prerequisites and connections: Background in the subject being read. Programming, mathematical notation, or statistics may be needed depending on the claim; locate the specific gap rather than treating all advanced material as a prerequisite.
The Shape of the Skill: Reading for Structure, Not Linearly
Start by identifying the document’s question, scope, and structure. Then choose a reading depth: orientation, evaluation for a task, implementation, or reproduction of an argument. These goals require different amounts of work. Skimming is useful for selection; it is insufficient when a decision depends on a technical condition you have not inspected.
Read claims together with their support. A theorem applies under stated assumptions; a benchmark reports measurements under particular conditions; an experience report describes observations from a setting. None can simply substitute for the others. A useful note records the claim, its evidence, its limits, and its relevance to your question.
Follow references when they supply a missing definition, a competing result, or the origin of an important assumption. Citation count and venue can help locate work, but neither replaces checking the argument. Likewise, an unfamiliar term is a reason to clarify a dependency in your understanding, not a reason to memorize every term in the document before proceeding.
Reading Papers, Specifications, and Documentation
Reading Research Papers
Keshav’s three-pass method offers a practical progression: first identify the problem and contribution, then examine the main argument and results, then investigate details needed for a deep understanding or reproduction. It is a strategy for allocating attention, not a promise that every paper can be understood in fixed amounts of time. Return to earlier parts when the details change your interpretation.
In the first pass, inspect the title, abstract, introduction, headings, conclusion, and relevant references. In the second, connect the main claims to figures, definitions, and results, marking gaps. In the third, reconstruct the decisive argument or procedure under the stated assumptions and compare it with the paper. A reader may reasonably stop after an earlier pass when the document does not answer the question.
For a theoretical result, write down the assumptions and the precise conclusion. A result about average behavior under one input distribution does not establish a worst-case bound for arbitrary inputs. Check how the proof uses its assumptions, and whether the implementation you want to build satisfies them.
For an empirical result, inspect the task, data, baseline, metric, hardware or environment, and sources of variation. Suppose an experiment reduces the time for a fixed amount of work from 100 ms to 80 ms. That is a 20% reduction in elapsed time. For sequential repeated work with unchanged conditions, the reciprocal rate rises by 25%. “25% faster” without a defined metric obscures this distinction. A better mean latency also need not imply a better tail latency.
Ask whether the comparison gives both methods comparable tuning and resources, and whether the tested workload resembles yours. An ablation that removes one component can help assess its contribution under that experiment, but interactions between components can complicate the interpretation. Repeated runs and uncertainty estimates help distinguish a stable difference from variation.
Code, data, and configuration make a claim easier to investigate, but match their versions to the paper. Reproducing one reported result is useful evidence about that result, not confirmation of every claim or every deployment setting. When reproduction fails, record the difference and investigate missing conditions before assigning a cause.
Reading Specifications and Standards
Identify a specification’s status, version, scope, and relevant updates or errata. An RFC is a publication form; not every RFC is an Internet Standard. A historical document can explain a design without defining the behavior required by the current version.
Distinguish normative requirements from examples and explanatory text. In specifications using the BCP 14 convention defined by RFC 2119 and RFC 8174, uppercase MUST, SHOULD, and MAY carry defined requirement levels. SHOULD allows justified exceptions after their consequences are understood; it does not mean an unimportant suggestion. Lowercase uses do not automatically have those special meanings, and requirements can also be expressed without these keywords.
Read the conditions around a rule. A field may be mandatory only for one message type, or a response may depend on negotiated capabilities. When a language specification distinguishes implementation-defined from undefined behavior, the former calls for a documented implementation choice; the latter imposes no behavioral requirements for that case. Check the definitions in the relevant specification rather than inferring them from ordinary English.
Use a small conformance example to test your interpretation, but keep the authority clear: an implementation may contain a bug or extension. Observed behavior can reveal what one version does without changing what the specification requires.
Reading Documentation
Documentation serves several needs: a tutorial guides a first successful task, a how-to guide addresses a concrete operation, reference material specifies interfaces, and an explanation develops the underlying concepts. Choose the kind that fits the question. A quick-start example may omit failure cases that the reference documents.
Check version and platform before copying an example. For an API, inspect accepted inputs, units, return values, errors, side effects, and resource ownership. Determine whether an operation is synchronous, lazy, or asynchronous and when its errors appear. These details often matter more than the call’s spelling.
Source code can clarify an undocumented implementation detail, provided you inspect the version and configuration actually in use. It can also show an implementation defect. Record whether your conclusion comes from a documented contract, source inspection, or a local experiment, since those support different expectations about future versions.
AI-Assisted Reading of Literature
AI assistance can explain notation, suggest related work, or summarize a section. Ask it to identify where a claim occurs, then read the passage with its conditions. Verify that cited papers exist and support the attributed claim; a real title or author is not enough.
For a proof or experiment that determines your decision, work through the relevant step yourself or reproduce a small case. Use a summary to locate questions, not to manufacture confidence about unread evidence. If a document cannot be inspected, leave the claim unverified rather than presenting a generated quotation as a source.
What Changes With Mastery
You can explain not only what a document says, but what would have to be true for its conclusion to apply to your task. You can stop reading when the bounded question is answered, or identify the precise missing concept that requires more study.
Choose one claim and prepare a short reading note: the claim, supporting passage or result, assumptions, a possible counterexample outside those assumptions, and the decision it informs. Comparing such notes in a reading group reveals disagreements that a general summary can conceal.
Resources
Guides, Specifications, and Literature
Keshav’s How to Read a Paper gives the three-pass method; Mitzenmacher’s guide supplies complementary questions. Read RFC 2119 together with RFC 8174 for requirement language. For empirical work, use the evaluation and testing discussions in §5.2 and §7.2 to ask about data, baselines, and independent checks.
| Resource | Role | Type |
|---|---|---|
| Keshav, “How to Read a Paper” (free) | Three-pass reading strategy | Entry |
| Mitzenmacher, “How to Read a Research Paper” (free) | Complementary paper-reading guidance | Entry |
| RFC 2119 and RFC 8174 (free) | Requirement levels and capitalization | Reference |
| Empirical evaluation and reproducibility (§5.2, §7.2) | Checking data, baselines, and independent evidence | Depth |
Practice, Venues, and Current Sources
A reading group can compare specific interpretations and evidence. arXiv hosts preprints, whose presence there does not imply peer review; conferences and journals both publish important CS work, with practices differing by subfield. Use proceedings, OpenReview, and subject collections to locate papers and their publication context. For protocols, check the RFC’s status and updates as well as its text.
| Resource | Platform | Type |
|---|---|---|
| Paper reading group | Local / online community | Practice |
| arXiv (free) | arxiv.org | Reference |
| Major conference proceedings (often free) | Conference sites / DBLP | Reference |
| OpenReview (free) | openreview.net | Reference |
| ACL Anthology (free) | aclanthology.org | Reference |
| RFC index (free) | rfc-editor.org | Reference |
| Papers We Love (free) | paperswelove.org | Auxiliary |
Practice, Tools, and Projects
Use scholarly search and citation links to locate related work, and DBLP to check bibliographic records. Connected Papers offers a related-paper visualization; a position in such a visualization is not evidence that one paper validates another. Check any paper-to-code index against the authors’ actual artifact and version. Zotero can keep the document, notes, and citation together so that a later claim remains traceable.
| Resource | Platform | Type |
|---|---|---|
| Semantic Scholar / Google Scholar (free) | semanticscholar.org / scholar.google.com | Practice |
| Connected Papers | connectedpapers.com | Practice |
| Paper-associated code and data | Authors’ repositories / artifact records | Reference |
| DBLP (free) | dblp.org | Reference |
| Zotero (free) | zotero.org | Practice |
Traps
| Trap | Why it misleads | Better response |
|---|---|---|
| Reading every document linearly at one depth | The needed evidence depends on the reading goal. | Orient first, then inspect the decisive parts closely. |
| Repeating a result without assumptions | The conclusion may not transfer to another workload or input model. | Record the conditions and exact metric. |
| Treating publication or citations as validation | Visibility does not establish the argument or experiment. | Inspect the claim and its supporting evidence. |
| Confusing implementation with specification | A version can contain bugs, extensions, or undocumented behavior. | Distinguish required behavior from observed behavior. |
| Relying on an unchecked generated summary | References or conditions may be missing or invented. | Verify the cited passage and the decisive reasoning. |
中文
阅读技术文献，是借助文档回答问题，同时理解文档的目的及其证据。研究论文论证一项贡献；规范定义必须或允许的行为；文档帮助读者理解或使用某个实现。应根据各自能够说明什么来阅读。
阅读之前，先说明需要作出什么判断：算法的假设是否适合自己的数据，协议是否允许某种响应，或特定版本中 API 应怎样调用。问题决定哪些部分值得细读，以及什么证据才足够。
前置知识与联系：对阅读主题的基础了解。根据结论，可能需要编程、数学符号或统计知识；应找到具体空缺，不必把所有高级内容都当作先修要求。
这项能力的形状：按结构阅读，而不是线性阅读
先确定文档的问题、范围与结构，再选择阅读深度：了解方向、为任务评估、实际实现，或复现论证。这些目标需要不同投入。略读适合筛选；但如果决定取决于尚未检查的技术条件，略读就不够。
把结论与支持它的证据一起阅读。定理在给定假设下成立；基准测试报告特定条件下的测量；经验报告描述某个场景中的观察。它们不能彼此直接替代。有用的笔记应记录结论、证据、限制，以及与自己问题的关系。
当参考文献补充缺失定义、相反结果或重要假设的来源时，再沿引用阅读。引用量与发表场所能帮助定位工作，却不能代替检查论证。同样，陌生术语提示你需要补上理解中的某项依赖，并不意味着必须先背会全文每个词才能继续。
阅读论文、规范和文档
阅读研究论文
Keshav 的三遍阅读法提供了一种实用顺序：先确定问题与贡献，再检查主要论证和结果，最后研究深入理解或复现所需的细节。它是分配注意力的策略，不保证每篇论文都能在固定时间内读懂。细节改变理解时，应回到前文重新检查。
第一遍查看标题、摘要、引言、小节标题、结论与相关参考文献。第二遍把主要结论与图、定义和结果联系起来，标记理解空缺。第三遍在给定假设下重建决定性的论证或过程，再与论文比较。如果文档不能回答当前问题，读者可以在较早的一遍之后停止。
对于理论结果，写下假设和精确结论。在某种输入分布下关于平均行为的结果，不能证明任意输入上的最坏情况界限。检查证明怎样使用假设，以及准备构建的实现是否满足这些假设。
对于实验结果，检查任务、数据、基线、指标、硬件或环境，以及波动来源。假设实验把完成固定工作量的时间从 100 毫秒降至 80 毫秒，这是耗时减少 20%。如果条件不变、顺序重复执行相同工作，耗时倒数所表示的处理速率则增加 25%。不说明指标就写“快了 25%”，会掩盖这种区别。平均延迟改善，也不一定表示尾部延迟改善。
检查比较是否给双方相近的调优机会和资源，以及测试负载是否接近自己的任务。移除某个组件的消融实验，有助于评估它在该实验中的贡献，但组件之间的相互作用可能使解释更复杂。多次运行和不确定性估计，有助于区分稳定差异与随机波动。
代码、数据和配置使结论更容易检查，但要确认它们的版本与论文对应。复现某个报告结果，是关于该结果的有用证据，不能确认所有结论或所有部署场景。复现失败时，应记录差异并调查缺失条件，再判断原因。
阅读规范和标准
确定规范的状态、版本、范围，以及相关更新和勘误。RFC 是一种文献发布形式，并非每份 RFC 都是互联网标准。历史文档可以解释设计，却未必规定当前版本必须具备的行为。
区分规范性要求、例子与解释文字。在采用 RFC 2119 和 RFC 8174 所定义的 BCP 14 约定的规范中，大写 MUST、SHOULD、MAY 具有规定的要求等级。SHOULD 允许在理解后果的前提下有合理例外，并不表示无关紧要的建议。小写形式不会自动具有这些特殊含义；没有使用关键词的句子也可能表达要求。
阅读规则周围的条件。某个字段可能只在一种消息类型中必填，某种响应也可能取决于协商出的能力。如果语言规范区分实现定义行为与未定义行为，前者要求实现记录自己的选择，后者则不对该情况提出行为要求。应检查相应规范的定义，不能只凭日常英语推断。
可以用小型符合性例子检查理解，但要分清依据：实现可能存在缺陷或扩展。观察能说明某个版本实际怎样运行，却不能改变规范的要求。
阅读文档
文档服务于多种需求：教程引导首次完成任务，操作指南解决具体操作，参考文档说明接口，解释性文档建立概念。根据问题选择类型。快速入门例子可能省略参考文档才会说明的失败情况。
复制例子之前，检查版本与平台。对于 API，应查看允许的输入、单位、返回值、错误、外部影响和资源所有权；还要确定操作是同步、惰性还是异步，以及错误何时出现。这些细节往往比调用形式更重要。
源代码可以澄清未记录的实现细节，前提是检查实际使用的版本与配置；它也可能展示一个实现缺陷。记录结论来自文档约定、源码检查，还是本地实验，因为这些依据对未来版本的预期具有不同支持力度。
AI 辅助阅读文献
AI 可以解释符号、建议相关工作或概括某一节。要求指出结论出现的位置，再连同条件一起阅读原文。确认所引论文存在，而且确实支持对应说法；标题或作者真实还不够。
如果某段证明或实验决定了你的判断，就亲自推导相关步骤，或复现一个小案例。总结可以帮助定位问题，不能让尚未阅读的证据变得可信。无法检查文档时，应保留“未验证”的状态，不能把生成的引文当成来源。
熟练之后会发生什么变化
你不仅能解释文档说了什么，还能说明它的结论适用于自己任务时，需要哪些条件成立。当范围明确的问题已经回答，可以停止阅读；也可以准确指出还缺哪个概念，需要进一步学习。
选取一个结论，写一份简短笔记：结论、支持它的段落或结果、假设、超出假设后可能出现的反例，以及它能帮助作出的决定。在阅读小组中比较这样的笔记，可以发现一般性总结容易掩盖的分歧。
资源
指南、规范与文献
Keshav 的 How to Read a Paper介绍三遍阅读法，Mitzenmacher 的指南提供补充问题。阅读要求用语时，应结合 RFC 2119 与 RFC 8174。对于实验性工作，可以结合 §5.2 与 §7.2 的评估、测试讨论，检查数据、基线与独立验证。
| 资源 | 作用 | 类型 |
|---|---|---|
| Keshav，How to Read a Paper（免费） | 三遍阅读策略 | 入门 |
| Mitzenmacher，“How to Read a Research Paper”（免费） | 补充性论文阅读指南 | 入门 |
| RFC 2119 与 RFC 8174（免费） | 要求等级与大小写规则 | 参考 |
| 实验评估与可复现性（§5.2，§7.2） | 检查数据、基线与独立证据 | 深入 |
实践、发表场域与当前来源
阅读小组可以比较具体解释与证据。arXiv 收录预印本，出现在那里并不表示通过同行评审；会议与期刊都会发表重要的计算机科学工作，不同子领域的惯例有所不同。可以通过论文集、OpenReview 与学科文献库定位论文及发表背景。阅读协议时，除了正文，还应检查 RFC 的状态与更新。
| 资源 | 平台 | 类型 |
|---|---|---|
| 论文阅读小组 | 本地 / 在线社群 | 实践 |
| arXiv（免费） | arxiv.org | 参考 |
| 主要会议论文集（通常免费） | 会议网站 / DBLP | 参考 |
| OpenReview（免费） | openreview.net | 参考 |
| ACL Anthology（免费） | aclanthology.org | 参考 |
| RFC index（免费） | rfc-editor.org | 参考 |
| Papers We Love（免费） | paperswelove.org | 辅助 |
实践、工具与项目
通过学术搜索与引用链接定位相关工作，用 DBLP 核对书目信息。Connected Papers 提供相关论文可视化，但图中的位置不能证明一篇论文验证了另一篇。论文与代码索引中的条目，应与作者实际提供的产物和版本核对。Zotero 可以一起保存文档、笔记和引用，让后续说法仍能追溯来源。
| 资源 | 平台 | 类型 |
|---|---|---|
| Semantic Scholar / Google Scholar（免费） | semanticscholar.org / scholar.google.com | 实践 |
| Connected Papers | connectedpapers.com | 实践 |
| 论文对应的代码与数据 | 作者仓库 / 研究产物记录 | 参考 |
| DBLP（免费） | dblp.org | 参考 |
| Zotero（免费） | zotero.org | 实践 |
陷阱
| 误区 | 为什么会误导 | 更好的做法 |
|---|---|---|
| 用同一种深度从头读到尾 | 所需证据取决于阅读目标。 | 先确定方向，再细读决定性部分。 |
| 忽略假设就复述结果 | 结论未必适用于其他负载或输入模型。 | 记录条件与精确指标。 |
| 把发表或引用量当成验证 | 可见度不能证明论证或实验成立。 | 检查结论与支持证据。 |
| 混淆实现与规范 | 某个版本可能包含缺陷、扩展或未记录行为。 | 区分规定行为与观察行为。 |
| 依赖未检查的生成总结 | 引用或条件可能遗漏，也可能虚构。 | 核查引用段落与决定性推理。 |