目录一、拾枝杂谈1.关于 WorkBuddy 和 Playwright2.关于多平台数据矩阵的搭建3.关于这篇文章的由来二、多平台数据矩阵的搭建策略1.前言2.搭建 CSDN 数据分析的方法3.搭建微信公众号数据分析的方法4.搭建知乎数据分析的方法5.搭建今日头条数据分析的方法6.搭建小红书数据分析的方法7.搭建百家号数据分析的方法8.搭建搜狐号数据分析的方法三、多平台矩阵搭建过程中遇到的问题1.CSDN2.微信公众号3.知乎4.今日头条5.小红书6.百家号7.搜狐号四、沉淀结果1.Skill2.AutomationΔ总结一、拾枝杂谈1.关于 WorkBuddy 和 PlaywrightWorkBuddy是腾讯在今年三月份新推出的一个AI Agent平台用官方的话说呢叫做“全场景职场 AI 智能体桌面工作台”。其实就是一个Agent产品只不过它的侧重点不是写代码而是多生态的集成比如飞书、钉钉、微信等。和目前主流的Agent产品如CursorCCCodex等一样WorkBuddy 作为一个 Agent 产品可以执行具体任务比如读写本地文件、运行爬虫脚本、操作浏览器Playwright、通过命令行调用飞书 API 写入数据表等等总之它能干的活儿很多。而且就像主流的 Agent 一样它同样具备分析、拆解和 执行复杂任务的能力。只不过还是那句话它的侧重点或者说它的卖点不是专门写代码而是多生态集成下的办公提效。我这次是借助 WorkBuddy配合 PlayWright 帮我爬取多平台的文章数据然后统一写到飞书表格这样就不用我自己一个个平台一篇篇文章去统计了。具体在搭建过程中WorkBuddy 扮演了三个角色一是架构师WorkBuddy帮我设计了平台爬取策略和飞书表结构二是码农我利用WorkBuddy为每个平台单独编写了 Python Playwright 脚本三是运维我还让WorkBuddy帮我部署自动化任务这样我可以每天定时或手动触发数据采集自主性拉满了。2.关于多平台数据矩阵的搭建因为我本身是一个内容创作者就是一写文章的不是AI文啊。然后你作为一个创作者你肯定不能只在一棵树上吊死吧所以我一般会把自己写好的文章发布在不同的平台例如CSDN、微信公众号、知乎等等。然后是我想统计一下每个平台下面的每一篇文章的数据按照每一天来统计累计量我希望通过这些统计好的数据来构建自己的数据矩阵但是你想想这个任务的复杂度。手动做这件事是这样的先打开不同平台的创作后台 → 然后逐个找文章管理或数据分析 → 挨个复制阅读量、点赞、评论、收藏等 → 粘贴到飞书表格 → 第二天再做一遍。而且这里面最可怕的是什么如果你要统计每篇文章每天的数据那随着你写文章越来越多你消耗的时间会以指数级上升。这不仅浪费时间而且极易出错 —— 漏一行、贴错列、忘了某个指标时间久了连数据都不可信。所以我决定尝试让 WorkBuddy 帮我搭建一个自动化数据收集系统每天一键爬取多个平台的数据自动写入飞书知识库格式化、去重、保留历史趋势。注意我爬取的可是我自己的数据所有数据爬取的前提是我登录我自己的多平台账号。3.关于这篇文章的由来从最初提出需求到跑通七个平台的数据流花了我整整三天时间过程中踩了无数坑比如字段名猜错了、历史数据被清空了、标题差一个空格导致匹配失败了、日期选择器有两个而不是一个等等。每踩一个坑都是一次血与泪的教训每踩一个坑也都是一次Agent人协作的实战经验。这篇文章只是一个阶段性的总览—— 我会先简单介绍七个平台的爬取策略差异、各自遇到的核心问题及解决思路。因为篇幅限制各个平台遇到的问题以及解决方案我会在后面单独写文章来深挖。二、多平台数据矩阵的搭建策略1.前言在总体思路上搭建七个平台的数据矩阵有一个通用的工作流登录账号— 各平台先登录一次之后 Playwright 会使用复制的 Chrome profile 保存登录状态下次跑脚本时自动免登。探索页面结构— 先写一个探索脚本截取页面 HTML 和截图用于分析 DOM 结构并确认真实的统计字段名称。编写正式爬虫— 基于探索结果遍写完整的数据采集脚本导航到数据页面 → 筛选日期 → 解析数据 → 保存 JSON。飞书写入— 使用FeishuSheetWriter.write_scraped_data()标准路径按文章标题匹配已有子表 → 追加今天的数据行 → 格式化黄色表头 日期列 12pt。如果列结构不一致自动做安全迁移保留历史数据 → 重新映射列 → 追加新行。自动化任务— 将脚本部署为 WorkBuddy Automation设为 PAUSED 状态需要时一键触发。在写入飞书表格时还要注意以下核心原则日期列 当天爬取日期不是文章发布日期每个平台的飞书表头 该平台自己的真实字段绝不继承其他平台绝不删除历史数据列不对就迁移而不是清空重写去重保护如果当天已经跑过自动跳过然而七个平台的后台结构各不相同每一个都需要针对性处理实在是令我头大。2.搭建 CSDN 数据分析的方法入口mp.csdn.net → 数据中心 → 内容分析 → 单篇分析字段日期、展现量、阅读量、点赞、收藏、评论CSDN 的数据结构最为标准 —— 有一个清晰的表格每篇文章一行带专栏按钮。数据页面的 URL 直接包含日期参数不需要手动操作日历选择器总之非常友好。3.搭建微信公众号数据分析的方法入口mp.weixin.qq.com → 数据 → 内容分析 → 已群发 → 文章详情字段日期、阅读量、点赞、在看、分享、评论、转载微信公众号的数据结构最为复杂不是一个标准表格而是每个文章入口带一组统计数字。需要先提取文章列表 URL 参数中的 token从首页 URL 截取再调用publish_page全局变量获取数据。关键点在于微信的统计数据单位——不需要展示的字段展现量、收藏存储为空字符串而非 0避免误导。每一篇文章的详细统计数据需要通过 HTMLunescape解码后提取。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解码特殊字符字段差异化处理没有展现量和收藏字段空字段存储为空字符串而非 03.知乎字段命名陷阱知乎用阅读而非阅读量赞同和喜欢是两个独立指标不能混用其他平台的字段模板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在搭建过程中提炼了两个可复用的 Skillplatform-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 工程。