# Paper Read Brief > 将论文整理成中文速读精要。用于用户给出 arXiv、PDF、论文网页、HTML、截图或论文文本，希望得到比摘要更可靠、比 paper-read 完整精读更短的版本：沿原论文每个章节和小节提取最核心、最重要的观点、方法机制、图表公式要点和关键结论；实验部分只压缩提炼实验目的、关键结果和作者想证明的结论，不逐表逐数字细讲，只有实现步骤或设置细节影响理解时才提炼。 - Skill: `limouren2000/paper-read-brief` (Agent Skill, multi-file: 21 files) - Install (CLI): `npx skillmds@latest add limouren2000/paper-read-brief` - Raw SKILL.md: https://api.skillmd.com/api/skills/limouren2000/paper-read-brief/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: limouren2000 (https://skillmd.com/u/limouren2000) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/limouren2000/paper-read-brief --- # Paper Read Brief 把论文读成一篇“沿原文结构逐节提炼核心内容”的中文速读精要。这个 skill 是 `paper-read` 的缩略版：保留忠实原文、完整阅读、按章节顺序、解释关键图表公式的底线，但输出明显更短，目标是让读者快速看到论文每个部分的核心内容和思想推进。 ## 核心定位 使用这个 skill 时，产出不是整篇论文维度的大摘要，也不是完整精读长文，而是“逐章节核心提炼”： - 按原论文主文顺序推进，不重组成自己的主题大纲。 - 每个一级/二级部分都要单独提炼最核心的观点、方法、证据和结论。 - 重点讲清该部分解决的问题、提出的机制、最重要的发现，以及它如何推进论文主线。 - 少写铺垫和长篇背景，不做段落级完整扩写。 - 图表和公式只保留对理解主线必要的部分，但不能跳过关键总览图、关键方法图、关键公式。 - 实验部分默认比方法和背景更压缩：只讲实验目的、核心对比、最关键数字和结论指向，不逐表逐数值展开。只有原文明确给出实现步骤、实验流程或设置细节，且这些细节有助于理解结论时，才提炼重点；否则直接给出实验结论。 - 核心贡献部分是速读版里最需要保留细节的部分。它不一定叫 `Method`，也可能叫 Approach、Model、Framework、System、Algorithm、Architecture、Theory、Preliminaries、Implementation 或其他名字。即使整体输出要短，也要识别论文真正提出新东西的部分，把核心机制、关键模块、算法流程、输入输出、公式含义、模块关系和设计动机讲清楚，不能只概括成几句结论。 如果用户明确要求“完整精读”“长文解读”“像 DiT 那样详细讲”，应使用 `paper-read`，不要使用本 skill。 ## Workflow 1. 完整读取论文正文，确认标题、任务、核心问题、方法主线、关键模块、主要图表公式和实验结论。 2. 写作前建立原文骨架：主文一级/二级标题、关键图表编号、关键公式编号、实验小节和结论。同步建立关键图片清单，记录图表编号、caption、所在页码、准备插入的正文位置和本地文件名；关键图不能只写 caption 而不获取图片。 3. 按原论文顺序输出中文速读精要。一级标题保留原文编号并中文化，二级标题可改写成中文解释型标题。 4. 每个章节和重要小节都要保留独立提炼，不要只在整篇论文层面做总体概括。每个部分只保留最重要内容：核心观点、关键机制、必要证据、关键结论和与主线的关系。 5. 对核心贡献部分保留更高密度解释：先识别论文真正的新方法、新框架、新模型、新系统、新理论或新算法在哪里，再按原文小节解释每个核心模块的作用、输入输出、流程关系、关键公式和为什么这样设计。核心贡献部分宁可比其他章节稍长，也不能牺牲读者对论文贡献的理解。 6. 对实验部分按原小节顺序压缩提炼：实验目的、baseline 或对比对象、最关键结果、作者想证明什么。不要把实验写得比核心贡献部分还细；如果原文没有值得保留的实现步骤或设置细节，直接写结论；除非用户明确要求，不做逐表逐数字展开。 7. 附录默认不展开；只有 prompt、算法细节、实现配置、失败分析等对理解主方法必要时，补到对应位置。 8. 自检输出是否足够短：如果变成逐段长文讲解，就压缩；如果只有摘要口号，就补上关键机制和证据。 ## Default Output 默认输出一篇中文速读精要，建议结构如下： 1. 开头用 1 到 2 段说明论文题目、任务、核心问题、提出的方法或发现，以及为什么值得读。不要单独列 `Paper` 元信息清单，除非用户要求。 2. 写一个简短的 `核心问题` 或 `核心结论` 小节，用连续段落说明：这篇论文想解决什么、核心答案是什么、最关键改造或发现是什么。不要使用 `一句话先看懂` 作为标题。 3. 正文必须有清晰标题层级，但默认不要额外写出一段 `目录` 清单。直接按原论文顺序进入正文；如果原文有摘要，保留一个简短的 `## 摘要` 提炼，再进入 `## 1 引言`、`## 2 相关工作`、`## 3 核心框架`、`### 3.1 思维分解` 等正文标题。标题中文化，除方法名、数据集名、指标名、算法缩写和确实不宜翻译的专有名词外，优先使用中文表达。 4. 正文按原文顺序展开，标题层级本身就承担目录作用，不要在开头重复列出所有章节名。 5. 一级章节和重要二级小节都要有自己的核心提炼。不要只写“整篇论文主要讲了什么”，要让读者顺着正文标题看到每个部分贡献了什么。 6. 核心贡献章节要比实验章节更充分。默认写出贡献总览、关键模块拆分、核心流程、重要公式/算法、模块之间如何衔接，以及该设计解决了旧方法的什么限制。不要机械等待章节标题叫“方法”；根据内容判断哪里是真正的核心贡献。 7. 每个小节优先使用短段落，也可用 3 到 5 个高密度要点。不要写成松散提纲，每个要点都要包含具体信息。 8. 结尾写一个短总结，提炼论文价值、适用边界和可能局限。 ## 标题层级 最终产物必须有清晰正文标题层级，不能只用加粗文本模拟章节。默认不要额外写出一段 `目录` 清单，除非用户明确要求。 - 使用 Markdown 标题组织正文，例如 `## 核心问题`、`## 摘要`、`## 1 引言`、`### 3.1 思维分解`。 - 标题层级要按原文顺序展开，直接让读者通过正文标题看到文章结构。 - 正文标题保留原文编号和顺序，但标题文字要中文化；除方法名、数据集名、指标名、算法缩写和确实不宜翻译的专有名词外，优先使用中文表达。 - 不要用连续的 `**加粗标题**` 代替章节标题；加粗只用于局部强调。 ## 每个部分怎么写 每个论文章节或重要小节尽量压缩成下面几类信息： - `核心观点`：该部分最重要的一句话是什么。 - `关键机制`：如果该部分提出方法、模块、算法或定义，说明输入、输出、作用和它与其他模块的关系。 - `关键证据`：如果该部分依赖图表、公式、实验或理论分析，提取最能支撑主线的证据。 - `主线作用`：说明该部分如何推动论文主线，或为什么后文需要它。 不要机械地每节都列四个标签；当自然段更顺时，用自然段表达。标签只是一种压缩思路。重要的是每个原文部分都有自己的核心信息，而不是把所有内容汇总成一段总评。 ## 核心贡献部分 核心贡献部分通常是论文最重要的内容，速读版也必须写得足够清楚。这个部分不一定叫“方法”，可能出现在 `Method`、`Approach`、`Model`、`Framework`、`System`、`Algorithm`、`Architecture`、`Theory`、`Implementation`、`Preliminaries` 或论文自定义标题中。不要把它压成“作者提出了某某框架，包含若干模块”这种空泛表述。 - 先给出核心贡献总览：输入是什么、输出是什么、整体流程如何从输入走到结果，或理论/系统贡献从什么假设推到什么结论。 - 按原文方法小节解释核心模块：每个模块解决什么问题、接收什么输入、产生什么输出、与前后模块如何连接。 - 保留关键公式、算法或伪代码的主干。公式不必长篇推导，但要解释主要符号、每一项的作用，以及公式在方法流程中的位置。 - 对架构图、流程图、算法图要讲清信息流和模块关系；如果是整篇论文的主图，核心贡献部分要围绕它展开。 - 解释设计动机：为什么旧方法不够，为什么这里要引入这个模块或步骤。 - 如果方法有多个可替换组件或变体，说明每个变体适用什么场景，不需要穷举所有实验配置。 - 核心贡献部分允许比其他章节更长；压缩优先级应低于实验、相关工作和附录。 ## 实验部分 实验部分要保留原文实验小节顺序，但默认压缩，不要像核心贡献部分那样细讲每个表格、每个数字或每个实验配置。 - 每个实验任务优先写：任务想验证什么、最关键结果、结果说明什么。 - 如果原文提到实现步骤、实验流程或关键设置，并且这些细节影响读者理解结果，再提炼 1 到 3 个重点，例如 thought 如何定义、搜索策略怎么选、评估信号是什么。 - 如果实验实现细节不重要、原文没有展开，或展开后只会稀释主线，就跳过设置细节，直接写结论。 - 只保留最能支撑论文主张的数字。一个表里如果数字很多，挑最关键的 2 到 4 个，不要整表细讲。 - 消融实验只提炼结论指向，例如“剪枝重要”“回溯重要”“瓶颈在生成而不是评估”，不需要展开所有配置。 - 如果实验部分很长，允许把多个相似实验压成一段，但不能打乱原文小节顺序。 ## 图表和公式 图表和公式要服务速读，不要把所有图表都完整展开。 ### 图片获取、保存与插入 - 关键总览图、方法图和支撑核心结论的关键实验图，默认必须实际获取并嵌入 Markdown，不能只保留 `Figure N`、caption 或文字解释。 - 获取图片时优先使用论文官方 HTML、arXiv 源码或作者项目页提供的原始图片资源；使用前必须与 PDF 中的图号、caption、面板数量和图内内容核对一致。拿不到可靠原图时，再从官方 PDF 中截图。 - 从 PDF 获取图片必须使用“整页定位 -> 高分辨率渲染 -> 按内容边界裁剪 -> 重新打开核验”的流程： 1. 根据图表编号、caption 或正文引用定位 PDF 页码，先查看完整页面，确认图表本体、caption、脚注和相邻正文的真实边界。 2. 将对应页面高分辨率渲染后再裁剪；不要使用模糊预览图，也不要直接保留包含大量正文的整页截图。默认只保留图表本体，caption 在正文中单独翻译和解释。 3. 完整保留全部面板、坐标轴、图例、标签、箭头和图内说明；表格必须保留表头、全部列、最后一行、必要脚注和底部边框。 4. 裁剪后以原尺寸重新打开图片，与 PDF 原页并排核验。发现缺面板、缺行列、标签截断、边框消失或混入无关正文时，必须重新裁剪。 - 图片统一保存在**论文解读 Markdown 文件同级的 `images/` 文件夹**。例如： ```text examples/ ├── Tree of Thoughts 速读精要.md └── images/ ├── tree-of-thoughts-figure-1.png └── tree-of-thoughts-figure-2.png ``` - 同一目录可能包含多篇论文，文件名必须带论文短名并按原编号稳定命名：`paper-slug-figure-N.png`、`paper-slug-table-N.png`；多面板图拆分时再增加 `-a`、`-b` 等后缀。不要使用时间戳、随机字符串或 `image1.png` 这类无法辨认来源的名称。 - 在 Markdown 中使用相对路径插入图片，图片放在中文图注和解释之前： ```markdown ![图1：Tree of Thoughts 框架总览](images/tree-of-thoughts-figure-1.png) > 图1：完整中文图注。 解释：说明图中的核心模块、信息流和关键结论。 ``` - 写完后必须逐项检查：Markdown 引用目标真实存在；文件名与图号一致；图片不是整页截图；原尺寸下文字清晰；没有截断面板、坐标轴、图例、标签、表格行列或边框。 - 如果确实无法可靠获得某张图片，必须明确说明获取受限，并只引用图号和可确认的 caption 信息；不能用猜测性重绘或无来源图片冒充原图。 ### 图表解释与公式 - 关键总览图、方法图必须讲；核心实验表只保留支撑主结论的数字和结论，次要消融或补充图表可合并概括。 - 读图时不要只依赖 OCR 或 PDF 文本抽取；遇到流程图、多面板图、复杂表格时，尽量查看原图、页面渲染或截图，避免把行列、箭头和模块关系读错。 - 解释图时直接讲图中内容、模块含义、信息流和结论，不要写“图是两行三列结构”这类纯结构描述。 - 关键图表仍按三段式处理，但可以比 `paper-read` 更短： 1. `Figure 1. ...` / `Table 1. ...` 保留原文 caption 英文表述。 2. `> 图1：...` / `> 表1：...` 给出完整中文翻译，并使用 Markdown 引用块包起来。 3. `解释：...` 用几句话讲清图表最重要的信息、模块关系或结论。 - 关键公式保留 LaTeX 原式，并解释主要符号和公式在方法里的作用。 - 非关键公式可只说明它定义了什么量、服务哪一步，不必逐项展开推导。 ## 写作规则 - 用中文写。 - 术语表达中文优先。凡是正文中第一次出现且需要保留英文的术语、方法名或专有名词，都必须给出对应中文解释，优先写成 `中文（English）`；后文默认使用中文或通用缩写，不要反复中英双写。 - 避免不必要的中英夹杂。普通概念、动作、机制、流程、模块、实验设置、结论表述优先翻译成中文；只有方法名、数据集名、指标名、算法缩写、代码接口名，或中文翻译不通用/容易误解时，才保留英文。 - 不要出现半中半英的生硬表达，例如 `动作s`、`推理 chain`、`heuristic 函数 design`、`prompt scheme`。应改成 `动作`、`推理链`、`启发式函数设计`、`提示方案`。 - 关键核心句要适当加粗，尤其是核心问题、核心答案、关键改造、主要贡献、关键实验结论和重要局限。加粗要克制，只强调真正需要读者抓住的句子或短语，不要整段加粗。为兼容不同 Markdown 软件，句号、问号、冒号、逗号、分号等标点不要包进加粗范围，写成 `**核心句子**。`，不要写成 `**核心句子。**`。 - 忠实原文，不虚构实验、数据集、指标、结论、引用或图表含义。 - 不要把“论文提出的方法”“实验评测设置”“应用例子”混在一起。 - 不要提前透支后文结论；按原文顺序逐步交代。 - 不要写成只有标题和空泛判断的提纲式摘要；每节都要有具体机制或证据。 - 不要写成完整精读长文；如果某节开始出现大段背景铺陈，压缩到最核心的信息。 - 减少明显的“解读痕迹”。不要频繁使用“这一节/这一部分/本节主要/这一节真正想说的是/这一节的核心是”等模板句。优先直接写内容，例如“现有方法的限制在于……”“ToT 将状态定义为……”“实验验证的是……”。 - 保留自然的章节承接，但不要每段都用元话语解释自己正在解读哪个部分。 - 遇到“第一是……”“第二是……”“核心问题是……”“关键区别在于……”这类标签式引出，如果后面紧接解释内容，优先用逗号承接，不要用句号把话题标签和解释切断。 ## 输出长度控制 默认总长度控制在完整 `paper-read` 精读的三分之一以内。用户要求更短时，可以进一步压缩成“每节 3 个要点”；用户要求更详细时，只适度扩写，除非用户明确切换到完整精读。