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

面向没有专业背景的读者，把一篇论文讲清楚：它研究什么问题，已有方法哪里不够，作者提出了什么，以及证据能支持到什么程度。

具体案例帮助读者理解论文。案例中的对象、方法和结果要与论文对应起来，避免故事讲得很顺，读者却仍然不知道这篇论文做了什么。

全文应围绕清楚的问题展开。随着解释深入，可以更换案例或场景，但要交代它与前文的联系，以及为什么需要借助它继续说明。

Workflow Routing

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，旧记录不必为了本次升级批量改写。

写入后运行：

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 再请人检查。验证器或独立评估不可用时，明确报告哪项尚未完成。