skillhub-026-systematic-literature-review
wehub-skill-sync
233 行
17 KiB
Markdown
233 行
17 KiB
Markdown
---
|
||
name: systematic-literature-review
|
||
description: 当用户需要对某个主题进行系统性文献综述、文献调查或跨多篇学术论文的综合分析时，使用本技能。同样适用于带注释的参考文献列表和跨论文比较。搜索 arXiv 并以 APA、IEEE 或 BibTeX 格式输出报告。不适用于单篇论文任务——审阅单篇论文请使用 academic-paper-review。
|
||
---
|
||
|
||
# 系统性文献综述技能
|
||
|
||
## 概述
|
||
|
||
本技能针对某个研究主题，跨多篇学术论文生成结构化的**系统性文献综述（SLR）**。给定主题查询后，它会在 arXiv 上执行搜索，并行提取每篇论文的结构化元数据（研究问题、方法论、关键发现、局限性），综合全集中出现的主题，并输出带有统一引用的最终报告。
|
||
|
||
**与 `academic-paper-review` 的区别：** 该技能针对单篇论文进行深度同行评审。本技能则是对多篇论文进行广度优先的综合分析。如果用户提供了一篇论文的 URL 并要求"审阅这篇论文"，请改用 `academic-paper-review`。
|
||
|
||
## 何时使用本技能
|
||
|
||
在用户提出以下任一需求时使用本技能：
|
||
|
||
- 对某个主题进行文献调查（"调研 transformer 注意力机制的变体"、"综述扩散模型的相关文献"）
|
||
- 跨多篇论文的综合分析（"近期论文对 X 有什么看法"、"比较关于 Y 的各篇论文的方法论"）
|
||
- 带有统一引用格式的系统性综述（"对 Z 做一个 APA 格式的 SLR"）
|
||
- 关于某个主题的带注释参考文献列表
|
||
- 某个领域在某时间段内的研究趋势概览
|
||
|
||
**不要**在以下情况下使用本技能：
|
||
|
||
- 用户提供了一篇论文并要求审阅它（请使用 `academic-paper-review`）
|
||
- 用户询问的事实性问题不需要综合多个来源（直接回答即可）
|
||
- 用户希望进行不要求学术严谨性的一般性网络调研（使用标准网络搜索）
|
||
|
||
## 工作流程
|
||
|
||
整个工作流程分为五个阶段。请按顺序执行。
|
||
|
||
### 阶段 1：规划
|
||
|
||
在开始任何检索之前，先向用户确认以下内容。如果其中任何一项不清楚，请提出**一个**涵盖所有缺失信息的澄清问题。不要逐个问题依次提问。
|
||
|
||
- **主题**：用通俗英语描述的研究领域（例如"transformer attention variants"）。
|
||
- **范围**：论文数量（默认 20，硬上限 50）、可选的时间窗口（如"last 2 years"）、可选的 arXiv 分类（如 `cs.CL`、`cs.CV`）。
|
||
- **引用格式**：APA、IEEE 或 BibTeX（如果用户未指定，且看起来不是为某个特定会议/期刊撰写，则默认 APA）。
|
||
- **输出位置**：最终报告的保存位置（默认为 `/mnt/user-data/outputs/`）。
|
||
|
||
如果用户说"50 篇以上"，请礼貌地将其上限设为 50，并说明超过该数量后综合质量会迅速下降——对于更大的综述，应按子主题拆分。
|
||
|
||
### 阶段 2：搜索 arXiv
|
||
|
||
调用附带的搜索脚本。**不要**尝试通过其他方式抓取 arXiv，也不要自行编写 HTTP 客户端——该脚本正确处理了 URL 编码、Atom XML 解析和 ID 规范化。
|
||
|
||
```bash
|
||
python /mnt/skills/public/systematic-literature-review/scripts/arxiv_search.py \
|
||
"<topic>" \
|
||
--max-results <N> \
|
||
[--category <cat>] \
|
||
[--sort-by relevance] \
|
||
[--start-date YYYY-MM-DD] \
|
||
[--end-date YYYY-MM-DD]
|
||
```
|
||
|
||
**重要——在搜索前提取 2-3 个核心关键词。** 不要将用户的完整主题描述作为查询语句。在调用脚本之前，先在脑中把主题缩减到 2-3 个最核心的术语。去掉诸如"in computer vision"、"for NLP"、"variants"、"recent"等修饰词——这些应放在 `--category` 或 `--start-date` 参数中，而不是查询字符串里。
|
||
|
||
**查询语句——保持简短。** 该脚本会将多词查询包裹在双引号中，以便在 arXiv 上进行短语匹配。这意味着：
|
||
|
||
- `"diffusion models"` → 搜索精确短语 → 效果好，返回相关论文。
|
||
- `"diffusion models in computer vision"` → 搜索精确的 5 词短语 → **过于具体，很可能返回 0 条结果**，因为很少有论文包含该确切字符串。
|
||
|
||
使用 **2-3 个核心关键词**作为查询语句，并使用 `--category` 来缩小领域范围，而不是将领域名称塞入查询中。示例：
|
||
|
||
| 用户表述 | 好的查询 | 差的查询 |
|
||
|---|---|---|
|
||
| "diffusion models in computer vision" | `"diffusion models" --category cs.CV` | `"diffusion models in computer vision"` |
|
||
| "transformer attention variants" | `"transformer attention"` | `"transformer attention variants in NLP"` |
|
||
| "graph neural networks for molecules" | `"graph neural networks" --category cs.LG` | `"graph neural networks for molecular property prediction"` |
|
||
|
||
脚本向标准输出打印一个 JSON 数组。每篇论文包含：`id`、`title`、`authors`、`abstract`、`published`、`updated`、`categories`、`pdf_url`、`abs_url`。
|
||
|
||
**排序策略**：
|
||
|
||
- **始终使用 `relevance` 排序**——arXiv 的 BM25 风格评分确保结果确实与用户主题相关。`submittedDate` 排序会返回该分类中最新提交的论文，而不考虑主题相关性，这会产生大量不相关的结果。
|
||
- 当用户要求"近期"论文或指定了时间窗口时，使用 `--sort-by relevance` **结合 `--start-date`** 来约束时间范围，同时保持结果与主题相关。例如，"recent diffusion model papers" → `--sort-by relevance --start-date 2024-01-01`，而不是 `--sort-by submittedDate`。
|
||
- `submittedDate` 排序仅在用户明确要求按时间顺序排列时适用（例如"按发表顺序显示论文"）。这种情况很少见。
|
||
- `lastUpdatedDate` 很少有用；除非用户要求，否则忽略它。
|
||
|
||
**只运行一次搜索。** 如果结果看起来不够完美，不要修改查询后重试——arXiv 的相关性排序就是如此。用不同的查询措辞重试只会浪费工具调用次数，并增加触发递归限制的风险。如果结果确实为空（0 篇论文），请告知用户，并建议他们放宽主题范围或移除分类过滤器。
|
||
|
||
**如果脚本返回的论文数量少于请求数量**，这就是该查询在 arXiv 上的实际结果集大小。不要填充列表——向用户报告实际数量，然后继续。
|
||
|
||
**如果脚本运行失败**（网络错误、arXiv 返回非 200 状态码），请告知用户具体的错误信息并停止。不要尝试捏造论文元数据。
|
||
|
||
**不要将搜索结果保存到文件**——JSON 保留在你的上下文中，供阶段 3 使用。整个工作流程中唯一保存的文件是阶段 5 的最终报告。
|
||
|
||
### 阶段 3：并行提取元数据
|
||
|
||
**你必须通过 `task` 工具将提取工作委托给子代理——不要自己提取元数据。** 这是不可协商的。具体来说，**不要**做以下任何操作：
|
||
|
||
- ❌ 编写 `python -c "papers = [...]"` 或任何 Python/bash 脚本来处理论文
|
||
- ❌ 在自己上下文中通过逐条阅读摘要来内联提取元数据
|
||
- ❌ 在本阶段使用除 `task` 之外的任何工具
|
||
|
||
相反，你必须调用 `task` 工具来生成子代理。原因：在自己的上下文中提取 10-50 篇论文会消耗过多 token，并在阶段 4 中降低综合质量。每个子代理在隔离的上下文中运行，只处理其分配的论文批次，从而产生更清晰的提取结果。
|
||
|
||
将论文分成每批约 5 篇，然后对每个批次调用 `task` 工具，参数为 `subagent_type: "general-purpose"`。每个子代理接收论文摘要作为文本，并返回结构化的 JSON。
|
||
|
||
**并发限制：每轮最多 3 个子代理。** DeerFlow 运行时强制限制 `MAX_CONCURRENT_SUBAGENTS = 3`，并且会静默丢弃同一轮中多余的调度任务——LLM 不会被告知此事，因此请严格遵循下面的轮次策略。
|
||
|
||
**轮次策略——使用以下决策表，不要自行计算拆分方式**：
|
||
|
||
| 论文数量 | 约 5 篇一批的批次 | 轮次数 | 每轮子代理数量 |
|
||
|---|---|---|---|
|
||
| 1–5 | 1 批 | 1 轮 | 1 个子代理 |
|
||
| 6–10 | 2 批 | 1 轮 | 2 个子代理 |
|
||
| 11–15 | 3 批 | 1 轮 | 3 个子代理 |
|
||
| 16–20 | 4 批 | 2 轮 | 3 + 1 |
|
||
| 21–25 | 5 批 | 2 轮 | 3 + 2 |
|
||
| 26–30 | 6 批 | 2 轮 | 3 + 3 |
|
||
| 31–35 | 7 批 | 3 轮 | 3 + 3 + 1 |
|
||
| 36–40 | 8 批 | 3 轮 | 3 + 3 + 2 |
|
||
| 41–45 | 9 批 | 3 轮 | 3 + 3 + 3 |
|
||
| 46–50 | 10 批 | 4 轮 | 3 + 3 + 3 + 1 |
|
||
|
||
**永远不要在同一轮中调度超过 3 个子代理。** 当某行显示"2 轮 (3 + 1)"时，意思是：第一轮并行调度 3 个子代理，等待所有 3 个完成后，第二轮调度 1 个子代理。在主代理层面，各轮严格按顺序执行。
|
||
|
||
如果论文数量落在两行之间（例如 23 篇），向上取整到下一行的布局，但只调度你实际需要的批次数——决策表给出的是框架，而不是死板的规定。
|
||
|
||
**在主代理层面进行分批**：你已经在阶段 2 中获得了每篇论文的摘要，因此每个子代理接收的是纯文本输入。子代理不需要访问网络或沙箱——它们的唯一任务就是阅读文本并返回 JSON。不要让子代理重新运行 `arxiv_search.py`，那会浪费 token 并增加触发频率限制的风险。
|
||
|
||
**每个子代理接收的结构化提示内容**：
|
||
|
||
```
|
||
执行以下任务：从以下 arXiv 论文中提取结构化元数据和关键发现。
|
||
|
||
论文：
|
||
[论文 1]
|
||
arxiv_id: 1706.03762
|
||
title: Attention Is All You Need
|
||
authors: Ashish Vaswani, Noam Shazeer, ...
|
||
published: 2017-06-12
|
||
abstract: <完整摘要文本>
|
||
|
||
[论文 2]
|
||
arxiv_id: ...
|
||
...
|
||
|
||
对于每篇论文，返回一个包含以下字段的 JSON 对象：
|
||
- arxiv_id（字符串）
|
||
- title（字符串）
|
||
- authors（字符串列表）
|
||
- published_date（字符串，格式 YYYY-MM-DD）
|
||
- research_question（1 句话，论文解决什么问题）
|
||
- methodology（1-2 句话，他们如何解决该问题）
|
||
- key_findings（3-5 条要点，他们实际发现了什么）
|
||
- limitations（1-2 句话，他们承认的局限性或明显缺失的内容）
|
||
|
||
以 JSON 数组形式返回结果，每篇论文一个对象，顺序与输入一致。不要在 JSON 之外包含任何文本——没有前言、没有 Markdown 围栏，只有数组。
|
||
```
|
||
|
||
**解析子代理结果**：`task` 工具返回的字符串带有固定前缀，例如 `Task Succeeded. Result: [...JSON...]`。在尝试解析 JSON 之前，先去掉 `Task Succeeded. Result: ` 前缀（或 `Task failed.` / `Task timed out.` 前缀）。如果某个批次失败或返回无法解析的 JSON，记录该情况，注明受影响的论文，然后继续处理其余批次——不要因为一个坏批次就放弃整个综合任务。
|
||
|
||
所有轮次完成后，将各批次的数组展平为单个论文元数据对象列表，保持原有顺序。
|
||
|
||
### 阶段 4：综合与格式化
|
||
|
||
现在生成最终的 SLR 报告。这里要做两件事：跨论文综合（主题分析）和引用格式化。
|
||
|
||
**跨论文综合**：报告不能仅仅是列出论文。至少应识别出：
|
||
|
||
- **主题**：整个论文集中 3-6 个重复出现的研究方向、方法或问题框架。
|
||
- **共识**：多篇论文一致认同的发现。
|
||
- **分歧**：论文得出不同结论或使用不相容方法论的地方。
|
||
- **空白**：整个文献体系尚未涉及的内容（通常在"局限性"字段中有明确说明）。
|
||
|
||
如果论文集规模太小或异质性过高，无法支持主题综合（例如 5 篇主题迥异的论文），请在报告中明确说明——不要强行制造不存在的主题。
|
||
|
||
**引用格式化**：具体格式取决于用户的偏好。只读取与用户请求格式匹配的模板文件，而不是全部三个：
|
||
|
||
- [templates/apa.md](templates/apa.md)——APA 第 7 版。社会科学和大多数 CS 期刊的默认格式。用户在请求 APA 或未指定格式时使用。
|
||
- [templates/ieee.md](templates/ieee.md)——IEEE 数字引用。用户目标为 IEEE 会议或期刊，或明确要求 IEEE 时使用。
|
||
- [templates/bibtex.md](templates/bibtex.md)——BibTeX 条目。用户提及 BibTeX、LaTeX 或希望获得机器可读参考文献时使用。**重要**：arXiv 论文应引用为 `@misc`，而非 `@article`——BibTeX 模板对此有明确说明。
|
||
|
||
每个模板既包含引用规则，也包含完整的报告结构（执行摘要、主题、逐篇论文注释、参考文献、方法论部分）。严格按照模板结构撰写报告正文，然后填入阶段 3 元数据中的内容。
|
||
|
||
### 阶段 5：保存与呈现
|
||
|
||
将完整报告保存到 `/mnt/user-data/outputs/slr-<主题简称>-<YYYYMMDD>.md`，其中 `<主题简称>` 是主题的小写连字符版本（例如 `transformer-attention`）。然后调用 `present_files` 工具并提供该路径，以便用户下载。
|
||
|
||
**在聊天消息中**，显示一个简短预览，让用户无需打开文件即可立即看到价值：
|
||
|
||
1. **执行摘要**——报告中开头的 3-5 句话段落，原文照引。
|
||
2. **主题列表**——你在阶段 4 综合中识别的主题列表（仅主题名称 + 一句话说明，不包含完整的主题章节）。
|
||
3. **论文数量 + 文件路径提示**——例如"包含 20 篇论文、逐篇注释和格式化参考文献的完整报告已保存至 `slr-transformer-attention-20260409.md`。"
|
||
|
||
**不要**将完整的 2000+ 字报告内联输出——逐篇论文注释、参考文献和方法论章节应放在文件中。预览的作用是让用户一眼就能判断报告价值，并决定是否打开它。
|
||
|
||
## 示例
|
||
|
||
**示例 1：典型的 SLR 请求**
|
||
|
||
用户："对我做一个关于近期 transformer 注意力变体的系统性文献综述，20 篇论文，APA 格式。"
|
||
|
||
你的流程：
|
||
1. 阶段 1：确认主题（transformer attention variants）、范围（20 篇论文，默认时间窗口）、格式（APA）。只有在信息缺失时才提**一个**澄清问题（例如"有没有特定的时间窗口，还是默认为最近 3 年？"）。
|
||
2. 阶段 2：`arxiv_search.py "transformer attention" --max-results 20 --sort-by relevance --start-date 2023-01-01`。
|
||
3. 阶段 3：20 篇论文 → 第 1 轮 = 3 个子代理 × 5 篇论文 = 覆盖 15 篇，第 2 轮 = 1 个子代理 × 5 篇论文 = 覆盖 5 篇。汇总。
|
||
4. 阶段 4：读取 `templates/apa.md`，按其结构撰写报告，填入阶段 3 元数据中的主题 + 逐篇注释。
|
||
5. 阶段 5：保存至 `slr-transformer-attention-20260409.md`，调用 `present_files`。
|
||
|
||
**示例 2：小规模请求，存在歧义**
|
||
|
||
用户："帮我调研几篇关于扩散模型的论文。"
|
||
|
||
你的流程：
|
||
1. 阶段 1："几篇"存在歧义。提出一个问题："你想要多少篇论文——10、20 还是 30？另外，引用格式有偏好吗（默认 APA）？"
|
||
2. 用户回复"10，BibTeX"。
|
||
3. 阶段 2：`arxiv_search.py "diffusion models" --max-results 10 --category cs.CV`。
|
||
4. 阶段 3：10 篇论文 → 单轮，2 个子代理 × 5 篇论文。
|
||
5. 阶段 4：读取 `templates/bibtex.md`，使用 `@misc` 条目（而非 `@article`）格式化。
|
||
6. 阶段 5：保存并呈现。
|
||
|
||
**示例 3：超出范围的请求**
|
||
|
||
用户："这里有一篇论文（https://arxiv.org/abs/1706.03762）。你能审阅一下吗？"
|
||
|
||
这是单篇论文的同行评审，不是文献综述。不要使用本技能。请改用 `academic-paper-review`。
|
||
|
||
## 备注
|
||
|
||
- **前置条件：`subagent_enabled` 必须为 `true`**。阶段 3 需要使用 `task` 工具进行并行元数据提取。该工具仅在运行时配置中将 `subagent_enabled` 设置为 `true` 时才会加载（`config.configurable.subagent_enabled`）。如果未启用，`task` 工具不会出现在可用工具列表中，阶段 3 也无法按设计执行。
|
||
- **仅限于 arXiv，此为设计原则。** 本技能不查询 Semantic Scholar、PubMed 或 Google Scholar。arXiv 涵盖了大多数 CS/ML/物理/数学预印本，这也是 DeerFlow 用户最常希望调研的内容。多来源学术搜索应放在专用的 MCP 服务器中，而不是本技能内部。
|
||
- **硬上限为 50 篇论文。** 这与阶段 3 的并发策略有关（每轮最多 3 个子代理，每个约 5 篇论文，最多约 3 轮）。超过 50 篇论文的综述会降低综合质量，更适合拆分为子主题进行。
|
||
- **阶段 3 需要启用子代理。** 本技能的并行提取步骤硬性要求 `task` 工具，该工具仅在运行时 `subagent_enabled=true` 时才可用。如果子代理不可用，不要声称要执行阶段 3 的并行方案；相反，告知用户必须启用子代理才能完成完整工作流程，或者提议将请求缩小/拆分为较小规模的手动审阅。
|
||
- **子代理结果为字符串，而非对象。** 在解析 JSON 载荷之前，务必去掉 `Task Succeeded. Result: ` / `Task failed.` / `Task timed out.` 前缀。
|
||
- **`id` 字段是裸 arXiv ID**（例如 `1706.03762`），不是 URL，也不带版本后缀。`abs_url` / `pdf_url` 包含完整 URL，如果需要可以取用。
|
||
- **综合，而非罗列。** 最终报告必须识别主题并比较论文之间的发现。一份仅逐篇罗列论文的报告是失败模式——如果你找不到主题，请明确说明，而不是伪造它们。
|