Paper Deep Reader

Overview

Read one or several papers as evidence, not as abstracts to paraphrase. First determine what kind of intellectual object the paper is. Then reconstruct it using the right lens: an empirical paper needs methods and experiments; a theory paper needs definitions, assumptions, derivation, and implications; a position paper needs thesis, argument chain, examples, objections, and evidential limits. Translate that reconstruction into an explanation optimized for understanding and reuse.

The default answer is Chinese with English technical terms retained on first mention. The default artifact is an inline Markdown answer. Create a Markdown note only when requested or when the task explicitly asks for a reusable artifact.

The skill has two separate layers:

Evidence layer: paper text, figures, equations, tables, appendix, code
Explanation layer: conclusion → mental-model correction when needed → paper-native structure
                   → example/derivation/evidence as appropriate → limitations → summary

The explanation layer must never outrun the evidence layer.

When to Use

Use for:

• “读/拆解/精读/总结/解释这篇论文”；
• a PDF, arXiv link or ID, DOI, title, or pasted paper text;
• questions about a paper's method, figure, equation, dataset, experiments, novelty, limitations, cost, or reproducibility;
• comparison or synthesis of multiple papers;
• deciding how a paper fits the user's own system or research direction.

Do not use as the primary workflow for field-wide discovery, simple bibliographic search, document extraction with no analysis, or manuscript writing. If the client provides separate PDF, scholarly-search, or research-landscape capabilities, use them as supporting tools without making this skill depend on their names.

Non-negotiable Rules

1. Read fresh. Do not analyze from memory or abstract alone when the full paper is accessible.
2. Version-lock. Record the exact PDF/version/date inspected. Preserve an arXiv version suffix when available.
3. No invented detail. Never manufacture scores, dimensions, dataset sizes, hardware, costs, baselines, citations, or implementation choices.
4. Separate provenance. Mark material as 论文事实, Agent推断, or Agent判断 whenever the boundary could be unclear.
5. Trace claims to evidence. Important technical and numerical claims need a section, figure, table, equation, appendix, or page locator.
6. Correct before expanding. If the user's wording implies a wrong mental model, correct it briefly before explaining the rest.
7. Clarify relationships. State whether listed items are parts of one system, sequential stages, alternative methods, parallel resources, or evaluation views.
8. One sample end to end. For abstract pipelines, walk one concrete input through every major stage.
9. Numbers need denominators. Report scale with units and context, not isolated large numbers.
10. Do not call a pipeline an Agent unless it has goal-directed multi-step behavior, state, tools/environment interaction, or feedback-driven execution.
11. Genre before template. Never force a conceptual, theoretical, survey, qualitative, or position paper into an empirical ML template.
12. No empty-section theater. Omit dimensions that are not meaningful for this paper instead of repeatedly saying “not applicable.”
13. User relevance is opt-in. Connect the paper to the user's project only when asked, clearly useful, or already part of the reading contract; do not append a domain adaptation section by default.
14. Adaptive explanation. Trees, tables, equations, and examples are tools, not mandatory slots. Use only the representation that reduces confusion.

Workflow

1. Resolve the reading contract

Infer the likely goal from the request. Do not block on clarification when a sensible default exists.

Default depth:

If the audience is unspecified, explain for a technically capable reader who is new to this exact method. Define specialist terms at first use but do not reteach generic fundamentals unless needed.

Completion criterion: input scope, paper count, and intended answer depth are known or safely defaulted.

2. Classify the paper before choosing an analysis frame

Classify by primary contribution, not by venue label or the presence of a few equations/tables. A paper may have secondary traits; choose one primary type and optionally one secondary type.

If classification is ambiguous, write a one-line hybrid label such as position paper with a historical case study or method paper plus benchmark contribution. Do not ask the user unless choosing the wrong frame would materially change the answer.

Completion criterion: primary type, secondary type if any, and the matching analysis dimensions are explicit internally before detailed reading.

3. Acquire and verify the source

Use this source order:

1. user-provided local PDF;
2. official publisher/proceedings or author PDF;
3. versioned arXiv HTML/PDF;
4. repository manuscript;
5. pasted text.

For a local PDF:

• inspect metadata and page count;
• use lightweight text extraction for text PDFs;
• use advanced OCR only for scans, equations, or broken layout;
• inspect figures/tables visually when text extraction loses spatial meaning.

For a URL or identifier:

• fetch metadata and full text;
• resolve title, authors, date, version, venue/status, and links;
• distinguish preprint, workshop, conference, journal, and withdrawn/retracted status.

If only a title is provided, search for the primary source. Ask for help only when multiple papers remain genuinely ambiguous or the source is inaccessible.

Completion criterion: the actual full text or the best available primary source has been inspected, and any source limitation is disclosed.

4. Build a genre-aware paper map before explaining

Read in two passes.

Pass A, orientation: title, abstract, introduction, section headings, conclusion, main figures, main result tables.

Pass B, verification: method, equations, datasets, implementation details, experiments, ablations, limitations, appendix, code/repository if relevant.

Construct a universal core map:

Paper
├── Identity: version, venue/status, task type
├── Question/problem: what gap or puzzle motivates the paper
├── Contribution: what intellectual work the paper claims to add
├── Reasoning object: model, theorem, argument, taxonomy, dataset, cases, or protocol
├── Support: experiments, proof, citations, examples, cases, synthesis, or expert reasoning
├── Alternatives: baselines, rival explanations, prior frameworks, objections, or null hypothesis
└── Boundaries: assumptions, scope, uncertainty, missing tests, and limitations

Then add only the type-specific branch:

Empirical       → data → method → evaluation protocol → results → failure analysis
Dataset         → provenance → schema/annotation → splits → coverage/leakage → benchmark use
Theory          → definitions → assumptions → statement → derivation/proof → consequences
Position        → thesis → premises → argument steps → cases/analogies → objections → agenda
Survey          → scope → selection → taxonomy → synthesis → omissions
Qualitative     → context → sampling → analysis method → evidence themes → transferability
Meta-analysis   → search protocol → eligibility → study quality → synthesis → heterogeneity/bias
Resource/tool   → use case → interface/workflow → dependencies → validation → operational limits

Do not mirror the paper's section order in the final explanation unless that order is genuinely clearer. Do not create empirical headings for a position paper just to mark them absent.

Completion criterion: every branch above is filled, marked absent, or marked not reported.

5. Create a claim-support ledger

Keep a compact ledger while reading. Support is deliberately broader than experimental evidence:

Preferred locators: Table 2, Fig. 3, Eq. (4), Appendix B, then PDF page. Page alone is weaker because versions differ.

When figure and prose disagree, report the discrepancy. When an exact fact is not reported, write 未报告, not an estimate. If an estimate is useful, show its assumptions and label it.

Support types include measurement, controlled experiment, formal proof, derivation, citation synthesis, historical case, qualitative excerpt, worked example, analogy, expert argument, author assertion, Agent inference, and Agent judgment.

For argument-driven papers, reconstruct premise → inference → conclusion and state whether each step is entailed, plausible, illustrative, or merely asserted. A case study may refute a universal claim or illustrate possibility, but it rarely establishes universal frequency or impossibility by itself.

Completion criterion: every headline claim and number has a locator, support type, and calibrated statement of what that support can and cannot establish.

6. Reconstruct the paper's central object

Use the branch matching the paper type.

For implemented methods, systems, and tools

First identify the relationship type:

Then reconstruct:

1. What is one input unit?
2. What fields/tensors/objects exist at entry?
3. Which component transforms each object?
4. What is learned, retrieved, frozen, generated, or manually supplied?
5. What changes during training?
6. What happens at inference?
7. What exact output is produced?
8. Which loss or rule connects the output to supervision?

For equations, use this order:

plain-language purpose
→ one concrete numeric/shape example
→ equation
→ symbol table
→ operational interpretation
→ assumptions and edge cases

Never present a symbol before saying what problem the equation solves. Do not rename dot products as cosine similarity, scores as probabilities, or correlation as causation unless the paper establishes it.

Completion criterion: one input can be traced end to end without an unexplained jump.

For theoretical and formal papers

Reconstruct in this order:

problem setting → definitions → assumptions → main statement
→ proof/derivation strategy → worked example or boundary case → implications

Distinguish a definition from an assumption, a theorem from an interpretation, and proof validity from real-world applicability. Explain equations only when central; define every symbol used.

For position and conceptual papers

Reconstruct the argument rather than inventing a “method pipeline”:

thesis
├── premise 1 + support
├── premise 2 + support
├── inference connecting premises to thesis
├── central case, analogy, or thought experiment
├── rival account or objection
└── proposed research agenda / consequence

For each major step, ask:

1. Is it descriptive, normative, causal, possibility, or impossibility language?
2. Is support direct evidence, cited evidence, a historical case, analogy, or author assertion?
3. Does the conclusion follow, or is an additional premise required?
4. What would falsify or weaken the thesis?

For surveys, qualitative studies, datasets, and reviews

Follow the type-specific branch from Step 4. Explain the selection/sampling process and coverage boundary before summarizing conclusions. The reader must know what universe the paper's synthesis can legitimately represent.

7. Audit evidence using the genre-appropriate protocol

Run this section only for dimensions meaningful to the paper. For an empirical or dataset paper, use the detailed checks below. For other genres, use the corresponding checklist after them.

Empirical data

Report:

• source and collection process;
• unit of observation;
• modalities and fields;
• labels, pair cardinality, or annotation process;
• raw vs augmented/synthetic counts;
• class/domain distribution;
• train/validation/test split;
• split timing relative to augmentation;
• duplicate, subject/site/source-instance leakage risks;
• release/license status if relevant.

For image-text datasets, separate:

1. pair existence;
2. one-to-one vs one-to-many cardinality;
3. class consistency;
4. instance-level factual grounding.

Empirical experiments

Normalize evidence into:

Distinguish best single score, average across tasks, relative improvement, and absolute percentage-point gain. Never convert among them silently.

Other evidence protocols

Completion criterion: each major claim is paired with the kind of support relevant to its genre and labeled supported, partially supported, illustrative, speculative, or unsupported.

8. Analyze contribution without repeating marketing

Select only applicable contribution layers:

Problem/data novelty
Method novelty
Training/objective novelty
System/integration novelty
Evaluation novelty
Theory/proof novelty
Conceptual/argument novelty
Taxonomy/synthesis novelty
Resource/protocol novelty

For each layer state:

• what existed before according to the paper;
• what changed here;
• whether it is a new mechanism, a new combination, a domain transfer, or a new evaluation;
• which ablation or comparison isolates its value.

Use “作者声称首次……” unless priority has been independently verified. A useful synthesis is:

• strongest genuine contribution;
• routine components recombined;
• claim not isolated by evidence.

Completion criterion: novelty is decomposed and no “SOTA/first” claim is repeated as an independent fact without verification.

9. Compose an adaptive explanation

Use a stable spine, then select only useful modules. The preferred explanation style is not a demand to fill every slot.

Required spine
├── conclusion first
├── paper type + central question
├── paper-native reconstruction
├── support and confidence
├── limitations / what remains unproven
└── one-sentence summary

Optional modules
├── misconception correction       only when a likely misconception exists
├── tree/flow                       for hierarchy, sequence, or argument structure
├── concrete example               when it makes an abstraction operational
├── equation + symbol table         for central formal content
├── data/module/result table        for empirical or structured comparisons
├── argument map                    for position/conceptual papers
├── taxonomy map                    for surveys
└── project relevance               only when requested or clearly useful

Default genre shapes:

Empirical       → conclusion → problem → method/data flow → protocol/results → limits
Theory          → conclusion → setting/assumptions → statement/derivation → example → scope
Position        → conclusion → thesis → argument map → central case → objections/gaps → agenda
Survey          → conclusion → scope → taxonomy → synthesis → omissions/date boundary
Qualitative     → conclusion → question/context → sampling/analysis → themes/evidence → transfer limits
Dataset         → conclusion → scope/provenance → schema/annotation → scale/splits → uses/risks

The following modules are available when useful:

A. 总结论先行

Two to four sentences:

• what the paper is fundamentally doing;
• the strongest contribution;
• the most important caveat;
• for multiple papers, the main difference among them.

B. 先纠正一个可能的误解

Only include when useful. Use:

先纠正一个容易形成错误心智模型的点：X 不是 Y。更准确地说，X 与 Y 是 [whole/part, sequence, alternatives, parallel resources, evaluation views] 的关系。

Do not manufacture a misunderstanding merely to fill the section.

C. 总体树状结构或论证图（按需）

Use a small tree when hierarchy or flow matters; use an argument map for premise/inference/conclusion; use neither when prose is clearer. Label relationship types explicitly. Avoid visually nesting parallel resources under one another.

D. 单一具体样例、思想实验或边界案例（按需）

For a pipeline, choose one representative input and walk it through the stages. For a theory paper, choose a worked or boundary case. For a position paper, reconstruct the paper's central case or thought experiment without pretending it is an experiment. Keep the example stable rather than introducing multiple analogies.

For an implemented prediction-and-retrieval system, for example:

one input instance
→ encoder creates a representation
→ retrieval finds supporting evidence
→ fusion combines input and evidence
→ predictor produces an output
→ explanation component cites its support

The example is explanatory. Do not invent paper-specific values. Use real fields and dimensions when reported; otherwise mark them schematic.

E. 结构化表格（按需）

Use compact tables only when rows share a schema. Good tables include:

• premise, support, inference role, weakness;
• definition, assumption, consequence, scope;
• component, input, operation, output, trained/frozen;
• dataset, unit, fields, count, split;
• baseline, metric, result, delta;
• claim, evidence, confidence, caveat;
• paper, common core, unique contribution, evidence, suitable use.

Avoid a table for narrative causal reasoning.

F. 数量、规模或语料范围（存在时）

Report quantitative scale when it is part of the paper's evidence. Do not create a scale section merely to list absent empirical fields. Relevant quantities may include:

• samples, classes, subjects/sites, modalities;
• train/validation/test counts or ratios;
• parameters, FLOPs, GPU type/hours, epochs, batch size;
• latency/memory/cost where reported;
• number of studies/cases/interviews/documents and search date range;
• theorem assumptions, asymptotic regime, or bound when these define scope.

Also say what each number counts. Example: “12,000 是增强后的训练图像数，不是 12,000 个独立采集叶片。”

G. 证据、局限与可信度

Separate:

论文直接证明了什么
论文间接支持了什么
论文没有证明什么
Agent 的判断

H. 一句话总结

Finish with the simplest technically faithful model of the paper, not a slogan.

10. Handle multiple papers as a normalized comparison

Do not write N disconnected summaries. First classify each paper, then choose shared axes that are meaningful across the set. Do not force data and scale or compute onto conceptual/theoretical papers.

Then classify their relationship:

• competing solutions to the same task;
• complementary stages in one pipeline;
• same method tested in different domains;
• foundation method vs application paper;
• dataset/benchmark vs model paper.

End multi-paper analysis with:

1. common mechanism;
2. decisive differences;
3. whether they can be combined;
4. which is most relevant to the user's goal and why;
5. unresolved contradiction or missing experiment.

Completion criterion: every paper is compared on the same axes, and missing information remains visibly missing rather than being filled by analogy.

11. Adapt to the user's research system only when relevant

Do not append this section by default. When the user asks how the paper fits a larger system, or when the stated reading goal is project adaptation, place it in:

Perception/input → grounding → inference → retrieval/evidence
→ decision/recommendation → safety validation → execution → feedback

State which links the paper actually implements. Clarify whether proposed additions are:

• components inside one Agent;
• parallel datasets/knowledge bases/tools used by an Agent;
• alternative models for the same component;
• evaluation resources outside the runtime system.

For agricultural or medical systems, do not infer deployment readiness from aggregate accuracy alone. Check external validation, rare severe errors, calibration, uncertainty, subgroup performance, provenance, and human oversight.

Output Modes

Focused answer

Use for one narrow question:

1. conclusion;
2. relationship correction if needed;
3. paper-native explanation of the requested point;
4. example, equation, or argument step when useful;
5. support and caveat;
6. one-sentence summary;
7. project relevance only if requested.

Deep-read answer

Use the required spine and the genre shape from Step 9. Aim for completeness without repeating the same idea or emitting empty genre-inapplicable sections.

Reproduction answer

Add:

• required data and preprocessing;
• architecture/configuration;
• training objective and schedule;
• hardware/software reported;
• missing implementation details;
• minimum viable reproduction vs faithful reproduction;
• likely blockers and verification tests.

Living paper note (mandatory)

A paper conversation has two synchronized outputs:

Chat answer = the best direct answer to the user's current question
Living note = durable, cumulative understanding of the paper

For every answer that materially analyzes, explains, compares, corrects, or extends understanding of a supplied paper, create or update the paper's living Markdown note before sending the final chat answer. This includes follow-up questions in later turns and resumed sessions. Do not wait for the user to separately request a file.

Storage root resolution

Resolve the storage root in this order:

1. PAPER_LIBRARY_PATH from the environment, resolved to an absolute path;
2. a project-local path declared by AGENTS.md, CLAUDE.md, .hermes.md, HERMES.md, or another client project-instruction file;
3. <current-project>/papers/library when the current working directory belongs to a project;
4. ~/Documents/Agent Papers/library as the final fallback.

Never store the paper library inside any client's skill installation directory or personal-memory file. Skills contain procedures, and agent memory contains compact preferences; neither is the paper knowledge base.

Library layout

Use one stable directory per paper:

<library-root>/
├── README.md
├── _index.md
└── <paper-key>/
    ├── paper.md
    ├── source.pdf              # copy only when locally supplied or explicitly downloaded
    ├── source.txt              # optional cached extraction
    └── assets/                 # optional figures/tables

paper-key must be stable and collision-resistant:

1. versionless arXiv ID, for example 1706.03762;
2. normalized DOI when no arXiv ID exists;
3. otherwise first-author-year-short-title.

Use the identifier to find an existing note even if the user's title wording changes. Never create a second note for the same paper merely because another version, filename, or alias is used. Record the exact inspected version inside paper.md.

Living note schema

Start a new note from assets/living-paper-note.md when available. The note has a stable core plus type-specific sections. Preserve stable headings already in use, but omit or remove untouched optional sections that do not apply. Never fill a position paper with empty dataset/benchmark/ablation sections.

---
title: ...
authors: [...]
year: ...
paper_key: ...
paper_type: ...
secondary_type: ...
arxiv: ...
doi: ...
venue: ...
status: ...
source_url: ...
source_version: ...
tags: [...]
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

# <Title>

## 一句话结论
## 先纠正可能的误解
## 核心问题与贡献
## 论文结构 / 论证结构
## 关键概念、对象与关系
## 证据与可信度
## 局限、边界与未验证项
## 问答沉淀
## 待确认问题
## Claim-Support Ledger
## Sources
## Update Log

Add only applicable modules, for example:

Empirical       → 方法与数据流；数据、字段与规模；实验结果与消融；复现条件
Dataset         → 数据来源与字段；标注与质控；划分与泄漏；覆盖与许可
Theory          → 定义与假设；主要命题；证明/推导；边界案例与推论
Position        → 核心论点；前提—推理—结论；中心案例/思想实验；反方与研究议程
Survey          → 范围与选取；分类框架；综合共识；遗漏与时效边界
Qualitative     → 场景与样本；分析方法；主题与证据摘录；可迁移性
Meta-analysis   → 检索与纳入；研究质量；效应综合；异质性与偏倚
Resource/tool   → 使用场景与接口；依赖与流程；验证；运维与限制
Project mapping → only when requested or materially useful

A core heading may say 尚未分析 initially. Optional headings should normally be absent until useful.

Update protocol for every answer

1. Resolve identity. Extract arXiv ID, DOI, or fallback key and locate the existing note by frontmatter/identifier before creating one.
2. Read before write. Read the current paper.md; do not update from session memory alone.
3. Classify the new material. Confirm paper type and decide which core or type-specific sections gain durable knowledge.
4. Merge, do not dump. Update canonical sections with distilled conclusions. Do not paste the full user question or duplicate the chat answer.
5. Preserve provenance. Keep 论文事实, 作者主张, Agent推断, and Agent判断 distinguishable; add support type and locators for new claims.
6. Record the question. Under 问答沉淀, append a compact entry containing date, normalized question, distilled answer, affected sections, and evidence IDs. Deduplicate semantically repeated questions.
7. Update metadata. Change updated, add new tags/aliases when useful, and append one concise Update Log line.
8. Update the index. Ensure _index.md has exactly one row/link for the paper with title, year, topic tags, status, last updated date, and one-sentence thesis.
9. Verify the write. Read back the edited sections or the full new note. The chat answer is not complete until the note and index are verified.
10. Report minimally. End the chat answer with 已同步：<absolute-path> and, when relevant, name the sections changed. If persistence fails, report the failure explicitly instead of implying success.

What belongs in the living note

Persist:

• corrected mental models and stable relationship classifications;
• genre-relevant method, proof, argument, taxonomy, data, or evidence with locators;
• useful equations and symbol definitions;
• cumulative answers that improve future understanding;
• unresolved contradictions and follow-up questions;
• relevance to the user's research system;
• external sources actually consulted.

Do not persist:

• greetings, conversational filler, or full chat transcripts;
• guesses that were immediately discarded;
• repeated explanations with no new durable information;
• unrelated personal information;
• unsupported claims copied from search snippets.

Multi-paper questions

For a question involving several papers:

• update every affected paper's own paper.md with paper-specific knowledge;
• create or update <library-root>/comparisons/<comparison-key>.md only when the cross-paper synthesis is itself reusable;
• link the comparison note from each affected paper and from _index.md;
• do not replace individual paper notes with one giant comparison file.

Use an explicit absolute path. Keep notes Obsidian-compatible and use relative wikilinks where practical.

Citation and External Search Policy

The paper itself is the primary source for method and reported results. External search is needed for:

• venue/status verification;
• current citation/adoption claims;
• code/project/retraction status;
• priority claims such as “first”;
• follow-up work or post-publication impact;
• comparison claims not contained in the supplied papers.

Cite external claims with source and access date. Do not use current citation counts without naming the database. Do not mix counts from different databases in one unlabeled comparison.

Efficiency Rules

1. Extract once and search within the extracted text; do not repeatedly refetch the same PDF.
2. Use orientation pass before deep reading so effort follows the user's question.
3. Search independent evidence tracks in parallel.
4. Keep a ledger rather than rereading for every number.
5. Prefer Markdown over elaborate HTML unless the user requests presentation output.
6. For several long papers, analyze each into the same compact intermediate schema before synthesizing.
7. Spend output tokens on the method, sample, evidence, and caveats, not a long related-work inventory.

Common Pitfalls

1. Abstract paraphrase masquerading as reading. Fix: inspect the full argument/method/proof, supporting material, and limitations appropriate to the genre.
2. Paper-section dump. Fix: reconstruct around question, contribution, central object, support, alternatives, and boundaries.
3. Wrong hierarchy. Fix: label whole/part, sequence, alternatives, parallel resources, or evaluation views before drawing a tree.
4. Too many analogies. Fix: use one stable example end to end.
5. Equation-first explanation. Fix: purpose and concrete sample before notation.
6. Paired means grounded. Fix: audit pair existence, cardinality, class consistency, and instance grounding separately.
7. SOTA means solved. Fix: inspect protocol fairness, absolute deltas, variance, external validation, and failure cases.
8. Ablation proves causality automatically. Fix: check whether the ablation changes only one factor and whether variance is reported.
9. Frozen means correct. Fix: frozen only means parameters are fixed, not that the representation is unbiased or domain-valid.
10. Several paper summaries without synthesis. Fix: normalize axes and classify relationships first.
11. Estimated number presented as reported. Fix: label assumptions and arithmetic explicitly.
12. Personal critique blended with author claims. Fix: use 论文事实, Agent推断, and Agent判断 labels.
13. Empirical-template bias. Fix: classify genre first; a position paper needs an argument map, not a table of nonexistent datasets and ablations.
14. Mandatory-format bias. Fix: treat trees, examples, and tables as optional explanatory tools, not required headings.
15. Automatic project mapping. Fix: answer the paper question first; add project relevance only when requested or clearly useful.
16. Case treated as proof. Fix: say whether a case illustrates, challenges a universal claim, or supports generalization; do not silently upgrade it to experimental proof.

Verification Checklist

Before answering, confirm:

• Actual full text or best available primary source was read in this turn.
• Exact title, version/date, and venue/status are correct.
• Primary paper type and any secondary type are identified before choosing the analysis frame.
• The universal core map and only the relevant type-specific branch are complete.
• Important relationships are explicit where needed; no unnecessary diagram was forced.
• A pipeline input, proof path, argument chain, taxonomy, or evidence synthesis is reconstructed according to genre.
• Every symbol used is defined when formal content is included.
• Genre-relevant evidence protocol is applied; irrelevant empirical fields are omitted rather than listed as absent.
• Each headline claim has a locator, support type, and calibrated statement of what it establishes.
• Facts, inferences, and judgments are separable.
• Multi-paper comparison uses shared axes.
• The answer starts with the conclusion, uses the paper-native genre shape, and ends with one simple sentence.
• Project relevance appears only when requested or materially useful.
• No unsupported “first”, “SOTA”, impact, or deployment claim remains.
• The living paper.md was created or read-and-updated for this answer.
• New durable knowledge was merged into canonical sections rather than pasted as a chat dump.
• The question was distilled under 问答沉淀, with evidence IDs where applicable.
• _index.md contains exactly one current entry for the paper.
• The note and index were read back after writing, and the final answer reports the absolute note path.