每天早上到了工位先开浏览器、登录后台、复制昨天的数据、填表格、写日报、再顺手把几个固定链接点一遍——这套流程我重复了快三年直到把 WorkBuddy 用起来以后上午黄金时间才真正还给了写代码和想方案。这篇就记录我用 WorkBuddy 搭建每日工作自动化的完整过程。它本质是一个本地运行的 AI 智能体工作台核心思路不是让大模型自由发挥而是通过 Skill 指令集把“固定动作”固化下来再由智能体调用浏览器、桌面应用和外部接口替你执行。整个过程不要求你会写完整代码懂一点 JSON 和基础逻辑就能上手。适合每天有大量重复网页操作、信息汇总、日报生成需求的人也适合想摸清 AI 智能体到底怎么落地的人。1. 为什么我最终用 WorkBuddy 替换掉了手写脚本和 RPA1.1 自动化工具那么多WorkBuddy 的差异点在哪先说背景。我最早处理这类重复劳动用的是 Python 脚本后来也试过 Playwright、Appium 之类的自动化测试框架来做浏览器操作再后来接触了 RPA 工具。这些方案各自都有让人头疼的地方。纯脚本的问题在于网页结构一改选择器全部失效又要花半天去改代码。RPA 工具则太笨重流程设计器拖来拖去遇到动态元素、登录态过期、弹窗变化就卡住而且贵。Coze、Dify 这类云端智能体平台我也试过优点是搭工作流快但涉及到本地文件、企业内部系统、需要长期保持登录态的网页时云端跑起来总觉得隔了一层。WorkBuddy 的做法是折中它把自己定位成安装在本地的智能体工作台对外提供桌面端和命令行两种使用方式。你仍然需要在本地安装浏览器控制组件但因为智能体的大脑是接大模型 API所以在语言理解、判断网页状态、生成操作参数上比传统 RPA 靠“录屏坐标”要聪明得多。最关键的是它引入了 Skill 机制让我可以把频繁使用的固定动作沉淀成模板下次直接调用不用重新写一遍。1.2 核心原理智能体、Skill 指令集和浏览器操作如何配合WorkBuddy 的工作模式可以简化成三部分大模型当大脑、Skill 当操作手册、浏览器控制组件当手脚。大模型负责理解你的自然语言指令然后把指令拆解成具体动作序列。Skill 则是一个结构化的 JSON 描述文件里面记录了某个任务的步骤、参数、提示词和校验规则。两者配合起来的效果是你不是在让 AI “随便帮我看一下”而是让它严格按照一套预先定义好的标准作业流程去执行。浏览器控制组件用于真正操作页面——打开网址、点击按钮、输入文字、读取表格内容、截图、下载文件。WorkBuddy 在这块兼容了 Playwright 协议的底层能力所以我在网页自动化里踩过的大部分经验迁移过来都是通的。提示把 WorkBuddy 理解成“带了一个只会照章办事的实习生”会更准确。它稳定是因为有章法而不是因为它智能到可以临场发挥。所以你想让它自动化什么前提是你自己得先把流程想清楚。2. 安装与模型接入Windows、Ubuntu 和 DeepSeek 兼容接口2.1 Windows 和 macOS 的安装流程WorkBuddy 的安装没有想象中麻烦。Windows 端我直接去官网下了安装包双击之后一路下一步装完会在系统托盘常驻。首次启动后它会引导你创建一个本地工作目录这个目录用来存放你的 Skill 文件、任务日志和浏览器配置文件。在 macOS 上也是类似下载 dmg 拖进 Applications 即可。有一点要注意首次启动浏览器自动化功能时系统会请求辅助功能权限需要在“系统设置-隐私与安全性-辅助功能”里把 WorkBuddy 勾上否则它控制不了浏览器窗口。安装完成后界面上会让填模型配置。WorkBuddy 支持 OpenAI 兼容格式的接口也就是说只要 API 风格兼容都可以填进去。我填的是 DeepSeek 的接口配置项如下。2.2 Ubuntu / Linux 环境下的安装要点热搜里看到很多人问 workbuddy linux、workbuddy ubuntu我专门在 Ubuntu 22.04 上试了一遍。Linux 下不是双击安装而是通过命令行装的# 拉取安装包具体包名以官方发布页为准 wget https://example.com/workbuddy-latest-linux.deb sudo dpkg -i workbuddy-latest-linux.deb # 如果缺依赖用下面的命令补装 sudo apt-get install -f装完以后WorkBuddy 会以服务形式运行你在终端输入workbuddy就能进入交互模式。Linux 下比较容易踩坑的是缺浏览器依赖。如果你系统里没有 Chromium它会提示找不到浏览器内核。解决方法是手动装一下sudo apt-get install -y chromium-browser装好之后在 WorkBuddy 的配置文件里指定浏览器的可执行文件路径。还有一个坑是 Linux 下的沙箱权限WorkBuddy 启动浏览器组件时如果报“sandbox 相关错误”通常需要在配置里加上--no-sandbox参数。这个参数在本地可控环境里是安全的但如果部署在多人共用的服务器上建议评估一下风险。2.3 模型接入以 DeepSeek 兼容接口为例模型配置界面大概长这样需要填 Base URL、API Key、模型名称三个字段。{ model_provider: openai_compatible, base_url: https://api.deepseek.com/v1, api_key: 你的API Key, model: deepseek-chat }这里面的逻辑不复杂WorkBuddy 的所有智能体对话、任务规划、步骤生成都通过这个接口发给大模型处理。DeepSeek 的成本比较低拿来跑日常自动化的批量任务很划算。如果你手上有其他兼容 OpenAI 格式的服务同样可以填进去。配置完之后我建议先做一个连通性测试让 WorkBuddy 跑一句最简单的指令比如“请介绍一下你自己”。只要这一步通了后面搭建工作流基本不会卡在模型层。注意API Key 属于敏感凭据WorkBuddy 默认存在本地配置文件里。如果你有多台机器同步配置千万不要把包含 Key 的配置文件传到公开仓库。3. Skill 机制拆解把“随口让AI干活”变成固定工作流3.1 Skill 的本质给智能体一本标准化操作手册很多人用 AI 智能体失败不是因为模型不够聪明而是因为指令不固定。今天说“把表格整理一下”明天说“把表格汇总好发我”模型每次理解的都不一样输出自然不稳定。Skill 就是来解决这个问题的。它相当于给智能体一本精细到每一步的操作手册——不是“整理表格”这种模糊指令而是“打开指定 Excel 文件读取 B 列到 F 列的数据按日期排序生成 Markdown 表格保存到 output 目录”这样明确的动作序列。我习惯用 Excel 里的宏来类比Excel 宏把一系列操作录制下来下次一键回放WorkBuddy 的 Skill 把一系列带判断逻辑的动作封装起来智能体执行时还可以根据实际页面内容做微调。它比宏灵活比纯自然语言稳定。3.2 一个实际 Skill 的 JSON 结构详解WorkBuddy 的 Skill 文件放在工作目录下的 skills 文件夹里一个 Skill 对应一个 JSON 文件。我拆一个最简单的示例——定时打开数据后台并截图{ name: open_dashboard_and_screenshot, description: 打开数据后台首页等待加载完成后截图保存, trigger: { type: schedule, cron: 0 9 * * * }, steps: [ { action: browser_open, url: https://your-dashboard.example.com }, { action: wait_for_selector, selector: .main-container, timeout: 30000 }, { action: screenshot, save_path: output/dashboard_{date}.png }, { action: ai_summarize, prompt: 请用三句话概括这张数据看板里的关键指标变化 } ] }这个文件虽然简单但已经包含了 WorkBuddy 自动化任务的完整要素。name 和 description 是给智能体识别用的trigger 定义了触发方式这里是每天 9 点steps 是核心按照顺序定义智能体要执行的动作。我把 steps 里的每个 action 理解成“积木块”WorkBuddy 内置了 browser_open、wait_for_selector、screenshot、ai_summarize、file_write、send_message 这一批常用积木。你不需要全部记住在配置界面里可以直接选选完填参数就行。3.3 让工作流真正落地定时触发与人工确认点Skill 里的 trigger 是整个自动化的开关。WorkBuddy 支持几种触发方式定时触发cron 表达式指定时间适合日报、周报、定时检查这类任务。手动触发点击运行按钮适合需要人在场的任务。监听触发监听某个目录的文件变化、某个网页元素的出现属于进阶玩法。我建议新手从定时任务开始。不过定时任务有个容易忽略的点无人值守的情况下中间任何一步出错都可能让整个链路断掉。所以我设计 Skill 时有两个习惯一是关键动作之间加 wait_for_selector 等待元素出现避免页面还没加载完就执行下一步二是在发送外部消息这种不可逆操作前设置一个人工确认点让 WorkBuddy 执行到这一步时停下来等我确认。提示自动化不是全自动半自动才是日常最稳的形态。把“会出错后很难挽回”的步骤留给人来确认其余无脑操作全交给智能体。4. 10 分钟搭一个每日自动化信息汇总日报全流程实录4.1 先定场景我选的是“早晨信息汇总日报”理论说了不少接下来是完整的实操记录。我选了一个很常见的场景每天早晨把几个网站的数据抓下来、汇总成日报、再发到团队协作平台。这个场景覆盖了 WorkBuddy 的核心能力浏览器操作打开网页、读取数据、AI 生成汇总关键信息、写日报文案、外部交互发送到协作平台。如果你要自动化的不是这个场景也完全可以参考这套流程把具体网址和数据字段替换掉就行。我先把整个任务拆成四段打开数据后台 A读取昨日核心指标打开资讯页面 B抓取当天前几条重要动态把两部分内容丢给大模型生成一份结构化日报把日报内容写入团队协作平台的指定文档并发送通知4.2 搭建工作流的四个核心节点WorkBuddy 的配置界面里可以直接创建任务然后按顺序添加节点。我实际配置的节点是这样的节点一打开数据后台并读取指标。这个节点用 browser_open 打开后台地址然后用 wait_for_selector 等待表格加载再用 extract_content 读取指定表格数据把内容存到一个临时变量里。节点二抓取资讯动态。打开资讯页面提取前五条内容的标题和摘要同样存成变量。节点三调用大模型生成日报。把前两个节点收集到的数据拼接成提示词让 DeepSeek 按固定模板生成日报文本。这里我在提示词里写明确了语气和格式要求比如“用三句话总结核心变化不要寒暄直接列要点”。节点四发送到协作平台。这一步我没有用浏览器的通用方式而是用了 WorkBuddy 内置的 webhook 发送功能直接调用协作平台的接口把日报文本传过去。比起操作网页接口方式稳定得多。4.3 配置浏览器操作从定位元素到稳定输入如果我不追求速度这套流程全用浏览器操作也能跑通但稳定性差很多。我的原则是能用接口的用接口必须操作网页的才用浏览器。需要操作网页时元素定位是最关键的环节。我建议优先使用稳定的选择器比如 id、name 这些属性尽量不用那种会自动生成的 class 名因为前端一改版就失效。WorkBuddy 里配置元素定位的时候会自动提取你点击过的元素的属性生成一段选择器但你最好还是手动检查一下选择器是不是够“硬”。在输入框输入文本时我给每个输入动作设置了 500ms 到 1000ms 的逐字输入延迟避免输入过快导致前端没有触发绑定事件。勾选、点击这类操作前后各加一个短暂等待保证页面的异步请求有足够时间完成。4.4 跑通第一次任务与调试记录第一次真正跑这个任务的时候其实没有想象中顺利。前两次都挂在同一个地方WorkBuddy 打开后台页面后表格数据是动态加载的实际等的时间比我预估的要长导致下一步读取内容时拿到的是空数据。调试方式很直接WorkBuddy 会保留任务运行日志我点开日志看了一下发现 extract_content 报出来的结果是空字符串。我把 wait_for_selector 的超时时间从 10 秒调整到 30 秒又在读取之前加了一个 2 秒的固定等待问题就解决了。第二次跑的时候日报文本生成得不错但发送通知时发现 Webhook 地址配置里少了一个参数导致消息没有发出去。加上参数再跑一次就通了。整个调试过程大概花了 20 分钟比我要是一开始用 Python 脚本写这套流程节省的时间多得多。配置完成后我手动触发了几次确认稳定才把 trigger 改成每天早上的定时执行。现在这套任务每天都自动跑我要做的只是在收到通知后扫一眼结果。5. 常见问题排查与三个踩坑实录5.1 常见问题速查表把我在试用和配置过程中遇到的高频问题整理成了表格方便你对照排查。问题现象可能原因处理方法任务一直卡在某一步页面元素没有正常加载检查 wait_for_selector 的选择器是否正确调大超时时间读取到的表格数据为空页面是异步渲染读取过早在读取前加 2~5 秒等待确认数据出现后再执行浏览器窗口一闪而过缺少浏览器内核依赖按对应系统安装 Chromium 或 ChromeLinux 下启动报沙箱错误系统缺少沙箱权限配置在配置中追加 --no-sandbox 参数模型返回内容不符合预期提示词写得太模糊在 Skill 的提示词中给固定模板和示例输出定时任务没有触发cron 表达式或时区不对检查系统时区先手动触发一次确认链路通网页登录态过期浏览器缓存被清理登录后保持浏览器缓存目录不被清理必要时配置登录 cookie5.2 踩坑实录一选择器太脆弱改版一次挂一次我第一次做网页自动化时直接用了 WorkBuddy 自动生成的元素选择器。结果运营那边改了一次页面样式所有选择器全部失效。后来我养成了一个习惯凡是涉及经常变的页面尽量用文本内容定位比如用“包含指定文字的按钮”来定位而不是用 class 属性。这样即使页面样式变了只要文案没变任务就不会挂。5.3 踩坑实录二模型自由发挥导致流程不可控最初我把 Skill 里的步骤写得比较粗只给了大模型一个目标让它自行决定操作顺序。结果发现不同时间跑出来的行为完全不一样有时它会跳过我预期的确认步骤直接执行不可逆操作。后来我把步骤拆细每个 Skill 里的步骤都明确指定“做什么、用什么选择器、等待多久、成功标准是什么”并且设置了只有上一步校验通过才继续执行的条件。经过这轮调整之后任务的成功率明显提升。5.4 踩坑实录三高频重复运行被限流有段时间我把一个检查任务设置成每 5 分钟跑一次跑了一个上午之后后端开始拒绝请求。控制节奏非常重要。对不需要实时响应的任务建议至少间隔 30 分钟以上或者只在业务低峰期执行。如果确实需要更高频率可以考虑给接口调用加上随机延迟模拟自然人操作节奏。实际用下来WorkBuddy 这套组合给我最大的收获不是省了多少时间而是让我重新梳理了一遍自己的工作流哪些环节是纯重复动作、哪些环节需要判断、哪些环节不可逆。把这些问题想清楚以后即使不用 WorkBuddy用手边的其他工具也能做出不错的自动化脚本。如果你刚开始接触 AI 智能体建议先拿一个每天 5 分钟的小任务练手跑通一遍 Skill 的配置和调试流程再慢慢扩大范围。我最后还会在 Skill 里加一个运行结束后的总结节点让智能体把当天的执行结果简要汇报给我这样既保留了自动化的便捷又留住了对关键业务环节的掌控感。
用WorkBuddy搭建每日自动化：AI智能体+Skill指令集实战
每天早上到了工位先开浏览器、登录后台、复制昨天的数据、填表格、写日报、再顺手把几个固定链接点一遍——这套流程我重复了快三年直到把 WorkBuddy 用起来以后上午黄金时间才真正还给了写代码和想方案。这篇就记录我用 WorkBuddy 搭建每日工作自动化的完整过程。它本质是一个本地运行的 AI 智能体工作台核心思路不是让大模型自由发挥而是通过 Skill 指令集把“固定动作”固化下来再由智能体调用浏览器、桌面应用和外部接口替你执行。整个过程不要求你会写完整代码懂一点 JSON 和基础逻辑就能上手。适合每天有大量重复网页操作、信息汇总、日报生成需求的人也适合想摸清 AI 智能体到底怎么落地的人。1. 为什么我最终用 WorkBuddy 替换掉了手写脚本和 RPA1.1 自动化工具那么多WorkBuddy 的差异点在哪先说背景。我最早处理这类重复劳动用的是 Python 脚本后来也试过 Playwright、Appium 之类的自动化测试框架来做浏览器操作再后来接触了 RPA 工具。这些方案各自都有让人头疼的地方。纯脚本的问题在于网页结构一改选择器全部失效又要花半天去改代码。RPA 工具则太笨重流程设计器拖来拖去遇到动态元素、登录态过期、弹窗变化就卡住而且贵。Coze、Dify 这类云端智能体平台我也试过优点是搭工作流快但涉及到本地文件、企业内部系统、需要长期保持登录态的网页时云端跑起来总觉得隔了一层。WorkBuddy 的做法是折中它把自己定位成安装在本地的智能体工作台对外提供桌面端和命令行两种使用方式。你仍然需要在本地安装浏览器控制组件但因为智能体的大脑是接大模型 API所以在语言理解、判断网页状态、生成操作参数上比传统 RPA 靠“录屏坐标”要聪明得多。最关键的是它引入了 Skill 机制让我可以把频繁使用的固定动作沉淀成模板下次直接调用不用重新写一遍。1.2 核心原理智能体、Skill 指令集和浏览器操作如何配合WorkBuddy 的工作模式可以简化成三部分大模型当大脑、Skill 当操作手册、浏览器控制组件当手脚。大模型负责理解你的自然语言指令然后把指令拆解成具体动作序列。Skill 则是一个结构化的 JSON 描述文件里面记录了某个任务的步骤、参数、提示词和校验规则。两者配合起来的效果是你不是在让 AI “随便帮我看一下”而是让它严格按照一套预先定义好的标准作业流程去执行。浏览器控制组件用于真正操作页面——打开网址、点击按钮、输入文字、读取表格内容、截图、下载文件。WorkBuddy 在这块兼容了 Playwright 协议的底层能力所以我在网页自动化里踩过的大部分经验迁移过来都是通的。提示把 WorkBuddy 理解成“带了一个只会照章办事的实习生”会更准确。它稳定是因为有章法而不是因为它智能到可以临场发挥。所以你想让它自动化什么前提是你自己得先把流程想清楚。2. 安装与模型接入Windows、Ubuntu 和 DeepSeek 兼容接口2.1 Windows 和 macOS 的安装流程WorkBuddy 的安装没有想象中麻烦。Windows 端我直接去官网下了安装包双击之后一路下一步装完会在系统托盘常驻。首次启动后它会引导你创建一个本地工作目录这个目录用来存放你的 Skill 文件、任务日志和浏览器配置文件。在 macOS 上也是类似下载 dmg 拖进 Applications 即可。有一点要注意首次启动浏览器自动化功能时系统会请求辅助功能权限需要在“系统设置-隐私与安全性-辅助功能”里把 WorkBuddy 勾上否则它控制不了浏览器窗口。安装完成后界面上会让填模型配置。WorkBuddy 支持 OpenAI 兼容格式的接口也就是说只要 API 风格兼容都可以填进去。我填的是 DeepSeek 的接口配置项如下。2.2 Ubuntu / Linux 环境下的安装要点热搜里看到很多人问 workbuddy linux、workbuddy ubuntu我专门在 Ubuntu 22.04 上试了一遍。Linux 下不是双击安装而是通过命令行装的# 拉取安装包具体包名以官方发布页为准 wget https://example.com/workbuddy-latest-linux.deb sudo dpkg -i workbuddy-latest-linux.deb # 如果缺依赖用下面的命令补装 sudo apt-get install -f装完以后WorkBuddy 会以服务形式运行你在终端输入workbuddy就能进入交互模式。Linux 下比较容易踩坑的是缺浏览器依赖。如果你系统里没有 Chromium它会提示找不到浏览器内核。解决方法是手动装一下sudo apt-get install -y chromium-browser装好之后在 WorkBuddy 的配置文件里指定浏览器的可执行文件路径。还有一个坑是 Linux 下的沙箱权限WorkBuddy 启动浏览器组件时如果报“sandbox 相关错误”通常需要在配置里加上--no-sandbox参数。这个参数在本地可控环境里是安全的但如果部署在多人共用的服务器上建议评估一下风险。2.3 模型接入以 DeepSeek 兼容接口为例模型配置界面大概长这样需要填 Base URL、API Key、模型名称三个字段。{ model_provider: openai_compatible, base_url: https://api.deepseek.com/v1, api_key: 你的API Key, model: deepseek-chat }这里面的逻辑不复杂WorkBuddy 的所有智能体对话、任务规划、步骤生成都通过这个接口发给大模型处理。DeepSeek 的成本比较低拿来跑日常自动化的批量任务很划算。如果你手上有其他兼容 OpenAI 格式的服务同样可以填进去。配置完之后我建议先做一个连通性测试让 WorkBuddy 跑一句最简单的指令比如“请介绍一下你自己”。只要这一步通了后面搭建工作流基本不会卡在模型层。注意API Key 属于敏感凭据WorkBuddy 默认存在本地配置文件里。如果你有多台机器同步配置千万不要把包含 Key 的配置文件传到公开仓库。3. Skill 机制拆解把“随口让AI干活”变成固定工作流3.1 Skill 的本质给智能体一本标准化操作手册很多人用 AI 智能体失败不是因为模型不够聪明而是因为指令不固定。今天说“把表格整理一下”明天说“把表格汇总好发我”模型每次理解的都不一样输出自然不稳定。Skill 就是来解决这个问题的。它相当于给智能体一本精细到每一步的操作手册——不是“整理表格”这种模糊指令而是“打开指定 Excel 文件读取 B 列到 F 列的数据按日期排序生成 Markdown 表格保存到 output 目录”这样明确的动作序列。我习惯用 Excel 里的宏来类比Excel 宏把一系列操作录制下来下次一键回放WorkBuddy 的 Skill 把一系列带判断逻辑的动作封装起来智能体执行时还可以根据实际页面内容做微调。它比宏灵活比纯自然语言稳定。3.2 一个实际 Skill 的 JSON 结构详解WorkBuddy 的 Skill 文件放在工作目录下的 skills 文件夹里一个 Skill 对应一个 JSON 文件。我拆一个最简单的示例——定时打开数据后台并截图{ name: open_dashboard_and_screenshot, description: 打开数据后台首页等待加载完成后截图保存, trigger: { type: schedule, cron: 0 9 * * * }, steps: [ { action: browser_open, url: https://your-dashboard.example.com }, { action: wait_for_selector, selector: .main-container, timeout: 30000 }, { action: screenshot, save_path: output/dashboard_{date}.png }, { action: ai_summarize, prompt: 请用三句话概括这张数据看板里的关键指标变化 } ] }这个文件虽然简单但已经包含了 WorkBuddy 自动化任务的完整要素。name 和 description 是给智能体识别用的trigger 定义了触发方式这里是每天 9 点steps 是核心按照顺序定义智能体要执行的动作。我把 steps 里的每个 action 理解成“积木块”WorkBuddy 内置了 browser_open、wait_for_selector、screenshot、ai_summarize、file_write、send_message 这一批常用积木。你不需要全部记住在配置界面里可以直接选选完填参数就行。3.3 让工作流真正落地定时触发与人工确认点Skill 里的 trigger 是整个自动化的开关。WorkBuddy 支持几种触发方式定时触发cron 表达式指定时间适合日报、周报、定时检查这类任务。手动触发点击运行按钮适合需要人在场的任务。监听触发监听某个目录的文件变化、某个网页元素的出现属于进阶玩法。我建议新手从定时任务开始。不过定时任务有个容易忽略的点无人值守的情况下中间任何一步出错都可能让整个链路断掉。所以我设计 Skill 时有两个习惯一是关键动作之间加 wait_for_selector 等待元素出现避免页面还没加载完就执行下一步二是在发送外部消息这种不可逆操作前设置一个人工确认点让 WorkBuddy 执行到这一步时停下来等我确认。提示自动化不是全自动半自动才是日常最稳的形态。把“会出错后很难挽回”的步骤留给人来确认其余无脑操作全交给智能体。4. 10 分钟搭一个每日自动化信息汇总日报全流程实录4.1 先定场景我选的是“早晨信息汇总日报”理论说了不少接下来是完整的实操记录。我选了一个很常见的场景每天早晨把几个网站的数据抓下来、汇总成日报、再发到团队协作平台。这个场景覆盖了 WorkBuddy 的核心能力浏览器操作打开网页、读取数据、AI 生成汇总关键信息、写日报文案、外部交互发送到协作平台。如果你要自动化的不是这个场景也完全可以参考这套流程把具体网址和数据字段替换掉就行。我先把整个任务拆成四段打开数据后台 A读取昨日核心指标打开资讯页面 B抓取当天前几条重要动态把两部分内容丢给大模型生成一份结构化日报把日报内容写入团队协作平台的指定文档并发送通知4.2 搭建工作流的四个核心节点WorkBuddy 的配置界面里可以直接创建任务然后按顺序添加节点。我实际配置的节点是这样的节点一打开数据后台并读取指标。这个节点用 browser_open 打开后台地址然后用 wait_for_selector 等待表格加载再用 extract_content 读取指定表格数据把内容存到一个临时变量里。节点二抓取资讯动态。打开资讯页面提取前五条内容的标题和摘要同样存成变量。节点三调用大模型生成日报。把前两个节点收集到的数据拼接成提示词让 DeepSeek 按固定模板生成日报文本。这里我在提示词里写明确了语气和格式要求比如“用三句话总结核心变化不要寒暄直接列要点”。节点四发送到协作平台。这一步我没有用浏览器的通用方式而是用了 WorkBuddy 内置的 webhook 发送功能直接调用协作平台的接口把日报文本传过去。比起操作网页接口方式稳定得多。4.3 配置浏览器操作从定位元素到稳定输入如果我不追求速度这套流程全用浏览器操作也能跑通但稳定性差很多。我的原则是能用接口的用接口必须操作网页的才用浏览器。需要操作网页时元素定位是最关键的环节。我建议优先使用稳定的选择器比如 id、name 这些属性尽量不用那种会自动生成的 class 名因为前端一改版就失效。WorkBuddy 里配置元素定位的时候会自动提取你点击过的元素的属性生成一段选择器但你最好还是手动检查一下选择器是不是够“硬”。在输入框输入文本时我给每个输入动作设置了 500ms 到 1000ms 的逐字输入延迟避免输入过快导致前端没有触发绑定事件。勾选、点击这类操作前后各加一个短暂等待保证页面的异步请求有足够时间完成。4.4 跑通第一次任务与调试记录第一次真正跑这个任务的时候其实没有想象中顺利。前两次都挂在同一个地方WorkBuddy 打开后台页面后表格数据是动态加载的实际等的时间比我预估的要长导致下一步读取内容时拿到的是空数据。调试方式很直接WorkBuddy 会保留任务运行日志我点开日志看了一下发现 extract_content 报出来的结果是空字符串。我把 wait_for_selector 的超时时间从 10 秒调整到 30 秒又在读取之前加了一个 2 秒的固定等待问题就解决了。第二次跑的时候日报文本生成得不错但发送通知时发现 Webhook 地址配置里少了一个参数导致消息没有发出去。加上参数再跑一次就通了。整个调试过程大概花了 20 分钟比我要是一开始用 Python 脚本写这套流程节省的时间多得多。配置完成后我手动触发了几次确认稳定才把 trigger 改成每天早上的定时执行。现在这套任务每天都自动跑我要做的只是在收到通知后扫一眼结果。5. 常见问题排查与三个踩坑实录5.1 常见问题速查表把我在试用和配置过程中遇到的高频问题整理成了表格方便你对照排查。问题现象可能原因处理方法任务一直卡在某一步页面元素没有正常加载检查 wait_for_selector 的选择器是否正确调大超时时间读取到的表格数据为空页面是异步渲染读取过早在读取前加 2~5 秒等待确认数据出现后再执行浏览器窗口一闪而过缺少浏览器内核依赖按对应系统安装 Chromium 或 ChromeLinux 下启动报沙箱错误系统缺少沙箱权限配置在配置中追加 --no-sandbox 参数模型返回内容不符合预期提示词写得太模糊在 Skill 的提示词中给固定模板和示例输出定时任务没有触发cron 表达式或时区不对检查系统时区先手动触发一次确认链路通网页登录态过期浏览器缓存被清理登录后保持浏览器缓存目录不被清理必要时配置登录 cookie5.2 踩坑实录一选择器太脆弱改版一次挂一次我第一次做网页自动化时直接用了 WorkBuddy 自动生成的元素选择器。结果运营那边改了一次页面样式所有选择器全部失效。后来我养成了一个习惯凡是涉及经常变的页面尽量用文本内容定位比如用“包含指定文字的按钮”来定位而不是用 class 属性。这样即使页面样式变了只要文案没变任务就不会挂。5.3 踩坑实录二模型自由发挥导致流程不可控最初我把 Skill 里的步骤写得比较粗只给了大模型一个目标让它自行决定操作顺序。结果发现不同时间跑出来的行为完全不一样有时它会跳过我预期的确认步骤直接执行不可逆操作。后来我把步骤拆细每个 Skill 里的步骤都明确指定“做什么、用什么选择器、等待多久、成功标准是什么”并且设置了只有上一步校验通过才继续执行的条件。经过这轮调整之后任务的成功率明显提升。5.4 踩坑实录三高频重复运行被限流有段时间我把一个检查任务设置成每 5 分钟跑一次跑了一个上午之后后端开始拒绝请求。控制节奏非常重要。对不需要实时响应的任务建议至少间隔 30 分钟以上或者只在业务低峰期执行。如果确实需要更高频率可以考虑给接口调用加上随机延迟模拟自然人操作节奏。实际用下来WorkBuddy 这套组合给我最大的收获不是省了多少时间而是让我重新梳理了一遍自己的工作流哪些环节是纯重复动作、哪些环节需要判断、哪些环节不可逆。把这些问题想清楚以后即使不用 WorkBuddy用手边的其他工具也能做出不错的自动化脚本。如果你刚开始接触 AI 智能体建议先拿一个每天 5 分钟的小任务练手跑通一遍 Skill 的配置和调试流程再慢慢扩大范围。我最后还会在 Skill 里加一个运行结束后的总结节点让智能体把当天的执行结果简要汇报给我这样既保留了自动化的便捷又留住了对关键业务环节的掌控感。
