监控维基百科品牌词条改动并邮件简报

原文要点

原模板为免费 n8n 工作流：每周(或手动)触发，读取设置的维基百科条目名、语言、User-Agent 与收发邮箱；向 Wikipedia 拉取最新修订元数据、向 Wikidata 拉取对应实体信息；与 n8n Data Table 中存的上次 revid 比对，把来源分类为 edited/unchanged/first look/missing；有改动时调用 MediaWiki compare 接口取 diff，页面消失时用维基搜索或 Wikidata 实体搜索找近似条目；将增删行交给 OpenAI 判断是否影响品牌描述并定优先级，组装 HTML 邮件经 SMTP 发出，最后把最新 revid 与状态 upsert 回 Data Table。

这次做成什么

在自有 n8n 实例里搭一个每周运行的品牌词条监控：盯 2 个虚构品牌词条及其 Wikidata 项，发现改动后自动生成带优先级标注的 HTML 简报邮件。练习数据与提示词均为本站设计。

准备什么

• 一个支持 Data Tables 功能的 n8n 实例(Cloud 或自托管新版)
• OpenAI API 凭据(用于 Chat 模型判断改动重要性)
• 可用的 SMTP 发信凭据(发件邮箱与授权码)
• 要监控的维基百科条目的精确标题(区分大小写)
• 一个用于 Wikimedia 请求的联络用 User-Agent 字符串

具体怎么做

1. 建 Data Table 存修订历史

   在 n8n 左侧 Data tables 新建表 entity_watch，依次加列 source_key、entity、source、revid、state、checked_on。revid 用数字类型，其余用字符串。首跑时表为空，所有来源会被归为 first look，属正常现象。

2. 配置 Settings 节点

   在工作流里放 Schedule Trigger 设为每周，再接一个 Set/Code 节点写入：titles(精确条目名数组)、language(如 en 或 zh)、user_agent(含你的联系邮箱)、email_to、email_from。后面所有节点都从这里读配置，换词条只改这一处。

3. 拉取 Wikipedia 与 Wikidata 最新版本

   用 HTTP Request 节点循环 titles：对维基调 action=query&prop=revisions&rvprop=ids|timestamp 取最新 revid；对 Wikidata 用条目的 pageprops/wikibase_item 找到 Q 号后取实体 lastrevid。请求头带上面配置的 User-Agent，否则维基可能拒请求。

4. 与历史比对并分类

   Merge 两路结果后，用 Code 节点按 source_key 查 entity_watch：查不到记 first look；revid 相同记 unchanged；不同记 edited。同时把维基返回中页面不存在的记 missing。只把 edited 和 missing 往后传。

5. 取 diff 或搜近似条目

   edited 来源调 MediaWiki compare 接口(fromrev=旧 revid,torev=新 revid)拿 HTML diff，用 Code 节点抽新增与删除行；missing 来源调维基 list=search 或 Wikidata wbsearchentities，取前几条候选名与链接。

6. OpenAI 判优先级并发邮件

   把结构化增删行连同条目名发给 OpenAI Chat 节点(提示词见下方材料)，要求返回 priority 与 reason。再用 HTML 模板节点组装简报：每条含条目链接、diff 摘要、优先级标签、missing 候选列表，经 SMTP 节点发到 email_to。

7. 回写最新修订号

   最后用 Data Table 的 upsert 操作，按 source_key 为每个监控来源写一行最新 revid、state 与 checked_on(当前日期)，供下周比对。

可直接复制的材料

你是品牌词条监控助手。下面是维基百科或 Wikidata 上一个品牌条目的本次改动，包含被删除的行(以 - 开头)和新增的行(以 + 开头)。条目名:{entity} 来源:{source}
改动内容:
{diff_lines}
请只判断这些改动是否影响公众对该品牌的认知(如公司定位、产品、创始人、争议、数据口径),忽略纯排版、错别字、分类链接类小编辑。严格输出 JSON:{"priority":"high|medium|low","affects_brand":true或false,"reason":"不超过40字的中文说明","summary":"不超过60字的改动中文摘要"}。不要输出 JSON 以外的任何内容。

source_key,entity,source,revid,state,checked_on
wiki:en:ExampleCo,ExampleCo,wikipedia,1240000001,unchanged,2026-09-02
wikidata:Q900001,ExampleCo,wikidata,2300000001,edited,2026-09-02

{
  "titles": ["ExampleCo", "ExampleCo Cloud"],
  "language": "en",
  "user_agent": "BrandWatchDemo/1.0 (contact: ops@example.com)",
  "email_to": "brand-team@example.com",
  "email_from": "noreply@example.com"
}

输入与输出示例

本站虚构演示,提示词与 diff 均为示例,未实际调用 OpenAI 或维基接口。

输入

监控条目 ExampleCo(en)与 Wikidata 项 Q900001;上周 revid 分别为 1240000000 与 2300000000,本周 Wikidata 描述从“软件公司”被改为“已停业的软件公司”。

对应输出

简报邮件含一条 high 优先级记录:Wikidata Q900001 描述新增“已停业”字样,affects_brand=true,reason=“停业表述直接影响品牌认知”,附 diff 链接;维基条目 unchanged 不列入正文,仅在末尾计数。

做完检查这些

• Data Table entity_watch 六列齐全,首跑后每个来源都能写入一行且 revid 为数字
• 故意把表中某行 revid 改成旧值后手动触发,该来源被分类为 edited 并生成 diff
• 把 titles 里一个不存在的条目名加入,简报中出现 missing 及候选搜索链接
• OpenAI 节点输出能被解析为含 priority/affects_brand/reason/summary 的 JSON
• SMTP 节点成功发出 HTML 邮件且收件人可点开条目链接

容易卡住的地方

• titles 必须是条目精确标题,拼写或大小写错了会被当成 missing
• Wikimedia 要求带联络信息的 User-Agent,缺了可能拿不到数据
• Data Table 为空的首跑会把所有条目标为 first look,不代表出错
• OpenAI 偶尔返回非纯 JSON,建议节点后加解析容错再继续
• 自托管 n8n 若版本过旧没有 Data Tables 功能,需先升级