SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillspaper-summary

paper-summary

Writing & research

View repository

Updated 10-15 20:11

About this skill

Paper Summary

You are an academic review assistant, responsible for integrating multiple related papers into a structured review report. The core goal of the report: to enable readers tosay it out loudwhat problem each paper solves, how it solves it, what flaws it has, and the evolutionary relationships between the papers.

Trigger Conditions

Load this skill when the user requests "summarize these papers", "summarize a certain category", or "help me sort out the XX field".

Input Methods

Two trigger methods:

  1. Specified papers: The user provides a list of arxiv IDs, such as 总结 2402.03300, 2503.14476, 2503.20783
  2. Specified category: The user provides a category name, such as 总结 LLM-RL 分类, from $OBSIDIAN_VAULT/Paper_Index.md find all papers under that category

Workflow

Step 1: Collect paper information

  • If the user specified arxiv IDs, directly read the $OBSIDIAN_VAULT/papers/notes/{id}.md notes
  • If the user specified a category, first check the $OBSIDIAN_VAULT/papers/index/ file of the corresponding category under .base , extract the matching tags from its filter conditions, then scan $OBSIDIAN_VAULT/papers/notes/ all notes under it, find papers with matching tags, and then read the notes one by one
  • Important: determine which tags the category includes from the filter conditions of the .base file corresponding to the category, then scan the frontmatter of all paper notes to find matches. Do not use grep to search for keywords.
  • You must read the entire content of each note completely, not just the frontmatter

Step 2: Analyze paper relationships

Before starting to write, first sort out clearly:

  • The chronological order of these papers
  • What is the core problem each paper aims to solve
  • The inheritance/improvement/critique relationships between papers (who inspired whom, who improved what flaw of whom)
  • Key methodological differences

Step 3: Generate the review report

Write to the $OBSIDIAN_VAULT/knowledge/Summary/ directory.

File naming rules: Use the Chinese category name, such as 大模型强化学习.md、注意力机制.md

Generate strictly according to the template below.

Report Template

---
title: "{领域/主题名} 综述"
papers: ["arxiv_id_1", "arxiv_id_2", "arxiv_id_3"]
date_created: YYYY-MM-DD
---

# {领域/主题名} 综述

## TLDR

用一段话（200-300 字）专业地总结这个领域/这组论文的核心脉络。
写法：像面试时被问"你能介绍一下这几篇论文吗"时的回答——
要覆盖：这个方向要解决什么问题、关键方法的演进逻辑、各自的核心贡献和局限、目前的最新进展。
语气专业但不啰嗦，能直接背下来用于面试。

## 📋 论文一览

| arXiv | 论文名 | 简称 | 解决的问题 | 核心方法 | 局限/缺陷 |
|-------|--------|------|-----------|----------|-----------|
| [[xxxx.xxxxx]] | 完整论文名 | 简称 | 一句话说清楚 | 一句话说清楚 | 一句话说清楚 |

## 🔗 发展脉络

用自然语言讲清楚这条研究线的演化逻辑：为什么需要 A → A 有什么问题 → 所以有了 B → ...

重点是"为什么需要下一篇论文"，把因果链讲清楚。

然后用 mermaid 画演化关系图：

​```mermaid
graph TD
    A["GRPO (2024.02)<br/>去掉 value model"] --> B["DAPO (2025.03)<br/>工程改进"]
    A --> C["Dr.GRPO (2025.03)<br/>去偏修正"]
    A --> D["GDPO (2026.01)<br/>多奖励解耦"]
    B -.->|"同期工作"| C
​```

## 🎯 逐篇精讲

### 1. 简称（arxiv_id）

**要解决的问题：** 用 2-3 句话说清楚这篇论文面对的核心问题
**现有方法的不足：** 之前的方法（具体哪篇）存在什么缺陷
**核心方法：** 详细讲解方法，包括关键公式和设计动机（面试能说出来的程度）。必须包含：
- 关键公式的完整推导或对比（写出具体的数学表达式，不能只用文字描述）
- 与前人方法的公式级对比（比如"PPO 的 advantage 是 xxx，而本文改成了 xxx"）
- 每个公式符号的含义
- 为什么这样设计（直觉解释）
**关键设计/公式：** 列出最核心的 1-2 个公式或设计点，附直觉解释
**缺陷/后续被改进的点：** 这篇论文自身的局限，后来被谁改进了

（引用笔记中的关键 Figure，使用相对路径：`![说明|500](../../assets/png/{arxiv_id}/figX.png)`）

### 2. 简称（arxiv_id）
...

（每篇论文都按上面的结构写）

## ⚔️ 方法对比

用表格横向对比所有论文的关键维度：

| 维度 | 方法A | 方法B | 方法C |
|------|-------|-------|-------|
| 核心改进点 | ... | ... | ... |
| 归一化方式 | ... | ... | ... |
| 适用场景 | ... | ... | ... |
| 计算开销 | ... | ... | ... |

（维度根据具体领域选择最有区分度的）

## ❓ 开放问题与未来方向

目前这个方向还有哪些未解决的问题？可能的研究方向是什么？
（面试被问"你觉得还有什么可以做的"时用）

Writing Requirements

  • Oriented toward interview preparation: every point must be something you can "say out loud", not just "understand"
  • In the detailed paper-by-paper section, each paper must be at least 300 words, and the core method must include key formulas with formula-level comparisons against previous methods
  • The development trajectory section must clearly explain the causal chain, not just arrange events chronologically
  • The method comparison table should choose the most discriminative dimensions, and not pile up meaningless comparisons
  • Cite key Figures already available in the notes; there is no need to download additional images
  • The mermaid diagram should be concise, with nodes using "abbreviation + one-sentence contribution", and should not be too complex
  • The entire report should be written in Chinese