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