ljg-paper

Summary

---
name: ljg-paper
description: "Explain research papers to readers without a specialist background: what the paper studies, what the authors contribute, how the findings follow, and what the evidence does not establish. USE WHEN the user shares an arXiv link, paper URL, PDF, local paper, or paper title, or asks to read, explain, analyze, or understand a paper. Defaults to a saved Org note. NOT FOR reproduction, formal peer review, benchmark tables, or literature surveys."
---

# ljg-paper：讲清论文，让读者理解结论是怎样得来的

默认读者有一般生活经验和理解能力，但不熟悉论文所属行业，也不知道该行业常用的对象、工具和工作方式。用户指定了读者背景时，以其指定为准。

从读者能够直接理解的事情出发，讲清谁在什么条件下做了什么、为什么遇到困难、作者改变了哪个环节，以及结果怎样变化。专业名称在有助于识别论文贡献时引入；读者在记住名称之前，应已理解它指向的事情。

读者最终既能用普通话解释论文的思想，也能说清作者实际研究了什么、做出了什么贡献。生活案例承担解释时，应明确对应论文中的角色与关系，并区分假想示例和真实实验。

全文应围绕清楚的问题展开，让读者跟着观察、疑问与检查理解研究怎样发生。具体对象和动作应持续承担解释；随着解释深入，可以更换案例或场景，但要交代它补充了什么。现场感来自与理解有关的细节，不靠虚构心理或夸大结论。

当关键关系需要读者在脑中自行拼装时，优先考虑 ASCII 图来呈现信息流向、前后状态或不同维度，再沿具体例子读图。是否用图、用几幅，由它能否减少理解负担决定，不固定故事或图数。

## Workflow Routing

| 输入 | 必读材料 | 输出 |
|---|---|---|
| arXiv、PDF、论文链接、本地论文 | `ReadingGuide.md`、`references/template.org`、`references/paper-map.md` | 一份 Org 解读笔记和一份 paper-map 研究记录 |
| 只有论文标题 | 找到可靠原文后，读同一组文件 | Org 笔记和 paper-map |
| 明确只要口头解释 | `ReadingGuide.md` | 直接解释，不保存文件；仍满足下面三个目标 |

Org 默认保存到 `~/Context/`。文件名沿用 Denote：`{YYYYMMDDTHHMMSS}--paper-{方法名或论文关键词}__paper.org`；时间戳由 `date +%Y%m%dT%H%M%S` 生成。改写已有笔记时，保留原文件与 identifier，核对原文，不另建重复笔记。

## 解读要达到的三个目标

- **说清论文做了什么。** 读者能说出研究问题、作者的主要贡献、方法或关系如何起作用，以及关键证据的适用范围。读到前两节时，就应知道论文在研究什么、作者做了什么。论文中不可省略的研究问题也要有所交代。
- **让读者理解为什么需要修正原有认识。** 从具体问题出发，说明通常会怎样理解，再用论文证据展示这种理解哪里不够、作者补充了什么、判断因此发生了什么变化。变化可以是纠正，也可以是补充、区分或缩小适用范围，无须制造戏剧性的反转。
- **让读者能够自己解释结果。** 如果论文提出了能解释多个发现的机制，读者应能用它说明至少两个不同发现，并推想改变相关条件后会发生什么。区分论文验证过的结论与依据机制作出的预测。论文没有统一解释时，如实说明各项发现之间的关系和仍未解决的问题。

三个目标分别检查。讲得流畅、内容准确、能够解释结果，各有要求，不能相互替代。

## 容易出错的地方

- **案例讲清了，论文仍可能没讲清。** 读者说不出研究问题或主要贡献时，回到原文重新组织解释。只修句子无法补上缺失的内容。
- **行业内的浅显说法，对外行仍可能陌生。** 例子本身也要符合读者起点。把术语换成另一组行业词，或讲完例子立刻回到专业概述，都会让读者重新承担翻译的工作；应让具体动作继续解释后面的关系。
- **不要强迫一个例子讲完整篇论文。** 一个案例说明不了所有研究问题时，可以换例子，保持问题与解释的联系。
- **贡献要说具体。** 写出作者提出的方法、理论、评测、资源或系统具体增加了什么。评测发现差异，不等于已经解释差异的原因。
- **重点突出，也要保留重要分支。** paper-map 记录每条必要研究主线及其证据；正文说明它们如何共同回答论文的问题，不能把整篇论文缩成一个中心实验。
- **按信息作用取舍证据。** 优先讲清最有代表性的结果。补充结果应提供不同信息、限制结论或解释例外；不按实验数量平均分配篇幅，也不强求全文只写一种结果。
- **数字需要上下文。** 交代实验在问什么、固定了什么、和谁比较，再说明结果改变了哪个判断。把数字拆成短段，或全部写成汉字，都不能代替解释。
- **章节可以递进，也可以并列。** 换序用于检查联系是否清楚。两个独立实验可以交换顺序，但应说明它们分别支持什么、为什么都需要。
- **检查工具只能检查格式与记录。** 它不能证明文章易懂。理解检查由未参与写作的新上下文完成，评估者只读最终笔记，并按 `ReadingGuide.md` 指出需要回读、补背景或自行补画面的地方；有图时核对图意，不能只凭能复述就判易读。

## 示例

**方法论文：** 用一个小任务说明旧做法卡在哪里，再解释新方法如何处理输入、经过哪些关键步骤、得到什么结果。中心实验说明比较条件与动作差异，结尾交代改善发生在哪一步，以及哪些情况仍未验证。

**评测论文：** 两个系统在旧指标上表现相近，新评测发现了原先没有区分的差异。解释新评测测量什么、代表性对照显示了什么，以及这些差异能支持哪些判断。不要把测量结果直接写成现实中的因果结论。

## 保存与检查

具体写法见 `ReadingGuide.md`。正文使用 `references/template.org`，研究与取舍记录使用 `references/paper-map.md`。新记录使用格式版本 3；验证脚本兼容旧版本 1、2，旧记录不必为了本次升级批量改写。

写入后运行：

```sh
bun {skill_dir}/scripts/validate_note.ts /absolute/path/to/note.org \
  --map /absolute/path/to/paper-map.md
```

用真实 Emacs 读回 identifier、文件名、目录索引、consult-notes 与 `org-lint`。再按指南完成独立阅读检查，记录全文复述、研究问题与贡献、认识变化、结果解释四项结果。全部通过后重新运行脚本，确认最终文件与检查记录一致。

验证脚本接受尚未填写阅读检查结果的记录用于诊断，但会返回失败；不能先写 PASS 再请人检查。验证器或独立评估不可用时，明确报告哪项尚未完成。

Security audits