这阵子折腾 AI 热点监控，最上头的不是写抓取脚本，而是怎么把“看消息”这件每天都在发生的琐事真正自动化掉。我把整个链路拆成了采集、分析、推送三段，调度交给 n8n 自托管服务，语义理解交给阿里云百炼的大模型接口，最后每天早上定时把一份“AI 热点简报”推到协作文档里，打开电脑就能直接看。这套 n8n + 阿里云百炼 的组合跑通之后，我身边做技术内容、做行业研究的朋友都来问具体怎么接，因为它不是简单的“RSS 抓取转发送”，而是把聚合、清洗、语义评分、分类、去重、推送几个环节完整串了起来。
这篇就把搭建这套“自动获取 AI 热点”工作流的全过程拆开讲，包括为什么选这个技术组合、数据链路怎么设计、每个核心节点怎么配、以及我运行两个月下来踩到的一堆坑。如果你也想搭一套类似的自动化内容管道，这篇可以直接照着落地；就算不改造成热点监控，里面对“API 节点编排”和“模型输出结构化解析”的处理思路，同样能迁移到别的自动化场景里。
1. 项目整体思路：一个热点自动化系统背后的真实需求
1.1 聚合、过滤、产出：被“抓取”掩盖的三个核心痛点
先说我自己遇到的真实问题。做 AI 相关的内容工作，每天要盯的信息源特别多：科技媒体的 RSS、社区热榜、模型发布公告、论文更新页面，再加上团队内部转发的各种链接。单看一两个不觉得累，叠起来就是个大工程——打开十几个页面、一个个扫标题、跳过重复内容和营销软文、判断哪几条值得细看，这套动作每天至少要吃掉四十分钟，还特别消耗注意力。
所以“获取 AI 热点”这个标题，落到实操层面上，要解决的其实不是“抓取”这一个动作，而是三件事：
- 聚合：把分散在 RSS、网页、API 里的信息统一收到一个管道里，不用每天手动开十几个页面。
- 过滤与分级：网络上关于 AI 的内容每天非常多，但很大一部分是站内转载、标题党或者低质信息，得有机制自动把它们挡在门外，只留下值得读的少数条目。
- 产出可用内容：把一堆原始链接堆在一起不叫简报，还得自动生成摘要、打上主题标签、给出热度判断，最终变成可以直接阅读的成果物。
这三个需求叠在一起，决定了它不是一个十几行的 Python 脚本能交差的事，而是需要一个能承载完整处理链、能持续调整的系统。一开始我就把目标定成“自动产出内容”而不是“自动攒一堆链接”，后面所有设计都围绕这个目标展开。
1.2 为什么调度层选 n8n，而不是自己写一套定时脚本
有朋友问：这些事用 Python 加 cron 不也能做吗？能，但我基于几次实践经验，最后还是选了 n8n 作为调度和编排层，核心原因有三点。
第一，n8n 自带调度触发器、HTTP 请求、数据转换、Webhook 这些基础设施，不用自己维护队列、失败重试和定时任务。第二，节点是插拔式的，后续想加一个新信息源，拖一个 RSS 节点填好地址就行，不用改代码、不用重新部署。第三，也是我个人最看重的，n8n 自托管之后数据完全在自己手里，抓取记录、API 调用日志、中间数据全部留在本地服务里，不会受某个平台的既定规则约束，想怎么改链路都行。
代价也有：n8n 的某些高级处理要靠 JavaScript 的 Function 节点补，这是学习曲线最陡的地方。但整体评估下来，对于“多个信息源 + 多次 API 调用 + 定期执行”这种中等复杂度的自动化场景，n8n 的灵活度和维护成本非常划算。如果你不需要可视化编排，习惯纯代码方案，那用 Python 写一套也不是不行，只是后续每次改源、加字段、调 prompt 都要动代码，测试成本会高不少。
1.3 为什么分析环节选阿里云百炼
信息聚合拉回来之后，下一步是让机器“看懂”这些内容，这一步我选了阿里云百炼，理由非常现实。
首先是模型服务稳定，百炼作为云上大模型服务平台，接口可用性有保障，日常调用不需要担心响应超时。其次是接入成本低，百炼提供了兼容模式接口，直接用 HTTP Request 节点就能调，不用额外引入 SDK，对 n8n 这种“节点拼链路”的场景特别友好。最后是支持结构化输出，让模型返回严格 JSON 对象，这对我后续的解析环节至关重要。
模型选型方面，我实际用的是通义千问系列里的标准档位，摘要任务用它足够，复杂判断任务再上调一档。选型逻辑后面展开，核心原则就是：自动化流程里模型不一定要最强，但输出格式一定要最可控。
2. 数据链路设计与环境准备
2.1 整条链路的三个阶段：采集、分析、交付
在设计工作流之前，我先给自己画了一条目标链路（这里不画图，用文字描述）：
- 定时触发 → RSS 源读取 → 网页抓取 → 正文提取 → 字段清洗
- 循环处理每一条 → 调百炼 API 分析 → 解析 JSON → 评分过滤与去重
- 汇总写入文档 → 发送通知
这条链路可以归成三个阶段。采集阶段由定时触发器按设定周期启动，RSS 节点并行读取预先配置的信息源，得到一批原始条目；对其中值得深入看的内容，再用 HTTP Request 节点抓全文。分析阶段把标题和正文片段拼成提示词，调用百炼 API，让模型输出包含“热度评分、摘要、主题标签、关联关键词”的 JSON。交付阶段解析返回结果，过滤低热度条目，合并后写入文档，同时发一条通知到协作工具群。
这样分段设计最大的好处是每段都可以独立调试。采集出问题不影响分析逻辑，模型返回效果不好可以单独拿一个测试节点验证，不用整条链路一起排查。我从最初的一坨代码改成这种阶段化设计之后，调试体验好了非常多。
2.2 n8n 的 Docker 部署与关键配置
n8n 我采用 Docker 部署，理由很简单：数据持久化、版本升级、迁移都方便。直接看实际用的 docker-compose 配置：
version: '3.8' services: n8n: image: docker.n8n.io/n8nio/n8n container_name: n8n restart: unless-stopped ports: - "5678:5678" environment: - N8N_BASIC_AUTH_ACTIVE=true - N8N_BASIC_AUTH_USER=admin - N8N_BASIC_AUTH_PASSWORD=换成自己的强密码 - GENERIC_TIMEZONE=Asia/Shanghai - TZ=Asia/Shanghai volumes: - n8n_data:/home/node/.n8n volumes: n8n_data:这里有几个点必须强调。一个是N8N_BASIC_AUTH_ACTIVE=true，这是给 n8n 编辑器加基础登录认证。自托管服务只要暴露到局域网或公网，这个必须开，不然别人访问到你的 5678 端口就能直接改工作流。另一个是GENERIC_TIMEZONE=Asia/Shanghai，它决定定时触发器按哪个时区执行。我最初没设这个变量，结果工作流一直按 UTC 时间跑，早上 8 点的定时任务下午 4 点才触发，排查了好久才发现是这个配置问题。第三个是 volume 一定得挂，容器删了数据不能跟着没。
部署完之后浏览器打开http://你的服务器IP:5678，完成管理员账号设置，就能进入工作流编辑界面了。到这里环境的骨架就搭好了。
2.3 百炼 API 接入：从开通到拿到可调用的 Key
百炼这边的准备工作相对简单：开通服务、拿到 API Key，就这两件事。
登录百炼控制台后，先开通需要用到的模型服务，然后在 API-KEY 管理页面生成专属 Key。生成后把它存在安全的地方，接下来配 n8n 节点的时候要用到。
我实际使用的接口地址是兼容模式下的对话补全路径：https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions。这个接口的请求体格式和 OpenAI 那一套非常接近，对用习惯这类 API 的人来说几乎没有学习成本。基础请求体长这样：
{ "model": "qwen-plus", "messages": [ {"role": "system", "content": "你是一个AI热点分析助手"}, {"role": "user", "content": "请分析以下新闻内容并返回JSON格式结果"} ], "temperature": 0.3, "response_format": {"type": "json_object"} }这里有一个参数必须留意：response_format设为json_object后，模型会以纯 JSON 返回。同时要把 temperature 调低，热点分析是偏稳定的任务，我们需要可复现的结果，而不是每次跑出来的答案都不一样。
3. 核心节点实操：从零搭建一条完整的热点工作流
3.1 定时触发器、RSS 源与入口聚合
在 n8n 左侧节点面板拖入一个 Schedule Trigger 节点，双击配置触发时间。我设的是每天早上 8 点 30 分执行，n8n 新版可以直接用 cron 表达式，我填的是30 8 * * *。如果你有多个时间点需求，也可以在界面上组合配置。
然后拖入 RSS Feed Read 节点，这个节点只需要填一个 URL 字段，指向你常用信息源的 RSS 地址。多个信息源的处理方式有两种：在 RSS 节点前加一个循环逐个处理链接，或者用多个 RSS 节点分别读取后用 Merge 节点做汇聚。我实际采用的是后一种——每个源一个 RSS 节点，输出全部汇入 Merge 节点，再做一次去重和排序。
这里提醒一句，RSS 源的质量直接决定后面所有环节的效果。优先选官方站点提供的 RSS 和稳定的大型聚合器，那些常年失效的源尽早剔除。我的经验是配置完先手动执行一次，看看每个源能不能返回数据，再进入下一步。
3.2 页面抓取、正文提取与字段清洗
RSS 的 description 字段通常只有摘要，要想拿到完整正文，还需要抓取原文页面。这一步我用 HTTP Request 节点请求目标 URL，拿到 HTML 后，在 Function 节点里写解析逻辑提取正文。
抓页面最大的问题是反爬。很多站点对非浏览器请求直接返回 403，解决办法是在 HTTP Request 节点里设置请求头，伪装成浏览器的 User-Agent：
{ "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" }还有一个容易被忽略的是页面编码。部分老页面是 GBK 编码，不处理的话正文提取出来全是乱码。n8n 的 HTTP 节点能自动处理大部分编码情况，但如果发现某个源抓下来乱码，就需要在 Function 节点里用 Buffer 配合转码库做一次显式转换，这个后面在问题排查部分细说。
正文清洗最关键的是去掉页面里的噪音：脚本、样式、导航、广告这些和正文无关的内容。我写了一段清洗逻辑放在 Function 节点里：
// n8n Function节点内：清洗HTML正文 const rawItems = $input.all(); const cleanHtml = (html) => { return html .replace(/<script[\s\S]*?<\/script>/gi, '') .replace(/<style[\s\S]*?<\/style>/gi, '') .replace(/<[^>]+>/g, ' ') .replace(/\s{2,}/g, ' ') .trim(); }; return rawItems.map(item => { const html = item.json.body || ''; const text = cleanHtml(html); const title = item.json.title || ''; return { json: { title: title, content: text, url: item.json.url || item.json.link || '', source: item.json.source || 'unknown' } }; });第一段正则把 script 和 style 整体删除，避免广告脚本和样式文本混进正文；第二段把剩余 HTML 标签替换成空格并压缩成单行。清洗后得到的content字段，就是接下来可以拼进提示词的正文内容。这一步做完，原始条目的“可读性”就具备了。
3.3 调用百炼 API 分析热点：节点配置与 Prompt 设计
这是整条链路的核心环节。在 n8n 里拖入 HTTP Request 节点，按下面的方式配置：
- Method: POST
- URL:
https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions - Authentication: 选择 Header Auth，填入
Authorization: Bearer 你的API_KEY - Body: 使用 JSON 模式，结构见下
{ "model": "qwen-plus", "messages": [ { "role": "system", "content": "你是资深AI行业编辑。请分析用户提供的新闻条目，输出JSON，字段包括：hot_score(1-10整数热度评分)、summary(100字以内中文摘要)、topic(主题标签，从这些中选择：模型发布/创业融资/行业政策/学术研究/产品更新/其他)、related_keywords(关联关键词数组)。只输出JSON，不要任何解释文字。" }, { "role": "user", "content": "标题：{{ $json.title }}\n正文：{{ $json.content.slice(0, 2000) }}" } ], "temperature": 0.3, "response_format": { "type": "json_object" } }这里有几个经验可以直接分享。
content.slice(0, 2000)是长度保护。模型上下文有限，热点分析只需要文章开头的核心信息，把正文截断到 2000 字以内，效果几乎没有下降，但响应速度和费用都会明显变好。
prompt 里“只输出 JSON，不要任何解释文字”这句话非常重要。不加这句，模型偶尔会在 JSON 外层包一个“以下是分析结果”之类的解释，后面的解析步骤就得处理这些意外文本。
temperature 用 0.3 这个档位，是为了保证同一条标题重复分析两次能得到基本一致的结果。如果调得太高，模型会在热度评分上忽高忽低，后续排序和去重都会变得不可靠。
调通这个节点之后，先跑一条静态输入测试一下返回内容，确认能被下一个节点正确解析，再接入完整的循环逻辑。
3.4 返回内容的二次解析、评分过滤与去重
百炼返回的 JSON 结构和 OpenAI 兼容格式一致，外层是 choices 数组，嵌套 message.content：
{ "choices": [ { "message": { "content": "{\"hot_score\":8,\"summary\":\"...\",\"topic\":\"模型发布\",\"related_keywords\":[\"多模态\",\"开源\"]}" } } ] }注意这里的坑：message.content 字段里存的其实是一个“字符串化的 JSON 对象”，需要先 JSON.parse 一次才能拿到真正的对象。很多人在这一步卡住，直接在 n8n 里引用$json.choices[0].message.content.hot_score，结果取到 undefined——因为 content 是字符串不是对象。
正确的做法是放在后面的 Function 节点里做解析，同时把热度评分作为过滤条件：
// n8n Function节点内：解析模型输出并过滤低热度条目 const items = $input.all(); const results = []; for (const item of items) { const rawContent = item.json.choices?.[0]?.message?.content || ''; try { const parsed = JSON.parse(rawContent); if (parsed.hot_score >= 7) { results.push({ json: { title: item.json._title, url: item.json._url, source: item.json._source, hot_score: parsed.hot_score, summary: parsed.summary, topic: parsed.topic, keywords: parsed.related_keywords } }); } } catch (e) { // 解析失败时保留原文，交给人工检查 results.push(item); } } return results;这里我提前把原始标题、URL、信息源通过_title、_url这些字段挂到了 HTTP Response 节点上，这样解析的时候不会丢失来源信息。过滤阈值我设的是 7 分，你完全可以根据自己对“热点”的苛刻程度来调整这个值。
去重逻辑我在这个节点里一并做掉：对已处理过的 URL 维护一个白名单集合，新条目的 URL 如果已经在集合里就直接跳过，避免同一篇文章被多个源重复推进管道。
3.5 结果落库与协作工具推送
过滤完的条目，最后一步是落库和推送。我的做法比较朴素：
- 用 n8n 的 Notion 节点，把每条结果作为一条记录写到 Notion 数据库里，字段就是 hot_score、summary、topic、url 这些。
- 同时用飞书机器人 Webhook 发一条汇总消息到群里，列出当天热点标题和链接。
如果是企业场景，你可能更希望写到 MySQL 或 PostgreSQL 里做后续分析，n8n 也提供原生数据库节点，逻辑是通用的。这一部分在配置上没什么特别难的点，唯一建议是推送消息的模板尽量简洁，别把整段摘要全塞进去，群里的长消息阅读率会直线下降。我的消息模板就是每个热点一行：热度分 + 标题 + 链接。
到这里，一条“自动获取 AI 热点”的工作流主体部分就完整了：定时采集、语义分析、过滤推送，几个环节全部自动化。
4. 常见问题与排查技巧实录
4.1 模型返回格式飘了：JSON 解析失败的两种兜底办法
这个问题在我运行第一周就遇到了。现象是 Function 节点时不时报错，提示Unexpected token，翻日志一看，content 字段里不是纯 JSON，而是被模型包在了 markdown 代码块里，类似下面这种形式：
```json {...}解决办法我采用了双管齐下的策略。第一，从 prompt 上堵：在 system 消息里明确写“只返回 JSON 对象，禁止使用 markdown 代码块标记”，同时把 temperature 降到 0.2 以下。第二，从代码上兜底：解析前判断有没有代码块包裹，有的话用正则先抠出来再 parse。 最终在解析函数里加上了这样一段兜底逻辑： ```javascript const extractJson = (text) => { const blockMatch = text.match(/```json\s*([\s\S]*?)```/); if (blockMatch) return blockMatch[1]; const start = text.indexOf('{'); const end = text.lastIndexOf('}'); if (start !== -1 && end !== -1) return text.slice(start, end + 1); return text; };这段兜底逻辑非常有效，基本堵住了模型格式抖动可能带来的所有异常情况。如果你在自己项目里用大模型返回结构化数据，这个函数可以直接抄走用。
4.2 抓取 403、乱码与超时的处理思路
抓取环节的问题是老三样：403、乱码、超时。
403 的坑前面提过，加 User-Agent 能解决大部分情况。剩下的两成是站点做了更严格的风控，我的原则是不硬抓，改走该源的官方 API，或者用聚合服务替代。为了过某个站点的反爬去搞更激进的操作，风险和收益完全不成比例，没必要。
乱码问题集中在个别老站点，HTTP 节点返回的 HTML 里 meta 声明是 charset=gbk，存到 n8n 里就变成了一堆替换符。处理方式是在 Function 节点里对 Buffer 做转换，或者在 node 运行环境里安装转码库后用其解码。还有一个更省事的变通方案：对这类字节级解码困难的站点，只取 RSS 里的 description 摘要传给百炼分析，效果也没有差多少。
超时问题相对简单。在 HTTP Request 节点里把 Timeout 从默认值调到一个更保守的数值，再配合 n8n 的重试机制。百炼 API 通常几秒内返回，如果长时间不响应基本都是服务端拥堵，重试一两次基本都能成功。
4.3 n8n 长时间运行后的稳定性维护
节点多了、运行久了之后，n8n 本身会暴露一些小问题，这里整理成速查表供对照：
| 现象 | 可能原因 | 处理建议 |
|---|---|---|
| 容器被 OOM 杀掉 | 长时间大量 HTTP 请求导致内存缓慢上涨 | 配合内存限制与自动重启，或定时重启容器 |
| 页面打开变卡 | 执行日志和运行数据积累过多 | 开启执行历史清理策略，只保留最近若干次 |
| 条目重复处理 | 定时触发与手动触发并发执行 | 启用排他执行，保证同一时间只有一个实例在跑 |
| 定时任务时间不对 | 容器时区配置缺失 | 显式设置 GENERIC_TIMEZONE 与 TZ |
这些都属于运行期维护问题，不影响功能逻辑，但直接影响长期稳定性。我建议在系统搭好之后就顺手把它们纳入规划，别等跑了几个月再处理。
4.4 Prompt 迭代经验：从“能用”调到“好用”
整个工作流里，花时间最多的其实是提示词调优。
初版 prompt 只让模型“总结新闻”，返回的内容很飘，经常是一堆套话，没有实际信息量。后来我把系统提示词改成“扮演资深 AI 行业编辑，以条目为单位输出 JSON，字段固定”，效果立刻改善了很多。
再往后我逐步增加限定：摘要必须包含发布方、具体数字，没有数字就要明确写“未披露”；热度评分只允许 1-10 整数；主题标签必须从给定选项里选。模型的行为就从一个泛泛的文本生成器，变成了严格按照规则执行的结构化工具。
我的体感是：对自动化流程来说，prompt 的约束力比模型本身的聪明程度更影响最终效果。先把输出格式钉死，再逐步收紧内容规范，每一次改动都重新跑一批历史条目对比效果差异。这是最稳的迭代方式，也是这套工作流最终能稳定产出高质量简报的关键原因。
5. 运行效果、踩坑体会与后续扩展方向
先汇报一下运行效果。现在每天花在这个工作流上的维护时间大概十分钟，主要就是看看执行日志有没有报警、手动处理几条模型判断拿不准的条目。以前四十分钟的机械浏览时间基本解放出来了，而且每天早上八点半整份简报准时出现，这种稳定感是人工刷页面完全没法比的。
如果后续想扩展，有几个方向我认为价值很高。加上趋势分析模块，把一周内收集的条目按 topic 聚合，让百炼生成一份“本周 AI 领域趋势变化”的周报，相当于从每日简报升级为周期洞察。接上个人知识库，把过滤后的高热度条目和摘要写入向量数据库，做一个可检索的 AI 热点知识库，后续写文章直接查。如果是团队共用，还可以做多账号绑定和权限分级，给不同成员配不同的推送渠道和关注标签。
最后分享一个我自己的体会。搭这种自动化工作流，最大的坑往往不在技术，而在需求没想清楚。一开始我以为自己只是需要“抓取工具”，跑了两天才发现真正需要的是“过滤 + 语义分析”的能力，于是把重心挪到了百炼的接入和 prompt 设计上。如果你也想搭一套类似的系统，建议先花半天把每天看信息时的真实动作列出来——你需要的到底是全量存档，还是只看少数高价值信息？这个问题的答案，会直接决定你的工作流最终长成什么样。
