一、拾枝杂谈

1.关于 WorkBuddy 和 Playwright

WorkBuddy 是腾讯在今年三月份新推出的一个 AI Agent 平台，用官方的话说呢，叫做“全场景职场 AI 智能体桌面工作台”。其实就是一个Agent产品，只不过它的侧重点不是写代码，而是多生态的集成，比如飞书、钉钉、微信等。

和目前主流的 Agent产品 如Cursor，CC，Codex等一样，WorkBuddy 作为一个 Agent 产品，可以执行具体任务，比如读写本地文件、运行爬虫脚本、操作浏览器（Playwright）、通过命令行调用飞书 API 写入数据表，等等，总之它能干的活儿很多。

而且就像主流的 Agent 一样，它同样具备分析、拆解，和 执行复杂任务的能力。只不过还是那句话，它的侧重点，或者说它的卖点，不是专门写代码，而是多生态集成下的办公提效。

我这次是借助 WorkBuddy，配合 PlayWright 帮我爬取多平台的文章数据，然后统一写到飞书表格，这样就不用我自己一个个平台，一篇篇文章去统计了。

具体在搭建过程中，WorkBuddy 扮演了三个角色：一是架构师，WorkBuddy帮我设计了平台爬取策略和飞书表结构；二是码农，我利用WorkBuddy为每个平台单独编写了 Python + Playwright 脚本；三是运维，我还让WorkBuddy帮我部署自动化任务，这样我可以每天定时或手动触发数据采集，自主性拉满了。

2.关于多平台数据矩阵的搭建

因为我本身是一个内容创作者，就是一写文章的，不是AI文啊。然后你作为一个创作者，你肯定不能只在一棵树上吊死吧，所以我一般会把自己写好的文章发布在不同的平台，例如CSDN、微信公众号、知乎，等等。

然后是我想统计一下每个平台下面的每一篇文章的数据，按照每一天来统计累计量，我希望通过这些统计好的数据来构建自己的数据矩阵，但是你想想这个任务的复杂度。

手动做这件事是这样的：先打开不同平台的创作后台 → 然后逐个找"文章管理"或"数据分析" → 挨个复制阅读量、点赞、评论、收藏等 → 粘贴到飞书表格 → 第二天再做一遍。

而且这里面最可怕的是什么，如果你要统计每篇文章每天的数据，那随着你写文章越来越多，你消耗的时间会以指数级上升。

这不仅浪费时间，而且极易出错 —— 漏一行、贴错列、忘了某个指标，时间久了连数据都不可信。

所以我决定尝试让 WorkBuddy 帮我搭建一个自动化数据收集系统：每天一键爬取多个平台的数据，自动写入飞书知识库，格式化、去重、保留历史趋势。

注意，我爬取的可是我自己的数据！所有数据爬取的前提是我登录我自己的多平台账号。

3.关于这篇文章的由来

从最初提出需求到跑通七个平台的数据流，花了我整整三天时间，过程中踩了无数坑，比如字段名猜错了、历史数据被清空了、标题差一个空格导致匹配失败了、日期选择器有两个而不是一个，等等。

每踩一个坑都是一次血与泪的教训，每踩一个坑也都是一次"Agent+人协作"的实战经验。

这篇文章只是一个阶段性的总览 —— 我会先简单介绍七个平台的爬取策略差异、各自遇到的核心问题及解决思路。因为篇幅限制，各个平台遇到的问题以及解决方案，我会在后面单独写文章来深挖。

---

二、多平台数据矩阵的搭建策略

1.前言

在总体思路上，搭建七个平台的数据矩阵有一个通用的工作流：

1. 登录账号 — 各平台先登录一次，之后 Playwright 会使用复制的 Chrome profile 保存登录状态，下次跑脚本时自动免登。
2. 探索页面结构 — 先写一个"探索脚本"，截取页面 HTML 和截图，用于分析 DOM 结构，并确认真实的统计字段名称。
3. 编写正式爬虫 — 基于探索结果遍写完整的数据采集脚本：导航到数据页面 → 筛选日期 → 解析数据 → 保存 JSON。
4. 飞书写入 — 使用 FeishuSheetWriter.write_scraped_data() 标准路径：按文章标题匹配已有子表 → 追加今天的数据行 → 格式化（黄色表头 + 日期列 12pt）。如果列结构不一致，自动做"安全迁移"（保留历史数据 → 重新映射列 → 追加新行）。
5. 自动化任务 — 将脚本部署为 WorkBuddy Automation，设为 PAUSED 状态，需要时一键触发。

在写入飞书表格时，还要注意以下核心原则：

• 日期列 = 当天爬取日期（不是文章发布日期）
• 每个平台的飞书表头 = 该平台自己的真实字段，绝不继承其他平台
• 绝不删除历史数据：列不对就迁移，而不是清空重写
• 去重保护：如果当天已经跑过，自动跳过

然而，七个平台的后台结构各不相同，每一个都需要针对性处理，实在是令我头大。

2.搭建 CSDN 数据分析的方法

入口： mp.csdn.net → 数据中心 → 内容分析 → 单篇分析

字段： 日期、展现量、阅读量、点赞、收藏、评论

CSDN 的数据结构最为标准 —— 有一个清晰的表格，每篇文章一行，带专栏按钮。数据页面的 URL 直接包含日期参数，不需要手动操作日历选择器，总之非常友好。

3.搭建微信公众号数据分析的方法

入口： mp.weixin.qq.com → 数据 → 内容分析 → 已群发 → 文章详情

字段： 日期、阅读量、点赞、在看、分享、评论、转载

微信公众号的数据结构最为复杂：不是一个标准表格，而是每个文章入口带一组统计数字。需要先提取文章列表 URL 参数中的 token（从首页 URL 截取），再调用 publish_page 全局变量获取数据。

关键点在于微信的统计数据单位——不需要展示的字段（展现量、收藏）存储为空字符串而非 0，避免误导。每一篇文章的详细统计数据需要通过 HTML unescape 解码后提取。

4.搭建知乎数据分析的方法

入口： www.zhihu.com/creator/manage/creation/article → 创作中心 → 内容管理

字段： 日期、阅读、赞同、评论、收藏、喜欢

知乎的字段命名有细微差别：不是"阅读量"而是"阅读"，并且"赞同"和"喜欢"是两个独立指标（大多数平台的"点赞"在知乎里一分为二）。数据在卡片式布局中，发布时间藏在 data-tooltip 属性里。

知乎是第一个让我意识到"不要复制 CSDN 字段模板"的平台 —— 如果直接用 CSDN 的字段定义（展现量、阅读量、点赞），会丢掉知乎独有的"赞同"和"喜欢"指标。

5.搭建今日头条数据分析的方法

入口： mp.toutiao.com → 管理 → 作品管理 → 数据 → 内容分析

字段： 日期、展现、阅读、点赞、评论

今日头条的"展现"和"阅读"是两个独立的指标，没有"收藏"和"转发"字段。它的后台使用一个分页的数据列表，每页 30 条，需要翻页或调整 pageSize 参数才能一次获取所有文章。

今日头条我踩了最大一个坑：我最初写的 write_to_feishu 方法直接调用了 _clear_with_retry —— 这在每次运行时都会清空整个飞书表格，把历史数据全部删掉。后来修复为使用 write_scraped_data 标准路径，加入去重和安全迁移逻辑。

6.搭建小红书数据分析的方法

入口： xiaohongshu.com/user/profile → 更多 → 创作中心 → 创作服务 → 笔记管理

字段： 日期、阅读、评论、点赞、收藏、分享

小红书的导航是最复杂的：需要经过三层菜单（更多 → 创作中心 → 创作服务）才能跳转到 creator.xiaohongshu.com 的后台。笔记数据在卡片式布局中，每张卡片有 5 个图标字段，没有文字标签。

最大的问题是字段确认 —— 5 个图标没有 tooltip，只能靠图标形状推测含义。第一次跑的时候猜错了"分享"和"转发"的关系，把两个同义字段当成了不同字段，导致表头多了一列。

7.搭建百家号数据分析的方法

入口： baijiahao.baidu.com/builder/rc/home → 内容管理 → 作品管理 → 图文

字段： 日期、阅读量、评论量、点赞量、收藏量、分享量

百家号的文章卡片上显示了 6 个数字，但我觉得第6个字段暂时没啥统计价值，所以只想要前 5 个（阅读量、评论量、点赞量、收藏量、分享量），第 6 个是"分润和赞赏收益"，不统计。

最尴尬的失误：第一次探索时WorkBuddy根据图标外形猜第一个字段是"推荐量"，写入了 config 和飞书表头。后来我纠正说根本没有推荐量，最前面就是阅读量，让WorkBuddy把"转发"值合并到"分享量"并删除转发列。最后通过 hover 到图标才确认了真实字段。

8.搭建搜狐号数据分析的方法

入口： mp.sohu.com/mpfe/v4/contentManagement → 数据分析 → 内容分析 → 单篇 → 图文

字段： 日期、阅读数、访问数、点赞数、评论数、分享数、投票数

搜狐号是最难爬的一个。数据页面使用了 Element UI 的 el-table 组件（不是标准 HTML 表格），数据在第二个"数据列表"选择器下（页面上边还有一个"内容影响力分析"图表区），两个日期选择器需要分别设定。

第一次尝试全部解析失败（0 条数据），经过排查才找到正确的 DOM 选择器：.el-table__body tbody tr → .label 取标题 → div.cell 取数值。这充分说明不能假设所有平台都使用标准 <table> 标签。

---

三、多平台矩阵搭建过程中遇到的问题

1.CSDN

• 展现量需单篇提取：列表页不显示展现量，需要进入每篇文章的单篇分析页面才能获取

2.微信公众号

• 数据格式差异：微信公众号的后台结构不是标准表格，需要从页面变量 publish_page 全局对象中解析数据，配合 html.unescape 解码特殊字符
• 字段差异化处理：没有展现量和收藏字段，空字段存储为空字符串而非 0

3.知乎

• 字段命名陷阱：知乎用"阅读"而非"阅读量"，"赞同"和"喜欢"是两个独立指标，不能混用其他平台的字段模板
• write_to_feishu 直接调 _clear_with_retry：此方法每次运行时清空整个飞书表，导致所有历史数据丢失 —— 后修复为标准 write_scraped_data 路径

4.今日头条

• 历史数据被清空：同样存在 _clear_with_retry 的破坏性问题。用户在飞书用版本回滚恢复了数据，然后修复了写入逻辑
• 旧列残留：由于旧数据中"展现量"字段值含逗号（“1,354”），CSV 解析产生列偏移，导致迁移后阅读量和转发列数值错位

5.小红书

• 导航路径复杂：三层菜单跳转（更多 → 创作中心 → 创作服务），"更多"菜单需要查找隐藏元素
• 字段图标确认困难：5 个无文字标注的图标，"分享"和"转发"实为同一指标但在不同上下文使用了不同列名，需要 rename_map 处理
• GEO 编号混乱：第一轮运行时因标题微小差异（“AI 一直” vs “AI一直”）匹配失败，重复创建了节点，且后续重跑产生重复数据行

6.百家号

• 字段名猜错：探索阶段误将第一个数据列标注为"推荐量"，经用户纠正后确认为"阅读量"（前 5 个是统计字段，第 6 个是分润收益）
• 旧列残留：迁移后"转发"列未被清除，需要手动用 cells-clear 删除 G 列
• rename_map 漏项：最初忘了 "转发": "分享量"，导致转发值没迁移到分享量列

7.搜狐号

• Element UI 表格：搜狐号使用 Vue + Element UI 的 el-table 组件，标准的 querySelectorAll('table') 找不到数据
• 两个日期选择器：内容影响力分析图表区和数据列表表格区各有一个日期选择器，只设一个会导致表格不更新
• 日历弹窗遮挡：fill() 输入框触发日历弹窗后未关闭，需要在填充后按 Escape 关闭

---

四、沉淀结果

1.Skill

在搭建过程中提炼了两个可复用的 Skill：

• platform-field-matching：规定每个平台的飞书表列必须使用该平台自己的真实字段，匹配列保留旧值、新列留空、旧列删除，严禁删除历史数据行
• feishu-table-formatting：统一飞书表格的视觉格式 —— 表头行（黄色背景 + 粗体 + 14pt）+ 日期列（12pt），跨平台、跨操作一致

2.Automation

七个平台各配置了一个 WorkBuddy Automation 任务，每个任务都是独立的 PAUSED 状态（需要时在 Automation 页面点 ▶ 手动触发）。任务自动完成浏览器启动 → 登录检测 → 数据采集 → 飞书写入 → 格式化 → 关闭浏览器的完整流程。

这种"一个平台一个任务"的设计确保了：某个平台出问题不影响其他平台、可以错开时间执行避免 Chrome profile 冲突、调试时日志清晰可追溯。

---

Δ总结

用了整整三天时间，通过 WorkBuddy Agent + Playwright，多次尝试，修复N个Bug，最终实现了七个内容平台的数据自动采集和飞书汇总。

最大的感悟是：AI Agent 不是"一键搞定一切"的魔法工具，真正的价值在于"人 + AI 的迭代协作" —— Agent 快速搭建框架、执行机械操作，人负责确认字段、纠正错误、提供业务判断。

两者互相补位，才能在一天内跑通一个原本需要一个人数十天手动工作的系统。

后续我还会拆解每个平台遇到的问题，单独写文章深入分析，包括标题匹配算法改进、安全迁移机制的设计理念、以及自动化任务的 Prompt 工程。