注意：不同提供商的覆盖范围有所不同。有些 API 能可靠地返回摘要，而其他 API 可能会遗漏。你的管道应将缺失摘要视为正常情况，而不是失败。

项目结构：像软件一样思考 n8n 工作流 🧠

虽然 n8n 是一个可视化工具，但将其设计为模块化阶段有助于避免“意大利面条式工作流”问题。

.
├── configuration/         # 关键词、阈值、限制、日期过滤器
├── collectors/            # 并行 HTTP 请求节点（多个来源）
├── processing/            # 标准化 + 去重代码节点
├── extraction/            # LLM 提取节点（严格 JSON）
├── scoring/               # 相关性 + 质量评分 + 过滤
└── delivery/              # Google Sheets + 邮件/HTML 报告

设计原则：每个阶段都应产生一个干净、可预测的输出形状，供下一阶段依赖。

第 1 阶段：集中配置 ⚙️

与其在多个节点中硬编码搜索参数（关键词、最小年份、引用阈值），不如使用一个配置节点来定义工作流变量。

这对可维护性（修改一次值，而不是在十个节点中修改）、可重用性（通过交换一个配置对象来复用整个管道）和可调试性（在每次运行开始时记录配置以便重现结果）至关重要。

使用 Set 节点，或返回如下 JSON 的 Code 节点：

{
  "keywords": "circular economy battery recycling remanufacturing",
  "min_year": 2020,
  "max_results_per_source": 10,
  "min_citations": 2,
  "relevance_threshold": 15,
  "batch_size": 10
}

💡 提示：保持数字字段为数字（而非字符串），以避免后续的评分错误。

第 2 阶段：并行 API 采集（带故障隔离） 🌐

你的工作流应同时查询多个来源。在 n8n 中，你可以从配置节点分支到多个 HTTP Request 节点，稍后再合并结果。

这里的生产思维很简单：API 会失败。速率限制会发生。提供商会返回部分数据。 关键是防止一个失败的采集器导致整个运行崩溃。

为此，在每个 HTTP Request 节点上，启用“失败时继续”（Continue On Fail）。然后，在标准化阶段，将缺失或失败的输出视为空数组，以便下游阶段仍能运行。

第 3 阶段：标准化和去重（DOI 优先，标题回退） 🔄

每个学术 API 返回的字段名称和形状都不同。一个可能使用 title，另一个使用 display_name，还有一个使用 paper_title。你的下一阶段应将所有输入标准化为一个模式。

目标标准化模式

这是一个简单的基准模式（稍后可按需扩展）：

{
  "title": "string",
  "abstract": "string|null",
  "doi": "string|null",
  "year": 2024,
  "citations": 12,
  "url": "string|null",
  "source": "Semantic Scholar|OpenAlex|arXiv|PubMed"
}

DOI 去重的含义

DOI（数字对象标识符）是分配给许多学术出版物的唯一、持久标识符。如果两篇记录共享相同的 DOI，则将其视为同一篇论文，仅保留一篇。

当 DOI 缺失时（这在某些预印本和 API 响应中很常见），回退方案是使用标准化标题键进行去重（小写、修剪、去标点、折叠空白）。

示例 n8n 代码节点（标准化 + 去重模式）

const itemsIn = $input.all();

const seen = new Set();
const results = [];

function titleKey(t) {
  return (t || "")
    .toLowerCase()
    .replace(/[\W_]+/g, " ")
    .replace(/\s+/g, " ")
    .trim();
}

for (const item of itemsIn) {
  // 示例：Semantic Scholar 响应形状
  const papers = item.json?.data || [];

  for (const paper of papers) {
    // "标准化为统一对象"：
    // 获取提供商特定字段并映射到我们的标准模式。
    const normalized = {
      title: paper.title || null,
      abstract: paper.abstract || null,
      doi: paper.externalIds?.DOI || null,
      year: paper.year || null,
      citations: paper.citationCount || 0,
      url: paper.url || null,
      source: "Semantic Scholar",
    };

    if (!normalized.title) continue;

    // 去重键：DOI 最强；标题为回退
    const key = normalized.doi
      ? `doi:${normalized.doi.toLowerCase()}`
      : `title:${titleKey(normalized.title)}`;

    if (seen.has(key)) continue;
    seen.add(key);

    results.push(normalized);
  }
}

return results.map(r => ({ json: r }));

第 4 阶段：AI 驱动的内容提取（严格 JSON） 🤖

一旦你有了去重后的论文列表，就可以将每篇论文（或一小批）发送给 Groq 进行结构化提取。

为什么结构化输出很重要

如果你的 LLM 返回叙述性文本而不是 JSON，遗漏字段，或输出格式错误的 JSON，你的工作流将在下游中断。在生产工作流中，这并不是罕见的边缘情况；这是你应该预料并针对性设计的。

这就是为什么要使用严格模式提示（strict schema prompting）并在下游验证响应。

系统提示与用户提示

• 系统提示
  
  定义不可协商的契约：输出格式、允许的键、无评论以及在不确定情况下的操作。
• 用户提示
  
  提供此特定请求的可变数据：标题、年份、引用、摘要和你想要填充的确切模式。

建议的提取模式

仅提取你可以从摘要级数据中支持的内容：

• research_question
  
  （研究问题）
• methodology
  
  （方法论）
• key_findings
  
  （主要发现）
• limitations
  
  （局限性）
• notes
  
  （备注）

示例提示（系统 + 用户）

System:

You are a research extraction engine. You must return ONLY valid JSON. No markdown. No extra keys. No commentary. If the abstract is missing or too vague, set fields to null and include a reason in “notes”.

User:

Extract structured fields from this paper. TITLE: {{title}} YEAR: {{year}} CITATIONS: {{citations}} ABSTRACT: {{abstract}} Return JSON with keys: research_question (string|null) methodology (string|null) key_findings (array of strings) limitations (array of strings) notes (string)

💡 模型设置：保持温度较低（约 0.2–0.3）并保持响应简短且结构化。

批量处理以避免超时

不要一次发送 50 篇论文，而是分批处理（例如 10 篇）。这减少了延迟峰值、故障爆炸半径和成本意外。

第 5 阶段：评分和综合 📊

不是每篇检索到的论文都值得你花时间。如果没有评分，你的管道就会变成消防水龙带：你自动化了收集，但仍需手动决定读什么。

我建议计算两个信号：

1. 相关性
   
   ：这真的关于你的研究问题吗？
2. 质量/优先级
   
   ：如果相关，值得先读吗？

对于相关性，计算标题和摘要中的关键词命中数。标题匹配的权重应更高。对于质量/优先级，使用新近度和引用数（作为弱信号）。

一旦过滤出“黄金”集合，综合就变得更安全、更有用。将每篇接受的论文写入 Google Sheets，然后生成每日/每周 HTML 摘要。

适合初学者的评估（检索和提取 QA） ✅

AI 工作流会静默退化。提示微调、模型更新或 API 模式更改可能会破坏提取而不抛出明显错误。添加轻量级评估是“上周还能用”和“它是可靠的”之间的区别。

n8n 中的实现

一个简单的实现是在提取步骤后立即添加一个“断言”（Assertions）代码节点。

const items = $input.all();
// ... (省略部分代码，保留核心逻辑)
const requiredKeys = ["research_question", "methodology", "key_findings", "limitations", "notes"];
// ...
// 验证 JSON 解析和必需键
// ...
const shouldFail =
  report.pct_extraction_json_parse_ok < HARD_FAIL_PARSE_BELOW ||
  report.pct_extraction_schema_ok < HARD_FAIL_SCHEMA_BELOW;

return [{
    json: {
      eval_report: report,
      shouldFail,
    },
}];

这是单元测试的自动化等价物：小巧、廉价且非常有效。

关键经验和错误处理 🛡️

构建此自动化教会了我，最好的工作流是为失败而设计的。

1. 错误恢复能力不是可选的
   
   。永远不要让一个失败的 API 导致工作流崩溃。
2. 批处理是你的朋友
   
   。分批处理论文以减少超时。
3. 结构化提示使 AI 在自动化中可靠
   
   。严格的 JSON 模式是无人值守运行的工作流与随机中断的工作流之间的区别。

结论 📝

一个好的研究管道不仅仅是检索论文——它将分散的结果转化为一致、去重、评分且准备好供审查的短名单。

通过将 n8n 工作流视为软件模块化阶段、步骤之间的严格契约和轻量级评估检查，你可以将数小时的人工文献综述缩短为一个快速、可重复的过程。

笔者锐评 🖊️

这篇文章介绍的科研自动化思路非常有价值。在国内，我们其实也可以利用类似的思路，结合国内的 DeepSeek 等高性能大模型，以及知网（CNKI）等平台的接口（如果有的话，或者使用其他学术镜像站），构建适合中文语境的科研情报系统。特别是对于硕博研究生来说，每天面对海量文献，如果能有一个自动化的“秘书”帮忙初筛和提取核心观点，将极大地解放生产力，把精力集中在真正的深度思考和创新上。这也提醒我们，AI 不仅仅是聊天机器人，更是生产力流程改造的核心引擎。

求点赞 👍 求关注 ❤️ 求收藏 ⭐️你的支持是我更新的最大动力！