1. 为什么我要自己搭一套竞品监控系统做小红书内容运营的同行应该都有同感对标账号今天发了什么、哪篇笔记突然爆了、评论区在讨论什么这些信息如果靠人工每天刷不仅费时间而且很容易漏。我之前试过用表格手动记录坚持了不到两周就放弃了——不是不想记是重复劳动太消耗人。后来我换了个思路既然 WorkBuddy 有 BrowserSkill 和连接器能力飞书多维表格又能当轻量数据库用那为什么不把「盯账号」这件事自动化于是就有了这套系统盯紧 10 个对标账号、100 篇笔记每天自动抓取数据写进飞书多维表格异常波动还能推消息提醒。这套东西解决的核心问题有三个。第一是信息采集自动化不用再一个个点开主页翻笔记第二是数据结构化抓下来的点赞、收藏、评论、发布时间全部进表方便做趋势对比第三是异常预警某篇笔记数据突然飙升或者对标账号发了新内容能第一时间知道。适合谁来参考如果你是小团队的内容运营、个人博主或者像我一样需要持续跟踪竞品动态但又不希望被工具绑架的人这套方案可以直接抄。不需要你会写复杂爬虫WorkBuddy 的 BrowserSkill 已经把浏览器操作封装得比较友好了剩下的就是配置和调优。我实际跑下来的感受是前期配置花了两三个小时后面每天基本零维护。这个投入产出比比手动刷主页高太多了。2. 整体方案设计与工具选型思路2.1 为什么选 WorkBuddy 飞书多维表格这个组合市面上做竞品监控的方案不少我对比过几种。纯代码方案比如自己写 Python 爬虫灵活但维护成本高平台一改版就得修现成的第三方监控工具省事但数据不在自己手里而且很多功能要付费。WorkBuddy 的定位刚好卡在中间它有 BrowserSkill 这种浏览器自动化能力又有连接器可以对接外部服务配置门槛比纯代码低数据又能落到自己的飞书表里。飞书多维表格在这里扮演的是「数据仓库 展示层」的角色。选它而不是 Excel 或者数据库原因很实际多维表格支持 API 读写WorkBuddy 的连接器能直接对接它的视图和筛选功能足够做数据分析团队协作时分享链接就行不用折腾部署。对于 10 个账号、100 篇笔记这个量级多维表格完全够用没必要上更重的东西。提示如果你之前没用过飞书多维表格建议先花十分钟熟悉一下它的字段类型和视图逻辑后面配置连接器会顺畅很多。2.2 系统架构拆解从抓取到入库的完整链路整套系统的数据流是这样的WorkBuddy 定时触发设定每天固定时间我设的是早上 8 点和晚上 8 点各一次启动任务。BrowserSkill 打开对标账号主页模拟浏览器访问获取笔记列表。提取关键字段笔记标题、发布时间、点赞数、收藏数、评论数、笔记链接。连接器写入飞书多维表格通过飞书开放平台接口把数据追加到指定表。异常检测与推送对比历史数据如果某篇笔记互动量涨幅超过阈值通过飞书机器人发消息提醒。这个链路里BrowserSkill 负责「看」连接器负责「传」多维表格负责「存」飞书机器人负责「喊」。每个环节各司其职拆开看都不复杂组合起来就形成了一个闭环。2.3 10 个账号、100 篇笔记的规模测算为什么定 10 个账号、100 篇笔记这是我根据实际运营需求算出来的。10 个账号基本能覆盖一个细分赛道的头部和腰部再多信息就冗余了每个账号抓最近 10 篇笔记加起来 100 篇足够看出内容趋势和爆款规律。从资源消耗角度看BrowserSkill 每次抓取一个账号大约需要 15-30 秒取决于网络和页面加载速度10 个账号跑一轮大概 5 分钟左右。这个频率和耗时对 WorkBuddy 的任务调度压力很小也不会因为请求太频繁触发平台的风控。如果你要扩大到 50 个账号建议分批跑中间加随机延迟这个后面会细说。3. 核心细节解析与实操要点3.1 BrowserSkill 抓取策略怎么稳定拿到笔记数据BrowserSkill 的本质是让 WorkBuddy 控制一个浏览器实例去访问页面、执行操作、提取内容。用它抓小红书数据核心要解决三个问题页面加载等待、元素定位、反爬规避。页面加载等待是最容易踩坑的地方。小红书的主页是动态加载的如果页面还没渲染完就去提取元素拿到的就是空数据。我的做法是在 BrowserSkill 里加显式等待等笔记列表的容器元素出现后再继续。具体等待时间不要写死用「等待某个元素出现」的条件判断更稳。元素定位方面建议用相对稳定的选择器。小红书的 DOM 结构会变但笔记卡片的链接通常包含特定路径特征用这个作为锚点比用 class 名靠谱。提取字段时点赞、收藏这些数字可能是「1.2万」这种格式需要在写入前做一次转换统一成整数。反爬规避是绕不开的话题。我的经验是控制频率比换 IP 更重要。每个账号之间加 3-5 秒随机延迟不要用固定间隔抓取时间分散到不同时段不要登录账号去抓用游客视角能看到的公开数据就够了。这些措施下来我跑了几个月没遇到过封禁。3.2 连接器配置飞书多维表格的读写要点连接器这块核心是拿到飞书开放平台的访问凭证然后调用多维表格的 API。流程分三步在飞书开放平台创建应用获取 App ID 和 App Secret。开通多维表格权限把应用添加为目标表格的协作者。在 WorkBuddy 连接器里配置凭证测试连通性。这里有个容易忽略的点多维表格的 API 需要指定 app_token 和 table_id这两个参数在表格的 URL 里能找到。app_token 是表格的唯一标识table_id 是具体工作表的标识别搞混了。写入数据时字段类型要匹配。比如「发布时间」字段如果设的是日期类型传参时就要用时间戳或标准格式字符串「点赞数」设的是数字类型就不能传字符串。我一开始没注意导致数据写进去全是文本格式没法做数值排序后来重新调整了字段类型才解决。注意飞书开放平台的接口有频率限制批量写入时建议每批不超过 500 条批次之间加短暂延迟。100 篇笔记的量级分两批写完全没问题。3.3 数据字段设计哪些指标值得盯字段设计直接决定这套系统能不能产出有价值的分析。我最终定的字段如下字段名类型说明账号名称文本对标账号的昵称笔记标题文本笔记的标题内容笔记链接链接用于快速跳转查看发布时间日期笔记发布的时间点赞数数字抓取时的点赞量收藏数数字抓取时的收藏量评论数数字抓取时的评论量互动总量公式点赞收藏评论自动计算抓取时间日期本次抓取的时间戳数据变化公式与上次抓取对比的涨幅「互动总量」和「数据变化」用公式字段自动算省得每次手动处理。有了这两个字段在表格里按「数据变化」降序排列哪篇笔记在涨、涨了多少一眼就能看出来。3.4 定时任务与异常预警的配置逻辑定时任务在 WorkBuddy 里设置我用的是 cron 表达式早上 8 点和晚上 8 点各跑一次。为什么选这两个时间点早上 8 点能覆盖前一天晚上的发布高峰晚上 8 点能覆盖当天的内容更新基本不会漏掉重要动态。异常预警的逻辑是这样的每次抓取后把当前数据与上一次抓取的数据做对比如果某篇笔记的互动总量涨幅超过 50%这个阈值可以调就触发飞书机器人推送。推送内容包含笔记标题、链接和涨幅数据点开就能看。飞书机器人的配置不复杂在群聊里添加自定义机器人拿到 webhook 地址然后在 WorkBuddy 里用连接器调用。消息格式用富文本卡片比纯文本可读性好很多。4. 实操过程与核心环节实现4.1 环境准备与 WorkBuddy 基础配置开始之前先把基础环境搭好。WorkBuddy 的安装按官方指引走就行装完后重点配置两个地方BrowserSkill 的运行环境和连接器的凭证管理。BrowserSkill 需要浏览器内核支持首次使用时会提示安装。我建议用默认配置除非你有特殊需求。安装完成后先跑一个简单的测试任务——比如打开一个网页、截个图确认 BrowserSkill 能正常工作。连接器配置在 WorkBuddy 的「连接器管理」里操作。飞书连接器需要填 App ID、App Secret 和表格的 app_token、table_id。填完后点「测试连接」返回成功就说明配置没问题。如果报错大概率是权限没开够回飞书开放平台检查一下应用的权限范围。提示凭证信息建议用 WorkBuddy 的密钥管理功能存储不要直接写在任务脚本里避免泄露风险。4.2 抓取任务的完整配置流程抓取任务的配置分几个步骤我按实际操作顺序说第一步定义账号列表。把 10 个对标账号的主页链接整理成一个列表存在 WorkBuddy 的变量里。这样后续要增删账号改一处就行。第二步配置 BrowserSkill 操作序列。对每个账号执行以下操作打开主页链接等待笔记列表加载完成滚动页面加载更多笔记小红书默认只显示部分需要滚动触发加载提取前 10 篇笔记的字段数据关闭页面第三步数据清洗与格式转换。把「1.2万」转成 12000把相对时间如「3天前」转成标准日期。这一步用 WorkBuddy 的脚本处理几行代码就能搞定。第四步写入飞书多维表格。调用连接器把清洗后的数据批量写入。写入前先查一下表里有没有重复的笔记链接避免重复记录。第五步更新对比字段。写入完成后触发公式字段重新计算更新「数据变化」列。整个流程跑通后可以设置成定时任务自动执行。我第一次跑的时候因为没加滚动加载只抓到了前 4 篇笔记后来补上滚动操作才拿到完整的 10 篇。4.3 数据写入与去重处理去重是保证数据质量的关键。我的做法是以笔记链接作为唯一标识写入前先查询表里是否已存在相同链接。如果存在就更新数据而不是新增记录如果不存在才追加新行。这个逻辑用飞书多维表格的「查询记录」接口实现。查询时用筛选条件匹配笔记链接返回结果为空就新增不为空就更新对应记录的互动数据。这样既能追踪同一篇笔记的数据变化又不会产生重复行。批量写入时我把 100 篇笔记分成两批每批 50 条中间间隔 2 秒。实测下来这个节奏很稳没有触发过频率限制。4.4 飞书机器人推送的配置与测试飞书机器人的配置分两步先在飞书群里添加自定义机器人拿到 webhook 地址然后在 WorkBuddy 里配置一个推送任务调用这个 webhook。推送消息我用的是卡片格式包含以下内容标题哪篇笔记数据异常正文笔记标题、当前互动量、涨幅百分比按钮点击跳转到笔记原文测试的时候我手动改了一条数据触发阈值确认机器人能正常推送。这里有个细节webhook 地址要保密泄露了别人就能往你群里发消息。WorkBuddy 的密钥管理可以存这个地址用的时候引用变量就行。4.5 完整跑一轮的实测记录与耗时分析我记录了一次完整运行的耗时环节耗时启动 BrowserSkill约 5 秒抓取 10 个账号约 4 分 30 秒数据清洗约 10 秒写入飞书表格约 15 秒异常检测与推送约 5 秒合计约 5 分钟这个耗时完全可以接受。如果账号数量增加主要瓶颈在抓取环节可以考虑并行处理但要注意控制并发数避免触发风控。5. 常见问题与排查技巧实录5.1 抓取失败或数据为空的排查思路抓取失败是最常见的问题表现是数据为空或者字段缺失。排查顺序如下检查页面是否加载完成在 BrowserSkill 里加截图看看抓取时页面长什么样。如果是空白页或加载中说明等待时间不够。检查选择器是否失效平台改版会导致元素定位失败。用浏览器的开发者工具重新确认选择器更新到任务配置里。检查网络是否正常偶尔的网络波动会导致页面加载失败加个重试机制能解决大部分问题。检查是否触发风控如果频繁失败可能是请求太密集降低频率或增加延迟。我遇到过一次抓取全空的情况排查后发现是小红书改了笔记卡片的 DOM 结构更新选择器后恢复正常。所以建议定期检查抓取结果发现异常及时调整。5.2 飞书连接器报错的常见原因连接器报错主要集中在权限和参数两方面错误现象可能原因解决方法401 未授权App ID/Secret 错误重新核对凭证403 无权限应用未添加为表格协作者在表格里添加应用404 找不到表格app_token 或 table_id 错误从 URL 重新提取429 频率超限请求太密集降低频率加延迟字段类型不匹配传参格式与字段类型不符检查字段类型转换格式这些错误我都踩过最麻烦的是字段类型不匹配因为报错信息不够明确。后来我养成了习惯写入前先查一下表的字段定义确认类型再传参。5.3 数据重复与时间戳错乱的解决数据重复通常是因为去重逻辑没生效。检查两点一是查询条件是否正确匹配了笔记链接二是写入时是否用了「新增或更新」的逻辑而不是无脑追加。时间戳错乱一般是时区问题。飞书多维表格的日期字段默认用 UTC 时间如果抓取的时间是北京时间写入时要做转换。我的做法是统一转成时间戳再写入显示的时候由表格自动格式化。5.4 我踩过的三个坑与对应经验第一个坑没加滚动加载只抓到部分笔记。小红书主页默认只渲染前几篇后面的要滚动才加载。解决办法是在 BrowserSkill 里加滚动操作滚到底部再提取。第二个坑用固定延迟等待页面加载。网络快的时候等太久网络慢的时候又不够。后来改成「等待特定元素出现」稳定多了。第三个坑忘记处理数字格式。「1.2万」直接写入表格导致没法做数值计算。加了一个转换函数把「万」乘以 10000问题解决。这三个坑本质上都是「想当然」导致的——以为页面会立刻加载完、以为网络速度稳定、以为数据格式统一。实际做的时候多验证、多检查能省很多返工时间。6. 系统扩展与长期维护的一些想法这套系统跑顺之后我陆续做了一些扩展。比如把抓取范围从笔记列表扩展到评论区看看用户在讨论什么把数据同步到飞书的仪表盘视图做可视化趋势图还试过用 WorkBuddy 的其他 Skill 做内容分析比如提取高频关键词。维护方面最重要的是定期检查抓取结果。我一般每周看一次数据确认没有大面积缺失或异常。如果平台改版导致抓取失败及时更新选择器就行。另外账号列表和阈值参数建议做成可配置的调整的时候不用改代码。如果你也想搭一套类似的系统我的建议是先从 3 个账号、30 篇笔记跑通流程确认每个环节都正常后再扩大规模。一上来就搞 10 个账号出了问题不好定位。跑通之后这套东西的边际成本很低加账号就是改个列表的事。最后分享一个小技巧抓取时间尽量避开平台的高峰时段比如晚上 8-10 点这时候请求多页面加载慢容易超时。我后来把抓取时间调到早上 7 点和下午 3 点成功率明显提升。 
长河君 · 2026/10/4 11:22:38 · 阅读 1.2k WorkBuddy+飞书多维表格：自动监控小红书竞品数据实战
1. 为什么我要自己搭一套竞品监控系统做小红书内容运营的同行应该都有同感对标账号今天发了什么、哪篇笔记突然爆了、评论区在讨论什么这些信息如果靠人工每天刷不仅费时间而且很容易漏。我之前试过用表格手动记录坚持了不到两周就放弃了——不是不想记是重复劳动太消耗人。后来我换了个思路既然 WorkBuddy 有 BrowserSkill 和连接器能力飞书多维表格又能当轻量数据库用那为什么不把「盯账号」这件事自动化于是就有了这套系统盯紧 10 个对标账号、100 篇笔记每天自动抓取数据写进飞书多维表格异常波动还能推消息提醒。这套东西解决的核心问题有三个。第一是信息采集自动化不用再一个个点开主页翻笔记第二是数据结构化抓下来的点赞、收藏、评论、发布时间全部进表方便做趋势对比第三是异常预警某篇笔记数据突然飙升或者对标账号发了新内容能第一时间知道。适合谁来参考如果你是小团队的内容运营、个人博主或者像我一样需要持续跟踪竞品动态但又不希望被工具绑架的人这套方案可以直接抄。不需要你会写复杂爬虫WorkBuddy 的 BrowserSkill 已经把浏览器操作封装得比较友好了剩下的就是配置和调优。我实际跑下来的感受是前期配置花了两三个小时后面每天基本零维护。这个投入产出比比手动刷主页高太多了。2. 整体方案设计与工具选型思路2.1 为什么选 WorkBuddy 飞书多维表格这个组合市面上做竞品监控的方案不少我对比过几种。纯代码方案比如自己写 Python 爬虫灵活但维护成本高平台一改版就得修现成的第三方监控工具省事但数据不在自己手里而且很多功能要付费。WorkBuddy 的定位刚好卡在中间它有 BrowserSkill 这种浏览器自动化能力又有连接器可以对接外部服务配置门槛比纯代码低数据又能落到自己的飞书表里。飞书多维表格在这里扮演的是「数据仓库 展示层」的角色。选它而不是 Excel 或者数据库原因很实际多维表格支持 API 读写WorkBuddy 的连接器能直接对接它的视图和筛选功能足够做数据分析团队协作时分享链接就行不用折腾部署。对于 10 个账号、100 篇笔记这个量级多维表格完全够用没必要上更重的东西。提示如果你之前没用过飞书多维表格建议先花十分钟熟悉一下它的字段类型和视图逻辑后面配置连接器会顺畅很多。2.2 系统架构拆解从抓取到入库的完整链路整套系统的数据流是这样的WorkBuddy 定时触发设定每天固定时间我设的是早上 8 点和晚上 8 点各一次启动任务。BrowserSkill 打开对标账号主页模拟浏览器访问获取笔记列表。提取关键字段笔记标题、发布时间、点赞数、收藏数、评论数、笔记链接。连接器写入飞书多维表格通过飞书开放平台接口把数据追加到指定表。异常检测与推送对比历史数据如果某篇笔记互动量涨幅超过阈值通过飞书机器人发消息提醒。这个链路里BrowserSkill 负责「看」连接器负责「传」多维表格负责「存」飞书机器人负责「喊」。每个环节各司其职拆开看都不复杂组合起来就形成了一个闭环。2.3 10 个账号、100 篇笔记的规模测算为什么定 10 个账号、100 篇笔记这是我根据实际运营需求算出来的。10 个账号基本能覆盖一个细分赛道的头部和腰部再多信息就冗余了每个账号抓最近 10 篇笔记加起来 100 篇足够看出内容趋势和爆款规律。从资源消耗角度看BrowserSkill 每次抓取一个账号大约需要 15-30 秒取决于网络和页面加载速度10 个账号跑一轮大概 5 分钟左右。这个频率和耗时对 WorkBuddy 的任务调度压力很小也不会因为请求太频繁触发平台的风控。如果你要扩大到 50 个账号建议分批跑中间加随机延迟这个后面会细说。3. 核心细节解析与实操要点3.1 BrowserSkill 抓取策略怎么稳定拿到笔记数据BrowserSkill 的本质是让 WorkBuddy 控制一个浏览器实例去访问页面、执行操作、提取内容。用它抓小红书数据核心要解决三个问题页面加载等待、元素定位、反爬规避。页面加载等待是最容易踩坑的地方。小红书的主页是动态加载的如果页面还没渲染完就去提取元素拿到的就是空数据。我的做法是在 BrowserSkill 里加显式等待等笔记列表的容器元素出现后再继续。具体等待时间不要写死用「等待某个元素出现」的条件判断更稳。元素定位方面建议用相对稳定的选择器。小红书的 DOM 结构会变但笔记卡片的链接通常包含特定路径特征用这个作为锚点比用 class 名靠谱。提取字段时点赞、收藏这些数字可能是「1.2万」这种格式需要在写入前做一次转换统一成整数。反爬规避是绕不开的话题。我的经验是控制频率比换 IP 更重要。每个账号之间加 3-5 秒随机延迟不要用固定间隔抓取时间分散到不同时段不要登录账号去抓用游客视角能看到的公开数据就够了。这些措施下来我跑了几个月没遇到过封禁。3.2 连接器配置飞书多维表格的读写要点连接器这块核心是拿到飞书开放平台的访问凭证然后调用多维表格的 API。流程分三步在飞书开放平台创建应用获取 App ID 和 App Secret。开通多维表格权限把应用添加为目标表格的协作者。在 WorkBuddy 连接器里配置凭证测试连通性。这里有个容易忽略的点多维表格的 API 需要指定 app_token 和 table_id这两个参数在表格的 URL 里能找到。app_token 是表格的唯一标识table_id 是具体工作表的标识别搞混了。写入数据时字段类型要匹配。比如「发布时间」字段如果设的是日期类型传参时就要用时间戳或标准格式字符串「点赞数」设的是数字类型就不能传字符串。我一开始没注意导致数据写进去全是文本格式没法做数值排序后来重新调整了字段类型才解决。注意飞书开放平台的接口有频率限制批量写入时建议每批不超过 500 条批次之间加短暂延迟。100 篇笔记的量级分两批写完全没问题。3.3 数据字段设计哪些指标值得盯字段设计直接决定这套系统能不能产出有价值的分析。我最终定的字段如下字段名类型说明账号名称文本对标账号的昵称笔记标题文本笔记的标题内容笔记链接链接用于快速跳转查看发布时间日期笔记发布的时间点赞数数字抓取时的点赞量收藏数数字抓取时的收藏量评论数数字抓取时的评论量互动总量公式点赞收藏评论自动计算抓取时间日期本次抓取的时间戳数据变化公式与上次抓取对比的涨幅「互动总量」和「数据变化」用公式字段自动算省得每次手动处理。有了这两个字段在表格里按「数据变化」降序排列哪篇笔记在涨、涨了多少一眼就能看出来。3.4 定时任务与异常预警的配置逻辑定时任务在 WorkBuddy 里设置我用的是 cron 表达式早上 8 点和晚上 8 点各跑一次。为什么选这两个时间点早上 8 点能覆盖前一天晚上的发布高峰晚上 8 点能覆盖当天的内容更新基本不会漏掉重要动态。异常预警的逻辑是这样的每次抓取后把当前数据与上一次抓取的数据做对比如果某篇笔记的互动总量涨幅超过 50%这个阈值可以调就触发飞书机器人推送。推送内容包含笔记标题、链接和涨幅数据点开就能看。飞书机器人的配置不复杂在群聊里添加自定义机器人拿到 webhook 地址然后在 WorkBuddy 里用连接器调用。消息格式用富文本卡片比纯文本可读性好很多。4. 实操过程与核心环节实现4.1 环境准备与 WorkBuddy 基础配置开始之前先把基础环境搭好。WorkBuddy 的安装按官方指引走就行装完后重点配置两个地方BrowserSkill 的运行环境和连接器的凭证管理。BrowserSkill 需要浏览器内核支持首次使用时会提示安装。我建议用默认配置除非你有特殊需求。安装完成后先跑一个简单的测试任务——比如打开一个网页、截个图确认 BrowserSkill 能正常工作。连接器配置在 WorkBuddy 的「连接器管理」里操作。飞书连接器需要填 App ID、App Secret 和表格的 app_token、table_id。填完后点「测试连接」返回成功就说明配置没问题。如果报错大概率是权限没开够回飞书开放平台检查一下应用的权限范围。提示凭证信息建议用 WorkBuddy 的密钥管理功能存储不要直接写在任务脚本里避免泄露风险。4.2 抓取任务的完整配置流程抓取任务的配置分几个步骤我按实际操作顺序说第一步定义账号列表。把 10 个对标账号的主页链接整理成一个列表存在 WorkBuddy 的变量里。这样后续要增删账号改一处就行。第二步配置 BrowserSkill 操作序列。对每个账号执行以下操作打开主页链接等待笔记列表加载完成滚动页面加载更多笔记小红书默认只显示部分需要滚动触发加载提取前 10 篇笔记的字段数据关闭页面第三步数据清洗与格式转换。把「1.2万」转成 12000把相对时间如「3天前」转成标准日期。这一步用 WorkBuddy 的脚本处理几行代码就能搞定。第四步写入飞书多维表格。调用连接器把清洗后的数据批量写入。写入前先查一下表里有没有重复的笔记链接避免重复记录。第五步更新对比字段。写入完成后触发公式字段重新计算更新「数据变化」列。整个流程跑通后可以设置成定时任务自动执行。我第一次跑的时候因为没加滚动加载只抓到了前 4 篇笔记后来补上滚动操作才拿到完整的 10 篇。4.3 数据写入与去重处理去重是保证数据质量的关键。我的做法是以笔记链接作为唯一标识写入前先查询表里是否已存在相同链接。如果存在就更新数据而不是新增记录如果不存在才追加新行。这个逻辑用飞书多维表格的「查询记录」接口实现。查询时用筛选条件匹配笔记链接返回结果为空就新增不为空就更新对应记录的互动数据。这样既能追踪同一篇笔记的数据变化又不会产生重复行。批量写入时我把 100 篇笔记分成两批每批 50 条中间间隔 2 秒。实测下来这个节奏很稳没有触发过频率限制。4.4 飞书机器人推送的配置与测试飞书机器人的配置分两步先在飞书群里添加自定义机器人拿到 webhook 地址然后在 WorkBuddy 里配置一个推送任务调用这个 webhook。推送消息我用的是卡片格式包含以下内容标题哪篇笔记数据异常正文笔记标题、当前互动量、涨幅百分比按钮点击跳转到笔记原文测试的时候我手动改了一条数据触发阈值确认机器人能正常推送。这里有个细节webhook 地址要保密泄露了别人就能往你群里发消息。WorkBuddy 的密钥管理可以存这个地址用的时候引用变量就行。4.5 完整跑一轮的实测记录与耗时分析我记录了一次完整运行的耗时环节耗时启动 BrowserSkill约 5 秒抓取 10 个账号约 4 分 30 秒数据清洗约 10 秒写入飞书表格约 15 秒异常检测与推送约 5 秒合计约 5 分钟这个耗时完全可以接受。如果账号数量增加主要瓶颈在抓取环节可以考虑并行处理但要注意控制并发数避免触发风控。5. 常见问题与排查技巧实录5.1 抓取失败或数据为空的排查思路抓取失败是最常见的问题表现是数据为空或者字段缺失。排查顺序如下检查页面是否加载完成在 BrowserSkill 里加截图看看抓取时页面长什么样。如果是空白页或加载中说明等待时间不够。检查选择器是否失效平台改版会导致元素定位失败。用浏览器的开发者工具重新确认选择器更新到任务配置里。检查网络是否正常偶尔的网络波动会导致页面加载失败加个重试机制能解决大部分问题。检查是否触发风控如果频繁失败可能是请求太密集降低频率或增加延迟。我遇到过一次抓取全空的情况排查后发现是小红书改了笔记卡片的 DOM 结构更新选择器后恢复正常。所以建议定期检查抓取结果发现异常及时调整。5.2 飞书连接器报错的常见原因连接器报错主要集中在权限和参数两方面错误现象可能原因解决方法401 未授权App ID/Secret 错误重新核对凭证403 无权限应用未添加为表格协作者在表格里添加应用404 找不到表格app_token 或 table_id 错误从 URL 重新提取429 频率超限请求太密集降低频率加延迟字段类型不匹配传参格式与字段类型不符检查字段类型转换格式这些错误我都踩过最麻烦的是字段类型不匹配因为报错信息不够明确。后来我养成了习惯写入前先查一下表的字段定义确认类型再传参。5.3 数据重复与时间戳错乱的解决数据重复通常是因为去重逻辑没生效。检查两点一是查询条件是否正确匹配了笔记链接二是写入时是否用了「新增或更新」的逻辑而不是无脑追加。时间戳错乱一般是时区问题。飞书多维表格的日期字段默认用 UTC 时间如果抓取的时间是北京时间写入时要做转换。我的做法是统一转成时间戳再写入显示的时候由表格自动格式化。5.4 我踩过的三个坑与对应经验第一个坑没加滚动加载只抓到部分笔记。小红书主页默认只渲染前几篇后面的要滚动才加载。解决办法是在 BrowserSkill 里加滚动操作滚到底部再提取。第二个坑用固定延迟等待页面加载。网络快的时候等太久网络慢的时候又不够。后来改成「等待特定元素出现」稳定多了。第三个坑忘记处理数字格式。「1.2万」直接写入表格导致没法做数值计算。加了一个转换函数把「万」乘以 10000问题解决。这三个坑本质上都是「想当然」导致的——以为页面会立刻加载完、以为网络速度稳定、以为数据格式统一。实际做的时候多验证、多检查能省很多返工时间。6. 系统扩展与长期维护的一些想法这套系统跑顺之后我陆续做了一些扩展。比如把抓取范围从笔记列表扩展到评论区看看用户在讨论什么把数据同步到飞书的仪表盘视图做可视化趋势图还试过用 WorkBuddy 的其他 Skill 做内容分析比如提取高频关键词。维护方面最重要的是定期检查抓取结果。我一般每周看一次数据确认没有大面积缺失或异常。如果平台改版导致抓取失败及时更新选择器就行。另外账号列表和阈值参数建议做成可配置的调整的时候不用改代码。如果你也想搭一套类似的系统我的建议是先从 3 个账号、30 篇笔记跑通流程确认每个环节都正常后再扩大规模。一上来就搞 10 个账号出了问题不好定位。跑通之后这套东西的边际成本很低加账号就是改个列表的事。最后分享一个小技巧抓取时间尽量避开平台的高峰时段比如晚上 8-10 点这时候请求多页面加载慢容易超时。我后来把抓取时间调到早上 7 点和下午 3 点成功率明显提升。