Reading papers 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*(single asterisk) for bold, forbid**bold** - Headings start from
*and don't skip levels
ASCII Art
All diagrams use plain ASCII characters. Allowed:+ - | / \ > < v ^ * = ~ . : # [ ] ( ) _ , ; ! ' " and spaces. Unicode drawing symbols are forbidden.
Template Authority
The output structure is based on references/template.org. It is forbidden to reference ~/Documents/notes/ 's existing paper file section structure—old files may use outdated templates.
Denote File Specification
- 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 writing the file.
Red Lines (each must pass)
- Spoken-language test — Would you introduce a paper to a friend like this? If not → revise. Academic tone is the default enemy
- Zero jargon — Land it in plain language first, then mention the term along the way. If you must use the original term to explain it, you haven't understood it yet
- Short words first — If it can be said in two words, 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 are visible, verbs have force. Cut adjectives wherever possible
- Give the reason up front — The first sentence of the problem section makes people want to know the answer
- No padding — Delete academic filler ("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 fatal flaw, say it has a fatal 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 living person talking" or "a machine reporting":
- One anchor supports the whole piece — Find a concrete central metaphor (an image, a scene, an action) and let all concepts grow around it. Don't list five concepts side by side; string them on one rope. The anchor must appear at the start 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 was one step away from their own thought
- Transformation instead of definition — When explaining the relationship between two concepts, continuously transform A into B; don't say "A and B are in an XX relationship." "Transform LSTM → it looks like ResNet" is ten times stronger than "LSTM and ResNet are dual"
- Land on usefulness — Give "this means you can ___", not "this makes us rethink ___". After reading, the reader should take away something they can act on, not a sentiment worth pondering
Toolbox (optional)
Tools you can use when explaining a paper; none are mandatory:
- Analogy — Load-bearing, every key component of the method maps onto it. Walk through the method along the analogy
- ASCII diagram — Show component relationships, data flow, and structural comparisons. Draw it 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 difficulty the paper solves into a question that even a layperson would be curious about
- Progressive examples — Build understanding step by step, from simple to complex
- Rhetorical question hook — When you encounter an implicit assumption, open with a question
Execution
1. Get the content
- arxiv URL → WebFetch
- PDF → Read (note the pages argument limit)
- Local file → Read
- Paper title → WebSearch
Make sure you get: title, authors, abstract, core method, results.
If the paper has an overview diagram that carries the paper's core idea (overview / architecture diagram, usually Figure 1), extract it and save it to ~/Documents/notes/images/filename {identifier}--paper-{簡短標題}-overview.png。
Criterion: this diagram lets people grasp what the paper is doing at a glance. Not every paper has one—if it doesn't, skip it; don't force it.
Extraction method:
- arxiv → visit the HTML version (
arxiv.org/html/...)), find the image URL, and download it with WebFetch - PDF → capture the page containing the figure and save it as an image
2. Positioning: What is it solving?
Find that real difficulty—something that can't be done, some phenomenon that can't be explained, some path that can't be taken. Explain the whole backstory clearly in one paragraph.
It's not "This paper proposes a new XXX framework," it's "Large models are clearly very smart, so why do they start making things up as soon as you ask about a specific fact?"
3. Feynman: Make it understandable to a layperson
Explain the paper's core idea well enough that a smart person who doesn't know this field can follow along. The form is free—analogies, diagrams, examples, progressive explanation; choose the approach that best fits this paper.
Establish an anchor at the beginning: find a concrete central metaphor or image and reveal it in the first paragraph of the translation. All later concepts should grow around this anchor, not be listed side by side.
Let the reasoning carry the reader along: don't give the conclusion directly. Simulate the process of "figuring it out step by step"—"Since X is like this, could Y also be like this?" Make the reader feel that the conclusion was just one step away from what they themselves thought of.
Need to cover:
- How it does it (core mechanism/method)
- What the results are like (pick the two or three most illustrative results)
- The key concepts needed to understand the full paper (if any)
The subheadings in the Feynman translation section should be organized according to the content; 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, etc.) and break them down one by one.
For each concept:
- One sentence: what this thing is and what it's used for
- Analogy or example: make it instantly understandable 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 logical chain break
Criterion for choosing concepts: if the reader doesn't understand this, they won't be able to follow the later insights and review. Don't choose concepts that have already been thoroughly explained in the "translation" section.
5. Insight: The crystallized idea
The most valuable part of an entire paper is often just one point—the new crystal the author truly found.
Say it in one sentence. That sentence should make the reader feel, "I can take this idea with me," rather than "Oh, the paper says this kind of thing."
Test: pull this sentence out on its own, away from the paper's context—does it still have force? If it is merely restating the paper's conclusion, it is not insight. Insight is the thing you see for yourself after reading—the paper may not say it outright, but the logic points to it.
If you cannot say it, reread step three. If the paper really has no spark of thought, say plainly, "This paper is an engineering improvement, with no new discovery at the cognitive level." Do not force it.
6. Advisor review
Switch identities: a doctoral advisor who has supervised graduate students in this direction for twenty years. A student comes to you with a paper, and you judge whether this thing is worth taking seriously.
Say it plainly, as if chatting with a student in your office:
- Choice of topic: Is the problem worth doing? A real gap or a manufactured one?
- Maturity of method: Cleverness or brute force? Is a more natural approach being ignored?
- Sincerity of experiments: Are the baselines fair? Is the ablation complete? Do the numbers withstand questioning?
- Writing skill: Has the place that most needs to be made clear been neglected?
- Verdict: strong accept / weak accept / borderline / weak reject / strong reject, with a one-sentence reason
Say good things are good, and say where bad things are bad.
7. Inspiration: reminders for me
The endpoint is "can use," not "can imagine." Give "this means you can ___," not "this makes us rethink ___."
Use three perspectives to probe for connections; if one hits, expand it, if not, skip it, and if none hits, say "none":
- Transfer: Can some mechanism/perspective from the paper be transplanted to upgrade some part of my system? How exactly would it connect?
- Mix and match: Can some component of the paper be combined with what I already have to produce something new? What would it produce?
- Inversion: Is the paper's approach opposite to my default assumptions? What should I stop, and what should I start?
8. Cross the red lines
Scan the red lines one by one. Additional checks:
- Break formulas—no more than two negative parallel constructions in the whole text; change three-part structures to two or four items
- Vary rhythm—alternate long and short sentences
- Kill golden lines—rewrite anything that sounds quotable
- Check jumps—every logical step must be traceable
List the revisions, and after confirmation generate the file.
9. Generate the Org file
Get the timestamp according to the Denote specification, read references/template.org, write to ~/Documents/notes/。
Acceptance
- The question is compelling: make even people who do not understand want to know the answer
- Has an anchor: the translation section has one concrete central metaphor, and later concepts grow around it
- Carries the reasoning: the reader can feel the process of "figuring it out step by step," rather than receiving a packaged conclusion
- Outsiders can follow: a smart person who does not know this field can restate the core idea after reading
- The advisor feels like an advisor: has judgment and restraint, with the verdict in the final sentence
- Inspiration prompts action: The inspiration section's payoff is "you can ___", not "worth pondering ___".
- Zero sense of fragmentation: After reading, it feels like someone is telling you, "I read a paper and found something interesting."