Paper Reading

Paper Reading

把“帮助读者看懂”作为叙述顺序，把完整 Claim 及与论文类型匹配的证据作为交付范围。证据可以是实验、证明、反例、数据、协议、系统测试、代码或外部文献。可以把细节移到附录，但不得因为追求简洁而删除会影响理解、判断或验证的内容。

1. 确定阅读模式

根据用户 prompt 选择模式；用户未指定时使用 review。不要在报告中输出模式标签。

• understand：仅在用户明确要求“速读 / 简单讲 / 快速判断”时使用；仍需覆盖核心思路、中心结论、决定性证据和边界，但可以省略次要审稿与验证细节。
• review：默认模式。覆盖论文全部核心 Claim、论证或机制、决定性证据、最接近路线与关键替代解释；按论文类型检查假设、证明、对照、统计、协议、实现、不一致结果和外推边界。
• reproduce：保持理解主线，且第 5 章必写；按论文类型列出实验资产、证明前提、数据/协议、代码状态、资源成本、阻断项和最小可判别验证路径。

同时推断读者起点与关注点。只有不同选择会实质改变报告时才询问；否则采用：熟悉 AI 基础、不了解该论文子方向，希望系统看懂并能判断论文是否可信。

先判定论文类型，再决定篇幅和公式密度：

• 理论论文：突出假设、定理、证明链；正文解释决定结论的公式，证明细节放附录。
• 方法论文：突出输入输出、模块关系和机制差异；解释所有承载新机制或关键训练信号的公式。
• 系统 / 平台 / 数据集 / benchmark：突出任务定义、数据、协议、实现语义和公平性；原文没有决定性公式时不要人为补公式。
• 实证论文：突出因果问题、对照、统计、外推边界；不要为满足配额硬讲公式。
• 综述 / meta-analysis / 观点论文：突出范围、纳入标准、分类或论证链、证据覆盖、反方观点和遗漏；没有原创实验时不要套用实验配额。

论文可以同时属于多个类型。选择一个主类型和必要的次类型来决定证据路径；不要把上述每个分支都填一遍，也不要把缺少某类内容本身当作缺陷。评价标准是“作者提出的 Claim 是否由适合该 Claim 的证据支持”，不是“报告是否凑齐图片、公式、表格或实验”。

2. 先运行确定性流水线

先进入用户希望保存报告的输出根目录，再用 skill 脚本的绝对路径执行。流水线以当前目录作为输出根目录；不要在 skill 目录内运行，否则会把论文工作区写进 skill 本身。

bashCopy code
cd "<输出根目录>"
bash "<skill 根目录>/scripts/run_pipeline.sh" "<论文链接或 arXiv ID>"

用户指定独立目录名时执行：

bashCopy code
cd "<输出根目录>"
bash "<skill 根目录>/scripts/run_pipeline.sh" "<论文链接或 arXiv ID>" --workspace-name "<目录名>"

流水线生成唯一工作区：

textCopy code
{workspace}/
├── {arxiv_id}_阅读报告.md
├── metadata.json
├── raw/
├── images/
└── cache/

只补全该主报告；不要另建平行报告。缺依赖时运行 bash "<skill 根目录>/scripts/bootstrap.sh"。

3. 阅读证据

至少检查：

• metadata.json
• raw/abs.html
• raw/paper.pdf
• raw/ar5iv.html（若存在）
• raw/hjfy.html
• raw/papers_cool.html
• cache/references.json
• cache/images_manifest.json
• arXiv 源码中的主 .tex、方法、实验、附录、表格和图注

若论文有公开代码且用户关心工程或复现，打开代码仓库核对关键路径；明确区分“静态代码核查”和“实际重跑结果”。

review 与 reproduce 模式必须阅读 references/literature_search.md，按论文实际问题核对最接近工作、竞争路线和必要的反对或替代证据；不设统一篇数配额，只使用已打开并核对的论文或官方页面。需要处理不确定性时阅读 references/uncertainty_policy.md。

4. 按理解顺序写报告

以 templates/report_template.md 为唯一结构来源。核心顺序是：

1. 三分钟读懂：研究问题、核心思路、中心结论与决定性证据、最终判断、阅读路线。
2. 建立心智模型：最小问题或具体例子、核心结构或论证链、必要定义与符号、最接近工作。
3. 核心思路如何成立：方法论文讲输入输出与机制，理论论文讲假设—定理—证明链，系统/数据论文讲协议与实现语义，综述/观点论文讲范围—选材—综合或论证链。
4. 证据是否成立：完整核心 Claim—Evidence—Verdict 表，以及与论文类型匹配的实验、证明、定理、数据、系统测试或代码证据。
5. 最终判断与边界：真实创新、决策性问题、学术位置、是否值得精读/验证。
6. 复现、验证与工程边界：交代验证前提、开放材料和最小判别路径；有代码、系统或部署主张时展开工程核对，理论论文则展开假设与证明复核。
7. 附录：完整证据、额外数学/算法/实现细节、外部文献和证据定位。

正文遵循 progressive disclosure：读完前两章，读者应能回答“研究什么、核心思路是什么、为什么可能成立”；读完第 3 章，应能回答“每条核心主张由什么证据支持”。分层只改变信息出现的位置，不改变核心内容的覆盖范围。

5. 可读性规则

• 描述先于评价：先讲清研究对象、核心思路或论证链，再判断 Claim；不要在读者尚未理解术语、定义或前提时连续给出审稿结论。
• 首次使用缩写时给出中文含义和一句话定义；术语、定义与符号表只保留理解主线所需的项目，不设数量配额。
• 一个核心质疑只完整解释一次。以 Claim ID 为唯一索引，其他位置引用它，不换措辞重复；去重不得删除独立证据、反例或实现条件。
• 正文通常为 10,000–18,000 个字符，这是软目标而不是删减配额。复杂论文可以更长；附录不设总长度上限。
• 每段只完成一个论证动作；长段落拆成“判断—证据—边界”。
• 不输出内部工作标签，如“ A 级公式 / B 级公式 / 公式理解卡”。
• 不使用无评分锚点的小数分数。优先给“值得精读 / 值得浏览 / 暂不建议验证或复现”等可行动判断；若用户要求打分，再写明评分标准。

详细写作规则见 references/report-writing-guidelines.md，审稿判断口径见 references/reviewer_rubric.md。写正文前必须读取这两个文件。

6. 公式、表格与图片

需要公式、证据表或图片时读取 references/inline-table-and-formula-template.md。

公式

只在删掉公式会妨碍理解核心机制或关键证据时，才在正文深入解释。解释顺序：

1. 为什么需要它；
2. 一个直观例子或 toy example；
3. 原公式；
4. 关键符号；
5. 训练 / 推理中的作用；
6. 证据与假设边界。

数学对象使用 $...$ 或独立 $$ ... $$；公式编号写在正文，不使用 \tag{}。能单行就单行，确需多行才用 aligned。代码标识符才使用反引号。

表格

实验丰富的方法、系统或实证论文，正文通常保留 2–4 张最能建立理解或改变判断的精简表：

• 主结果表；
• 关键消融表；
• 必要的难度 / 泛化 / 数据规模表。

理论论文不为满足表格数量硬造实验表，应使用假设—引理—定理—证明依赖、反例或复杂度边界作为证据载体；数据集/benchmark 论文优先数据组成、划分、协议和泄漏审查。正文表格优先保留最关键列并立即解释它验证哪条 Claim。附录 A 收录所有承载核心结论的完整证据：可包括实验表、定理与证明依赖、反例、协议、数据统计、代码路径或失败案例。不要在正文和附录重复同一完整内容。

图片

论文存在能改变理解或判断的原始 figure 时，优先使用 arXiv 源码文件；失败时从原始 PDF 提取或裁剪。根据 \includegraphics、caption、section 和正文首次引用定位。图片紧邻它服务的解释，每张图后写 1–3 句“看什么、为什么重要”。原文无图或图片不承载核心证据时可以不插图；禁止为通过模板而造图、使用网页整页截图或设置文末图片区。

7. 证据与批判

以 Claim—Evidence—Verdict 表作为报告主骨架。先从 Abstract、Introduction/Contributions、Conclusion 建立核心 Claim 清单，再检查方法、定理、实验或系统章节中的隐含结论。Claim 数量完全由原文决定：短理论论文可以只有一条中心定理，复杂系统论文可以有多条子主张；不凑数，也不得只保留最容易验证的部分。每条 Claim 标明：

• 作者主张；
• 原文位置；
• 证明 / 实验 / 反例 / 数据 / 协议 / 系统测试 / 代码 / 外部文献等实际证据；
• 支撑强度；
• 最大缺口；
• 报告结论。

区分作者显式主张、有原文支持的隐含结论和报告自身推断。批判要针对会改变结论的假设、对照、统计、实现或外推，不为“显得严格”罗列通用缺点。第 3 章的每个 Claim 都必须在附录 D 有独立证据定位。

所有关键判断必须可追溯。无法确认时写“论文未提及 / 原文证据不足 / 当前未检索到可靠文献 / 当前环境无法确认”，并说明缺少什么证据。

8. 完成与验证

补全报告后运行：

bashCopy code
python3 "<skill 根目录>/scripts/validate_report_text.py" --input "<论文输入>" --root "<输出根目录>" --workspace-name "<目录名>"
python3 "<skill 根目录>/scripts/validate_report.py" --input "<论文输入>" --root "<输出根目录>" --workspace-name "<目录名>" --final

若未使用自定义目录名，可省略 --workspace-name。同一 arXiv ID 存在多个工作区时必须显式指定；验证器不得猜测或静默选择其中一个。

交付前确认：

• 三分钟摘要在正文最前面，且不依赖未定义术语；
• 核心思路或论证链在 Claims 审判之前被解释；
• 关键 Claim 及实际使用的数值、图、公式、证明、协议、代码和外部文献均可追溯；
• Abstract、Introduction/Contributions 与 Conclusion 中的核心主张均已进入 Claim 清单，或明确说明为何不属于可检验主张；
• 正文无占位符、重复整段、公式工作标签或无锚点小数评分；
• 0.6 论文与链接 严格使用模板中的五行固定格式：中文字段名、全角冒号、直接显示完整 URL；不要改成 [名称](URL)，不要添加项目页、论文标题、作者或工作区；
• 图片若使用则相对路径可用；正文包含与论文类型匹配的关键证据；附录 A 有完整证据与结果，附录 B 有必要的推导、算法、协议或实现细节，附录 C 对实际使用的外部文献给出直接链接或明确说明未使用，附录 D 覆盖全部 Claim；
• 主线和附录仍在同一个 {arxiv_id}_阅读报告.md 中。