早晨八点五十分我打开电脑WorkBuddy 已经把我昨天在后台配置好的几条自动化流程跑完了。多平台订单汇总表安静地躺在工作目录里格式跟往常一模一样定时的站点签到也显示“已完成”昨晚丢给它的一个数据处理需求连结果带脚本都整齐地放在指定文件夹。而我只需要花十分钟扫一眼结果有问题的地方点开日志看一眼剩下的时间直接进入正经工作。这个状态我刚开始用 AI 智能体的时候根本不敢想。用过一段 WorkBuddy 之后我最大的感受是它真正解决的不是“帮我回答问题”而是“到点就把活干了而且每次干得都一样”。这篇东西我不打算讲什么高深原理就是把从安装到搭好一套每日自动化流程的完整路径写出来所有步骤都是我自己跑过的照着抄就行。1. 它不是另一个聊天机器人WorkBuddy 解决的是“反复做”而不是“聊得好”1.1 先搞清楚 AI 智能体和聊天助手的本质区别很多人第一次用 WorkBuddy 的时候都会下意识地把它当成 ChatGPT、豆包那样的对话框来用输入一个问题等它吐一段回答。这个用法不能说错但完全没有发挥出它的价值甚至会让你觉得“这不就是个普通 AI 吗”。这两类工具的定位差别我用一句话概括聊天助手是“你问它答”AI 智能体是“你定规则它执行”。你问 ChatGPT“帮我写一封催款邮件”它给你一封邮件这件事就结束了。但 WorkBuddy 的打开方式是你把“每天上午 9 点检查一遍所有待回款的订单超过 7 天没付款的发一封提醒邮件”这个完整流程交给他它接下来每天自动执行过程中如果遇到异常还会停下来写日志等你看。也就是说聊天机器人交付的是内容Agent 交付的是“持续运行的结果”。1.2 一套自动化系统里WorkBuddy 到底扮演什么角色刚开始接触 WorkBuddy 的人容易被一个词搞混它到底算 AI 模型还是一个工具平台我的理解是它更像一个调度中枢夹在模型和执行环境之间。整套系统分三层去看就清楚了模型层负责理解你的指令、做规划、生成文本和代码。它可以是 WorkBuddy 内置接入的模型也可以是你自己配置的 API比如 DeepSeek、OpenAI 之类的。执行层WorkBuddy 帮你把模型输出变成真实操作——读写文件、调接口、打开浏览器点击按钮、跑一个 Python 脚本、按定时器触发等等。规则层Skill技能和自定义指令负责把“该怎么做”沉淀下来。没有这一层每次运行都像重新教一遍新人有了这一层模型拿到手就是按规程做事。这样拆开看你就能理解 WorkBuddy 和单纯用 Claude Code 这类命令行编程智能体的差异命令行工具擅长在代码库里写代码、改代码而 WorkBuddy 的 Skill 体系和定时机制让它更适合跟网页、办公文件、业务 API 打交道是个更偏向日常业务自动化的工具。1.3 什么样的场景才值得上自动化什么场景别浪费这是我最想劝新手想清楚的一点不是所有事都适合做成 AI 自动化。我见过有人花一个下午试图让 Agent 自动整理他的收件箱结果因为规则太多、例外太多反而比手动做还累。我自己判断一个任务值不值得交给 WorkBuddy就看三个条件同时是否成立判断条件说明反例每天重复至少一周里出现两三次一个月一次的年报规则相对固定流程看得见、说得清高度依赖人来拍板的内容创作输出要稳定格式、位置、时间有明确要求凭感觉写的文案初稿拿我自己来举例每天早上抓取各平台订单并汇总成表格完全满足这三条值得自动化。但“帮我看看这版海报哪里不好看”这种主观任务就算做成 Skill 也只能给你一堆模棱两可的建议不适合硬上。2. 开工前这几件事不做好后面全是坑安装与初始化避坑笔记2.1 环境准备与第一步跑通先聊最容易被忽略的部分WorkBuddy 的安装本身不复杂但很多人卡在一个思维误区——想等把所有参数、所有账号都配明白了再跑第一条任务。千万别这样自动化工具跟编程一样必须先把最小闭环跑通再逐步加功能。我第一次的安装路径是这样的确认本机 Node.js 版本在要求范围之内然后通过命令行安装 WorkBuddy 的 CLI 包具体包名会因为版本迭代有差异以官方文档为准。安装完成后先执行一个最简单的命令验证环境比如让它自动创建一个测试文件夹并写入一行文本能成功就说明安装没有问题。如果你用的是 Linux 服务器版本还要额外检查一下系统依赖里有没有缺基础的图形库和浏览器组件因为后面的浏览器自动化任务会用得到。最好先跑一个打开网页的命令看看能不能正常启动浏览器实例这一步提前验证能帮你把最底层的环境问题排除干净。2.2 把模型接成自己的API Key 和基础配置WorkBuddy 官方平台本身会提供额度但我的建议是如果运行强度和频次上来了老老实实申请一个自己的模型 API把 WorkBuddy 切到自有密钥上跑。以国内很多人选的 DeepSeek 为例配置思路其实和其他 API 兼容服务一样# 在环境变量里写入模型 API 配置 export LLM_API_KEYsk-你的密钥 export LLM_BASE_URLhttps://api.deepseek.com/v1 export LLM_MODELdeepseek-chat有几个细节要提醒一下环境变量只在当前终端会话生效如果你是通过面板启动 WorkBuddy建议把环境变量写进配置文件里避免重启就丢。选模型时别一味追求顶配日常的订单汇总、签到这个级别用轻量模型就可以成本能省下一大截。复杂任务再单独指定强模型。一定要把密钥放在环境变量或.env文件里不要把明文密钥写进 Skill 或指令文件不然下次分享流程的时候就把密钥泄了。2.3 我最想让你避开的报错502 EACCES 权限问题搜索 WorkBuddy 相关经验的时候网上有一个很高的搜索词组是“workbuddy 502 write eacces”我有话要说这个错我踩过还花了不少时间。它表面上看是网络错误502实际是文件系统权限问题——EACCES 是 Linux/Unix 系统里 Permission denied 的标准报错码。WorkBuddy 在运行的时候要写日志、写缓存、写临时文件如果安装目录位于系统受保护路径下而当前用户没有写权限就会报出这个错。我的排查链路大概是这样的给各位当参考先看报错上下文确认是“failed to write”还是“EACCES”找到 WorkBuddy 的日志目录试试手动在那个目录下创建文件复现权限问题如果是全局安装导致的目录归属问题最简单的方法是把 WorkBuddy 的缓存和工作目录改到当前用户的 Home 目录下或者直接用管理员权限执行一次chown -R 当前用户名 目录路径让用户获得目录归属权改完以后再跑一次之前的测试命令确认日志能正常写入。这个错最大的坑在于它藏在网络错误的外衣下面不看日志根本不知道根因在文件权限。所以我建议所有人拿到新环境第一件事就是确认 WorkBuddy 的工作目录、日志目录、缓存目录这三处的位置和权限提前排除掉这个雷。2.4 初始化阶段顺手做掉的几件事初始化的时候我有几件小事是每次都做的养成习惯能省不少事建一个独立的工作根目录比如~/workbuddy-workspace所有 Automation、Skill、日志都归拢在这里。这样后续迁移、备份都很干净不会跟系统目录混在一起。建立一个skills目录从第一天下载 Skill 或者自建 Skill 就往里放Val 后面找起来会乱。配置一个定时任务的环境变量把每天要用的时间时区、默认输出路径写进去后续每个任务都能共用。这三件事的成本极低但能把“把工作区当成系统文件一样管理”变成肌肉记忆后面维护几套流程的时候你会感谢自己的。3. 把每天重复的事情写成“指令”自定义指令与 Skill 的工作机制3.1 自定义指令不是 Prompt而是操作章程很多人容易有一个错觉给 AI 写指令不就是写一段 prompt 吗差别其实非常大。Prompt 是“给我一段总结”“写一个回复”它面向的是单次生成。而 WorkBuddy 里的自定义指令相当于你给一个很聪明但无行业常识的新员工写的一本操作手册——你得保证他今天看这本能干对明天看这本还能干对换一个人来看也差不太多。我会用下面这个结构来写一个自定义指令这套结构在多数任务里都稳定适用## 任务目标 这一段任务到底要被设置成什么样拿到什么结果才算成功 ## 输入来源 数据从哪里读取文件路径、API 地址、网页 URL 都要写清楚 ## 执行步骤 1. 先做什么2. 再做什么3. 最后做什么。不要只写一步“去整理数据” ## 输出格式 字段有哪些顺序、分隔符、表格标题全部固定下来 ## 异常处理 如果遇到登录失效怎么办如果某平台没数据怎么办这个字段很多人会漏但恰恰是它决定了 Agent 是停下来等你还是自作主张写完整条指令之后你自己检查一遍如果一个第一次接触这个业务的人拿到这份文档能照做吗如果不能说明细节还不够。3.2 Skill 到底是什么流程打包成可复用能力理解了自定义指令Skill 就很好理解了。Skill 指令 配套脚本 元信息描述它的目的是把一整条操作流程打包成一个可以被重复调用的能力模块。我的理解是自定义指令是“给某一次任务写的说明”而 Skill 是“把这类任务变成一个产品”。比如“自动签到”这个需求拆开来看它包含读取需要签到的账户信息和待办列表打开对应站点找到签到入口完成操作把签到结果记录到日志失败时重试并汇报。这一整套东西固化下来就是一个 Skill。以后你只需要给 WorkBuddy 说“用签到技能跑一遍”它就会自动加载技能里的全部说明和脚本去执行。SkillHub 上有很多别人贡献好的成品技能可以少走一些弯路。但我建议拿到别人的 Skill 不要直接用先看一遍它的指令文件搞清楚它期望的输入是什么输出的日志在哪再落到自己目录里跑一次试试。3.3 自己写一个最小可用的 Skill如果完全自己从零写 Skill核心是写好两个文件一个是描述信息和参数定义的清单另一个是操作流程说明。以我最常用的“自动签到”为例Skill 文件大概长这样不同版本的字段名可能有差异思路是一致的name: daily-checkin description: 每天自动完成指定站点的签到任务并记录结果 version: 1.0.0 inputs: - name: site_list description: 待签到站点的基础信息和入口 URL required: true配套的操作说明里会写清楚Site 列表每个条目需要包含哪些字段、每步停顿等待时间、什么样的情况算失败、失败之后是重试还是跳过并记录。写完以后关键的命令行运行方式大体是workbuddy run --skill daily-checkin第一次跑的时候别后台运行守在旁边看一遍它的实际行为是不是你想的有问题马上调整。这一步非常重要等你确认它三次运行结果一致再考虑设置定时调度。4. 一套完整的每日自动化工单拆解从需求到可运行工作流4.1 先拆需求再碰键盘一页纸把每日任务说清楚很多自动化失败问题不是出在执行技术而是出在需求根本没拆清楚。我搭过的最值得拿来当范例的一条是跨境电商多平台订单抓取每天 9 点自动把各平台后台的昨日订单抓下来汇总成一张统一格式的表格再在群里发一条简报。动手配 WorkBuddy 之前我先按下面这个表把所有信息固定下来项目内容触发时间每个工作日上午 9:00数据来源3 个电商平台后台的订单页面处理动作提取订单号、金额、状态、收货地址换算成统一币种输出文件/reports/{日期}-order-summary.xlsx消息推送生成一条文字简报发送到企业微信群失败预案某个平台抓取失败时保留既有数据并在简报中标记异常这张纸写完之后一切技术配置都围绕它去展开不会做着做着就忘了原始需求。4.2 浏览器操作类任务关键参数与容错设计多平台订单抓取这种任务核心实现方式就是浏览器自动操作。实现思路是让 AI 智能体打开浏览器访问指定地址等待页面加载定位订单表格提取数据。这里有个经验千万不要指望 Agent 像人一样“看”网页而是给它稳定的定位方式。比如让它在页面里查找“订单列表”区块、按表格行遍历数据。凡是涉及页面加载一定要设置等待时间或等待条件不然脚本跑得太快页面数据还没加载出来抓到的就是空白。还有经常被忽略的是登录态问题。一般平台后台的会话有效期只有几天经常出现定时任务跑到第三天突然全部失败的情况。我建议把“登录态失效检测”写进流程里当页面上出现“请登录”等特征信息时Agent 不要再往下执行而是直接停止并发出提醒等人工处理。宁可少跑一次也不要让它带着失效的会话硬跑把页面结构搞乱了。4.3 让整个流程协作起来串联、调度与验证拆解完需求、配好单个步骤之后就要把这些步骤在 WorkBuddy 里串成一个完整工作流。我的顺序设计是这样的定时触发器工作日上午 9 点启动采集步骤依次打开各个平台后台抓取前一日的订单数据每个平台单列一个临时文件清洗汇总把多平台数据按统一字段合并处理币种换算和缺失字段生成报告基于汇总表生成 Excel 和一段文字简报消息分发调用群机器人 Webhook 把简报发出去收尾把当天的运行日志和结果文件的存储路径记录下来。前 1 到 3 步在 WorkBuddy 中分别由不同的 Skill 承担第 4、5 步则直接写脚本调用对应 API。每一步的输出都落到磁盘这样就算第 5 步失败前面的成果也都还在不会出现“一步失败全部推倒重来”的惨案。定时配置这里WorkBuddy 内部有调度管理如果你跑在 Linux 服务器上也可以直接用系统自带的 crontab 来触发命令行入口。两种方式我都试过更推荐把调度放到 WorkBuddy 内管因为它的日志和状态联动更完整出问题了在一处就能排查。4.4 首次运行我陪着盯一遍一套调试自查清单自动化上线第一天别设置完就跑路。我通常会陪跑至少三次每次重点检查这几个位置数据准确性拿一条已知订单跟汇总表里的对应记录比对确认没有多加、漏加或格式错乱。异常路径故意把一个平台的后台会话清掉让流程走到失败逻辑确认它能正确识别并停下来提醒而不是带着错误数据继续。幂等性同一天的任务重复跑两遍第二遍不应该生成两份重复数据应该做去重或覆盖。资源释放浏览器进程有没有在任务结束后正常关闭磁盘临时文件有没有清理干净。等这四项都稳定了才算是真正把这条自动化流程“养熟”。5. 跑通了之后三组高频问题的排查与提效技巧5.1 抓取类任务最容易挂的三个位置如果让我做过一个统计在跑网页操作类自动化时90% 的失败都集中在这三类登录态过期症状是某一天开始所有数据都是空的页面实际跳去了登录页。对策是加入特征检测识别到“登录”“验证”等关键词立即触发预警。网站页面改版症状是长期稳定的流程突然开始报错。这种问题无解必须人工上去看一眼。对策是把“页面结构描述”集中在 Skill 的一个配置区域改版时只改那个区域而不是动整套逻辑。访问频率被限制症状是页面出现“访问过于频繁”的提示。对策是拉长操作间隔、降低并发尽量在平台业务低峰时段跑批量任务。优先用平台官方提供的 API 读取数据能调 API 就不用页面抓取这是最稳的路径。每一次异常我都建议把报错截图、触发时间段、当时日志一起存档。跑了两三周之后你再回头翻这些记录会发现很多“随机故障”其实都是有规律的。5.2 Agent 生成的任务为什么第二天就罢工了有一种典型困境是昨天跑得好好的 Skill今天跑就报错。多数情况不是因为 Agent“变笨了”而是你的 Skill 把不该写死的东西写死了。我把脚本里涉及的内容分成两层去处理稳定层数据字段、处理逻辑、输出格式这部分要写死保证结果稳定易变层URL、页面按钮位置、选择器、等待时间这些很容易随外部环境变化要抽到配置里。举个直观例子。有个抓取任务我最初把页面表格的定位方式直接写死在流程步骤里结果平台改了一次页面样式全盘崩溃。后来我把定位信息挪到 Skill 的配置区单独拎出来改动就只影响一处不需要重新设计整个流程。这个原则在 WorkBuddy 所有类型任务里都适用。凡是“针对具体环境的东西”永远不要和“通用规则”混在一起。5.3 省积分的三个实用思路运行强度上去之后很多人会来问怎么节约 WorkBuddy 积分或算力消耗。我自己实践下来比较有效的是这三条能用脚本处理的部分不要占用 Agent 调用次数。比如把几十个 CSV 文件合并成一张总表这种纯粹的数据处理用 Python 写死就行根本不需要模型参与。模型只负责“做决策”和“写代码”固定执行的活交给普通脚本。指令写不清楚代价是返工。指令越模糊Agent 就越容易多跑几轮去试探你的意图。把输入字段、步骤、异常处理写清楚一次跑通的概率会大幅提高消耗自然就降下来了。把多个相关任务合并到一次运行里。比如我抓取多个平台的数据不会一个平台起一个任务而是合并成一个流程、共用一个浏览器会话会话启动和模型调用的固定成本只付一次。这三条里面第一条见效最快几乎立刻可以看到消耗明显下降。最后聊一点我的使用体会用 WorkBuddy 跑了两个多月我最大的变化不是“省了多少时间”而是“我不再害怕那些枯燥的重复工作了。”以前一想到每天早上要打开六七个后台挨个看一遍就头疼现在这些事跟着定时器自动发生我只需要在异常提醒弹出来的时候处理一下。如果你正准备入坑 AI 智能体我的建议是别一上来就搭一个万能自动化中枢先找一个每天最多小事比如整理一张表格、定时签到、抓取一个页面的数据把它完整做成一整套 Skill 跑顺。这个过程你会自然理解指令、Skill、调度这些概念之间的关系。迈过这个坎之后再去扩到多平台、多任务的复杂工作流就是水到渠成的事。 
长河君 · 2026/9/19 3:54:14 · 阅读 1.2k AI智能体WorkBuddy实战：从安装到搭建每日自动化流程
早晨八点五十分我打开电脑WorkBuddy 已经把我昨天在后台配置好的几条自动化流程跑完了。多平台订单汇总表安静地躺在工作目录里格式跟往常一模一样定时的站点签到也显示“已完成”昨晚丢给它的一个数据处理需求连结果带脚本都整齐地放在指定文件夹。而我只需要花十分钟扫一眼结果有问题的地方点开日志看一眼剩下的时间直接进入正经工作。这个状态我刚开始用 AI 智能体的时候根本不敢想。用过一段 WorkBuddy 之后我最大的感受是它真正解决的不是“帮我回答问题”而是“到点就把活干了而且每次干得都一样”。这篇东西我不打算讲什么高深原理就是把从安装到搭好一套每日自动化流程的完整路径写出来所有步骤都是我自己跑过的照着抄就行。1. 它不是另一个聊天机器人WorkBuddy 解决的是“反复做”而不是“聊得好”1.1 先搞清楚 AI 智能体和聊天助手的本质区别很多人第一次用 WorkBuddy 的时候都会下意识地把它当成 ChatGPT、豆包那样的对话框来用输入一个问题等它吐一段回答。这个用法不能说错但完全没有发挥出它的价值甚至会让你觉得“这不就是个普通 AI 吗”。这两类工具的定位差别我用一句话概括聊天助手是“你问它答”AI 智能体是“你定规则它执行”。你问 ChatGPT“帮我写一封催款邮件”它给你一封邮件这件事就结束了。但 WorkBuddy 的打开方式是你把“每天上午 9 点检查一遍所有待回款的订单超过 7 天没付款的发一封提醒邮件”这个完整流程交给他它接下来每天自动执行过程中如果遇到异常还会停下来写日志等你看。也就是说聊天机器人交付的是内容Agent 交付的是“持续运行的结果”。1.2 一套自动化系统里WorkBuddy 到底扮演什么角色刚开始接触 WorkBuddy 的人容易被一个词搞混它到底算 AI 模型还是一个工具平台我的理解是它更像一个调度中枢夹在模型和执行环境之间。整套系统分三层去看就清楚了模型层负责理解你的指令、做规划、生成文本和代码。它可以是 WorkBuddy 内置接入的模型也可以是你自己配置的 API比如 DeepSeek、OpenAI 之类的。执行层WorkBuddy 帮你把模型输出变成真实操作——读写文件、调接口、打开浏览器点击按钮、跑一个 Python 脚本、按定时器触发等等。规则层Skill技能和自定义指令负责把“该怎么做”沉淀下来。没有这一层每次运行都像重新教一遍新人有了这一层模型拿到手就是按规程做事。这样拆开看你就能理解 WorkBuddy 和单纯用 Claude Code 这类命令行编程智能体的差异命令行工具擅长在代码库里写代码、改代码而 WorkBuddy 的 Skill 体系和定时机制让它更适合跟网页、办公文件、业务 API 打交道是个更偏向日常业务自动化的工具。1.3 什么样的场景才值得上自动化什么场景别浪费这是我最想劝新手想清楚的一点不是所有事都适合做成 AI 自动化。我见过有人花一个下午试图让 Agent 自动整理他的收件箱结果因为规则太多、例外太多反而比手动做还累。我自己判断一个任务值不值得交给 WorkBuddy就看三个条件同时是否成立判断条件说明反例每天重复至少一周里出现两三次一个月一次的年报规则相对固定流程看得见、说得清高度依赖人来拍板的内容创作输出要稳定格式、位置、时间有明确要求凭感觉写的文案初稿拿我自己来举例每天早上抓取各平台订单并汇总成表格完全满足这三条值得自动化。但“帮我看看这版海报哪里不好看”这种主观任务就算做成 Skill 也只能给你一堆模棱两可的建议不适合硬上。2. 开工前这几件事不做好后面全是坑安装与初始化避坑笔记2.1 环境准备与第一步跑通先聊最容易被忽略的部分WorkBuddy 的安装本身不复杂但很多人卡在一个思维误区——想等把所有参数、所有账号都配明白了再跑第一条任务。千万别这样自动化工具跟编程一样必须先把最小闭环跑通再逐步加功能。我第一次的安装路径是这样的确认本机 Node.js 版本在要求范围之内然后通过命令行安装 WorkBuddy 的 CLI 包具体包名会因为版本迭代有差异以官方文档为准。安装完成后先执行一个最简单的命令验证环境比如让它自动创建一个测试文件夹并写入一行文本能成功就说明安装没有问题。如果你用的是 Linux 服务器版本还要额外检查一下系统依赖里有没有缺基础的图形库和浏览器组件因为后面的浏览器自动化任务会用得到。最好先跑一个打开网页的命令看看能不能正常启动浏览器实例这一步提前验证能帮你把最底层的环境问题排除干净。2.2 把模型接成自己的API Key 和基础配置WorkBuddy 官方平台本身会提供额度但我的建议是如果运行强度和频次上来了老老实实申请一个自己的模型 API把 WorkBuddy 切到自有密钥上跑。以国内很多人选的 DeepSeek 为例配置思路其实和其他 API 兼容服务一样# 在环境变量里写入模型 API 配置 export LLM_API_KEYsk-你的密钥 export LLM_BASE_URLhttps://api.deepseek.com/v1 export LLM_MODELdeepseek-chat有几个细节要提醒一下环境变量只在当前终端会话生效如果你是通过面板启动 WorkBuddy建议把环境变量写进配置文件里避免重启就丢。选模型时别一味追求顶配日常的订单汇总、签到这个级别用轻量模型就可以成本能省下一大截。复杂任务再单独指定强模型。一定要把密钥放在环境变量或.env文件里不要把明文密钥写进 Skill 或指令文件不然下次分享流程的时候就把密钥泄了。2.3 我最想让你避开的报错502 EACCES 权限问题搜索 WorkBuddy 相关经验的时候网上有一个很高的搜索词组是“workbuddy 502 write eacces”我有话要说这个错我踩过还花了不少时间。它表面上看是网络错误502实际是文件系统权限问题——EACCES 是 Linux/Unix 系统里 Permission denied 的标准报错码。WorkBuddy 在运行的时候要写日志、写缓存、写临时文件如果安装目录位于系统受保护路径下而当前用户没有写权限就会报出这个错。我的排查链路大概是这样的给各位当参考先看报错上下文确认是“failed to write”还是“EACCES”找到 WorkBuddy 的日志目录试试手动在那个目录下创建文件复现权限问题如果是全局安装导致的目录归属问题最简单的方法是把 WorkBuddy 的缓存和工作目录改到当前用户的 Home 目录下或者直接用管理员权限执行一次chown -R 当前用户名 目录路径让用户获得目录归属权改完以后再跑一次之前的测试命令确认日志能正常写入。这个错最大的坑在于它藏在网络错误的外衣下面不看日志根本不知道根因在文件权限。所以我建议所有人拿到新环境第一件事就是确认 WorkBuddy 的工作目录、日志目录、缓存目录这三处的位置和权限提前排除掉这个雷。2.4 初始化阶段顺手做掉的几件事初始化的时候我有几件小事是每次都做的养成习惯能省不少事建一个独立的工作根目录比如~/workbuddy-workspace所有 Automation、Skill、日志都归拢在这里。这样后续迁移、备份都很干净不会跟系统目录混在一起。建立一个skills目录从第一天下载 Skill 或者自建 Skill 就往里放Val 后面找起来会乱。配置一个定时任务的环境变量把每天要用的时间时区、默认输出路径写进去后续每个任务都能共用。这三件事的成本极低但能把“把工作区当成系统文件一样管理”变成肌肉记忆后面维护几套流程的时候你会感谢自己的。3. 把每天重复的事情写成“指令”自定义指令与 Skill 的工作机制3.1 自定义指令不是 Prompt而是操作章程很多人容易有一个错觉给 AI 写指令不就是写一段 prompt 吗差别其实非常大。Prompt 是“给我一段总结”“写一个回复”它面向的是单次生成。而 WorkBuddy 里的自定义指令相当于你给一个很聪明但无行业常识的新员工写的一本操作手册——你得保证他今天看这本能干对明天看这本还能干对换一个人来看也差不太多。我会用下面这个结构来写一个自定义指令这套结构在多数任务里都稳定适用## 任务目标 这一段任务到底要被设置成什么样拿到什么结果才算成功 ## 输入来源 数据从哪里读取文件路径、API 地址、网页 URL 都要写清楚 ## 执行步骤 1. 先做什么2. 再做什么3. 最后做什么。不要只写一步“去整理数据” ## 输出格式 字段有哪些顺序、分隔符、表格标题全部固定下来 ## 异常处理 如果遇到登录失效怎么办如果某平台没数据怎么办这个字段很多人会漏但恰恰是它决定了 Agent 是停下来等你还是自作主张写完整条指令之后你自己检查一遍如果一个第一次接触这个业务的人拿到这份文档能照做吗如果不能说明细节还不够。3.2 Skill 到底是什么流程打包成可复用能力理解了自定义指令Skill 就很好理解了。Skill 指令 配套脚本 元信息描述它的目的是把一整条操作流程打包成一个可以被重复调用的能力模块。我的理解是自定义指令是“给某一次任务写的说明”而 Skill 是“把这类任务变成一个产品”。比如“自动签到”这个需求拆开来看它包含读取需要签到的账户信息和待办列表打开对应站点找到签到入口完成操作把签到结果记录到日志失败时重试并汇报。这一整套东西固化下来就是一个 Skill。以后你只需要给 WorkBuddy 说“用签到技能跑一遍”它就会自动加载技能里的全部说明和脚本去执行。SkillHub 上有很多别人贡献好的成品技能可以少走一些弯路。但我建议拿到别人的 Skill 不要直接用先看一遍它的指令文件搞清楚它期望的输入是什么输出的日志在哪再落到自己目录里跑一次试试。3.3 自己写一个最小可用的 Skill如果完全自己从零写 Skill核心是写好两个文件一个是描述信息和参数定义的清单另一个是操作流程说明。以我最常用的“自动签到”为例Skill 文件大概长这样不同版本的字段名可能有差异思路是一致的name: daily-checkin description: 每天自动完成指定站点的签到任务并记录结果 version: 1.0.0 inputs: - name: site_list description: 待签到站点的基础信息和入口 URL required: true配套的操作说明里会写清楚Site 列表每个条目需要包含哪些字段、每步停顿等待时间、什么样的情况算失败、失败之后是重试还是跳过并记录。写完以后关键的命令行运行方式大体是workbuddy run --skill daily-checkin第一次跑的时候别后台运行守在旁边看一遍它的实际行为是不是你想的有问题马上调整。这一步非常重要等你确认它三次运行结果一致再考虑设置定时调度。4. 一套完整的每日自动化工单拆解从需求到可运行工作流4.1 先拆需求再碰键盘一页纸把每日任务说清楚很多自动化失败问题不是出在执行技术而是出在需求根本没拆清楚。我搭过的最值得拿来当范例的一条是跨境电商多平台订单抓取每天 9 点自动把各平台后台的昨日订单抓下来汇总成一张统一格式的表格再在群里发一条简报。动手配 WorkBuddy 之前我先按下面这个表把所有信息固定下来项目内容触发时间每个工作日上午 9:00数据来源3 个电商平台后台的订单页面处理动作提取订单号、金额、状态、收货地址换算成统一币种输出文件/reports/{日期}-order-summary.xlsx消息推送生成一条文字简报发送到企业微信群失败预案某个平台抓取失败时保留既有数据并在简报中标记异常这张纸写完之后一切技术配置都围绕它去展开不会做着做着就忘了原始需求。4.2 浏览器操作类任务关键参数与容错设计多平台订单抓取这种任务核心实现方式就是浏览器自动操作。实现思路是让 AI 智能体打开浏览器访问指定地址等待页面加载定位订单表格提取数据。这里有个经验千万不要指望 Agent 像人一样“看”网页而是给它稳定的定位方式。比如让它在页面里查找“订单列表”区块、按表格行遍历数据。凡是涉及页面加载一定要设置等待时间或等待条件不然脚本跑得太快页面数据还没加载出来抓到的就是空白。还有经常被忽略的是登录态问题。一般平台后台的会话有效期只有几天经常出现定时任务跑到第三天突然全部失败的情况。我建议把“登录态失效检测”写进流程里当页面上出现“请登录”等特征信息时Agent 不要再往下执行而是直接停止并发出提醒等人工处理。宁可少跑一次也不要让它带着失效的会话硬跑把页面结构搞乱了。4.3 让整个流程协作起来串联、调度与验证拆解完需求、配好单个步骤之后就要把这些步骤在 WorkBuddy 里串成一个完整工作流。我的顺序设计是这样的定时触发器工作日上午 9 点启动采集步骤依次打开各个平台后台抓取前一日的订单数据每个平台单列一个临时文件清洗汇总把多平台数据按统一字段合并处理币种换算和缺失字段生成报告基于汇总表生成 Excel 和一段文字简报消息分发调用群机器人 Webhook 把简报发出去收尾把当天的运行日志和结果文件的存储路径记录下来。前 1 到 3 步在 WorkBuddy 中分别由不同的 Skill 承担第 4、5 步则直接写脚本调用对应 API。每一步的输出都落到磁盘这样就算第 5 步失败前面的成果也都还在不会出现“一步失败全部推倒重来”的惨案。定时配置这里WorkBuddy 内部有调度管理如果你跑在 Linux 服务器上也可以直接用系统自带的 crontab 来触发命令行入口。两种方式我都试过更推荐把调度放到 WorkBuddy 内管因为它的日志和状态联动更完整出问题了在一处就能排查。4.4 首次运行我陪着盯一遍一套调试自查清单自动化上线第一天别设置完就跑路。我通常会陪跑至少三次每次重点检查这几个位置数据准确性拿一条已知订单跟汇总表里的对应记录比对确认没有多加、漏加或格式错乱。异常路径故意把一个平台的后台会话清掉让流程走到失败逻辑确认它能正确识别并停下来提醒而不是带着错误数据继续。幂等性同一天的任务重复跑两遍第二遍不应该生成两份重复数据应该做去重或覆盖。资源释放浏览器进程有没有在任务结束后正常关闭磁盘临时文件有没有清理干净。等这四项都稳定了才算是真正把这条自动化流程“养熟”。5. 跑通了之后三组高频问题的排查与提效技巧5.1 抓取类任务最容易挂的三个位置如果让我做过一个统计在跑网页操作类自动化时90% 的失败都集中在这三类登录态过期症状是某一天开始所有数据都是空的页面实际跳去了登录页。对策是加入特征检测识别到“登录”“验证”等关键词立即触发预警。网站页面改版症状是长期稳定的流程突然开始报错。这种问题无解必须人工上去看一眼。对策是把“页面结构描述”集中在 Skill 的一个配置区域改版时只改那个区域而不是动整套逻辑。访问频率被限制症状是页面出现“访问过于频繁”的提示。对策是拉长操作间隔、降低并发尽量在平台业务低峰时段跑批量任务。优先用平台官方提供的 API 读取数据能调 API 就不用页面抓取这是最稳的路径。每一次异常我都建议把报错截图、触发时间段、当时日志一起存档。跑了两三周之后你再回头翻这些记录会发现很多“随机故障”其实都是有规律的。5.2 Agent 生成的任务为什么第二天就罢工了有一种典型困境是昨天跑得好好的 Skill今天跑就报错。多数情况不是因为 Agent“变笨了”而是你的 Skill 把不该写死的东西写死了。我把脚本里涉及的内容分成两层去处理稳定层数据字段、处理逻辑、输出格式这部分要写死保证结果稳定易变层URL、页面按钮位置、选择器、等待时间这些很容易随外部环境变化要抽到配置里。举个直观例子。有个抓取任务我最初把页面表格的定位方式直接写死在流程步骤里结果平台改了一次页面样式全盘崩溃。后来我把定位信息挪到 Skill 的配置区单独拎出来改动就只影响一处不需要重新设计整个流程。这个原则在 WorkBuddy 所有类型任务里都适用。凡是“针对具体环境的东西”永远不要和“通用规则”混在一起。5.3 省积分的三个实用思路运行强度上去之后很多人会来问怎么节约 WorkBuddy 积分或算力消耗。我自己实践下来比较有效的是这三条能用脚本处理的部分不要占用 Agent 调用次数。比如把几十个 CSV 文件合并成一张总表这种纯粹的数据处理用 Python 写死就行根本不需要模型参与。模型只负责“做决策”和“写代码”固定执行的活交给普通脚本。指令写不清楚代价是返工。指令越模糊Agent 就越容易多跑几轮去试探你的意图。把输入字段、步骤、异常处理写清楚一次跑通的概率会大幅提高消耗自然就降下来了。把多个相关任务合并到一次运行里。比如我抓取多个平台的数据不会一个平台起一个任务而是合并成一个流程、共用一个浏览器会话会话启动和模型调用的固定成本只付一次。这三条里面第一条见效最快几乎立刻可以看到消耗明显下降。最后聊一点我的使用体会用 WorkBuddy 跑了两个多月我最大的变化不是“省了多少时间”而是“我不再害怕那些枯燥的重复工作了。”以前一想到每天早上要打开六七个后台挨个看一遍就头疼现在这些事跟着定时器自动发生我只需要在异常提醒弹出来的时候处理一下。如果你正准备入坑 AI 智能体我的建议是别一上来就搭一个万能自动化中枢先找一个每天最多小事比如整理一张表格、定时签到、抓取一个页面的数据把它完整做成一整套 Skill 跑顺。这个过程你会自然理解指令、Skill、调度这些概念之间的关系。迈过这个坎之后再去扩到多平台、多任务的复杂工作流就是水到渠成的事。