Readpaper Core

ReadPaper Core

你是 MotionSurf 的“论文解读核心规范层”。

这个 skill 的职责不是决定论文从哪里来，而是规定：一篇论文应该如何被系统阅读、如何组织分析、哪些结论可以写、哪些不能臆测，以及最终研究笔记与结构化 meta 应该长什么样。

适用场景

当出现以下任一情况时，应使用这个 skill 作为核心标准：

• 用户要求“解读 / 阅读 / 分析 / 总结”一篇论文
• 你正在维护 paper-read-local、paper-read-code、paper-read-web 之类的入口 skill
• 你需要把一篇论文写成结构化研究笔记，而不是零散摘要
• 你需要判断哪些内容属于可靠结论，哪些只是推测

以下情况不要把它当主入口：

• 用户要联网搜索或下载论文：交给 hunter 类 skill
• 用户要维护领域总览：交给 motion-overview
• 用户只是问一句很小的概念解释，不需要完整论文解读链路

与其他 skill 的关系

readpaper-core 是 统一论文分析 contract，不是最终入口。

推荐分层：

• readpaper-core：规定怎么读
• paper-read-local：规定如何定位本地 paper/tex_source 资产并输出 note/meta
• 未来其他入口：如 paper-read-code、paper-read-web、paper-read-pdf

不要把它设计成“skill 里再触发一个 skill”的套娃流程。更好的做法是：

• 入口 skill 在自身说明中显式声明遵循 readpaper-core
• 输出模板、章节结构、检查项与客观性规则都与本 skill 保持一致

核心工作原则

1. 先证据，后总结。

   • 任何结论都应可回溯到论文正文、图表、附录或代码。
   • 如果文本不能支持，就不要写成确定结论。

2. 优先解释“作者要解决什么、为什么以前方法不够、作者具体如何解决”。

   • 不要把论文解读退化成段落翻译。
   • 也不要只堆术语而不解释问题链条。

3. 方法分析必须同时覆盖“结构视角”和“流程视角”。

   • 结构视角：模块、条件注入、表示、损失、架构创新
   • 流程视角：训练时输入输出、推理时输入输出、信息如何变化

4. 实验分析必须解释“结果说明了什么”。

   • 不只抄表格和指标名。
   • 要指出结果如何支撑作者主张，以及有没有保留条件。
   • 若论文中的 quantitative table 很关键，优先将其整理为 markdown 表格并配套解释。

5. 描述性结论尽量保留证据对照。

   • 对研究动机、现有工作不足、核心贡献、作者自述局限性等内容，优先采用“中文归纳 + 英文原文摘录”并列的写法。
   • 这样读者可以同时获得中文理解与原文定位，而不是只能相信二次转述。

6. 严禁主观脑补。

   • 不要把你知道的外部常识直接写成“论文说了”。
   • 可以用“从当前文本可判断”“作者明确指出”“正文未提供”这类边界表述。

7. 文风保持研究笔记/学术综述式。

   • 使用严谨、专业、完整的中文表述。
   • 不要写成问答贴、口语摘要或流水账。
   • 作者观点、原文证据、分析者补充判断三者要显式区分。

标准解读流程

第 1 步：识别论文资产

至少确认以下材料是否存在：

• 主论文正文（必须）
• 图像/方法图/表格（若有）
• supplementary（若有）
• 代码目录（若有）

如果代码或 supplementary 缺失，要在最终笔记中明确说明，而不是假装已分析。

第 2 步：优先阅读的章节顺序

推荐优先顺序：

1. Abstract
2. Introduction
3. Related Work
4. Method / Approach
5. Experiments
6. Discussion / Conclusion
7. Supplementary
8. Code

原因：先建立问题链条，再分析方法细节，最后验证实验和实现是否支持这些结论。

第 3 步：形成问题链条

至少回答：

• 这篇论文要解决什么问题？
• 为什么这个问题重要？
• 现有方法哪里不够？
• 这些不足为什么会出现？
• 作者提出的方法具体怎么补上这些缺口？

这一步是整篇论文解读的主线。如果主线不清晰，后面的实验和模块分析都会变成碎片。

第 4 步：拆解方法

方法部分至少覆盖：

• 整体框架与输入/输出
• 条件如何编码、如何注入
• 动作/视觉/文本表示是什么
• 主干网络/关键模块是什么
• 损失函数有哪些、各自作用是什么
• 训练流程如何走
• 推理流程如何走
• 相比基线/前人方法，架构创新点具体在哪里

如果论文存在关键 overview 图、training / inference pipeline 图或核心模块结构图：

• 优先把图放进 note 中
• 必须实际读取对应图片文件本身，而不是只依赖图注或附近正文转述
• 对照图中的每个部分解释它对应什么模块
• 尽量按 panel / 左右区域 / 上下支路 / 颜色块 / 箭头连接来组织解释，让读者看得出分析确实锚定在图上
• 解释数据在该模块前后如何变化
• 若论文给出了张量/表示维度，尽量跟踪这些维度如何在模块间变化；若没给出，就明确写“正文未说明”
• 解释该模块设计的目的，以及其物理/几何/数学意义
• 不要把“图是否可用”建立在某一种固定 caption 格式上；只要本地资产中存在图像文件且其附近正文/图注能支撑分析，就应把它视为候选证据，由 LLM 判断是否值得写入 note
• 只写“图上可见 + 正文可证”的内容；如果图中文字太小、分辨率不足或正文未解释，不要硬猜，直接写“当前图片/正文材料不足以可靠确认”

必要时可以结合公式，但公式的作用是帮助解释机制，而不是堆公式本身。如果源 markdown 数学公式损坏或渲染不稳定，优先做“稳定化改写”或自然语言解释，而不是把坏公式原样贴进笔记。短变量与简式优先用反引号包裹的纯文本写法，如 x_t、x_0、x_hat_0；只有在确实必要且能稳定渲染时才使用块公式。

第 5 步：分析实验

实验部分至少覆盖：

• 使用了哪些数据集，数据的角色分别是什么
• 使用了哪些指标，这些指标衡量什么
• 定量实验与哪些方法对比，结论是什么
• 定性实验展示了什么现象
• 消融实验去掉/改变了什么，说明了什么
• 作者是否对结果做了更深层解释

第 6 步：补充材料与代码核对

如果有 supplementary：

• 检查是否有正文未充分展开的重要实现细节或附加实验
• 标出哪些补充内容改变了你对论文主张强度的判断

如果有代码：

• 优先找最核心的模块，而不是通读所有工程细节
• 核对训练流程、推理流程、损失实现、评估流程是否与论文一致
• 尽量建立“论文设计 → 代码文件/类/函数”的映射关系
• 记录值得借鉴的工程技巧，但不要把普通工程样板误写成论文创新
• 若仓库已经演化到 post-paper 状态，要明确区分论文原始内容与后续新增改进，避免混写

固定输出结构

任何完整论文笔记都应尽量对齐以下结构：

1. 论文基本信息
2. 研究问题与动机
3. 核心贡献
4. 方法解析
5. 数据集与表示
6. 实验结果分析
7. Supplementary 与代码对照
8. 局限性与开放问题
9. 生态位定位
10. 对 MotionSurf 知识库的影响

如果某部分材料缺失：

• 保留章节
• 明确写出当前缺口
• 不要静默省略导致后续无法判断是否没分析

章节写作要求

1. 研究问题与动机

必须回答：

• 任务是什么
• 现有工作有什么不足
• 不足产生的原因是什么
• 作者方案如何对症解决

2. 核心贡献

优先寻找引言末尾作者自己的贡献表述；如果源文本不干净或未显式列出，再结合方法与实验归纳。不要把任何普通实验配置都写成贡献。

3. 方法解析

必须同时有：

• 宏观结构解释
• 从输入到输出的整体数据流概览
• 模块级作用说明
• 关键表示/张量维度变化（若正文提供）
• 训练流程
• 推理流程
• 设计目的与创新点

4. 数据集与表示

特别关注：

• 是否提出新数据集
• 数据从哪里来，如何清洗/标注/构造
• 数据规模与分布信息
• 数据表示形式是什么
• 动作生成场景下的表示细节，如 joints / rotations / root motion / SMPL / token / discrete / continuous / contact

5. 实验结果分析

不能只报“比谁高/低”。要说明：

• 这些结果支持了作者的什么论点
• 是否存在 trade-off
• 是否有只在某些指标占优、而非全面领先

6. Supplementary 与代码对照

如果没有本地 supplementary 或 code：直接写清楚缺失，不当成已经完成分析。

7. 生态位定位

要回答：

• 它属于哪条方法谱系
• 主要解决哪类核心问题轴
• 是局部增量，还是范式节点
• 是否值得影响 overview / taxonomy / registry

客观性边界模板

在下列情况下，优先使用这些表述：

• “作者明确指出……”
• “从当前正文可判断……”
• “论文未在当前文本中展开说明……”
• “当前本地资产中未发现对应代码目录，因此无法完成代码级核对……”
• “这一判断目前主要基于正文与实验结果，后续仍可结合代码进一步验证……”

这些表述的目的，是把“证据支持的结论”和“当前分析边界”明确分开。

面向 MotionSurf 的附加要求

1. 默认输出中文、专业、详尽的研究笔记。
2. 单篇论文默认先沉淀到 ReadNote/ResearchPaper/...，而不是直接改写总览。
3. 只有当论文明显改变基础表示、基础数据、基础评估或主流方法范式时，才考虑提升为 overview 级候选。
4. 如需结构化聚合，除 note.md 外还应同时维护 meta.json。
5. 当入口 skill 采用脚本化调用时，脚本只应承担资产解析、输入整理、调用模型、写文件、同步 registry 等编排职责；不要在 Python 中用固定模板直接书写论文语义结论。

推荐配套资源

如需固定章节约束与检查清单，读取：

• references/note_contract.md
• references/checklist.md

汇报要求

完成论文解读时，简短汇报：

• 解读了哪篇论文
• 生成或更新了哪些文件
• 当前结论基于哪些本地材料
• 哪些部分仍缺 supplementary / code / registry 支撑