paper-details

论文详情

关于撰写学术论文详细 Markdown 解读文档的规范。本技能旨在准确描述论文，而非对其进行批评。

本技能遵循 documenting-with-sources 中定义的通用来源写作规范。请在起草前阅读 documenting-with-sources。

1. 交付文档结构

1.0 输出位置

将解读文档写入项目 reports/ 目录下的 .md 文件中，其中“项目”指包含论文源 PDF 的根目录。如果目录不存在，请创建。

• 路径：{project-root}/reports/{paper-filename-base}.md
• 示例：如果 PDF 位于 /path/to/project/papers/foo.pdf，则输出文件为 /path/to/project/reports/foo.md

请勿将文件写在 PDF 旁边，也不要写在项目根目录下。不要询问用户输出路径——请按照上述规则确定路径。

1.1 开篇

按以下顺序编写：

1. 标题（# {paper title} — Detailed Explainer）
2. 书目信息（作者、所属机构、会议或期刊、年份、arXiv/DOI、URL）
3. 完整摘要——按照 writing-quotation 的要求，在代码块中引用原文；如果原文不是工作语言，则在同一代码块中另起一段并列呈现译文。

1.2 正文部分结构

正文的章节结构应遵循论文原有结构。如果论文包含第 1 节“引言”、第 2 节“方法”、第 3 节“结果”等，解读文档也应按相同顺序使用相同标题。

仅在论文自身的章节结构之后，添加解读文档专属章节（例如“论文的优势”“论文的局限性”“来源列表”）。

1.3 项目符号列表与散文

根据内容性质选择形式。

• 项目符号列表适用于并列项目的枚举，例如变量列表、评估指标定义、表格列说明、方法间的比较要点等。内容确实适合列表时，散文形式会模糊各项之间的界限。
• 散文适用于表达关系、因果脉络和背景说明。当读者需要理解各项为何并列出现，或它们如何共同构成一个论证时，散文更能将内容连贯起来。

1.4 图和表：提取为图像

切勿从头重建图或表（不得手写 HTML 表格，也不得重新绘制 SVG 图）。请从源论文中将其提取为图像，并插入交付文件（.md 或 HTML）中。手动重建会引入转录错误并丢失原始布局——如粗体、下划线和颜色编码的图例——因此严禁这样做。

请使用此技能附带的脚本：

uv run {this-skill-dir}/scripts/extract_images.py <PDF path>

• 脚本会在 PDF 中查找 Figure N / Table N 标题，并以 300 dpi 对每个标题正上方的图或表区域进行剪裁渲染——该区域由矢量绘图、线条和嵌入图像的边界框确定。图和表通常以矢量形式绘制，不含嵌入的栅格图像，因此提取方式是区域渲染，而非提取嵌入图像。
• 默认输出到 {project-root}/images-from-papers/，文件名为 {paper-filename-base}-fig{N}.png / {paper-filename-base}-table{N}.png。提取清单记录在同一目录下的 {base}-manifest.json 中。
• 多面板浮动对象（例如，一个表格浮动对象包含面板 (a)–(f)）会作为单张图像提取，与论文中的单个浮动对象保持一致。
• 提取完成后，将 images-from-papers/ 中的图像插入交付文件。在 .md 中，请使用相对路径引用，例如 ![Figure N](../images-from-papers/{base}-fig{N}.png)。使用 html 创建的 HTML 交付文件可以将图像嵌入为 base64 data URI。
• 在图像下方另起一段添加译文标题。图像内的标题文字保留原文（不重新绘制），因此译文应放在图像外。
• 如果脚本偶尔漏掉图或表，或包含了过多边距，请提高 --dpi，或检查输出并调整相应项目的 pymupdf 剪裁矩形。无论如何，都不要放弃图像提取方案。

2. 引用与来源标注

2.0 输出以译文引文块为核心

说明文应主要由“原文引文 + 译文”块构成，完整覆盖论文正文。不要以概述或转述为主。全文应让读者始终能够对照原文与译文。

说明文——即作者自行撰写的文字——只是对引文主导结构的补充，仅在以下情况下添加：

• 引文块之间的衔接不清楚，需要说明各章节或段落之间的关系或逻辑脉络。
• 补充说明（变量定义、必备知识、如何阅读某个图或表、术语首次出现时的定义）确实有助于读者理解。

不符合上述情况时，不要用说明文重新概述原文；让引文块本身说明内容。不要陷入“引文传达大意、说明文负责总结”的模式。

为了准确传达论文的观点，请直接引用原文。仅有摘要无法让读者判断作者的解读是否正确。

在 documenting-with-sources 中定义的 [label (YYYY/MM), location] 结构内，paper-details 技能会根据引用的作品不同，以不同方式填写 label 部分。

引用正在解读的论文

引用正在解读的论文时，省略作者和年份，仅标注位置，格式为 [p.X, Section Y.Z]。由于整篇说明文围绕单篇论文展开，无需每次都重复作者姓名。

示例：[p.4, Section 1]、[p.21, (15)]、[p.31, Figure 2]。

引用其他作品

对于论文引用的其他作品，正文中请使用 [作者简称（YYYY）]。

• 标明具体位置，包括章节、页码、表格或图号。
• 不要用“……及其他人”之类的说法缩略引用作品列表。请逐一列出每部作品及其作者和年份。解读文章的读者依赖此列表；仅引用解读文章所依据的论文，并不能代替列出该论文引用的作品。

3. 公式

3.1 语法

• 公式使用 LaTeX 编写。行内公式使用 $...$，独立公式使用 $$...$$。
• 禁止将公式放在代码块中。禁止以纯文本、伪代码或任何非 LaTeX 语法形式书写公式。

3.2 变量定义

公式中的每个符号，在定义之前对读者来说都是未知的。呈现公式前，请定义其中出现的每个变量和符号。变量尚未定义时，不得呈现公式。

在公式较多的章节（理论、方法形式化）中，请在章节开头放置变量表，并按用途对变量分组。每项包括：

• 符号（使用 LaTeX）。
• 含义（一句话说明）。
• 有助于直观理解的注释（具体示例、取值范围、特殊情况下的行为）。

示例：

Inputs:

- $n$: number of characters in the input text. The length of the user's prompt.
- $K$: the model's context-window length in characters. Inputs longer than this cannot be passed to the model directly.

Planner outputs:

- $k^*$: branching factor at each level — how many chunks to split into. With $k^*=5$ the input is split into five chunks at each level.
- $\tau^*$: threshold below which the chunk is sent to the LLM as-is, without further splitting. With $\tau^*=26{,}000$, chunks of 26,000 characters or fewer go straight to the LLM.

公式较少的章节中，可以在每个公式前后就地定义变量，但仍须遵循公式中不能出现未定义符号的原则。

4. 数值结果

• 尽可能使用表格呈现实验结果。
• 将所提方法与基线并排列出。
• 按照论文中的原样转录数字。不要四舍五入或近似处理。
• 展示表格前，请在前面的项目符号列表中定义每一列和每项指标。读者看到数字时，应已清楚每一列的含义。
• 不要宽泛地使用“准确率”或“性能”等通用词语。请使用论文定义的具体指标名称（分类准确率、通过率、pass@1 等）。
• 如果论文在不同语境中以不同含义使用同一个词（例如，某个方法名称在表格中表示“单次最佳结果”，但在正文中表示“整个流程”），请明确指出这种一词多义现象。

5. 描述实验

5.1 详细说明流程

在实验章节中，读者必须能够了解实际执行的操作。不要省略：

• 具体任务步骤（输入是什么、每一步产生什么、最终输出是什么）。
• 数据划分结构（搜索集／验证集／测试集——各自的用途，以及哪些结果对应哪个划分）。
• 搜索或优化流程（初始状态、迭代次数、每次迭代生成的内容，以及根据什么标准选出最终结果）。

5.2 各章节相互独立

每个实验章节都应能独立阅读。不要用未说明的缩写回指“第 X 节中定义的方法”。即使两个实验共用搜索流程，也要在各自章节中根据实验参数重新说明。

5.3 细节粒度一致

论文包含多个实验章节时，各章节的细节程度应保持一致。不要在一个章节中详尽说明搜索流程，却在另一个章节中用一句话带过。

5.4 使用前先定义概念

解读文章中每个概念首次出现时，都要先定义再使用。不要遗漏论文本身定义的概念。尤其是在呈现表格或数字之前，请确保阅读这些内容所需的所有概念均已定义。

6. 来源列表

在解读文章末尾按照 documenting-with-sources 的格式放置来源列表。除了评述的论文之外，还要列出解读文章提及的所有其他作品。

7. 按章节进行子 Agent 审核

初稿通常会包含单次重读难以发现的错误：数字抄错一位、引文编号对应到错误的参考文献、译文偏离原文含义，或论文中的引文未被纳入解读。在将初稿视为完成前，应使用子 Agent 按章节审核。

7.1 输出位置

将审核结果写入 {cwd}/subagent-reviews/{NN-section-name}.md，每个章节一个文件。如果目录不存在，请创建。审核结果应作为独立文件，与解读文档分开；不要将其放在 reports/ 下。

7.2 章节划分

将解读文档拆分为与论文结构对应的独立单元：

• 摘要和书目信息（一个单元）
• 论文正文中的每个顶级章节（引言、背景／相关工作、方法、实验、局限性、结论等）
• 解读文档末尾的来源列表

如果章节内容较多（例如实验章节包含多个子实验和表格），可以进一步拆分，以免单个审核者面对过多内容。每个文件安排一名审核者。

7.3 审核者任务说明

并行地为每个章节启动一名通用子 Agent。任务说明应要求每名子 Agent：

1. 阅读论文 PDF 和解读文档中对应的章节。
2. 核实事实准确性：论述、公式、表格中的数字和正文中的数字、引文编号与参考文献的对应关系。
3. 如果解读文档使用了非源语言，则核实翻译准确性。检查是否存在：遗漏词语、原文未表达的新增含义、不恰当的语序、未翻译的源语言习语。
4. 核实格式是否合规：引文格式（正在审核的论文使用 [p.X, Section Y.Z]，其他作品使用 [author-short (YYYY)]）、不使用 ** 加粗装饰，以及遵守 writing-quotation 中的引文规则（代码块引文、原文与译文配对、来源引用单独置于代码块外一行）。
5. 核实章节内术语是否一致。

每个审核文件使用三个标题：总体评价、发现的问题、建议修改。发现的问题应指出解读文档中的具体行或引文；对于翻译问题，应同时引用原文和解读文档中的译文，以便综合时并排比较。

7.4 综合与修改

所有审核完成后：

1. 完整阅读每个审核文件。
2. 在应用审核意见前，依据论文原文交叉核实。审核者可能出错，而且两名审核者可能对同一事实存在分歧（例如，两名审核者可能将数字引文 [16] 对应到不同的参考文献）。遇到这种情况时，请查阅论文的参考文献列表，并根据原文解决分歧。
3. 对解读文档应用已确认的修改。
4. 在不同章节应用相互关联的修改时（例如，某个引文标签的更改在全文多处出现），请确保所有位置都一致修改。
5. 发现的问题解决后即可继续，无需另写“审核意见回复”文档；经过审核的解读文档本身就是最终产物。

7.5 术语

此技能产出的文件是详细解读文档，而不是评审。审核产出是评审。与用户交流以及拟定标题时，应区分这两个术语：不要将解读文档称为“评审”，也不要将审核称为“详细解读文档”。这样可以避免用户在工作流程中途要求“更新评审”时产生歧义。