ESSAY
用 n8n + DeepSeek 搭建个人科技情报系统:从信息过载到智能筛选
“信息过载的时代,筛选比获取更重要。“
核心观点 / 起源
每天追踪 13 个科技智库和媒体的最新动态,面对 500+ 条英文更新,手动筛选需要 2-3 小时。我用 n8n(低代码工作流引擎)+ DeepSeek(AI 分析)+ Obsidian(知识管理),搭建了一套端到端的自动化情报系统——从抓取、翻译、分析到归档,全程自动化,仅需 2.5 分钟。
这不是一个纯技术炫技,而是一次工具选型的实践思考:为什么选择低代码而非纯编程?为什么是 DeepSeek 而非 GPT?关键技术决策背后的权衡是什么?
问题的本质
作为关注科技地缘政治的学生,我需要追踪的信息源包括:
- 科技媒体:TechCrunch、Wired、MIT Tech Review、The Verge、arXiv AI
- 智库机构:Brookings、Carnegie、CFR、Atlantic Council、RAND、CNAS 等
这些源每天产生 500+ 条更新,存在三个核心障碍:
- 信息分散:13 个不同的 RSS 源,手动浏览耗时
- 语言障碍:英文内容需要翻译和地缘政治背景分析
- 知识管理:处理后的信息需要结构化存储到 Obsidian
传统方案是 RSS 阅读器 + 手动翻译 + 笔记整理,效率极低。
过程 / 推演
为什么选择 n8n 而非纯代码?
最初我考虑用 Python 写脚本,但很快发现低代码方案更合适:
n8n 的三个关键优势:
- 可视化调试:每个节点的输入输出实时可见,出问题立刻定位
- 快速迭代:修改工作流无需重新编译部署,改完就能测试
- 丰富集成:内置 RSS、HTTP、LangChain 节点,省去大量胶水代码
用 Python 写同样的功能,需要处理 RSS 解析、HTTP 请求、错误重试、并发控制、日志记录等基础设施。而 n8n 把这些都封装好了,我只需要关注业务逻辑。
权衡:n8n 的灵活性不如纯代码,但对于这种”数据流水线”场景,可视化编排的效率远超手写代码。
为什么选择 DeepSeek?
在 LLM 选型上,我对比了 GPT-3.5、GPT-4 和 DeepSeek:
DeepSeek 的优势:
- 中文能力强:翻译质量和地缘政治分析深度优于 GPT-3.5
- 成本可控:API 价格远低于 GPT-4(每天 10 篇分析,月成本不到 10 元)
- JSON 输出稳定:结构化输出可靠性高,减少解析错误
实测对比:
- GPT-3.5:翻译准确但分析浅显,经常给出”正确但无用”的泛泛而谈
- GPT-4:分析深度好,但成本是 DeepSeek 的 10 倍以上
- DeepSeek:在翻译和地缘政治分析上达到了 GPT-4 的 80% 水平,但成本只有 1/10
三个最有价值的坑
坑 1:Merge 节点的多输入陷阱
问题:n8n 的 Merge 节点在处理 13 个输入时,连接配置极其复杂,使用 SDK 生成的 JSON 配置导入后无法正确合并数据。
解决方案:放弃 Merge 节点,改用 Code 节点手动合并:
const allItems = [];
for (let i = 0; i < 13; i++) {
try {
const items = $input.all(i);
if (items && items.length > 0) {
allItems.push(...items);
}
} catch (e) {
// 单个源失败不影响整体
}
}
return allItems;
启示:低代码工具不是万能的,当内置节点无法满足需求时,Code 节点是最好的逃生舱。明确的代码逻辑比复杂的可视化配置更可靠。
坑 2:Docker 环境下的 HTTP 认证陷阱
问题:配置 HTTP Request 节点使用 n8n 凭证系统访问 Obsidian API,持续返回 401 错误。用 curl 测试成功,但 n8n 中始终失败。
根本原因:n8n 的安全机制会在非加密 HTTP 连接(如 http://host.docker.internal:27123)中静默丢弃凭证系统中的敏感信息,以防止密码明文泄露。
解决方案:绕过凭证系统,手动设置 Authorization Header:
{
"authentication": "none", // 关键:不使用凭证系统
"sendHeaders": true,
"headerParameters": {
"parameters": [{
"name": "Authorization",
"value": "Bearer YOUR_API_KEY" // 手动设置
}]
}
}
启示:工具的”安全特性”有时会成为障碍。当遇到无法解释的认证失败时,检查工具是否有隐藏的安全机制在起作用。
坑 3:LLM 子节点的隐藏配置
问题:从 JSON 导入工作流后,执行 DeepSeek Analysis 节点报错:“A Chat Model sub-node must be connected”。
根本原因:n8n 的 LangChain Agent 节点需要配置 Chat Model 子节点,但这些子节点的配置在 JSON 导出时不完整,导入后需要手动重建。
解决方案:在 n8n UI 中手动添加 Chat Model 子节点,配置 Model、Temperature、Max Tokens 等参数。
启示:低代码工具的”导入导出”功能并非完美。复杂节点(尤其是嵌套子节点)的配置可能无法完全序列化,需要手动补全。
系统架构的核心设计
整个系统分为 6 个阶段:
- 并行抓取:13 个 RSS 节点同时触发,单个源失败不影响其他源
- 数据标准化:统一字段名称,生成唯一标识符
- 清洗去重:从 500+ 条压缩到 20-30 条有效内容
- 关键词评分:基于地缘政治关键词(CHIPS、export control、tech diplomacy 等)筛选 Top 10
- LLM 深度分析:翻译 + 地缘政治洞察 + AI 评分(0-10 分)
- 输出到 Obsidian:格式化为 Markdown,文件名:
日期-score评分-中文标题.md
关键设计决策:
- 两层筛选:先用关键词快速过滤(成本低),再用 LLM 深度分析(成本高)
- 容错机制:所有 RSS 节点设置
continueOnFail: true,确保单点故障不影响整体 - 结构化输出:LLM 返回严格的 JSON 格式,包含翻译、摘要、分析、评分、保留决策
一点补充:实际效果
系统运行后的真实数据:
| 指标 | 数值 |
|---|---|
| 原始抓取 | 500+ 条 |
| 去重后 | 20-30 条 |
| LLM 分析 | 10 条 |
| 执行时长 | 2.5 分钟 |
| 成功率 | 95%+ |
真实输出案例:
文件名:2026-04-10-score9-美国对华科技投资限制升级地缘政治博弈下的资本与技术流动新格局.md
内容包含:
- 准确的中文翻译
- 200-300 字核心摘要
- 多维度地缘政治分析(战略意图、产业链影响、连锁反应、企业启示)
- 9 分的高评分(表示高度相关)
对比手动处理:
- 时间:从 2-3 小时降至 2.5 分钟(自动化)
- 质量:LLM 分析深度超过快速浏览的人工判断
- 覆盖:不会因为疲劳而遗漏重要信息
结语 / 反思
这个项目最大的收获不是技术实现本身,而是工具选型的思考框架:
- 低代码 vs 纯代码:不是非此即彼,而是根据场景选择。数据流水线适合低代码,复杂算法适合纯代码。
- AI 模型选择:不是越贵越好,而是在成本、质量、稳定性之间找平衡点。DeepSeek 在这个场景下是最优解。
- 自动化的边界:不是所有环节都要自动化。我保留了”最终阅读”这个人工环节,因为 AI 筛选再好,也需要人的判断。
适用场景扩展:
这套方案不仅适用于科技情报,还可以扩展到:
- 行业研究:金融市场、医疗健康、能源环保
- 竞品监控:竞争对手动态、产品发布
- 学术研究:论文追踪、会议信息
- 内容创作:素材收集、灵感管理
完整技术文档:详细的代码实现、配置步骤、部署指南见 技术文档
项目信息:
- 执行时长:2.5 分钟
- 月成本:< 10 元(DeepSeek API)
- 成功率:95%+
- 开源:工作流配置文件可在技术文档中获取