ljg-paper

ljg-paper: Reading papers

Reading papers is not doing scholarship, it is hunting for ideas. Break down other people's findings into cognition you can use yourself.

Overall goal (read this first)

Let asmart person who doesn't understand this fieldfinish reading the notes and be able to restate:

What problem the paper is solving (down to a concrete example)
What moves the authors used to solve it (mechanism + reasons for design choices)
What the core finding is (including the most counterintuitive side finding, which is often the most fascinating part of the paper)
What insight you (the reader) can take away

If the output gets a layperson stuck at any point, it is a failure.Concision is sought only in the title; expand the body where it should be expanded—the goal is not to be short, it is to move people from not understanding to understanding.

Format constraints

Org-mode syntax

Use for bold *bold*(single asterisk), forbidden **bold**
Heading levels start from * , do not skip levels

ASCII Art

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

Template authority

The 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 an expired template.

Denote file conventions

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

Org file header

#+title:      {一句精练语句提炼论文核心思想或发现}
#+subtitle:   {论文原始标题，通常英文}
#+date:       [{YYYY-MM-DD Day HH:MM}]
#+filetags:   :paper:
#+identifier: {YYYYMMDDTHHMMSS}
#+source:     {URL 或来源描述}
#+authors:    {作者列表}
#+venue:      {发表场所/年份}

How to write this title sentence

The title is this note'ssoul sentence—a reader can tell at a glance what this paper takes away. It is not the filename, not the method name, but the distilled expression of the core idea or findingconcise expression。

It is not "compress a passage into one sentence," it is "take out the bone with one cut." Pull out the title and stick it on the wall; it itself should be like an aphorism, a title, a line you can remember.

Writing constraints (by priority)

Concise Chinese native tongue — like the titles of Wang Zengqi, Wang Xiaobo, A Cheng, Li Juan: short, clean, with an edge.
- After writing, silently ask: "Would a Chinese person who has never read translated fiction say it this way?" If not → rewrite.
- Complete anti-translationese self-check list:~/.claude/PAI/USER/AI_WRITING_PATTERNS.md(must scan Layer A).
- Kill sentence patterns: passive sentences ("locked inside..."), "is..." sentences, long postposed modifiers ("that...caused by..."), "conduct + noun," "let us...".
Zero Chinese-English mixing — no English terms appear in the title (RL / HR / Agent / Multi-agent / token and the like are all not allowed). Terms go in the body to be expanded; the title only holds the idea. Exceptions: personal names, product names (GPT, Claude).
6-15 characters — short enough to remember, long enough to carry a finding. Over 15 characters basically means it was not refined enough—go back and cut again.
Verbs as the bone, concrete nouns — cut adjectives wherever possible ("major," "fundamental," "astonishing" all deleted). Every character must do work.
Built-in tension, choose one of three postures：
- Counterintuitive — "learning instead becomes shackles"
- Antithesis or juxtaposition — "Teaching others is like teaching yourself"; "Too firm a memory, and no new ideas come"
- Twist or irony — "The more accurately you answer, the less you see"
Don't restate the topic, don't use a method name —
- ✗ "An Exploratory Study on Spatial Transfer in Reinforcement Learning Pretraining" (academic tone)
- ✗ "PreRL: Moving Reinforcement Learning into the Pretraining Space" (method name + method description)

Positive examples for contrast (look at the direction of transformation)

Core idea of the paper	✗ Translationese / colloquial	✓ Concise Chinese
The reward signal locks the model into trajectories it already knows; erase the problem and it unlocks	The reward signal locks the model to death in trajectories it already knows; erase the problem and it unlocks	To learn is to be shackled
Do RL with only wrong samples, and reflection grows on its own	Do RL with only wrong samples, and reflection grows on its own	Reflection grows from error
The model thinks in vector space more cheaply and accurately than generating tokens	The model thinks in vectors, which is cheaper, more accurate, and faster than thinking while writing	Silent thought beats spoken output
What multi-agent systems lack is organization and coordination, not individual intelligence	What Multi-agent lacks isn't smarts, it's HR—success rate jumps from 69 to 85	Many minds are not as good as good weaving
Teachers and students see problems from different angles, causing teaching to fail	A teacher who scores higher than the student still can't teach them, because the way he thinks about the problem is different from the student's	High scores make a poor teacher
Predicting the remaining length while writing lets the model know when to wrap up	Make "how much longer to write" into a value function, and the model knows, with every token it writes, how far it is from the end	Only by knowing when to stop can one put pen to paper

Note the common features of the positive examples:

Mostly 4-8 character stems, with a rhythm close to idioms / classical Chinese titles
Verbs with an edge: "lock", "grow", "silent", "good", "stop"
Has a classical flavor but is not obscure; makes a judgment but is not sentimental
Stands on its own when taken out alone

Three self-check questions (recite silently after writing)

Pull it out and paste it on the wall—does it look like a section title / aphorism?
Would a native Chinese speaker say it this way? (Would Wang Zengqi write it this way?)
If you delete any one character, will it collapse?

If any answer is No → go back and rewrite, don't settle and publish.

Recognizability test (must pass)

Post the title by itself and show it to someone who hasn't read this paper, and ask: "What is this paper roughly about?"—they don't need to give an accurate answer, but they should have a sense of direction.

If they can tell the direction → the title passes. If they can't guess at all (typically a highly compressed classical-Chinese-style title),you must use a Chinese subtitle as a fallback, letting it carry the explanatory function. An English subtitle is just the paper's original title and does not count as a fallback:

#+title:      字未出，止已现
#+subtitle:   把"还要写多远"做成一个 value 函数 — Length Value Model: ...

Compression and recognizability must coexist. Compression only = six months later even you can't tell which paper it was; recognizability only = it degrades back to a wordy 28-character sentence. Only publish when both tests pass.

Relationship with other fields

Title and the "Insight" section: first finish writing the "Insight" section, then go back and from that passagetake the bone(Not compression, but forging one cut) put it into title.
title and filename: denote filename paper-{简短标题} 's "short title" is the method name / core concept name (e.g., prerl、dsrl), used for file retrieval; title is the thought backbone sentence, used as the content entry point—the two are different fields and do not replace each other.

After the file is written, report the path.

Red lines (every one must pass)

Colloquial 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 language, then mention the term name in passing. If you must use the original term to explain it, you still do not understand it
Short words first — If two words can say it, do not use four. "This paper proposes a new framework" → "They made a thing"
One sentence, one thing — 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 makes people want to know the answer
No filler — Delete academic boilerplate ("In recent years, with the development of...", "It is worth noting that"). Every sentence does work
Trust the reader — Say it once and that is enough. Do not repeat conclusions
Honest — If the paper has a fatal flaw, say it has a fatal flaw. If you cannot understand a part, say you cannot understand it
Will I, 6 months later, understand this? — Every term must land the first time it appears ("value function = given the current state, predict future cumulative reward"), every formula must be translated into natural language, and every citation must explain its significance to a layperson. Self-check: silently ask, "Half a year later, if I find this in denote, can I recall the core within 30 seconds?" If not → rewrite
Layperson clarity over concision — Expand when expansion is needed; do not cut the setup the reader truly needs just to be "short." The scale of concision applies only to title; the main text should be as long as it needs to be, and the pace is determined by the need to make people understand, not by a fetish for "short"

Writing principles

Four core principles that determine whether an article is "a living person speaking" or "a machine reporting":

One anchor supports the whole text — The concrete example set up in "Problem" is the anchor. "Translation" and "core concepts" all unfold on this anchor, and every paragraph returns to it, keeping the reader in the same problem domain the whole time. Changing the anchor = changing the map = the reader loses all the intuition built earlier.
- In the "personal experience" subsection, you can also use only one example. Two examples = chopping the reader's intuition into pieces; even if both examples are strong, pick the sharpest one. Counterexample: first use "100-word product introduction" and then use "LIFEBench"—the reader's brain has to switch between two storylines twice. Good example: from beginning to end, "GSM8K 200 token" runs through—the reader stays in the same predicament the whole time
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, can C also be D?" to lead the reader through the reasoning. Make the reader feel the conclusion was one step away from being their own idea
Transformation instead of definition — When explaining the relationship between two concepts, continuously transform A into B; do not say "A and B have relationship XX." "Transform LSTM → it looks like ResNet" is ten times stronger than "LSTM and ResNet are dual"
The landing point must be actionable — Give "this means you can ___," not "this makes us rethink ___." The reader should walk away with something they can do, not a sentiment worth pondering

Toolbox (optional)

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

Analogy — Load-bearing: every key component of the method can be mapped onto it. Walk through the method along the analogy
ASCII diagram — Show component relationships, data flow, structural comparisons. Draw it after the reader has a conceptual scaffold
Napkin sketch — A side-by-side comparison of "how it used to be thought of, how it should be thought of now"
Good question — Turn the predicament the paper solves into a question that makes even a layperson curious
Progressive examples — From simple to complex, building understanding step by step
Rhetorical question hook — 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.

If the paper has an overview figure that carries the core idea of the whole text (overview / architecture diagram, usually Figure 1), extract it and save it to ~/Documents/notes/images/, filename {identifier}--paper-{简短标题}-overview.png。

Criterion: this figure 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 methods:

arxiv → visit the HTML version (arxiv.org/html/...), find the image URL, download it with WebFetch
PDF → capture the page containing the figure and save it as an image

2. Problem: let the reader encounter that predicament

Don't describe the problem—let the readerexperiencethat problem firsthand. Open with a concrete example—a specific scenario, a piece of input and output, a failure screenshot, a user story—so the reader sees the predicament in that example.

Not "large models have a hallucination problem on factual answers," but: "You ask GPT, 'Who won the 2023 Turing Award?' It answers gravely, Yann LeCun. Ask again, it says Hinton. A third time, it changes again."

Three-part narrative, carried through with the same example:

Experience firsthand — Pull the reader onto the scene of the predicament. The example is best if it's simple enough to state in one or two sentences
Old path — How did previous researchers handle this example? Why didn't it work? Expose the shortcoming with the same example, so the reader sees "oh, this path really is stuck"
New opening — What entry point did this paper's authors see in this example that others didn't? Introduce their solution approach (only introduce the direction, don't unpack the mechanism—that's the job of "translation")

If the paper has no clear predecessor (a pioneering problem, a new field), skip the second part and go directly "experience firsthand → new opening."

Three parts is a pacing requirement, not a formatting requirement— Don't force in **亲历/**旧路/**新口 subheadings. The problem section is more hooking asone continuous narrative; subheadings cut the "flow" into "segments." Save subheadings for the translation section (the mechanism must be revealed step by step).

Counterexample: "This paper proposes a new XXX framework" — this is an academic abstract, not a problem.

3. Translation: Get straight to the essence of the method

The "Problem" has already explained the predicament thoroughly —this section should not restate the problem. The focus is "how it is done": the paper's method, mechanism, and key insight.

Use the same example throughout: continue with the concrete example from "Problem". The reader has just seen, on that example, that the old path does not work and where the new opening is — now take them through the paper's method step by step on that same example. Switching examples = switching context, and the intuition the reader built earlier is lost.

The only exemption: if the same example cannot support the mechanism details (for example, the algorithmic process requires unfolding the data flow), introduce a "sub-example" as an extension — but the sub-example must be in the same problem domain as the parent example, so the reader feels it is "looking at a part under a magnifying glass," not switching maps.

Establish an anchor at the beginning: find a concrete central metaphor or image — the anchor describeswhat the method looks like on that example. For example, "on the Turing Award problem we just discussed, the method is like a triage desk: first stop the uncertain answers and deal with them later." The anchor is welded to the example from "Problem".

Reveal step by step, letting the reader unlock the fog: each paragraph pushes one step forward, each paragraph gives the reader a new perspective, and the small "aha, so that's how it is" revelations accumulate into a deep understanding of the example. Reveal verbs: "at this point you see..." "so what happened was..." "then what about this step — they thought of..." The thing said in the previous paragraph opens the door for the next paragraph.

Need to cover (all on that example):

How it works (core mechanism/method)
What the results are like (pick the two or three most illustrative results)
Key concepts needed to understand the whole paper (if any)

Organize subheadings according to content needs; they do not have to be fixed.

The translation section must have a checklist (to prevent "condensation" from trimming away the meat)：

Load-bearing analogy — not just decoration; it must map the method's key components. Model example: "runner + watch" (mapping "model" to runner and "value head" to watch; the analogy can support the entire mechanism explanation). Bad example: only "countdown watch" — it does not map in "where the training signal comes from," so the analogy floats on the surface
Three or more sets of concrete numbers — baseline / improvement / key ablation. Let outsiders feel "so the gap is this big"
A counterintuitive secondary finding — the most "wow" passage in the paper, presented in its own section. Model example: LenVM's "token word cloud analysis" ("think/wait" vs "finalize/confirm").If present, it must be kept and cannot be cut for the sake of concision; if absent, say plainly "this paper does not have one" and do not force it in
Do not include raw formulas — formulas are useless to outsiders. Either translate them into words ("L_len = ... means the model is supervised every time it writes a character"), or leave them as an optional appendix section.LaTeX / MathJax-style formulas must not appear in the main text

4. Core concepts: unlock on the same example

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

3 is the floor, not the ceiling—Cutting it down to 2 usually means missing a key design choice hidden inside the method (e.g., LenVM's constant -1 reward—it isn't a "component," it's the design trick that makes the whole mechanism work, and it must be covered in its own section). If the paper really does have only 2 independent key concepts (rare), state that explicitly; don't force it.

Every concept lands on that "problem" example—Don't explain a term in isolation; go back to that example and let the concept surface in that context. Each concept the reader unlocks deepens their understanding of that example by one layer, and clears away one patch of fog.

For each concept:

One sentence: what this thing is, what it's used for
Back to the example: In that example, what does this concept look like? What would happen in that example without it? When explaining the relationship between two concepts, prefer "transform A into B" over "A and B are in an XX relationship"—transformation is more powerful than definition
Why it matters: Without it, where does the paper's logical chain break

Criteria for choosing concepts: if the reader doesn't understand this, they won't be able to follow the later insights and the review. Don't pick again what has already been thoroughly explained in "Translation."

5. Insight: the crystallization of thought

The most valuable thing in an entire paper is often just one point—the new crystal the author truly found.

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

Test: pull this sentence out on its own, away from the paper's context—does it still have force? If it's merely restating the paper's conclusion, it isn't an insight. An 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 can't articulate it, reread step three. If the paper truly has no spark of thought, say plainly "this paper is an engineering improvement with no new discovery at the cognitive level." Don't force it.

6. Advisor review

Switch identity: 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.

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

Eye for the topic: Is the problem worth doing? A real gap or a manufactured one?
Method maturity: Cleverness or brute force? Is there a more natural approach that was overlooked?Check whether the method's fundamental presuppositions have problems—Don't just look at whether the numbers are pretty; look at what the authorsassumed. Example: LenVM assumes the sampling distribution remains stable after using the value signal to nudge—but once the nudge happens the distribution changes, and value prediction may become inaccurate. This kind ofself-referential hidden concernis ten times more important than "insufficient scale." Ask yourself: if this paper is wrong, where is it most likely to go wrong? Is the root of the error an undiscussed presupposition?
Experimental sincerity: Are the baselines fair? Is the ablation thorough? Do the numbers hold up under questioning?
Writing skill: Did they cut corners where things most needed to be made clear?
Verdict: strong accept / weak accept / borderline / weak reject / strong reject, with a one-sentence reason

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

7. Inspiration: reminders to myself

The landing point is "can use," not "can think." Give "this means you can ___", not "this makes us rethink ___".

Probe for connections from three angles; expand on a hit, skip if no hit, and if none hit, 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?
Reverse: Is the paper's approach the opposite of my default assumption? What should I stop, and what should I start?

8. Cross the red lines

Scan the red lines one by one. Additional checks:

Break the formula—no more than two negative parallelism constructions in the whole text; change three-part patterns to two or four items
Vary the rhythm—alternate long and short sentences
Kill the quotable lines—anything that sounds citable, rewrite it
Check for 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 ~/Documents/notes/。

Acceptance

The problem makes people experience it firsthand: The opening has a concrete example, and the reader encounters the difficulty in the example; the shortcomings of the old solution are exposed using the same example
The translation goes straight to the essence: It does not restate the problem; the focus is "how it is done"—the method, mechanism, and key insight
The same example runs throughout: Both the translation and the core concepts unfold on the same example from "The problem," so the reader stays in the same problem domain the whole time
A sense of exploration: Each paragraph gives the reader a new perspective; small "ah, so that's it" revelations accumulate into a deep understanding of the example
Has an anchor: The anchor in the translation section describes "what the method looks like on that example," and subsequent concepts grow around it
Pushed along: The reader can feel the process of "figuring it out step by step," rather than receiving a prepackaged conclusion
A layperson can follow: A smart person who does not know this field can restate the core idea after reading
The advisor acts like an advisor: Has judgment and restraint, with a verdict in the final sentence
Inspiration is actionable: The landing point of the inspiration section is "you can ___", not "it is worth thinking about ___"
Zero sense of fragmentation: After reading, it feels like one person telling you, "I read a paper and found something interesting"
A layperson can restate four things: the problem (concrete to one example) / the solution (mechanism + design rationale) / the core finding (including the counterintuitive secondary finding) / the insight (something takeaway-able). If any item gets a layperson stuck → failure
title passes both: Passes both the three-question concision self-check and the recognizability test
Translation section has all four: load-bearing analogy / three sets of numbers / counterintuitive secondary finding / no original formulas
Core concepts ≥ 3: Includes one "design choice" concept (not just "components")
Advisor review reveals assumptions: In the method maturity item, points out at least one fundamental assumption/concern that has not been discussed