WorkBuddy配合Playwright——多平台数据矩阵搭建实战（从数据爬取到飞书表格汇总一套打通）

一、拾枝杂谈

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 + 人协作” 的宝贵实战经验。

后续在运行自动化任务时，我才发现Python脚本的健壮性有问题，于是我又花了数天时间解决各个平台的分页逻辑、滚动逻辑，包括公众号上文章和贴图的区分。

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

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

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 的数据结构最为标准 ：有一个清晰的表格，每篇文章一行，带专栏按钮。Python爬虫可以直接解析每篇文章的发布日期，在代码中过滤掉早于起始日期的文章，不需要手动操作日历选择器，总之非常友好。唯一需要注意的就是展现量获取，注意分页处理和Ajax等待控制。

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

入口： mp.weixin.qq.com → 内容管理 → 发表记录 → 分页逻辑处理

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

微信公众号的数据结构最为复杂：数据在 publish_page JS 全局对象里，不是标准 DOM 表格。每个文章入口带一组统计数字，需要先从登录后的首页 URL 中提取 token 参数，拼接到文章列表 URL（appmsgpublish?sub=list）上，再读取页面内嵌的 publish_page 全局变量获取数据，最后用 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 标准路径，加入去重和安全迁移逻辑。

其实“破坏性清空”这个Bug在知乎的时候就出现过了，但是我当时是手动修复的。到了头条的时候，我才让 WorkBuddy 从代码层面彻底修复。

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

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

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

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

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

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

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

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

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

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

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

入口： mp.sohu.com/mpfe/v4/contentManagement → 数据分析 → 内容分析 → 单篇 → 图文 → 控制日期选择器

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

搜狐号是最难爬的一个。数据页面使用了 Element UI 的 el-table 组件，虽然最终渲染出来的仍是 HTML

第一次尝试全部解析失败（0 条数据），经过排查发现两个原因：一是底部日期选择器没被正确设定，导致表格没加载目标数据；二是盲目遍历所有 <table> 标签拿不到准确的行结构，最终通过精准选择器 .el-table__body tbody tr → .label 取标题 → div.cell 取数值才成功。

但是随着我写得文章越来越多，创作后台开始分页展示，el-pagination 点击页码 URL 不变、局部刷新，Playwright 驱动不稳；同时日期选择器 JS 设值无法触发查询。我想既然页面本身用 AJAX 请求数据，于是我干脆改为捕获页面自身的 AJAX 请求（single/list 接口）直接调用 API 循环翻页——这比 DOM 解析稳定得多。

三、多平台矩阵搭建过程中遇到的问题及解决方案

1.CSDN

• 展现量需单篇提取：列表页不显示展现量，需要进入每篇文章的单篇分析页面才能获取。
• 方案可行性验证：CSDN是我用 WorkBuddy + Playwright 打造多平台数据矩阵开始尝试的第一个平台，算是第一个试验田，毕竟我也在CSDN上写了5年文章了😂。所以展现量的单独获取确实是CSDN上“特有”的问题，但绝对不是这个过程中最厉害的问题。最厉害的问题还是方案可行性的验证，即 WorkBuddy 给我提供的方案能不能成功。
• 解决方案：如下链接所示

https://blog.csdn.net/fastopAI/article/details/163334543?spm=1001.2014.3001.5501

在这篇文章中，我重点讲解了如下内容：

1. 首先介绍了 WorkBuddy 是如何操作飞书表格的，用到了飞书官方的 Skill。
2. 然后介绍了 Playwright 的自动化策略。
3. WorkBuddy 提供的两种自动化方案 对比与选型。
4. 采用第一种方案踩的坑（调试端口失效、Chrome新版本的安全策略、Profile登录态失效）
5. 采用第二种方案踩的坑（Playwright无法加载原生profile、窗口设置时间过短）
6. 配置文件 config.py 的功能说明，以及和各平台脚本的关系说明
7. Python脚本代码源码，以及表格讲解

2.微信公众号

• 数据格式差异：微信公众号的后台结构不是标准表格，需要从页面变量 publish_page 全局对象中解析数据，配合 html.unescape 解码特殊字符
• 字段差异化处理：不同平台的数据统计情况是不一样的，主要体现在统计字段不同，比如微信公众号不存在“展现量”这一字段，但是有“在看”，“转载”这样的特有字段。也就是说，每个平台的数据统计字段是不完全匹配的。
• 解决方案：链接如下：

https://blog.csdn.net/fastopAI/article/details/163358386?spm=1001.2014.3001.5502

在这篇文章中，我重点讲解了如下内容：

1. 多平台统计字段不一致的问题（原因 + 解决方案）
2. 新旧字段不一致的问题（情况说明 + 解决方案）
3. platform-field-matching Skill 的诞生和作用
4. feishu-table-formatting Skill 的诞生和作用
5. 数据的特殊提取形式：通过执行JS代码直接访问 window.publish_page JS对象

3.知乎

• 字段命名陷阱：知乎用"阅读"而非"阅读量"，"赞同"和"喜欢"是两个独立指标，不能混用其他平台的字段模板
• write_to_feishu 直接调 _clear_with_retry：此方法每次运行时清空整个飞书表，导致所有历史数据丢失 —— 后修复为标准 write_scraped_data 路径
• 解决方案：清空飞书表格的Bug解决，我放在下文 “小红书篇” 了，大家可以移步下文。我在解决知乎爬虫问题的时候，重点是研究了 WorkBuddy 的三层Memory机制。链接如下：

https://blog.csdn.net/fastopAI/article/details/163373246?spm=1001.2014.3001.5502

在这篇文章中，我重点讲解了如下内容：

1. 引出了 WorkBuddy 的 MEMORY.md 超限截断的问题
2. 介绍了 MEMORY.md 和当前工作目录的关系
3. MEMORY.md 超限被截断的处理方法（画图详解）
4. WorkBuddy 三层Memory机制讲解
5. Playwright是如何识别网页的

4.今日头条

• 历史数据被清空：同样存在 _clear_with_retry 的破坏性问题。up 通过在飞书用“历史版本” 回滚恢复了数据，然后修复了写入逻辑
• 登录态误判：脚本一开始对登陆态的判断并不是进行严格的 DOM 检测，而是玩了 文字游戏，导致一开始无法正常登录。
• 解决方案：飞书破坏性清空的Bug解决，我放在下文 “小红书篇” 了，大家可以移步下文。头条相关的问题解决，链接如下：

https://blog.csdn.net/fastopAI/article/details/163448249?spm=1001.2014.3001.5502

在这篇文章中，我重点讲解了如下内容：

1. 回顾了“多平台数据矩阵搭建”的三大难点。
2. 说明了头条脚本一开始的问题表现。
3. DOM检测是如何解决登录判断问题的。

5.小红书

• 导航路径复杂：三层菜单跳转（更多 → 创作中心 → 创作服务），"更多"菜单需要查找隐藏元素
• 标题 CJK 归一化问题：第一轮运行时因标题微小的 空格差异（“AI 一直” vs “AI一直”）匹配失败，重复创建了节点，且后续重跑产生重复数据行
• 解决方案：分两篇文章，第一篇文章就是 飞书表格破坏性清空 的彻底解决方案；第二篇文章是 “CJK归一化问题” 的详细讲解。

第一篇文章 —— “飞书表格破坏性清空问题” ，链接如下：
https://blog.csdn.net/fastopAI/article/details/163505687?spm=1001.2014.3001.5502

在这篇文章中，我详细讲解了如下内容：

1. 破坏性清空发生的原因是什么
2. 安全迁移 Skill 是如何解决破坏性清空的
3. “安全迁移” 全景架构详解，含代码详解
4. 公用的飞书写入脚本，在各大平台的爬虫脚本中是如何调用的
5. 写入飞书表格的方法，又是如何调用安全迁移的

第二篇文章 —— “CJK 归一化问题”，链接如下：
https://blog.csdn.net/fastopAI/article/details/163570377?spm=1001.2014.3001.5502

在这篇文章中，我详细讲解了如下内容：

1. 标题匹配失败出现的原因
2. CJK归一化是什么
3. 爬虫是如何将平台上的文章标题匹配到飞书表格的标题的，含代码讲解
4. CJK归一化背后支撑的代码详解，包括举例讲解，正则规则讲解

6.百家号

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

https://blog.csdn.net/fastopAI/article/details/163541278?spm=1001.2014.3001.5502

在这篇文章中，我主要分享了如下内容：

1. 百家号字段名猜错的问题表现
2. WorkBuddy出现幻觉的原因刨析（含代码讲解）
3. 最终的解决方案

7.搜狐号

• 导航复杂：搜狐号的数据展示需要进行多级导航，还得配合日期选择器
• Element UI 表格：搜狐号使用 Vue + Element UI 的 el-table 组件，标准的 querySelectorAll('table') 找不到数据
• 两个日期选择器：内容影响力分析图表区和数据列表表格区各有一个日期选择器，只设一个会导致表格不更新
• 日历弹窗遮挡：fill() 输入框触发日历弹窗后未关闭，需要在填充后按 Escape 关闭
• 解决方案：链接如下：

https://blog.csdn.net/fastopAI/article/details/163673337?spm=1001.2014.3001.5502

在这篇文章中，我主要讲解了如下内容：

1. WorkBuddy 挑战四大天王
2. “导航层级天王”
3. “日期选择天王”
4. “数据表格天王”
5. “日历弹窗天王”

四、沉淀结果

1.Skill

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

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

2.Automation (自动化任务)

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

这种"一个平台一个自动化任务"的设计确保了：某个平台出问题不影响其他平台，可以错开时间执行避免 Chrome profile 冲突。并且调试时日志清晰可追溯，新对话可以用来跑自动化任务，旧对话可以进行调试。

具体的自动化任务的设置和选择策略，up 还单独写了一篇文章来讲解，链接如下：

https://blog.csdn.net/fastopAI/article/details/163994915?spm=1001.2014.3001.5502

在这篇文章中，up 详细讲解了如下内容：

1. 搭建“多平台数据矩阵” 如何进行自动化选型
2. WorkBuddy自动化任务详解
3. “多平台数据矩阵”对应的自动化任务
4. 自动化任务 Prompt 示例

3.分页逻辑处理（重要）

我在最初通过 WorkBuddy + Playwright 搭建多平台数据矩阵时，写得文章还不算多，因此就没考虑到分页问题。

没想到它突如其来，急如星火，一下子让我措手不及。

很快，七个平台都遇到了类似的问题，但是又都表现不同，于是我下定决心要将它们一网打尽。内容比较多，我又单独写了一篇文章，系统地介绍每个平台的分页问题是怎样表现的，以及我是如何一一解决的。链接如下：

https://blog.csdn.net/fastopAI/article/details/164062603?spm=1001.2014.3001.5502

在这篇文章中，我主要讲解了如下内容：

1. 七个平台各自的分页表现形式、问题
2. CSDN 分页问题的解决思路（选择器定位 + Ajax 时机控制）
3. 微信公众号 的分页问题解决（展示逻辑与分页逻辑）
4. 知乎 的滚动逻辑问题解决（滚动方式 + 日期解析 + 终止条件）
5. 今日头条的分页问题解决（找按钮 + 等待页码变化 + 踩坑实录）
6. 小红书滚动逻辑的解决（定位容器 + 触发加载 + 日期驱动收尾）
7. 百家号的分页问题解决（构造分页URL + 翻页循环）
8. 搜狐的分页问题解决（API直连，思路 + 代码实操）

Δ总结

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

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

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

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