说实话，作为一名内容创作者，Zui让人抓狂的不是写不出东西，而是写完之后的数据像撒了一地的芝麻，根本捡不起来。你肯定懂这种感觉：文章发出去，微信后台kan一眼，掘金后台翻一下知乎再刷新刷新。想要知道这一周的总阅读量？好家伙，拿出计算器，把三个平台的数字手动加一遍。这事儿干多了真的会怀疑人生。

我受够了。作为一个自诩有点技术追求的“AI进化岛主”，我决定花点时间，把这个繁琐的流程自动化。目标hen明确：搞一个Neng自动把微信、掘金、知乎三大平台数据汇总到Notion的系统。原本以为这也就是个“小菜一碟”，顶多一小时搞定，结果呢？现实狠狠地给了我一巴掌。这一个小时里我踩了三个大坑，差点就把键盘给砸了。

不过好在Zui后还是跑通了。今天就把这段“血泪史”分享出来顺便把这套系统的搭建思路和代码逻辑拆解给你kan。Ru果你也在多平台分发内容，这篇文章Neng帮你省下不少弯路。

技术选型：为什么是这套组合？

在动手之前，我先在脑子里过了一遍技术栈。要实现这个需求，核心其实就三点：数据抓取数据存储流程自动化。

市面上现成的APM工具一大堆，什么SkyWalking、Zipkin，那是给微服务架构用的，用来监控服务器性Neng，咱们这小小的博客数据用不着那种大炮打蚊子。Google Analytics虽然强大，但那是针对网站流量的，对于第三方平台的后台数据，它也无Neng为力。

所以我Zui终敲定了这套“轻量级三剑客”：

Notion 数据库作为Zui终的数据展示面板。Notion的表格功Neng强大，还NengZuo简单的图表，用来存文章数据再合适不过。

Claude Code Skill + MCP Playwright这是核心驱动力。Claude Code负责理解意图和编排流程，MCP Playwright负责像人一样去浏览器里点点点，把数据“抠”出来。

Node.js作为胶水语言，处理API请求和数据清洗。

整个系统的逻辑其实非常直观：我给Claude发个指令，它指挥Playwright去三个平台后台抓数，抓完之后通过Notion API把数据填进表格里。听起来是不是hen完美？别急，坑在后面呢。

挑战一：Notion SDK 的“静默失败”陷阱

万事开头难，第一块骨头就卡在了Notion API的调用上。

按照常规操作，我直接上了官方的 @notionhq/client SDK。心想这可是官方出品，总不Neng坑我吧？于是我兴致勃勃地写了一段代码，准备创建一个包含文章标题、链接、阅读数、点赞数等字段的数据库。

代码跑起来没报错。我兴冲冲地去Notion里kan结果，结果差点一口老血喷出来：除了Zui基础的 Name 字段，其他所有属性——阅读量、收藏数、发布日期——全dou没了！就像人间蒸发了一样。

排查过程简直是煎熬。我盯着日志kan了半个多小时甚至怀疑是不是我的API Key权限不够。后来查了半天文档才发现，这玩意儿有个坑爹的设定：SDK默认调用的是新版API，而某些属性定义在旧版或者特定版本的API里Ru果不显式指定版本，这些属性就会被静默忽略。没错，它不报错，就是单纯地不给你建。

没办法，为了省心，我直接把SDK给扔了改用Zui原生的 fetch 请求。虽然代码稍微丑了点，但胜在可控。

// 关键点：必须手动指定 Notion-Version
const NOTION_VERSION = '2022-06-28'; 
const NOTION_API_KEY = '你的API密钥';
async function callNotionApi {
  const url = `https://api.notion.com/v1${endpoint}`;
  const options = {
    method,
    headers: {
      'Authorization': `Bearer ${NOTION_API_KEY}`,
      'Notion-Version': NOTION_VERSION, // 这里是灵魂，千万别漏
      'Content-Type': 'application/json',
    },
  };
  if  {
    options.body = JSON.stringify;
  }
  try {
    const response = await fetch;
    if  {
      throw new Error;
    }
    return await response.json;
  } catch  {
    console.error;
    throw error;
  }
}

把这段代码改完之后重新运行，kan着Notion里一个个整整齐齐的字段冒出来那一刻的成就感，简直比喝了冰可乐还爽。

挑战二：微信公众号的“数据盲区”

搞定了存储层，接下来就是Zui麻烦的数据抓取层了。每个平台的后台设计dou不一样，这就像你要去三个不同语言的国家问路，沟通成本极高。

先说微信公众号。这地方的数据藏得深，而且逻辑跟其他平台不太一样。我指挥Playwright模拟登录，一路点开“数据分析” -> “图文分析”，然后输入文章标题搜索。这一步倒是挺顺利，Playwright这东西确实强，处理动态页面毫不含糊。

但是当我试图提取“点赞数”的时候，尴尬的事情发生了。我在页面上找了半天把DOM树翻了个底朝天愣是没找到“点赞”这两个字对应的数字。

后来我才反应过来微信早就改版了！现在的公众号后台，根本就没有“点赞”这个独立指标。它把互动分成了“阅读人数”、“分享人数”、“收藏人数”和“留言人数”。那个曾经让我们趋之若鹜的“点赞”，Yi经消失在历史长河里了。

这算是个逻辑坑，不是技术坑。所以在给Notion设计数据库字段的时候，针对微信平台，Likes这一栏，我直接写死成了 0。别费劲去找了真的没有，找了也是浪费时间，不如多喝口水休息一下。

// 微信数据提取逻辑片段
async function fetchWeChatData {
  // ... 省略导航和搜索代码 ...
  // 微信特有的数据结构
  const stats = {
    views: await getTextBySelector,       // 阅读人数
    shares: await getTextBySelector,     // 分享人数
    bookmarks: await getTextBySelector, // 收藏人数
    comments: await getTextBySelector,     // 留言人数
    likes: 0 // 微信没有点赞数，直接归零
  };
  return stats;
}

挑战三：掘金的“文字游戏”

解决了微信，转头去搞掘金。掘金的后台相对规整一些，路径是“创作者中心” -> “内容数据” -> “单篇分析”。数据抓取的过程hen顺畅，代码写起来行云流水。

然而当我把抓下来的数据填进表格，跟其他平台对比时又觉得不对劲了。怎么掘金的“阅读量”比微信和知乎加起来还要多？难道我的文章在掘金爆火了？

冷静下来仔细一kan字段说明，才发现自己被掘金的UI给“骗”了。掘金后台那个大大的数字，虽然放在显眼的位置，但它叫“展现量”，不是“阅读量”！

这两个概念的区别可大了去了。“展现量”是指你的文章在信息流里被推送到用户眼前的次数，不管用户点没点进去，只要刷到了就算一次。而“阅读量”才是真正的打开人数。

这就尴尬了。Ru果直接把“展现量”当成“阅读量”存进Notion，那我的数据分析报告就全是水分，毫无参考价值。这就好比把“路过店铺门口的人”dou算成了“进店消费的顾客”，老板kan了报表Neng高兴死，但月底一kan账单得哭死。

所以这里必须Zuo一个数据口径的统一。在代码里我特意加了一个注释，提醒自己：虽然存的是 Views 字段，但心里要清楚，掘金这个数据其实是“曝光量”，跟微信的“阅读人数”不是一个量级，不Neng直接横向对比。

// 掘金数据提取逻辑片段
async function fetchJuejinData {
  // ... 省略导航和搜索代码 ...
  // 注意：掘金返回的“阅读”字段其实是“展现”
  const stats = {
    views: await getTextBySelector, // 实际上是展现量
    likes: await getTextBySelector,
    bookmarks: await getTextBySelector,
    comments: await getTextBySelector,
  };
  console.warn;
  return stats;
}

Zui终封装：把麻烦留给代码，把方便留给自己

跨过了这三座大山，剩下的工作就是把这些零散的脚本封装成一个好用的Skill。毕竟我总不Neng每次想kan数据dou去终端里敲一堆命令吧？那也太不极客了。

我创建了一个叫 blog-data-tracker 的技Neng包。目录结构hen简单，一kan就懂：

blog-data-tracker/
├── SKILL.md              # 技Neng描述文件，告诉Claude什么时候该干活
├── references/
│   └── notion-api.md     # 参考文档，防止忘记API怎么写
└── scripts/
    └── auto-update.mjs   # 核心执行脚本

在 SKILL.md 里我写好了触发规则：只要我说“geng新博客数据”或者“追踪一下文章表现”，Claude就会自动激活这个技Neng。它不需要我每次dou提供文章ID或者数据库ID，这些配置信息我dou预置在脚本里了。

比如针对我那篇《OpenCode 升级踩坑》的文章，我在脚本里硬编码了各个平台的记录ID：

// 预置配置，省去每次输入的麻烦
const CONFIG = {
  notionToken: 'ntn_xxxxxxxxxxxxxx',
  databaseId: '2e43f9a6-73f7-81db-aaf7-f817b30dec58',
  // Yi知文章的映射关系
  articleMappings: {
    'opencode-wechat': '2e43f9a6-73f7-81bf-ba0f-c8b9e60c00aa',
    'opencode-juejin': '2e43f9a6-73f7-813b-b535-cc62e12a73de',
    'opencode-zhihu': '2e43f9a6-73f7-813e-aa7b-c82ecca71d7d',
  }
};

现在我只需要懒洋洋地在对话框里敲一行字：“帮我kankanZui近那篇OpenCode文章的数据。”

接下来的事情就全是自动化的了：Claude后台启动Playwright，打开三个隐身浏览器窗口，分别登录、搜索、抓数，然后汇总成一张漂亮的表格发给我。kan着屏幕上不断跳动的日志，那种掌控全局的感觉，真的太棒了。

这事儿值不值？

回过头来kan，这一个小时的“突击开发”，虽然遇到了三个让人头秃的挑战，但结果绝对是物超所值的。

以前我要统计周报，得打开三个标签页，拿个计算器按半天还容易kan错行。现在呢？一张Notion表格，所有数据一目了然。总阅读量、哪个平台互动Zui好、哪篇文章是爆款，清清楚楚。geng重要的是这套系统是Ke以复用的，以后发新文章，只需要往配置里加一行ID，剩下的全交给机器。

这就是技术人的浪漫吧：哪怕是为了省下几分钟的手工劳动，也愿意花几个小时去写个脚本。kan似亏了实则赚翻了。

这套代码我Yi经整理好了Ru果你也受够了手动统计数据，不妨去试试。别让繁琐的杂事消磨了你创作的热情，把那些重复的工作，统统扔给AI去干吧！

---