English
Much of what is known in computer science lives in technical literature that most practitioners never learn to read. Research papers contain the algorithms, systems, and results that define the field’s frontier and much of its established core. Specifications and standards define how the protocols, languages, and formats that everything depends on actually behave. Documentation describes how the tools and libraries that practitioners use every day are meant to be used. Each of these is a distinct genre with its own conventions, its own difficulties, and its own techniques for reading efficiently — and reading them well is a skill separate from reading code, separate from general reading, and almost never taught. The practitioner who can read the literature has access to the field’s accumulated knowledge directly; the practitioner who cannot is limited to what has been filtered down into tutorials, blog posts, and secondhand summaries, always a step removed and often distorted.
The reason this matters is that the secondhand sources are insufficient and unreliable for serious work. A blog post about a research result conveys someone’s interpretation of it, which may be wrong, incomplete, or oversimplified. A tutorial about a protocol covers the common cases and omits the corners where real systems break. The authoritative source — the paper, the specification, the reference documentation — is where the precise truth lives, and the practitioner who needs precise truth (to implement a protocol correctly, to understand exactly what an algorithm guarantees, to use a library at the edges of its documented behavior) must go to the source. The ability to read the source is what makes a practitioner self-sufficient rather than dependent on others having already explained things.
Reading technical literature is also how a practitioner stays current and goes deep. Fields within computer science move quickly — the literature is where new developments appear first, often years before they are distilled into accessible forms. And depth in any subject eventually requires the primary sources: the foundational papers, the detailed specifications, the original arguments, which contain the precision and the reasoning that derivative sources strip away. This section addresses the skill of reading the three main genres — research papers, specifications, and documentation — and the broader skill of navigating a body of literature to learn a field and stay current in it.
Prerequisites: The mathematical maturity from the foundational chapters (§2.2–§2.6) for reading papers with formal content. Reading code (§8.3) as a companion skill — much technical literature accompanies or describes code. Domain knowledge in the relevant subject, which makes its literature legible.
The Shape of the Skill: Reading for Structure, Not Linearly
Reading technical literature efficiently rests on a recognition that novices lack: these documents are not meant to be read linearly from beginning to end, and reading them that way is slow, exhausting, and often defeats comprehension. Each genre has a structure, and reading with the structure — extracting what you need in the order that builds understanding most efficiently — is the core of the skill.
The novice reads a research paper the way they would read a textbook chapter: start at the abstract, read every word in order, try to understand each sentence before moving to the next, and grind to a halt somewhere in the technical sections, exhausted and confused. This fails because a paper is not written to be understood on a single linear pass — it is written to be precise and complete, which makes it dense, and its parts depend on each other in ways that a linear reading cannot resolve (the experimental section makes sense only after the method, which makes sense only after the problem, but the problem’s significance is clearest after seeing the results). The experienced reader reads a paper in multiple passes, each with a purpose, extracting progressively more and deciding after each pass whether the next is worthwhile.
The structure of the skill is therefore a set of genre-specific reading strategies, each exploiting the structure of its genre. For research papers, the multiple-pass approach: a first pass for the gist (is this paper relevant, what does it claim?), a second pass for the content (what did they do, what did they find?), and a third pass, only for the papers that warrant it, for full understanding (could I reconstruct this, do I believe the claims, what are the weaknesses?). For specifications, the reference approach: specifications are not read through but consulted, navigated to the relevant section, read precisely because precision is their purpose, and cross-referenced because their parts interconnect. For documentation, the layered approach: the overview to understand the shape, the tutorial to get started, the reference for precise detail, the source when the documentation is insufficient. Each genre rewards a different strategy, and knowing the strategy is most of the skill.
There is little history to recount here — the skill is about reading the literature, not about the literature’s evolution — but one change in the landscape is worth noting because it bears on the present. The literature has become vastly more accessible: research papers that once required a university library subscription are now mostly available freely (arXiv, open-access journals, authors’ websites); specifications are published openly (the RFCs, the W3C and ECMA standards, the language specifications); documentation is online and searchable. The barrier is no longer access; it is the skill of reading what is freely available. And the most recent development, AI assistance, has changed the activity in a specific way addressed below: a language model can summarize a paper, explain a dense passage, and answer questions about a specification, which is genuinely useful and carries the now-familiar risk that the summary may be wrong in ways the reader cannot detect without going to the source.
Reading Papers, Specifications, and Documentation
Reading Research Papers
The research paper is the genre that most rewards a deliberate reading strategy, because it is the densest and the most resistant to linear reading. The standard approach, articulated most cleanly in S. Keshav’s “How to Read a Paper,” is the three-pass method, and it is worth following until it becomes second nature.
The first pass is a quick scan, five to ten minutes, to get the bird’s-eye view: read the title, abstract, and introduction; read the section headings; read the conclusion; glance at the references. The goal is to answer a few questions: what category of paper is this, what is it about, what does it claim to contribute, and is it relevant to what I need? Many papers are dispatched at the first pass — they are not relevant, or their contribution is clear enough from the abstract and introduction that no further reading is needed. The first pass also lets you decide whether the paper warrants a second pass, which is the main point: most of the value of the first pass is in deciding what not to read further.
The second pass, up to an hour, reads the paper with attention but not full rigor: read the whole thing, look at the figures and tables (which often convey the results most directly), note the parts you do not understand and the references you might need, but do not get stuck on the detailed proofs or derivations. After the second pass, you should understand what the paper did, what it found, and how it fits with what you know — enough to summarize it to someone else and to decide whether it matters for your work. For most papers that pass the first-pass relevance filter, the second pass is sufficient: you understand the contribution and can use it without reconstructing every detail.
The third pass, several hours, is for the papers that genuinely matter — the ones you need to understand deeply, implement, build on, or critically evaluate. The third pass is a virtual re-implementation: you attempt to reconstruct the work, following the reasoning in detail, checking the derivations, questioning the assumptions, identifying the weaknesses and the unstated limitations. After the third pass you understand the paper as the authors did, can reconstruct it from memory, and can identify its strengths and weaknesses with confidence. This is expensive and reserved for the papers that warrant the investment — the foundational papers of a field you are entering, the papers you are building your work on, the papers you must evaluate rigorously.
Critical reading is the dimension that distinguishes a sophisticated reader from a credulous one. A paper is an argument, and arguments can be wrong, overstated, or misleading even when they pass peer review. The critical reader asks: are the claims supported by the evidence? Are the experiments designed to test the claims fairly, or are they set up to favor the proposed method? What are the baselines, and are they strong? What is not measured that should be? What are the limitations the authors do not mention? The fields that have experienced replication crises (some areas of machine learning, where reported results often do not reproduce) make this scrutiny essential: a result reported in a paper is a claim, and the sophisticated reader evaluates the claim rather than accepting it. The skill of critical reading is built by reading many papers, by reading the critiques of papers, and by attempting to reproduce results and discovering how often they do not hold up.
Reading Specifications and Standards
Specifications — the RFCs that define internet protocols, the language specifications that define how programming languages behave, the W3C and ECMA standards that define web technologies, the IEEE standards like 754 for floating point — are a different genre with a different purpose and a different reading strategy. Their purpose is precision: they define exactly how something behaves, including the corner cases, so that independent implementations interoperate. This makes them dense, exhaustive, and not meant to be read through but to be consulted.
Reading a specification is a reference activity. You go to it with a specific question — how exactly does this protocol handle this case? what does the standard require here? what is the precise behavior at this boundary? — and you navigate to the relevant section and read it precisely. Precision is the point: the specification means exactly what it says, including the difference between “MUST,” “SHOULD,” and “MAY” (which in RFCs have precise defined meanings, per RFC 2119), and the careful reader attends to exactly these distinctions because they are where correct implementations differ from incorrect ones. Specifications are also heavily cross-referenced — a section depends on definitions and requirements stated elsewhere — and reading one often means following the references to assemble the complete picture.
The value of being able to read specifications is self-sufficiency at the level of precise truth. When implementations disagree, when documentation is ambiguous, when a system behaves unexpectedly at a boundary, the specification is the authority that resolves the question. The practitioner who can read the specification can determine what the correct behavior is and which implementation is wrong; the practitioner who cannot is reduced to guessing or to trusting whichever secondhand source they can find. For anyone implementing a protocol, a format, or a language feature, the specification is the source, and reading it accurately is the difference between a correct implementation and one that works in the common cases and fails at the edges.
Reading Documentation
Documentation — the reference material for languages, libraries, frameworks, and tools — is the genre practitioners read most often, and reading it efficiently is a daily skill. Documentation comes in layers, and using the right layer for the current need is the core of the skill. The overview or conceptual documentation explains the shape of a system and the model behind it; read this to understand how a tool thinks before using it. The tutorial walks through getting started; use this to begin. The reference documents every function, option, and behavior precisely; consult this for the specific detail you need. The examples show idiomatic use; read these to learn the patterns.
The most common documentation-reading mistake is going to the wrong layer: reading the reference (precise but contextless) when you need the conceptual overview (to understand the model), or searching for a tutorial when you need the reference (the precise behavior of a specific function). Matching the layer to the need — overview to understand, tutorial to start, reference for detail — is what makes documentation reading efficient.
When documentation is insufficient — incomplete, ambiguous, out of date, or absent — the source code is the ultimate documentation, and the ability to read it (§8.3) is what makes a practitioner independent of documentation quality. For open-source tools, the source resolves every question that the documentation leaves open: how the function actually behaves, what the edge cases are, whether the documented behavior matches the implementation. The practitioner who can drop to the source when the documentation runs out is not blocked by documentation gaps that stop others.
AI-Assisted Reading of Literature
Language models have become useful aids for reading technical literature: they can summarize a paper, explain a dense passage or unfamiliar notation, answer questions about a specification, and help locate the relevant part of a long document. For the orientation phase — deciding whether a paper is relevant, getting the gist before a careful read, understanding a confusing passage — this genuinely accelerates the work, much as it does for reading code (§8.3).
The risks mirror those of AI-assisted code reading. An AI summary of a paper can be wrong — misstating the contribution, missing a crucial limitation, oversimplifying a nuanced result — and it is wrong with the same fluent confidence whether or not it is correct. An AI’s explanation of a specification can misstate the precise behavior that is the specification’s entire reason for existing. The reader who relies on the AI’s summary in place of reading the source gets a secondhand interpretation with an additional layer of potential distortion, and loses exactly the precision and the critical engagement that reading the literature directly is supposed to provide. The danger is acute for the third-pass reading — the deep, critical understanding of a paper that matters — where the AI’s summary is no substitute for the reconstruction and scrutiny that deep understanding requires.
The productive use treats AI as an orientation and explanation aid whose output is verified against the source. Use it to triage (is this paper relevant?), to get oriented (what is this about?), and to explain confusing passages (what does this notation mean?), then read the source for anything that matters, applying the critical scrutiny that is the point of reading the literature. For precise truth — what the specification requires, what the paper actually proved, what the result’s limitations are — go to the source. AI accelerates the path to the source and helps with the reading; it does not replace the reading where precision and critical judgment are required.
What Changes With Mastery
The ability to read technical literature changes a practitioner’s relationship to the field’s knowledge.
The first change is self-sufficiency. The practitioner who can read papers, specifications, and documentation goes to the authoritative source when they need precise truth, rather than depending on secondhand explanations that may be wrong or absent. They can implement a protocol from its specification, understand an algorithm from its paper, and use a library from its reference and source. This independence is liberating: they are not blocked when the tutorial does not cover their case, not misled when the blog post is wrong, not stuck when no one has explained the thing they need.
The second change is the ability to stay current and go deep. Fields move quickly, and the literature is where developments appear first; the practitioner who reads it can follow a field at its frontier rather than waiting for developments to be distilled into accessible forms years later. And depth in any subject eventually requires the primary sources, which the literature-reader can access directly. The combination — currency at the frontier and depth in the foundations — is available only to those who read the literature.
The third change is calibrated judgment about claims. The critical reader evaluates the claims in the literature rather than accepting them, which is essential in a field where results are sometimes overstated, experiments sometimes rigged to favor the proposed method, and reported results sometimes fail to reproduce. The practitioner who reads critically can tell a strong result from a weak one, a sound argument from a flawed one, a robust finding from a fragile one — judgment that protects them from building on results that do not hold.
The fourth change is access to the conversation. The literature is a conversation among researchers and practitioners, in which papers cite and build on and critique each other, specifications evolve through revision, and the field’s understanding develops over time. The practitioner who can read the literature can follow this conversation, understand how ideas developed and why, and eventually contribute to it. This is the difference between consuming the field’s outputs and participating in its development.
Resources
Guides, Specifications, and Literature
S. Keshav’s “How to Read a Paper” (free, a short paper widely available online) is the essential guide to the three-pass method for reading research papers. It is itself a few pages, readable in the time it describes for a first pass, and it is the single most useful thing to read before attempting to read research papers seriously. Every practitioner who needs to read papers should read it first.
Michael Mitzenmacher’s “How to Read a Research Paper” and various university guides (many CS departments publish their own) complement Keshav with discipline-specific advice. For the critical-reading dimension, the guides to evaluating empirical claims — particularly in the machine learning reproducibility literature (the papers documenting how often results fail to reproduce, such as those discussed in §5.4 and §7.2) — teach the skeptical reading that the literature requires.
For specifications specifically, RFC 2119 (“Key words for use in RFCs to Indicate Requirement Levels,” free) defines the precise meanings of MUST, SHOULD, and MAY that are essential to reading any RFC accurately, and reading it is a prerequisite to reading internet specifications correctly.
| Resource | Role | Type |
|---|---|---|
| Keshav, “How to Read a Paper” (free) | The three-pass method; essential | Entry |
| Mitzenmacher, “How to Read a Research Paper” (free) | Complementary paper-reading guidance | Entry |
| RFC 2119 (free) | Reading specification requirement levels | Reference |
| ML reproducibility literature (§5.4, §7.2) | Critical reading of empirical claims | Depth |
Practice, Venues, and Current Sources
The skill is built by reading, deliberately and with increasing ambition. The most effective practice for reading research papers is a paper reading group: a regular meeting where a group reads the same paper and discusses it. The discussion surfaces different readings, exposes misunderstandings, and forces the articulation of understanding that deepens it, and the social commitment ensures the reading actually happens. Many research groups, companies, and online communities run paper reading groups; joining or starting one is the most reliable way to build the habit and the skill.
Knowing where the literature lives is part of the skill. arXiv (arxiv.org, free) is where most CS research appears first, often before formal publication; the relevant subject categories (cs.LG for machine learning, cs.DS for data structures and algorithms, and so on) are where a field’s frontier appears. The major conferences (not journals — CS is conference-driven) are where the field’s important work is published: their proceedings are the record of the field, and knowing the top venues in a subfield (NeurIPS, ICML, ICLR for ML; SOSP, OSDI for systems; POPL, PLDI for languages; SIGCOMM for networking; and so on) is how a practitioner knows where to find the significant work. Many conferences make proceedings freely available.
For specifications: the RFC index (rfc-editor.org, free) for internet protocols, the W3C and WHATWG specifications for web technologies, the ECMA standards for JavaScript and other languages, and the language-specific specifications (the documents that formally define each language). Reading the specification of a protocol or language you use — even a portion of it — is a valuable exercise in specification reading and usually reveals behavior you did not know.
| 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
Semantic Scholar and Google Scholar (both free) are the tools for navigating the literature: finding papers, following citation graphs (what a paper cites, and what cites it — which is how you trace the development of an idea and find the most influential work), and discovering related work. The citation graph is the structure of the literature, and following it backward (to foundations) and forward (to developments) is how a reader maps a field. Connected Papers (free) visualizes the citation neighborhood of a paper, which is useful for orienting in an unfamiliar area.
DBLP (free) is the comprehensive bibliography of computer science, useful for finding an author’s complete work, a conference’s complete proceedings, and the precise citation for any CS paper. Zotero (free) manages a personal library of papers — storing, organizing, annotating, and citing them — which is essential infrastructure for anyone reading the literature seriously, because the papers accumulate and become unmanageable without a system.
| Resource | Platform | Type |
|---|---|---|
| Semantic Scholar / Google Scholar (free) | semanticscholar.org / scholar.google.com | Practice |
| Connected Papers (free) | connectedpapers.com | Practice |
| Papers With Code 2 (free) | paperswithcode2.com | Reference |
| DBLP (free) | dblp.org | Reference |
| Zotero (free) | zotero.org | Practice |
Traps
| Trap | Why it misleads | Better response |
|---|---|---|
| Reading papers linearly | Reading a research paper word by word from the abstract through the conclusion, trying to understand each sentence before moving on, is slow, exhausting, and usually defeats comprehension — the paper’s parts depend on each other in ways a single linear pass cannot resolve, and most papers do not warrant that depth of reading anyway. | Use the three-pass method: a first pass for relevance and gist, a second for the content, and a third — only for the papers that warrant it — for deep understanding. Decide after each pass whether the next is worthwhile. Most papers are dispatched in one or two passes; reserve the expensive deep reading for the few that matter. |
| Accepting published results uncritically | A result in a peer-reviewed paper is a claim, not a certified fact. Results are sometimes overstated, experiments sometimes designed to favor the proposed method, baselines sometimes weak, and reported results sometimes fail to reproduce — the replication problems in parts of machine learning make this concrete. The reader who accepts published claims uncritically builds on findings that may not hold. | Read critically: are the claims supported by the evidence? Are the experiments fair, the baselines strong, the limitations acknowledged? Evaluate the argument rather than accepting the conclusion. Read critiques of influential papers, and where it matters, attempt to reproduce results — the experience of how often they do not reproduce calibrates the appropriate skepticism. |
| Relying on secondhand sources for precise truth | Blog posts, tutorials, and summaries convey someone’s interpretation, which may be wrong, incomplete, or oversimplified, and they omit the corners where real systems break. For anything requiring precise truth — implementing a protocol, understanding exactly what an algorithm guarantees, using a library at the edges — the secondhand source is insufficient and often misleading. | Go to the authoritative source for precise truth: the specification for protocol behavior, the paper for what a result actually proved, the reference and source for how a library actually behaves. Use secondhand sources for orientation and accessibility, but verify against the source for anything that must be correct. |
| Reading specifications like prose | Specifications are dense, exhaustive, and cross-referenced, written for precision rather than readability. Attempting to read one through from start to finish is exhausting and unnecessary; it is a reference document, not a narrative. | Read specifications as reference: navigate to the section relevant to your question, read it precisely (attending to the exact meaning of MUST/SHOULD/MAY), and follow the cross-references to assemble the complete picture. The precision is the point; read for exactly what the specification requires. |
| Trusting AI summaries of literature in place of the source | AI summaries of papers and specifications are fluent and confident whether or not they are accurate, and they can misstate a contribution, miss a crucial limitation, or misrepresent the precise behavior a specification defines. Relying on the summary in place of the source adds a layer of potential distortion and loses the precision and critical engagement that reading the literature provides. | Use AI to triage, orient, and explain confusing passages, then read the source for anything that matters — applying the critical scrutiny that is the point of reading the literature. For precise truth (what the specification requires, what the paper proved, what the limitations are), go to the source. AI accelerates the path to the source; it does not replace reading it where precision and judgment are required. |
中文
计算机科学中的许多知识，存在于大多数实践者从未学会阅读的技术文献中。研究论文包含定义这个领域前沿、也构成许多既有核心内容的算法、系统和结果。规范和标准定义了协议、语言和格式到底如何运行，而一切都依赖这些东西。文档描述了实践者每天使用的工具和库应当如何使用。它们各自都是不同文类，有自己的惯例、困难和高效阅读技术；而良好阅读它们，是一种不同于阅读代码、不同于一般阅读、并且几乎从未被教授的能力。能够阅读文献的实践者，可以直接接触这个领域积累下来的知识；不能阅读文献的实践者，则被限制在教程、博客文章和二手总结中过滤后的内容里，总是隔了一层，并且常常已经被扭曲。
这件事之所以重要，是因为对于严肃工作来说，二手来源既不充分，也不可靠。一篇关于研究结果的博客文章，传达的是某个人对它的解释，而这种解释可能错误、不完整，或过度简化。一个关于协议的教程会覆盖常见情况，却省略真实系统容易出问题的边界情况。权威来源——论文、规范、参考文档——才是精确真相所在之处；而需要精确真相的实践者，例如要正确实现一个协议、准确理解某个算法到底保证什么、在库文档边缘行为处使用一个库，就必须回到源头。阅读源头的能力，使实践者能够自给自足，而不是依赖别人已经解释过某个东西。
阅读技术文献，也是实践者保持前沿和深入理解的方式。计算机科学内部的各个领域变化很快——新发展首先出现在文献中，常常要过很多年才会被提炼成更易接近的形式。而任何主题的深度理解，最终都需要回到一手来源：奠基性论文、详细规范、原始论证；这些内容包含衍生来源会剥离掉的精确性和推理。本节讨论阅读三种主要文类的能力——研究论文、规范和文档——以及更广泛地在一组文献中导航，以学习一个领域并保持更新的能力。
前置知识：基础章节（§2.2–§2.6）提供的数学成熟度，用于阅读带有形式内容的论文。阅读代码（§8.3）是相伴能力——许多技术文献伴随或描述代码。相关主题的领域知识，则使其文献变得可读。
这项能力的形状：按结构阅读，而不是线性阅读
高效阅读技术文献，建立在一个新手通常缺乏的认识上：这些文档并不适合从头到尾线性阅读；那样读既慢又累，而且常常会破坏理解。每一种文类都有自己的结构；顺着结构阅读——按照最有效建立理解的顺序提取所需内容——才是这项能力的核心。
新手读研究论文，往往像读教材章节一样：从摘要开始，按顺序读每一个词，试图在进入下一句之前理解当前每一句，然后在技术部分某处耗尽力气，困惑地停下来。这种方法会失败，因为论文并不是为了让人在一次线性阅读中理解而写的——它是为了精确和完整而写的，因此密度很高；而且各部分之间的依赖关系，无法通过一次线性阅读解决。实验部分只有在理解方法之后才有意义，方法只有在理解问题之后才有意义，但问题的重要性又常常要在看到结果之后才最清楚。有经验的读者会分多遍读论文，每一遍都有目的，逐步提取更多内容，并在每一遍之后决定下一遍是否值得继续。
因此，这项能力的结构是一组针对不同文类的阅读策略，每一种都利用该文类自身的结构。对于研究论文，是多遍阅读法：第一遍把握大意——这篇论文是否相关，它主张什么；第二遍理解内容——他们做了什么，发现了什么；第三遍只用于真正值得投入的论文，以获得完整理解——我能否重建这个工作？我是否相信它的主张？它的弱点在哪里？对于规范，是参考式阅读：规范不是通读的，而是查阅的；导航到相关章节，精确阅读，因为精确正是规范的目的；还要跟随交叉引用，因为不同部分彼此连接。对于文档，是分层阅读法：概览用于理解整体形状，教程用于开始上手，参考文档用于获得精确细节，在文档不足时回到源码。每种文类奖励不同策略；知道策略，就已经掌握了这项能力的大半。
这里没有太多历史可讲——这项能力关乎阅读文献，而不是文献本身的演化——但有一个格局变化值得指出，因为它关系到当下。文献已经变得极其容易获取：过去需要大学图书馆订阅才能获得的研究论文，如今大多可以免费获得，例如 arXiv、开放获取期刊、作者个人网站；规范也公开发布，例如 RFC、W3C 和 ECMA 标准、语言规范；文档在线可搜索。障碍不再是访问，而是阅读这些免费可得内容的能力。最新的发展是 AI 辅助，它以一种特定方式改变了这项活动，下文会处理：语言模型可以总结论文，解释密集段落，回答关于规范的问题；这确实有用，但也带来如今熟悉的风险，即总结可能是错的，而读者如果不回到源头，就无法发现错误。
阅读论文、规范和文档
阅读研究论文
研究论文是最奖励有意识阅读策略的文类，因为它最密集，也最抗拒线性阅读。标准方法由 S. Keshav 的 “How to Read a Paper” 最清楚地表述出来，即三遍阅读法；在它变成第二天性之前，值得严格遵循。
第一遍是快速扫描，五到十分钟，用来获得鸟瞰图：阅读标题、摘要和引言；阅读章节标题；阅读结论；快速看一眼参考文献。目标是回答几个问题：这是什么类型的论文？它讲什么？它声称贡献了什么？它是否与我需要的内容相关？许多论文在第一遍就可以处理掉——它们不相关，或者从摘要和引言已经足以看清贡献，不需要继续阅读。第一遍还让你决定这篇论文是否值得第二遍阅读，而这正是它的主要意义：第一遍的大部分价值，在于决定什么不值得继续读。
第二遍最多一小时，要认真阅读整篇论文，但不追求完全严格：读完整篇，查看图表，因为图表常常最直接地传达结果；标出你不理解的部分和可能需要查阅的参考文献，但不要卡在详细证明或推导上。第二遍之后，你应该理解这篇论文做了什么、发现了什么，以及它如何与你已知的内容相连接——足以向别人总结它，也足以判断它是否与你的工作有关。对于大多数通过第一遍相关性筛选的论文，第二遍已经足够：你理解了其贡献，并能使用它，而不需要重建每一个细节。
第三遍需要数小时，用于真正重要的论文——那些你需要深入理解、实现、基于其继续工作，或进行批判性评估的论文。第三遍是一种虚拟重新实现：你试图重建这个工作，详细跟随其推理，检查推导，质疑假设，识别弱点和未说明的限制。第三遍之后，你会像作者一样理解这篇论文，能够凭记忆重建它，并有信心指出其强项和弱项。这种阅读很昂贵，只应保留给值得投入的论文——一个新领域的奠基性论文、你要在其上构建工作的论文、你必须严格评估的论文。
批判性阅读，是区分成熟读者和轻信读者的维度。论文是一种论证，而论证即使通过同行评审，也可能错误、夸大或误导。批判性读者会问：这些主张是否由证据支持？实验设计是否公平地检验了主张，还是被设置得有利于提出的方法？基线是什么，是否足够强？哪些应该测量的东西没有被测量？作者没有提到哪些限制？经历过复现危机的领域，例如机器学习的某些部分，其中报告结果经常无法复现，使这种审查变得必要：论文中报告的结果是一种主张，而成熟读者会评估这个主张，而不是直接接受它。批判性阅读能力来自阅读大量论文，阅读对论文的批评，以及尝试复现结果并发现它们经常经不起检验。
阅读规范和标准
规范——定义互联网协议的 RFC、定义编程语言行为的语言规范、定义 Web 技术的 W3C 和 ECMA 标准、IEEE 754 这类定义浮点数的标准——是另一种文类，目的不同，阅读策略也不同。它们的目的在于精确：准确规定某个东西如何行为，包括边界情况，使独立实现能够互操作。这使它们密集、穷尽，并不适合通读，而是适合查阅。
阅读规范是一种参考活动。你带着一个具体问题进入规范：这个协议到底如何处理这种情况？标准在这里要求什么？这个边界处的精确行为是什么？然后导航到相关章节，精确阅读。精确就是重点：规范的意思就是它所说的内容，包括 “MUST”“SHOULD”“MAY” 之间的区别；在 RFC 中，这些词根据 RFC 2119 有精确定义。细心读者会关注这些区别，因为正确实现与错误实现的差异正是在这些地方产生的。规范也大量交叉引用——某一节依赖其他地方给出的定义和要求——因此阅读规范常常意味着跟随引用，把完整图景组装起来。
能够阅读规范的价值，是在精确真相层面的自给自足。当实现之间不一致，文档含糊，系统在边界处表现异常时，规范就是解决问题的权威。能够阅读规范的实践者，可以判定正确行为是什么，以及哪个实现是错的；不能阅读规范的实践者，只能猜测，或者相信自己找到的某个二手来源。对于任何要实现协议、格式或语言特性的人来说，规范就是源头；准确阅读它，是正确实现与只在常见情况中有效、却在边界处失败的实现之间的区别。
阅读文档
文档——语言、库、框架和工具的参考材料——是实践者最常阅读的文类，而高效阅读文档是一项日常能力。文档通常分层存在；根据当前需要使用正确层级，是这项能力的核心。概览或概念文档解释一个系统的形状及其背后的模型；在使用工具之前，应读它来理解这个工具如何思考。教程会带你上手；用它来开始。参考文档会精确记录每个函数、选项和行为；需要具体细节时查它。示例展示地道用法；读它们来学习模式。
最常见的文档阅读错误，是进入了错误层级：当你需要概念概览来理解模型时，却去读精确但缺乏语境的参考文档；或者当你需要某个具体函数的精确行为时，却去搜索教程。让层级匹配需求——概览用于理解，教程用于开始，参考文档用于细节——才会让文档阅读高效。
当文档不足时——不完整、含糊、过时或缺失——源码就是最终文档，而阅读源码的能力（§8.3）使实践者不再受制于文档质量。对于开源工具来说，源码能够解决文档留下的所有问题：函数实际如何行为，边界情况是什么，文档行为是否与实现一致。当文档走到尽头时，能够降到源码层面的实践者，不会被那些会阻止其他人的文档缺口卡住。
AI 辅助阅读文献
语言模型已经成为阅读技术文献的有用辅助：它们可以总结论文，解释密集段落或陌生记号，回答关于规范的问题，并帮助定位长文档中的相关部分。对于定向阶段——判断论文是否相关、在仔细阅读前把握大意、理解令人困惑的段落——这确实会加速工作，就像它对阅读代码的帮助一样（§8.3）。
风险则与 AI 辅助阅读代码类似。AI 对论文的总结可能是错的——误述贡献、漏掉关键限制、过度简化细致结果——而且无论正确与否，它都会以同样流畅的自信表达出来。AI 对规范的解释，可能会误述精确行为，而精确行为正是规范存在的全部理由。读者如果用 AI 总结替代阅读源头，就得到了一种二手解释，而且还多了一层潜在扭曲；这会丢掉直接阅读文献本应提供的精确性和批判性参与。对于第三遍阅读来说，危险尤其明显——当某篇论文真正重要、需要深入批判性理解时，AI 总结无法替代重建和审查，而这些正是深度理解所要求的。
有效用法，是把 AI 当作定向和解释辅助，并把其输出与源头核对。用它来筛选——这篇论文是否相关？用它来定向——这篇文章大概讲什么？用它来解释困惑段落——这个记号是什么意思？然后，对于任何重要内容，都要阅读源头，并应用技术文献阅读本来要求的批判性审查。对于精确真相——规范到底要求什么，论文实际证明了什么，结果的限制在哪里——要回到源头。AI 会加速你到达源头的路径，并帮助阅读；但在需要精确性和判断力的地方，它不能替代阅读本身。
熟练之后会发生什么变化
阅读技术文献的能力，会改变实践者与这个领域知识之间的关系。
第一种变化，是自给自足。能够阅读论文、规范和文档的实践者，在需要精确真相时会去权威来源，而不是依赖可能错误或不存在的二手解释。他们可以根据规范实现协议，根据论文理解算法，根据参考文档和源码使用库。这种独立性是一种解放：教程没有覆盖自己的情况时，他们不会被卡住；博客文章错误时，他们不会被误导；没有人解释过他们需要的东西时，他们也不会停滞。
第二种变化，是能够保持前沿并深入下去。领域变化很快，文献是新发展最先出现的地方；能够阅读文献的实践者，可以在一个领域的前沿处跟进，而不是等待多年之后它被提炼成易读形式。任何主题的深度理解最终也都需要一手来源，而文献读者可以直接进入这些来源。前沿的及时性与基础的深度，只有能阅读文献的人才能同时获得。
第三种变化，是对主张形成校准过的判断。批判性读者会评估文献中的主张，而不是直接接受它们；在一个结果有时被夸大、实验有时被设计得有利于提出方法、报告结果有时无法复现的领域中，这一点非常必要。能够批判性阅读的实践者，可以区分强结果与弱结果、可靠论证与有缺陷论证、稳健发现与脆弱发现；这种判断会保护他们不把工作建立在经不起检验的结果之上。
第四种变化，是进入对话。文献是研究者和实践者之间的对话；论文彼此引用、继承和批评，规范通过修订演化，领域理解随时间发展。能够阅读文献的实践者，可以跟随这场对话，理解思想如何发展以及为什么这样发展，并最终参与其中。这就是消费一个领域的产出与参与一个领域的发展之间的区别。
资源
指南、规范与文献
S. Keshav 的 “How to Read a Paper”（免费，一篇广泛可在线获取的短论文）是研究论文三遍阅读法的核心指南。它本身只有几页，可以在它所建议的第一遍阅读时间内读完；而在认真尝试阅读研究论文之前，它是最有用的单一阅读材料。任何需要阅读论文的实践者，都应该先读它。
Michael Mitzenmacher 的 “How to Read a Research Paper” 以及各大学指南——许多 CS 院系会发布自己的指南——可以补充 Keshav，并提供特定学科建议。对于批判性阅读维度，评估经验性主张的指南尤其重要，特别是机器学习复现性文献，例如 §5.4 和 §7.2 中讨论的那些记录结果多常无法复现的论文，它们会教授文献所要求的怀疑式阅读。
具体到规范，RFC 2119（“Key words for use in RFCs to Indicate Requirement Levels”，免费）定义了 MUST、SHOULD 和 MAY 的精确含义，而这些含义对于准确阅读任何 RFC 都是必要的。阅读它，是正确阅读互联网规范的前提。
| 资源 | 作用 | 类型 |
|---|---|---|
| Keshav，“How to Read a Paper”（免费） | 三遍阅读法；必读 | 入门 |
| Mitzenmacher，“How to Read a Research Paper”（免费） | 补充性论文阅读指南 | 入门 |
| RFC 2119（免费） | 阅读规范中的要求等级 | 参考 |
| 机器学习复现性文献（§5.4，§7.2） | 对经验性主张的批判性阅读 | 深入 |
实践、发表场域与当前来源
这项能力通过阅读建立，而且要有意识地、逐步提高难度地阅读。阅读研究论文最有效的实践，是论文阅读小组：一组人定期阅读同一篇论文并讨论。讨论会暴露不同理解，揭示误解，并迫使参与者把自己的理解表达出来，从而加深理解；社会承诺也能确保阅读真正发生。许多研究组、公司和在线社群都会组织论文阅读小组；加入或发起一个，是建立习惯和能力最可靠的方法。
知道文献在哪里，也是这项能力的一部分。arXiv（arxiv.org，免费）是大多数 CS 研究最早出现的地方，常常早于正式发表；相关主题分类，例如机器学习的 cs.LG、数据结构与算法的 cs.DS 等，是一个领域前沿出现的地方。主要会议——不是期刊，因为 CS 是会议驱动的——是重要工作的发表场域：会议论文集是这个领域的记录；知道某个子领域的顶级场域，例如机器学习的 NeurIPS、ICML、ICLR，系统的 SOSP、OSDI，编程语言的 POPL、PLDI，网络的 SIGCOMM 等，是实践者知道去哪里寻找重要工作的方式。许多会议会免费公开论文集。
对于规范：互联网协议对应 RFC index（rfc-editor.org，免费），Web 技术对应 W3C 和 WHATWG 规范，JavaScript 和其他语言对应 ECMA 标准，另外还有各语言专门的规范文档，即正式定义每门语言的文档。阅读自己使用的某个协议或语言的规范——即使只读其中一部分——都是一种有价值的规范阅读练习，而且通常会揭示你原本不知道的行为。
| 资源 | 平台 | 类型 |
|---|---|---|
| 论文阅读小组 | 本地 / 在线社群 | 实践 |
| arXiv（免费） | arxiv.org | 参考 |
| 主要会议论文集（通常免费） | 会议网站 / DBLP | 参考 |
| OpenReview（免费） | openreview.net | 参考 |
| ACL Anthology（免费） | aclanthology.org | 参考 |
| RFC index（免费） | rfc-editor.org | 参考 |
| Papers We Love（免费） | paperswelove.org | 辅助 |
实践、工具与项目
Semantic Scholar 和 Google Scholar（二者均免费）是导航文献的工具：寻找论文，跟随引用图，也就是看一篇论文引用了什么，以及谁引用了这篇论文——这正是追踪一个思想的发展、找到最有影响力工作的方式；还可以发现相关工作。引用图是文献的结构；向后跟随它到基础，向前跟随它到后续发展，是读者绘制一个领域地图的方式。Connected Papers（免费）可以可视化一篇论文周围的引用邻域，适合在陌生领域中定向。
DBLP（免费）是计算机科学的综合书目数据库，适合查找某位作者的完整作品、某个会议的完整论文集，以及任何 CS 论文的精确引用。Zotero（免费）用于管理个人论文库——存储、组织、批注和引用论文——对于任何认真阅读文献的人都是必要基础设施，因为论文会不断积累，没有系统就会变得不可管理。
| 资源 | 平台 | 类型 |
|---|---|---|
| Semantic Scholar / Google Scholar（免费） | semanticscholar.org / scholar.google.com | 实践 |
| Connected Papers（免费） | connectedpapers.com | 实践 |
| Papers With Code 2（免费） | paperswithcode2.com | 参考 |
| DBLP（免费） | dblp.org | 参考 |
| Zotero（免费） | zotero.org | 实践 |
陷阱
| 陷阱 | 为什么会误导 | 更好的回应 |
|---|---|---|
| 线性阅读论文 | 从摘要到结论逐字阅读研究论文，并试图在继续之前理解每一句，既慢又累，通常还会破坏理解——论文各部分之间的依赖关系无法由一次线性阅读解决，而且大多数论文也不值得投入这种深度。 | 使用三遍阅读法：第一遍判断相关性和把握大意，第二遍理解内容，第三遍——只用于真正值得的论文——获得深度理解。每一遍之后都判断下一遍是否值得。大多数论文一到两遍就可以处理；把昂贵的深读保留给少数真正重要的论文。 |
| 不加批判地接受已发表结果 | 同行评审论文中的结果是一种主张，不是被认证的事实。结果有时被夸大，实验有时被设计得有利于提出的方法，基线有时很弱，报告结果有时无法复现——机器学习部分领域的复现问题使这一点非常具体。不加批判地接受发表主张的读者，会把工作建立在可能不成立的发现上。 | 批判性阅读：主张是否由证据支持？实验是否公平，基线是否强，限制是否被承认？评估论证，而不是直接接受结论。阅读有影响力论文的批评；在重要时尝试复现结果——亲自经历结果多常不能复现，会校准适当的怀疑程度。 |
| 依赖二手来源获取精确真相 | 博客文章、教程和总结传达的是某个人的解释，可能错误、不完整或过度简化，并且会省略真实系统容易出问题的边界。对于任何需要精确真相的事情——实现协议、理解某个算法到底保证什么、在边界情况下使用库——二手来源都不足够，而且常常会误导。 | 精确真相要回到权威来源：协议行为查规范，结果实际证明了什么查论文，库实际如何行为查参考文档和源码。二手来源可以用于定向和降低进入门槛，但任何必须正确的内容，都要回到源头验证。 |
| 像读散文一样读规范 | 规范密集、穷尽、充满交叉引用；它们是为了精确性而写，不是为了可读性而写。试图从头到尾通读规范，既累也没必要；它是参考文档，不是叙事文本。 | 把规范当作参考来读：导航到与你的问题相关的章节，精确阅读，注意 MUST/SHOULD/MAY 的确切含义，并跟随交叉引用组装完整图景。精确性就是重点；要读出规范到底要求什么。 |
| 用 AI 文献总结替代源头 | AI 对论文和规范的总结无论是否准确，都可能流畅而自信；它可能误述贡献，漏掉关键限制，或歪曲规范定义的精确行为。用总结代替源头，会增加一层潜在扭曲，并失去阅读文献本身提供的精确性和批判性参与。 | 用 AI 进行筛选、定向和解释困惑段落，然后对于任何重要内容都阅读源头，并应用技术文献阅读本来要求的批判性审查。对于精确真相——规范要求什么，论文证明了什么，限制在哪里——回到源头。AI 会加速通往源头的路径，但在需要精确性和判断力时，不能替代阅读源头。 |