每天早晨打开电脑第一件事不是想今天要干嘛而是先登录后台、打卡、翻一遍群消息、把昨天数据拉成表格、再憋一段日报。这套流程我做了快两年直到上个月用 WorkBuddy 这个 AI 智能体工具把它们全部编排成自动化任务时间从 30 分钟压缩到 10 分钟内跑完。这篇我把自己从零搭建的过程完整捋了一遍包括安装时碰到的坑、自定义指令怎么写效果最好、以及如何用 WorkBuddy 接入不同模型来控制成本。不管你是第一次听说 AI 智能体还是已经在用其他框架这篇文章的思路和步骤应该都能直接上手。1. 先搞清楚你的每日工作自动化到底要自动什么很多人接触 WorkBuddy 的第一反应是它能不能帮我把所有事情都干了答案是能但前提是你得先想明白哪些事情值得让智能体去干哪些事情交出去反而添乱。这一步看起来简单实际上决定了后面所有配置是“省心”还是“返工”。1.1 三类最适合交给智能体的任务根据我这段时间的实践适合交给 WorkBuddy 的任务基本可以分成三类。第一类是信息采集与汇总。比如每天需要从后台拉数据、翻公告、看竞品页面更新、收集群消息里的关键信息。这类任务的特点是频率固定、信息源分散、格式经常变传统脚本最怕“格式变了”但 AI 智能体不怕它能理解“把这两段内容提取成要点”这种模糊指令。第二类是格式生成类。日报、周报、会议纪要、邮件回复这些任务本质上是你已经有素材但需要按特定格式整理出来。以前我手工复制粘贴用上 WorkBuddy 之后把素材丢在指定目录它自己会读、会总结、会按模板生成我只需要最后看一眼有没有跑偏。第三类是跨系统操作。比如登录某个后台截图、在表格里追加一行数据、把 CSV 转成 Excel 再发到指定位置。这类任务过去用 RPA机器人流程自动化也能做但 RPA 每遇到一次页面改版就要重新录制一遍流程而 WorkBuddy 这类 AI 智能体可以通过自然语言描述来理解操作路径改版之后往往改一下指令描述就好维护成本低不少。1.2 为什么不用传统脚本而是用 AI 智能体这里我给个坦白说我自己就是写脚本出身的人以前用 Python cron 做过很多自动化。传统方案的问题不在于“能不能做”而在于“怕变化”。页面结构变一下脚本就要翻出来重写数据格式调整一列正则表达式又要重新对一遍。WorkBuddy 的 AI 智能体不一样的地方在于它把“理解”和“执行”拆开了。对网页内容的提取它靠模型理解语义而不是写死的正则对文件的操作它走的是工具调用而非固定的函数逻辑。所以当需求变化不太大时你只需要微调自然语言描述而不需要重写整个流程。当然这不意味着脚本就没用了。比如运行 10 万次的循环计算、毫秒级接口调用这些高确定性的场景脚本仍然是第一选择。智能体更适合的是“每天不太一样、但大体有规律”的事务性工作。1.3 判断一个任务值不值得自动化的标准我自己的衡量标准很简单每天花超过 5 分钟、每周重复至少 3 次、而且做完之后不需要太多创造性决策的任务基本都可以交给 WorkBuddy。举个例子我有个习惯是每天早上把行业几个网站的长文抓取下来提取核心观点整理成摘要发到群里。这个任务要是手动做每天至少 20 分钟而且很容易偷懒跳过。交给 WorkBuddy 之后每天定时触发把原文链接给它它自己抓取、整理、输出摘要我只需要花 30 秒检查质量。这就是典型的“高重复、低决策”任务。反过来那些需要你根据背景知识做专业判断的工作比如审核最终方案、跟客户沟通、做关键决策千万别急着全权委托。把一个 AI 智能体当搜索和分析助手用由你把关最终输出是当前阶段更稳妥的姿势。2. 安装部署选择适合自己的 WorkBuddy 形态确定好要自动化什么任务之后下一步就是把 WorkBuddy 装起来。安装本身不复杂但不同平台、不同使用习惯的人适合的方式不太一样。我把几种形态和踩过的坑都放在这里方便你对照着自己的情况选。2.1 搞清楚 WorkBuddy 的两种主要形态WorkBuddy 现在主要分 CLI命令行形态和工作台桌面应用形态。CLI 形态适合本身习惯用终端的开发者和技术用户优点是资源占用小、可以通过命令行脚本深度集成、在 Linux/Ubuntu 服务器上也能跑。工作台形态适合更偏向可视化操作的用户界面里能直观看到任务列表、Agent 运行日志、Skill 配置不需要记太多命令。如果你不是技术背景直接从工作台形态开始会顺畅很多如果你打算把它部署在服务器上做定时任务那 CLI 形态是必须掌握的。我自己的组合是日常调试和改配置用工作台正式跑定时任务用 CLI。因为工作台适合观察 Agent 每一步在干什么CLI 适合交给系统级定时器去调度两者互不冲突。2.2 Windows 和 Linux 环境准备无论哪种形态WorkBuddy 都依赖 Node.js 运行时所以这一步是绕不开的。Windows 上的安装相对省心直接从官网下载对应安装包按引导下一步安装就行。需要留意的只有一点安装路径尽量别有空格和中文否则后续某些 Skill 在写文件时可能出现路径解析异常。Linux比如 Ubuntu上稍微多几个步骤。我自己用的顺序是这样的# 1. 更新系统软件源 sudo apt update # 2. 安装 Node.js建议装 18 或以上的 LTS 版本 curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt install -y nodejs # 3. 检查版本 node -v npm -v # 4. 安装 WorkBuddy具体包名以你拿到的官方指引为准 npm install -g workbuddy装完之后可以试一下workbuddy --version能正常输出版本号就说明安装成功了。这里提醒一句不要用 Ubuntu 自带 apt 源里的 nodejs那个版本通常比较老。我最早图省事直接apt install nodejs结果版本只有 12后续安装 WorkBuddy 时一堆依赖错误。2.3 新手最容易卡住的安装报错502 write eacces安装时最常遇到的报错很多人一搜就会看到502 write eacces这个关键词。我第一次遇到也是一头雾水后来完整排查了一遍发现它其实不是 WorkBuddy 自身的问题而是 Node.js 全局安装目录没有写权限导致的。这里我把排查链路完整写出来你以后遇到类似报错也能按这个思路走。第一步看报错全文。不要只看前面几个字符。502 write eacces里eacces是 Linux 系统返回的“权限不足”错误码502是执行编号真正的问题描述在后面跟着的路径信息。第二步确认当前 npm 全局目录。执行npm config get prefix默认情况下它返回的是/usr/local而/usr/local/lib/node_modules这个目录往往需要 root 权限才能写入。Node.js 进程以当前用户运行时自然就写不进去于是报错。第三步验证是不是权限问题。手动尝试创建一个文件touch /usr/local/lib/node_modules/test.txt如果提示Permission denied问题就实锤了。第四步解决方案。有两种思路。一种是给目录加上当前用户写权限直接在命令前加sudo安装sudo npm install -g workbuddy这种方法省事但后续如果经常要更新全局包每次都得 sudo比较烦。另一种更推荐——修改 npm 的全局安装路径让它指向当前用户有权限的目录mkdir -p ~/.npm-global npm config set prefix ~/.npm-global然后把这个目录加进 PATH 环境变量。编辑~/.bashrc加上export PATH~/.npm-global/bin:$PATH再执行source ~/.bashrc重新安装一次就不会再报502 write eacces了。我后来一直用的就是这种方式清理 C 盘、避免权限问题、管理多个 Node 工具都更方便。安装成功后建议再跑一次workbuddy doctor如果版本支持的话它会帮你检查网络连通性、依赖完整性、目录权限这些基础项目。这一步相当于体检能提前暴露不少后面可能爆雷的问题。3. 掌握 WorkBuddy 的三个核心概念Agent、Skill、自定义指令安装只是开始真正让 WorkBuddy 从“装了但不知道干嘛”到“帮我干活”的关键是理解它最核心的三个抽象概念Agent、Skill、自定义指令。这三个概念互相关联却各司其职。3.1 Agent每次自动化任务的执行单元Agent 是 WorkBuddy 里一个任务的执行单元。你可以把它理解为一个“随时听令的数字员工”。每个 Agent 有自己的目标、职责边界和可用工具集。比如我建了一个“日报生成 Agent”它的目标描述是“读取今日工作日志和后台数据文件整理成结构化日报并输出到指定目录”。它的职责边界是“只处理文本和表格文件不访问浏览器不发送外部请求”。它的工具集则是“文件读取、文本分析、Markdown 渲染”。这样的设定不是越多越好关键是职责清晰。一个 Agent 越专注它在执行时就越少受无关信息干扰。如果你想既抓取网页又生成日报又发通知不如拆成三个 Agent 串联让每个 Agent 只做一件事。这样做的好处是单独调试任何一个环节时不会因为其他逻辑出错而殃及池鱼。3.2 Skill把经验沉淀为可复用的能力包Skill 是 WorkBuddy 里最容易被低估的概念。简单说Skill 就是一段预置的指令逻辑组合封装成可以被不同 Agent 调用的“能力单元”。举个例子。我经常需要把一段网页正文提取成核心观点列表。如果每次都把提取规则写死在指令里换一个网页就要重新描述一遍。但当我把它封装成一个 Skill比如叫summarize_web_content定义好输入是 URL、输出是带标题和要点的 Markdown 文档之后任何 Agent 只要在自己的工具列表里加上这个 Skill就能直接复用。Skill 的好处是经验的沉淀。你第一次手写规则踩了坑第二次把规则改进后放进 Skill第三次、第四次以后就越来越准而且是组织级别的资产不需要别人重新经历你踩坑的过程。3.3 自定义指令如何写出一段让智能体真正听懂的指令自定义指令是普通用户能最快感受到效果差异的地方。同样的模型你指令写得好不好输出质量能差出一大截。这里我总结了几条实战中验证有效的技巧。第一明确角色和目标。不要只写“帮我写个日报”而是写“你是我的行政助理请根据我提供的当日事项清单按【已完成事项】【进行中事项】【明日计划】【风险与问题】四个板块生成日报”。角色定义越清楚模型遵循格式的稳定性越高。第二提供上下文和输入位置。要让 Agent 知道去哪里找数据和输出到哪里。比如说“读取 ./daily/ 目录下最新的 CSV 文件处理结果保存为 markdown 文件到 ./reports/ 目录”。信息越具体出错率越低。第三给出反例或限制。如果你不希望日报里出现口语化的词就明确说“禁止使用口语不要出现‘我觉得’‘大概’这类模糊表达”。如果你希望摘要不超过三点就说“只保留三条最核心的信息不展开背景”。第四拆分复杂任务。不要把十个要求堆在一段话里。如果任务确实复杂拆成多个步骤每步一个指令让 Agent 分阶段执行中途可以检查输出。我不是说每一条指令都要写得像学术论文而是建议至少把“对象、动作、条件、输出”四个要素说清楚。我见过很多人抱怨智能体“笨”其实大部分时候是指令给得不够具体责任不完全在模型。4. 十步跑通“自动签到 自动日报”完整工作流理论部分说完了这一节我们进入实战。我用一个最有代表性的场景——“每天自动签到 生成日报”——来演示如何在 WorkBuddy 里从零搭一条完整工作流。之所以选这个场景是因为它包含了一个完整自动化闭环必需的几乎所有元素定时触发、数据读取、文件操作、格式生成、结果输出。4.1 先用手动方式把流程完整走一遍这是我认为整条链路里最重要的一步也是大多数人最容易跳过的一步在交给智能体之前先手动把流程完整走几遍。你如果连手工操作都需要停下来想半天那让 AI 智能体去执行时它大概率也会卡住。拿自动日报来说你需要先明确每天要读哪些文件数据在哪个目录字段长什么样生成日报要哪些模块保存到哪里这些问题不需要写进系统里但你自己必须知道答案。我在搭建之前会先把手工流程整理成一张表步骤操作内容耗时输入输出1登录工作后台1 分钟账号密码后台会话2导出今日数据2 分钟日期参数CSV 文件3阅读工作日志2 分钟日志文本理解事项4生成日报3 分钟数据和日志Markdown 日报5发送到群2 分钟日报文件群消息有了这张表你才知道要配置哪些步骤、哪些需要 Agent 做、哪些需要外部系统配合。表里第 1 步登录后台如果平台有验证码自动化就不方便需要先跟管理员申请 API Token 或白名单第 5 步发群消息可能需要配置 Webhook。这些前置事项光靠智能体自己是解决不了的。4.2 在 WorkBuddy 中创建 Agent 并配置基础信息打开 WorkBuddy 工作台新建一个 Agent我给它起名叫daily_reporter。基本信息这样填名称日报生成Agent角色描述负责汇总工作日志与业务数据生成结构化日报执行模式按顺序执行步骤不支持并行因为下一步依赖上一步输出工作目录/home/user/workbuddy_workspace/daily/工作目录这一项很关键。把所有输入文件放到这个目录下Agent 就只会在该目录内做文件读写不容易误操作其他位置也方便清理和备份。4.3 配置 Skill日报格式生成器接下来为该 Agent 添加一个新的 Skill我命名为daily_report_formatter。这个 Skill 的核心指令是这样的你是一名专业的日报助手。 请读取指定目录下的 【工作日志.md】 和 【业务数据.csv】。 按以下4个板块生成日报 1. 今日核心数据从CSV中提炼使用表格展示 2. 已完成事项从工作日志提取条目不超过5条 3. 进行中的事项从工作日志提取注明进度百分比 4. 风险与明日计划基于今日事项推断 输出要求 - 使用 Markdown 格式 - 保存为 output/日报_日期.md - 不输出与日报无关的内容注意看这个 Skill 的关键在于把“格式要求”和“数据来源”写清楚。首次执行时Agent 会根据这个指令生成日报。执行结束后你可以打开生成的日报逐条检查有没有遗漏。4.4 配置签到步骤让 Agent 完成定时打卡日报只是输出签到则涉及实际操作。WorkBuddy 的 Agent 可以调用 HTTP 工具、浏览器工具或内置的自动化脚本来完成这类操作。具体取决于你的签到平台。如果签到平台提供 API最简单的方案是让 Agent 每次执行时访问签到接口调用 HTTP POST 请求地址为 https://your-system.com/api/checkin 请求头 Content-Type: application/json 请求体为 {employee_id: 12345, date: 今天日期}。 请求成功后输出“签到完成”。如果平台没有 API只能模拟浏览器操作那就要配置“浏览器操作 Skill”让它打开指定网址定位输入框提交表单。这种方案更复杂但只要流程稳定也可以用。我的建议是优先争取 API 方式尽量减少对 UI 自动化这种脆弱方案的依赖。4.5 设置定时触发每天自动运行WorkBuddy 支持定时触发配置。在这个 Agent 的“调度”设置里我添加了一个 cron 表达式0 9 * * 1-5这个表达式的含义是每周一到周五的上午 9 点整执行一次。如果你不熟悉 cron 语法也没关系WorkBuddy 的可视化界面一般支持“每天 9:00”这种自然语言配置。服务器上的 CLI 版本则建议直接用系统级 cron 或 systemd timer 来调度。这里有一个细节值得注意定时任务运行的用户身份。如果你用 CLI 方式在服务器上部署cron 默认用当前用户身份执行务必确认该用户对工作目录有读写权限否则你会在日志里看到各种EACCES。这跟上文提到的502 write eacces是同一类问题。4.6 首轮测试运行与效果修正配置完成之后先不要等第二天早上 9 点自动触发。在工作台界面里找到运行按钮执行一次“手动运行”观察每一步日志。我自己的经验是首轮运行几乎一定会遇到问题常见的有三类路径不对Agent 说“找不到 /data/业务数据.csv”往往是因为文件名多了一个空格或路径大小写不一致。CSV 解析出错有些导出的 CSV 带 BOM 头或者用逗号和分号混排Agent 可能解读错误。日报格式不符合预期可能少了某个板块、表格没法对齐、或者语气太口语化。每类问题都有对应的修正方式。路径问题就调整 Skill 里的路径描述CSV 问题可以在 Skill 里加一句“注意该CSV文件包含中文表头使用 UTF-8 编码第一行为列名”格式问题则需要在指令里补充更明确的示例。不要怕返工第一次跑通完整流程后面的维护成本会指数级下降。我调试完整条工作流大概花了 1 个多小时之后的十天里每天只需要花 30 秒检查日报质量整体是非常划算的。5. 模型接入与成本控制让 WorkBuddy 更聪明也更省钱WorkBuddy 本身不直接拥有模型推理能力它依赖大语言模型来完成理解、规划、生成这些环节。所以模型选得好不好、配置对不对直接影响自动化的效果和花费。5.1 为什么建议在 WorkBuddy 里接入外部模型WorkBuddy 默认会有一个基础模型配置开箱即用对轻量任务来说够用。但一旦你的任务涉及复杂推理、长文本处理或特定的行业术语默认模型的准确率和稳定性就可能拖后腿。比如我处理电力设计规范查询时就要求模型能理解规范条文之间的逻辑关系、能引用具体条款编号而不是泛泛而谈。这种情况下接入更强的模型或领域微调模型能显著提升效果。另外很多用户在意的点是“WorkBuddy 接入 DeepSeek”这种操作。DeepSeek 在国内访问和充值相对方便而且它的中文理解能力在很多任务上表现很好API 成本也比较可控。如果你所在团队已经采购了某家模型的服务通常也能通过标准 OpenAI 兼容接口接入 WorkBuddy。5.2 模型接入的完整配置过程在 WorkBuddy 的模型设置界面里一般支持新增一个“模型供应商”填写 Base URL、API Key、模型名称即可。以接入 DeepSeek 为例需要填的信息大致如下供应商名称DeepSeekBase URLhttps://api.deepseek.com/v1API Key你在 DeepSeek 开放平台申请的密钥默认模型deepseek-chat对应 DeepSeek-V3 系列有些版本还支持设置备用模型当主模型网络超时或限流时自动切换。这个选项建议打开能显著提高自动化任务的成功率。我经历过某天凌晨模型服务方限流自动化任务直接失败后来配上备用模型就再也没被限流坑过。5.3 成本控制别让自动化从“省时间”变成“烧预算”AI 智能体的成本主要是 Token 消耗简单说就是模型读了多少字、写多少字。单个任务看起来不贵但乘以每天频率和 Agent 数量月底账单可能吓你一跳。我总结了几条控制成本的方法。第一给不同任务分配合适的模型。像签到这种只需要调用一个 API 接口的简单操作不需要调用最强模型像日报生成这种涉及理解和格式化的任务再用中等模型像复杂方案设计这类才值得用最强模型。WorkBuddy 允许每个 Agent 单独指定模型这点千万别偷懒。第二控制输入长度。很多任务失败或成本高是因为 Agent 读取了太多无用内容。比如它本来只需要读 CSV 里某几列你要是把整个 500MB 的文件丢给它Token 消耗自然爆表。可以在 Skill 里明确“只读取前 50 行”或“只读取 [日期, 销售额, 备注] 三列”。第三开启日志审计。每次任务运行后查看 Token 消耗记录。我会定期导出一周内的 Token 使用统计表看看哪个 Agent 是“能耗大户”再针对性地优化它的指令或模型配置。任务类型推荐模型档位参考单次Token消耗定时签到/简单接口调用轻量模型500 - 2000日报/周报生成中端模型5000 - 20000网页内容抓取与摘要中端模型8000 - 30000方案设计/代码生成高端模型30000这张表不是标准答案只是提供一个量级参考。真正精准的评估还是要看你的业务数据量。6. 进阶实战信息抓取、代码生成、知识库三合一当你把基础工作流跑通之后WorkBuddy 的价值才开始真正释放。这一节我会分享三个进阶场景内容抓取与归档、用 WorkBuddy 辅助写工具脚本、以及把 Obsidian 知识库变成 AI 智能体的协作对象。这些场景能覆盖相当一部分“知识工作者”的日常需求。6.1 让 WorkBuddy 抓取小红书和网页内容并按规范归档很多人想用 WorkBuddy 做小红书内容抓取目的是追踪竞品选题、收集灵感或者做自己的内容库。这里要分情况说如果是通过官方开放的接口且有授权那一切好说如果是绕过平台限制去抓取既违反平台规定也可能触碰相关法规。我自己更建议把精力放在自己有权访问的信息源上比如行业新闻站、订阅内容、公司内部文档、公开的 RSS 源。实操层面我在 WorkBuddy 里建了一个“内容采集 Agent”配置了一个fetch_and_archiveSkill读取文本文件 ./links.txt 中的链接列表。 对每个链接 1. 抓取网页正文 2. 提取标题、发布时间、核心观点不超过3条 3. 将结果追加到 ./archive/内容库_日期.md 最后输出“本次共归档 N 条内容”。这个流程跑通后我每天只需要把新看到的优质链接丢进links.txtAgent 会自动完成抓取、摘要和归档。这里有个优化点摘要质量很大程度上取决于你给它提供的“提取标准”比如“只提取对产品设计有启发的观点”它能筛得很准如果只泛泛说“总结内容”它就什么都会往里面塞。6.2 用 WorkBuddy 生成一个实用的小工具脚本WorkBuddy 不只是处理文本它也能辅助生成代码尤其是那些一次性的、几十行的工具脚本。比如有段时间我需要把一堆 Excel 文件里特定 Sheet 的数据合并成一张总表手动操作很麻烦我就让 WorkBuddy 帮我生成 Python 脚本。我的指令大致是请帮我生成一段 Python 代码功能如下 1. 读取 ./data/ 目录下的所有 .xlsx 文件 2. 每个文件取名为“汇总”的 Sheet 3. 提取所有行数据并合并 4. 输出到 ./output/merged.xlsx保留表头 环境说明Python 3.10已安装 pandas 和 openpyxlWorkBuddy 生成的代码并不复杂但它帮我节省了查 pandas API 的时间。拿到代码后我会先检查再运行重点看文件路径是否正确、异常处理是否完善。这里提醒一句对于别人生成或智能体生成的代码一定不要盲目生产环境直接跑。先把输入文件备份再在测试目录里运行确认输出正确了再挪到正式环境。从“用智能体生成脚本”到“让智能体自己调试脚本”中间还有一段距离。目前比较稳的做法是把它当结对编程的搭档而不是甩手掌柜。6.3 把 Obsidian 知识库变成智能体的协作对象Obsidian 是很多知识管理者的主力工具WorkBuddy 和它结合之后等于给知识库安了一个会自己整理、索引、检索的助手。我的用法是这样的WorkBuddy 的一个 Agent 定时扫描我的 Obsidian 仓库指定目录里的新日记和笔记读取全文提取章节标题、标签和关键词然后更新一份“索引笔记”。这样我搜索资料时不用再逐个文件翻直接看索引就能定位。另一个用法是把知识库当作 Agent 回答问题的上下文。比如我让“电力设计规范查询 Agent”在回答规范相关问题时优先读取我 Obsidian 库中已经整理好的规范摘要而不是凭空回答。这种做法能显著降低模型胡编乱造的概率因为答案有了可靠事实依据。实现起来也不复杂在 Skill 里把知识库目录添加到搜索范围即可。关键点在于知识库本身要整洁笔记有清晰的标题和标签否则 Agent 检索时会被低质量内容干扰。这些进阶玩法有一个共同逻辑把 WorkBuddy 当成一个能理解上下文的“数字助理”而不是一个孤立运行的任务脚本。它连接的模型能力、Skill 资产、知识库数据越丰富自动化的价值就越大。7. 我用了几个月后的真实体会WorkBuddy 能做和不能做的事这篇文章写到这里核心操作流程已经都讲完了。最后说点我自己的真实体会给正准备入手的你一个更现实的参考。7.1 自动化不是一次配置而是持续迭代刚开始搭建 WorkBuddy 时我犯过一个错误觉得配置好一条工作流就一劳永逸了。实际上工作的业务逻辑、信息源格式、输出要求随时在变Agent 的指令和 Skill 也需要跟着调整。我的建议是每周留出 15 分钟回顾一遍所有自动化任务的运行日志看看有没有失败、有没有输出质量下降的苗头。这个小习惯能避免很多“等到月底才发现这个任务已经失败两周了”的尴尬。7.2 WorkBuddy 最强的能力是“把规则交给模型把经验留给 Skill”用了一段时间之后我对“AI 智能体”这个概念的理解发生了一些变化。它不是一个全能的机器人而是一个能把自然语言转化为行动、并且能沉淀经验的框架。指令负责让模型理解当下任务Skill 负责把重复使用的方法固化下来Agent 负责把任务封装成一个有边界的执行单元。你用得多它会越来越像你你懒得维护它也只是一套漂亮的空壳。7.3 别忽略人的检查和判断WorkBuddy 能自动化很多步骤但自动化的终点一定需要人工验证。每天花几十秒检查日报格式、抽查一下抓取内容的准确性、偶尔看看 Token 消耗有没有异常这些看起来不起眼的动作才是整个自动化体系稳定运行的基石。毕竟一旦把重复劳动交出去人的价值就不再是“做事”而是“判断做出来的事对不对”。这个转变恰恰是 AI 智能体时代每个人都要适应的新节奏。最后分享一个我最近在用的习惯任何新任务先连续手动跑一周确定流程稳定后再交给 WorkBuddy 自动化。这样做看起来“多此一举”其实能帮你避免绝大多数配置返工。每一次成功的手动执行都是一份天然的、带标注的指令样本拿它去写 Skill成功率会高得多。