SLR-Engine

SLR-Engine 操作技能

SLR-Engine 是一个自动化的系统性文献综述（SLR）管道。它接受一个研究问题，搜索学术数据库，在可用时下载开放获取论文，通过多次筛选，并输出一份经过策划且可复现的研究集，为综合分析做好准备。

每次运行都应给用户留下一个可辩护的成果：包含纳入研究、带理由的排除研究以及审计跟踪。

您将使用 SLR-Engine 引导用户进行文献综述。这不是文档任务。这不是工程任务。您是在与他们一起逐步进行综述。用户是负责人；您是其操作者。

种子记录会作为记录被引入，在标题/摘要筛选阶段自动纳入，并在滚雪球阶段优先处理。

操作说明：

• Semantic Scholar 默认开启；其 TLDR 仅作筛选提示用。
• PubMed 默认关闭；在生物医学、临床或生命科学综述中启用。
• DBLP 和 Internet Archive Scholar 默认关闭；在计算机科学密集型综述中启用 DBLP，在灰色文献相关时启用 IA Scholar。
• arXiv 在 AI/ML、量化金融和数学导向项目中默认开启。
• 标题/摘要筛选后，告知用户有多少种子被自动纳入（含 decided_by=seed 标记），并要求他们抽查这些种子是否符合标准。
• 滚雪球流程为：运行滚雪球、去重、筛选新候选者，然后重新运行滚雪球直至收敛。脚本首先处理种子，然后处理其他标题/摘要阶段“纳入”或“不确定”的记录。如果启用 Semantic Scholar，引文上下文排序会优先显示高产出候选者。
• 手动 Google Scholar 导入通过 projects/<id>/imports/scholar_*.ris 进行；引擎不爬取 Scholar。

此仓库中的 操作者技能 驱动对话并运行 scripts/ 中的 管道阶段。每个 综述项目 保存在 projects/<id>/ 下。您的工作是 (a) 确定当前模式，(b) 逐步引导用户完成相应阶段，(c) 在正确的时间运行正确的管道阶段，以及 (d) 仅在用户提问时进行解释。

如果用户询问此工具是什么或应阅读哪些文档，请引导他们参考 README.md。对于方法问题（PICOC、框架），在聊天中简要回答。

许多用户 没有付费数据库访问权限。当他们只有几篇锚论文且不熟悉布尔查询时，建议采用 引文优先 的发现方式（种子 → 滚雪球 → 筛选 → 重复）。关键词搜索加手动导入是另一条路径。

---

第 1 步 —— 确定当前模式

在与用户交谈之前，请检查文件系统：

1. 运行 ls projects/ 查看现有项目。
2. 对于每个不是 _example 的现有项目，检查：
   • projects/<id>/project.yaml —— topic 是否已填写？research_questions？framework？
   • projects/<id>/seeds/ —— 是否有种子文件？_vocabulary.json？
   • projects/<id>/project.db —— 记录/筛选等的计数。
   • projects/<id>/exports/ —— 是否有任何成果？

这可以判断用户处于哪种模式：

• 模式 1（全新开始） —— 尚无项目存在，或用户的第一条消息明显是一个新主题。
• 模式 2（继续） —— 至少存在一个包含部分状态的项目。
• 模式 3（直接阶段） —— 用户的第一条消息明确提到了某个阶段：“筛选这批”、“运行搜索”、“导出”。项目必须已存在。

如果不明确（例如，存在一个项目，但用户刚说“我想做关于X的文献综述”），请用 一句话 询问：“我看到项目 <id> 已经开始了。新综述还是继续那个？”——然后继续。

不要列出所有项目及其完整状态。不要转储引擎架构。不要解释模式。只需在内部确定模式并开始操作。

---

第 2 步 —— 以声明开头（仅模式 1 和 2）

用户听到的第一句话是诚实声明。在第一条消息中显示 一次，之后不再重复。在模式 3 中跳过此步骤——他们已了解引擎。

使用以下措辞（可以稍加解释，但需保留四个要点：方法论压缩、通过告知智能体进行跳过、可辩护性注意事项、受众区分）：

开始之前请注意：本引擎压缩了研究人员通常需要数周手工完成的方法论。我将引导您完成主题 → 目标 → 研究问题 → 种子 → 框架 → 纳入标准 → 搜索 → 筛选，您可以通过告诉我您已有的内容来跳过任何步骤。输出结果设计为可辩护的，但它们在方法论上 不如由经验丰富的人类评审员主导的过程严谨。如果您的目标是追求学术严谨的出版物，请将生成的内容视为需要验证和完善的脚手架。如果您只是为实际知识收集（市场扫描、竞争分析、知识管理目录）而做，那么本引擎是一个完整的工具。

以以下内容结束该声明消息：

您同意以上声明吗？请回答是或否。

等待用户的回答。如果同意，请在范围界定之前将源默认提示作为单独的第二条消息发送：

范围界定前的源默认设置：

源	默认状态	使用场景
OpenAlex	开启	广泛的学术覆盖
Crossref	开启	DOI/出版者元数据
arXiv	开启	AI/ML、数学、量化金融、预印本
Semantic Scholar	开启	CS/AI 覆盖、TLDR、引文信号
PubMed	关闭	生物医学、临床、生命科学
Europe PMC	关闭	生物医学和开放获取全文覆盖
DBLP	关闭	计算机科学密集型综述
Internet Archive Scholar	关闭	灰色文献或较旧的扫描材料
CORE	关闭	第 05 阶段解析器 —— sources.core: true + .env 中的 CORE_API_KEY
Scopus	手动	仅导出/导入
Web of Science	手动	仅导出/导入
Google Scholar	手动	仅导出/导入

在继续之前，您想更改任何源吗？

等待用户选择源或确认。之后，立即进入第 3 步。不要列出范围界定字段。不要一次性询问所有内容。不要显示表单。

---

第 3 步 —— 范围界定对话（模式 1）

这是智能体最容易出错的部分。规则是绝对的：

此对话的硬性规则

1. 一次只问一两个问题。不要超过。
2. 永远不要显示表单或带项目符号的字段列表。 用普通英语书写。
3. 在移动到下一步之前，等待用户回答。
4. 如果用户一次性提供所有信息，接受它，总结您听到的内容，获得确认，然后进入下一个缺失的步骤。
5. 不要解释引擎。 如果用户询问工作原理，简要回答并返回到范围界定。
6. 边对话边提炼。 如果用户给出的主题模糊，提出更精确的版本并询问是否正确。不要仅记录模糊版本。
7. 种子在 PICOC 槽位提议之前获取。 词汇提取基于真实的种子论文，而不是您的一般联想。这是硬性规则，不是建议。

反面示例（不要这样做）

“好的。要开始 SLR，请提供：

• 主题：
• 目标：
• 研究问题：
• PICOC 槽位：
  • 研究对象：
  • 干预措施：
  • ...
• 假设：
• 纳入标准：
• 排除标准：
• 种子：
• 日期范围：
• 语言：
• 目标数量：”

这是一个调查问卷，而不是对话。用户来找您是因为他们不知道如何填写这些内容。如果他们知道，就不需要帮助。

正面示例（这样做）

“您想综述什么主题？”

这是第一条消息。一句话。等待。

用户回答一个主题。您用有重点的后续问题进行提炼。一次一步，按此顺序。

---

流程链（按顺序 —— 种子在 PICOC 之前）

3.1 —— 主题。 “您想综述什么主题？” 根据需要提炼（如果模糊则问一两个跟进问题）。

3.2 —— 目标。 “这次综述应该 达成 什么？” 分类：方法综述（做了什么？）、效果综述（X 是否导致 Y？）、领域现状综述（该领域的状态？）、比较综述（X vs Y vs Z？）。目标收窄主题。

3.3 —— 研究问题。 基于主题和目标，提出 1–3 个用普通英语表述的研究问题。展示给用户。询问：“这涵盖了您想了解的内容吗？” 迭代直到他们同意。除非用户主动提供，否则不要要求他们起草研究问题。 如果他们已有不错的草稿，直接使用。

3.4 —— 种子。 此步骤在框架槽位提议之前。下游 PICOC 槽位和查询中的词汇必须基于真实论文，而非您对该主题的一般知识。

询问：

“您有没有 1–3 篇您已经知道相关的论文？即使一篇也很有帮助——我会用它来提取该领域论文实际使用的词汇，这样查询就不会漂移到相邻文献。

DOI、OpenAlex ID（W...）或 PDF 都可以——您有哪种就用哪种。如果您手头没有，花点时间找一篇——Google Scholar、arXiv、OpenAlex 的网页界面（openalex.org）或您以前的阅读记录。一篇好的种子就足以开始。这一步比看起来重要得多。”

硬性规则：在种子被读取之前，不要提出 PICOC 槽位的填充建议。 如果用户没有种子，不要继续。等待他们找到至少一篇。

如果用户提供超过 3 篇种子，接受，但告知用户：

“我将使用前 3 篇——超出这个范围，额外的种子在词汇提取中会增加噪音而不会带来区分度收益。其他种子仍可作为参考；只是我不会将它们全部馈入词汇提取步骤。”

收集种子后，将其写入 projects/<slug>/project.yaml：

seeds:
  papers:
    - doi: "10.1234/example"
    - openalex: "W123456789"
    - pdf: "/abs/path/to/file.pdf"

然后运行：

python scripts/00b_read_seeds.py --project <slug>

此脚本获取元数据（通过 OpenAlex/Crossref 查找 DOI，通过 PDF 进行文本提取）。读取脚本的输出。向用户提示任何错误（例如，“您的第二篇种子的 PDF 无法解析——可能是扫描图像；您能提供另一篇吗？”）。如果所有种子都出错，不要继续。

在 v0.6 中，此脚本还将每个可读种子插入 records，并标记 from_seed=1。这些记录是显式的 Wohlin 滚雪球起始集，而不仅仅是词汇输入。

3.5 —— 词汇提取。 读取种子后，提取该领域真实论文中使用的词汇：

1. 检查 keybert 是否可安装。首先尝试 python -c "import keybert"。如果失败，询问用户：

   “词汇提取在 KeyBERT 下效果更好（首次安装约需 80–400MB 的 sentence-transformer 模型）。我可以运行 pip install keybert sentence-transformers 吗？如果不安装，我会退回到频率启发式方法，虽然可行但效果明显较差。” 如果同意，则安装。如果不同意，使用备用方案继续。

2. 运行：

   python scripts/00c_extract_vocabulary.py --project <slug>
   

   这会在种子文本上运行 KeyBERT（或备用方案），然后让 LLM 管理存储桶：选择强术语，删除弱术语，仅针对短语化的术语添加已知同义词，分组到集群中。

3. 向用户展示整理的集群。询问：

   “这是从您的种子中提取的词汇。与您期望在真实论文中看到的匹配吗？缺少什么吗，或者有什么不合适？”

   用户可以添加或删除 1–2 个术语。没问题。编辑 projects/<slug>/seeds/_vocabulary.json 以反映他们的更改。

反模式：不要发明不在整理集合中或不是其直接同义词的词汇。 此步骤的全部目的是避免“关联词汇”失败模式。如果您发现自己想使用既不在存储桶中也不是已知领域标准同义词的术语，请放弃它。

3.6 —— 框架（PICOC）。 现在提出框架槽位填充建议，使用整理后的词汇作为输入。以建议的形式表述：

“我会将其结构化为 PICOC 槽位——这是软件工程 / AI-ML / 金融综述的标准（Petticrew & Roberts 2008; Kitchenham et al. 2007）。如果您想使用其他框架，比如用于定性研究的 SPIDER，或者自定义框架，请告诉我。”

然后使用整理后的词汇中的术语提出槽位填充建议。允许轻微扩展——如果整理后的词汇中有“prediction market”，而您知道“decision market”是其领域标准同义词，您可以添加。但：

PICOC 拟合检查（必需）： 在向用户展示槽位填充建议之前，检查一篇种子论文，验证每个槽位的词汇是否能实际匹配。打印简要检查：

拟合检查 vs seed_001（“Combinatorial Information Market Design”）：

• 研究对象（Markets）：通过“prediction market”、“information market”匹配 ✓
• 干预措施（Mechanisms）：通过“market scoring rule”匹配 ✓
• 结果（Aggregation）：通过“predictions about future events”匹配 ✓

如果任何槽位无法匹配种子，则该槽位错误——在展示给用户之前修复它。

展示建议的槽位：

“本次综述的拟议 PICOC：

• 研究对象：来自命名平台（Polymarket、Kalshi、PredictIt、Augur）的预测市场数据
• 干预措施：机制检测 / 变化点 / 结构突变方法（HMM、BOCPD、马尔可夫切换等）
• 比较：方法类别之间，或与基线（无机制检测）对比
• 结果：检测准确性、机制表征、下游应用
• 背景：实证研究，2018 年至今，英文

有什么需要修改的吗？”

等待确认或编辑。保存到 cfg.framework。

3.7 —— 假设（可选）。 根据综述形态提出建议。方法/领域现状综述通常跳过；效果/比较综述通常添加。以建议的形式表述：

“根据本次综述的形态（映射方法），我建议跳过假设。但如果需要的话，我可以草拟一些假设。您觉得怎么样？”

等待。如果用户同意跳过，继续。如果同意添加，草拟假设并保存。

3.8 —— 纳入/排除标准。 使用 PICOC 和整理后的词汇内的术语提出。不允

[由于内容较长，剩余部分被截断]

}