paper-interpretation

paper-interpretation: Read Papers

Reading a paper isn't doing academia, it's hunting for ideas. Break down other people's findings into cognition you can use.

Format Constraints

Org-mode Syntax

Use *bold*for bold (single asterisk), do not use **bold**
Heading levels start from * , no skipping levels

ASCII Art

All diagrams use pure ASCII characters. Allowed:+ - | / \ > < v ^ * = ~ . : # [ ] ( ) _ , ; ! ' " and spaces. Unicode drawing symbols are prohibited.

Template Authority

Output structure is based on references/template.org. Do not refer to the section structure of existing paper files in ~/Documents/notes/ —old files may use expired templates.

Denote File Conventions

Timestamp:date +%Y%m%dT%H%M%S
Human-readable time:date "+%Y-%m-%d %a %H:%M"
Filename:{时间戳}--paper-{简短标题}__paper.org
Output directory:~/Documents/notes/

Org File Header

#+title:      paper-{简短标题}
#+date:       [{YYYY-MM-DD Day HH:MM}]
#+filetags:   :paper:
#+identifier: {YYYYMMDDTHHMMSS}
#+source:     {URL 或来源描述}
#+authors:    {作者列表}
#+venue:      {发表场所/年份}

Report the path after the file is written.

Red Lines (every one must pass)

Spoken-language test — Would you introduce a paper to a friend like this? If not→change it. Academic tone is the default enemy
Zero jargon — First land it in plain words, then mention the jargon term along the way. If you must use the original term to explain it, you haven't understood it yet
Short words first — If you can say it in two characters, don't use four. "This paper proposes a new framework"→"They made a thing"
One thing per sentence — Each sentence advances only one step
Concrete — Nouns you can see, verbs with force. Cut adjectives whenever possible
Give the reason at the start — The first sentence of the problem section should make people want to know the answer
No filler — Delete academic platitudes ("In recent years, with the development of...", "It is worth noting that"). Every sentence does work
Trust the reader — Saying it once is enough. Don't repeat conclusions
Honest — If the paper has a hard flaw, say it has a hard flaw. If you can't understand part of it, say you can't understand it

Writing Principles

Four core principles that determine whether the article is "a live person talking" or "a machine reporting":

One anchor carries the whole text — Find a concrete central metaphor (a picture, a scene, an action) and let all concepts grow around it. It's not listing five concepts side by side, it's stringing them together on one rope. The anchor must appear at the beginning of the "translation" and later sections can keep returning to it
Make reasoning visible — Simulate "the process of a person figuring it out," rather than presenting "the result after figuring it out." Use "Since A is B, could C also be D?" to lead the reader through the reasoning. Make the reader feel the conclusion is one step away from being their own idea
Transformation instead of definition — When explaining the relationship between two concepts, continuously morph A into B; don't say "A and B have an XX relationship." "Morph LSTM→it looks like ResNet" is ten times stronger than "LSTM and ResNet are duals"
The landing point is usability — Give "This means you can ___", not "This makes us rethink ___". After reading, the reader must take away something they can act on, not a sigh worth pondering

Toolbox (optional)

Tools you can use when explaining a paper; none are mandatory:

Analogy — Load-bearing: the key components of the method can all be mapped onto it. Walk through the method along the analogy
ASCII diagrams — show component relationships, data flow, structural comparisons. Draw them after readers have a conceptual scaffold
Napkin sketch — a side-by-side comparison of "how it used to be thought of vs. how it should be thought of now"
Good question — turn the predicament the paper solves into a question that even a layperson is curious about
Progressive examples — build understanding step by step, from simple to complex
Rhetorical question as an entry point — when you hit an implicit assumption, open it up with a question

Execution

1. Get the content

arxiv URL → WebFetch
PDF → Read (note the pages parameter limit)
Local file → Read
Paper title → WebSearch

Make sure you get: title, authors, abstract, core method, results.

2. Positioning: what is it solving?

Find the real predicament—something that can't be done, some phenomenon that can't be explained, some path that can't be taken any further. Explain the full context in one paragraph.

Not "this paper proposes a new XXX framework," but "large models are clearly smart, so why do they start making things up the moment you ask them about specific facts?"

3. Feynman: make it understandable to a layperson

Explain the paper's core idea well enough that a smart person who knows nothing about this field can follow along. The format is free—analogies, diagrams, examples, progressive explanation—choose whatever suits this paper best.

Establish an anchor at the start: find a concrete central metaphor or image and bring it out in the first paragraph of the translation. All later concepts grow around this anchor rather than being listed side by side.

Let the reasoning carry the reader along: don't just give the conclusion. Simulate the process of "figuring it out step by step"—"since X is like this, could Y also be like this?" Make readers feel the conclusion was one step away from being their own idea.

Need to cover:

How it does it (core mechanism/method)
How well it works (pick the two or three most telling results)
The key concepts needed to understand the whole text (if any)

The subheadings of the Feynman translation section should be organized according to the content's needs; they don't have to be fixed.

4. Core concepts: turn terminology into intuition

Pick out the 1 to 3 most critical concepts in the paper (method names, architecture components, mathematical objects, new definitions...), and break them down one by one.

For each concept:

One sentence: what this thing is, what it's used for
Analogy or example: make it instantly clear to someone who has never encountered it. When explaining the relationship between two concepts, prefer "transform A into B" over "A and B have an XX relationship"—transformation is more powerful than definition
Why it matters: without it, where does the paper's chain of logic break

Criteria for choosing concepts: if the reader doesn't understand this, they won't be able to follow the later insights and review. Don't repeat concepts already explained thoroughly in the "translation" section.

5. Insight: the crystallization of thought

The most valuable thing in the whole paper is often just one point—the new crystallization the authors truly found.

Say it in one sentence. This sentence should make readers feel "this idea is something I can take away," not "oh, the paper said such-and-such a thing."

Test criterion: if you pull this sentence out on its own, detached from the paper's context, does it still have force? If it's just restating the paper's conclusion, it's not an insight. An insight is the thing you see for yourself after reading—something the paper may not state outright, but the logic points to it.

If you can't articulate it, reread step three. If the paper really has no spark of thought, just say "this paper is an engineering improvement with no new discovery at the cognitive level." Don't force it.

6. PhD advisor review

Switch identity: a PhD advisor who has supervised graduate students in this direction for twenty years. A student brings you a paper, and you judge whether this thing is worth taking seriously.

In plain language, as if chatting with a student in your office:

Taste in topic selection: Is the problem worth doing? A real gap or a manufactured one?
Methodological maturity: Cleverness or brute force? Has a more natural approach been overlooked?
Experimental sincerity: Is the baseline fair? Is the ablation thorough? Do the numbers hold up under questioning?
Writing craft: Has the author been lazy where things most need to be clear?
Verdict: strong accept / weak accept / borderline / weak reject / strong reject, with a one-sentence reason

Praise what's good, say where the bad falls short.

7. Inspiration: reminders for me

The landing point is "can be used," not "can be thought about." Give "this means you can ___", not "this makes us rethink ___".

Use three perspectives to probe for connections; expand on hits, skip misses, and if nothing hits, say "none":

Transfer: Can some mechanism/perspective from the paper be transplanted to upgrade a component of my system? How exactly would it connect?
Mix and match: Can some component of the paper combine with something I already have to produce something new? What would it produce?
Inversion: Does the paper's approach run counter to my default assumptions? What should I stop doing, and what should I start doing?

8. Pass the red lines

Scan the red lines one by one. Additional checks:

Break the formula—no more than two instances of negative parallelism in the whole text; change three-part structures to two or four parts
Vary the rhythm—alternate long and short sentences
Kill the punchlines—anything that sounds quotable, rewrite
Check for jumps—every logical step must be traceable

List the revisions, confirm, then generate the file.

9. Generate the Org file

Get the timestamp according to the Denote convention, read references/template.org, write ~/Documents/notes/。

Acceptance

The question hooks people: make even those who don't understand want to know the answer
Has an anchor: the translation section has one concrete central metaphor, and later concepts grow around it
Carried by reasoning: the reader can feel the process of "figuring it out step by step," rather than receiving a pre-packaged conclusion
An outsider can follow: a smart person who doesn't know this field can restate the core idea after reading
The PhD advisor sounds like a PhD advisor: has judgment and a sense of proportion, with a verdict in the final sentence
Inspiration is actionable: the landing point of the inspiration section is "you can ___", not "worth thinking about ___"
Zero sense of fragmentation: after reading, it feels like a person telling you "I read a paper and found something interesting"