你有没有算过每天早上打开电脑后在各个后台、邮箱、报表之间来回切换到底要花掉多少时间我自己认真统计过一次光是拉数据、整理格式、写日报这几件事每天至少吃掉40分钟。后来我把这一整套流程全部交给了用 WorkBuddy 搭出来的 AI 智能体现在每天到工位只需要敲一个回车10分钟之内就能拿到整理好的日报、待办清单和项目提醒。这篇文章就专门记录这套每日工作自动化的完整搭建过程包含每一步的具体操作和踩过的坑适合所有想用 AI 智能体接管重复劳动、又不想写一大堆脚本的同学参考。1. 项目概述先搞清楚自动化要解决什么问题1.1 为什么选 WorkBuddy 做每日自动化很多人一听到“自动化”就想到写 Python 脚本、配定时任务、处理各种异常情况最后往往写了一堆代码还是三天两头出问题。我最早也是这么干的用脚本定时代码去抓接口、格式化数据但接口字段一改、网络一抖、格式一乱脚本就废了维护成本比我手动操作还高。WorkBuddy 这类 AI 智能体的思路完全不一样。它本质上是一个能理解自然语言、能调用工具、能读写文件、能执行命令的智能体。你可以用大白话告诉它“去拉取某个接口的数据整理成日报格式保存到指定目录”它自己会去理解步骤、拆解任务、调用对应的工具去完成。遇到格式变化、字段调整这些乱子它不像传统脚本那样直接崩溃而是会根据上下文判断自己适配。我选择 WorkBuddy 还有几个很实际的原因第一它支持自定义指令和 Skill 技能包相当于你可以给智能体预置一套“工作手册”让它在执行任务时按照你的规范来第二它支持跨平台Windows、macOS、Linux 都能跑我办公电脑和家里电脑用的是同一套配置第三它对模型的要求相对灵活既可以用各家的云端模型也可以接本地模型数据敏感的场景也不至于完全没辙。1.2 别急着打开工具先把任务拆清楚这里我想强调一个特别容易犯的错拿到 WorkBuddy 之后第一反应就是让它“帮我做日报”结果它输出了一堆通用内容根本不贴合你的业务。原因很简单你自己都没把任务拆清楚AI 更不知道你想要什么。我在搭建之前花了大半个下午把每天重复做的事列了一张表然后逐一判断哪些适合交给智能体。判断标准有三条一是动作是否重复二是是否有明确的数据入口和出口三是是否需要“动脑子”去适配变化。日常任务数据源理想输出是否适合交给AI智能体日报整理项目后台、数据库结构化 Markdown 日报非常适合邮件分类归档邮箱摘要优先级标签适合竞品信息收集几十个网页/资讯源汇总清单非常适合定时提醒日历/任务管理提醒消息一般脚本也能做项目状态同步多个文档/表格变更摘要非常适合拆完这张表你会发现真正适合 AI 智能体的任务几乎都有一个共同点输入是不固定的、需要一定判断力的、最终输出又是有固定格式的。这类活儿用传统脚本做起来特别别扭而让 AI 智能体来做正好踩在它的优势区间上。我的第一个自动化场景——“每日项目日报自动生成”就是从这张表里挑出来的。2. 环境与基础安装 WorkBuddy 并理解核心概念2.1 安装方式与模型配置安装这块其实没什么玄学。WorkBuddy 的主程序有桌面版和命令行两种形态我日常用的是命令行版因为它更方便被定时任务调用也更接近“智能体”原本的样子。不同平台安装命令稍有区别以官方文档为准。我用的是 macOS直接通过包管理器安装的装完在终端输入wb --version能看到版本号就说明成功了。Windows 环境建议用官方推荐的安装包或者 PowerShell 命令Linux 上则是下载对应发行版的二进制包。如果你之前用过 Node 生态的命令行工具上手难度基本为零。安装完成之后还需要配置模型。WorkBuddy 本身不内置大模型它需要连接一个推理后端。我第一次跑的时候卡在最前面这一步因为光想着装完就开干结果模型没配好问它什么都是“连接失败”。后来我理了一下云端模型在配置里填入 API Key再把模型名配上路径基本就是wb config set model xxx这样。本地模型如果你有 Ollama 或者类似工具可以让 WorkBuddy 连本地跑好处是数据不出内网坏处是速度和推理能力受机器性能限制。我个人的建议是第一次玩先用云端模型把流程跑通别一上来就折腾本地推理。本地模型对显存、内存要求不低你不想“自动化没跑起来先把显卡跑冒烟了”。2.2 四个必须懂的核心概念Agent、Skill、MCP、自定义指令如果你之前没接触过 AI 智能体WorkBuddy 里这几个概念一定要提前搞清楚否则后面配置起来容易懵Agent智能体这就是那个替你干活的“虚拟员工”。你给它一个目标它会自己规划步骤、调工具、判断结果。在 WorkBuddy 里你可以有多个 Agent每个负责不同工种比如“日报助手”“邮差”“分析员”。Skill技能包相当于给 Agent 预置的操作手册。一个 Skill 里可以包含提示词、脚本模板和说明文档。比如我建了一个“日报生成” Skill里面写清楚了日报的结构、数据来源、输出路径Agent 调用之后就会按照这套规则执行。Skill 是 WorkBuddy 最核心的扩展方式也是让 AI 输出稳定的关键。MCPModel Context Protocol模型上下文协议这个名词听起来高大上说白了就是一套标准接口让 Agent 能访问外部数据源比如数据库、网盘、邮箱、第三方 API。没有 MCPAgent 只能靠你喂文件有了 MCP它可以自己“伸手”去取数据。自定义指令Custom Instructions这是全局层面的“性格设定”相当于你告诉 Agent“你是我的助理回复要简洁不要废话所有输出用中文默认保存路径是 xxx”。它作用于所有对话和任务属于常驻上下文。这四个概念的关系我用一个生活中的类比来解释Agent 是新来的实习生Skill 是岗位职责说明书MCP 是公司内部系统的访问权限自定义指令则是你对这个实习生的总体要求。四件事配齐了他才能靠谱地干活。2.3 先跑一条最简单的指令验证环境配好环境之后别急着搞大工程。先从最小任务开始验证链路是否通畅。我在正式搭日报之前先试着让 WorkBuddy 做了两件事一是列当前目录的文件清单二是读某个文件并总结内容。这一步看似简单其实能把很多潜在问题提前暴露出来。比如模型 API 密钥填没填对、文件读写权限是不是正常、Skill 目录路径有没有配置好、MCP 连接是否成功等。如果连“列个目录”都出错那后面那些复杂的自动化工作流就更别想了。我第一次跑的时候就是在这个阶段发现配置文件里的目录路径写错了导致 Agent 根本找不到我放数据的地方。好在这个错误发现得早改完路径重试一遍就通了。所以真心建议大家不要跳步先用简单任务把地基打牢。3. 10分钟实战搭一个每日工作自动化的完整流程3.1 选一个高频场景明确数据入口和出口理论部分说再多不如直接上手。下面我就以“每日项目日报自动生成”为例完整演示一遍用 WorkBuddy 搭建自动化的工作流程。为什么选日报两个原因。第一这几乎是每个职场人每天都做的事有普适性第二它的输入和输出都很清晰输入是项目系统里当天产生的数据需求变更、任务进度、风险问题等输出是一份固定格式的 Markdown 日报。边界清晰的任务最适合第一次尝试。我的数据入口比较简单项目组每天会把当日的关键信息同步到一个共享表格里另外我还能通过内部接口拉取任务状态。 WorkBuddy 可以通过 MCP 连上数据源把它当作“信息中枢”把多个来源的数据拉到一起。输出端则固定为一个reports/目录文件命名带日期方便后续汇总。我不建议让 Agent 把结果输出到聊天窗口就完事一定要落盘保存因为日报是要留存、要归档的。这一步踩过的坑我会在后面的常见问题里细说。3.2 写一个 Skill把“怎么做日报”固化下来为了让 Agent 每次输出都保持稳定我不在对话里临时描述需求而是写成一个 Skill。这样做的好处是以后我可以随时调用同一个 Skill不用每次重新描述一遍需求而且输出格式不会漂移。Skill 本质上是一个包含指令和模板的目录。我在~/.workbuddy/skills/daily-report/下面创建了核心文件内容大致是这样的结构# skill: daily-report 名称: 每日项目日报生成 触发方式: /daily-report 描述: 读取项目当日数据按固定结构生成日报并保存到 reports 目录 ## 执行步骤 1. 读取 MCP 中配置的项目任务数据源获取当天任务、需求、缺陷列表 2. 读取数据源中的“项目风险”“待办事项”字段 3. 按“今日进展 / 风险项 / 明日计划 / 待协调事项”四段式结构组织内容 4. 使用简洁中文每项不超过 50 字数据和日期必须准确 5. 将结果保存到 reports/日报-YYYY-MM-DD.md 6. 输出文件路径和生成摘要 ## 输出模板 ### 今日进展 - 任务A状态描述 ### 风险项 - 暂无/描述 ### 明日计划 - 具体事项 ### 待协调事项 - 具体事项写这个 Skill 有几点很关键第一触发方式必须简短好记第二描述字段要写清楚这个 Skill 是干什么的Agent 会根据描述来决定何时调用它第三执行步骤要尽可能明确尤其是输出模板它直接决定了生成结果的稳定性。我把这个文件保存好之后在 WorkBuddy 会话里输入/daily-report它就开始自动执行了。第一次跑通的那一刻看着日报文件自动出现在reports/目录里说实话还挺有成就感的原本要手动折腾半小时的活现在几秒就出来了。3.3 接上定时任务实现“全自动”而不是“半自动”Skill 写好了但每次手动输入指令仍然不够“自动化”。我需要的效果是每天早上 9 点日报自动生成好我到工位直接看结果。这一步要借助系统的定时任务。我用的是 macOS所以用crontab来配置。Windows 环境的话用“任务计划程序”可以达到同样的效果。Linux 环境同样也是 cron原理一致。我给 WorkBuddy 配置的定时任务长这样0 9 * * 1-5 /usr/local/bin/wb run daily-report /tmp/workbuddy_daily.log 21解释一下这行命令的含义每天早上 9 点工作日周一到周五执行一次wb run daily-report让 WorkBuddy 以非交互模式运行 daily-report 这个 Skill并把日志输出到指定文件里方便之后排查问题。配置定时任务的时候有一个特别容易踩的坑cron 环境和你手动打开终端的环境不完全一样。我第一次配置完第二天早上发现日报没有生成日志里显示“命令找不到”。原因就是 cron 的 PATH 环境变量里没有包含 WorkBuddy 所在目录。解决办法是命令里直接用绝对路径不要用简短的wb。3.4 给指令留余量让 AI 自己应对变化等流程跑熟之后你会发现 Skill 里写得太死也有问题。比如我在步骤里写“读取 MCP 中配置的项目任务数据源”但如果某天数据源里的字段变了、或者某个数据源临时不可用Agent 就会卡住甚至直接报错。这时候就需要在 Skill 里给 Agent 留一些“决策空间”。我后来在 Skill 里补充了几条如果某个数据源读取失败跳过该数据源并注明“该部分数据未获取到”不要中断整个流程。如果数据中字段为空不强行编造内容直接写“暂无”。如果发现数据格式和以往明显不同先尝试自行理解适配并在日报末尾加一句说明。这是 AI 智能体区别于传统脚本的最大优势它有能力处理“没遇到过的情况”。你只需要给它足够的上下文和决策授权它就能在规则之外找到出路。我把它加到 Skill 之后日报跑了两周多再也没有出现过“流程中断”的尴尬情况。即使某天数据不全它也能生成一份带说明的日报保证流程不崩。3.5 多任务串联让日报、抓取、提醒成为一个工作流单跑一个日报只是热身。WorkBuddy 真正值钱的地方在于可以把多个任务串成一个完整的工作流。比如“跨境电商多平台订单抓取WorkBuddy 自动化工作流搭建”这个场景就是典型的串联玩法。我后来还加了一个群聊推送任务日报生成之后自动提取摘要然后通过群机器人 webhook 推送到项目群里。这一步用到了 WorkBuddy 的“动作”能力核心其实是调用系统命令发送 HTTP 请求。我给这个工作流写过一个简单的执行脚本关键思路是# 日报生成后提取关键内容并通过 webhook 推送 daily_report$(cat reports/日报-$(date %F).md) curl -s -X POST $WEBHOOK_URL \ -H Content-Type: application/json \ -d {\msgtype\: \text\, \text\: {\content\: \$daily_report\}}这样一来每天早上 9 点整日报生成、保存、推送到群里一步到位项目组的同事到点就能看到当日信息同步。整个工作流从“手动整理”变成了“自动生成自动通知”这才是真正意义上的每日自动化。4. 常见问题与排查技巧实录4.1 权限与写入失败EACCES 错误运行 WorkBuddy 时如果报502 write EACCES之类的错误基本可以断定是文件写入权限问题。我在排查这个错上花了不少时间。一开始我把输出目录设在了/etc/reports/这在 Linux/macOS 上是没有写权限的。后来我把输出目录改到了用户目录下的~/workbuddy-reports/问题立刻解决了。这个问题的排查思路其实很简单先确认问题是“写不进文件”还是“读不出文件”然后查看目标目录的属主和权限最后用chmod给当前用户加上写权限或者干脆换一个在用户目录下的路径。在这里提醒一句不要让 Agent 直接向系统关键目录写入文件这不仅会报错还存在安全风险。尽量让所有读写都发生在项目目录或用户目录下这也是管理 AI 智能体的基本素养。4.2 Skill 不生效或调用无响应如果你输入/daily-report之后没有反应大概率是 Skill 没有被正确加载。常见原因有三个目录放错了位置、Skill 描述写得不够清楚、修改后没有重新加载。我的排查顺序通常是先检查 Skill 目录放没放对位置再看描述里有没有写清楚“何时触发这个 Skill”最后在 WorkBuddy 里执行一次重新加载命令。有些版本修改 Skill 文件后需要重启会话才能生效这个属于正常现象不用慌。为了减少这类问题我在创建 Skill 时都会遵循一个原则描述里明确写明适用场景和任务目标。例如“读取项目数据并按固定模板生成日报”就比“日报”两个字要好得多因为 Agent 是靠描述来理解这个 Skill 能干什么的。4.3 输出格式不稳定日报跑了一段时间之后有几次输出格式完全乱了一会儿是表格一会儿是列表模板形同虚设。后来我找到了问题的根源我在 Skill 的“执行步骤”里只写了结构要求但没有给出“成品示例”。AI 模型对指令的理解高度依赖上下文的明确程度。只告诉它“用四段式结构”不如直接把一份我亲手写的日报样例贴在模板里让它模仿。我后来把输出模板部分改成了一个“参考示例”效果立竿见影格式稳定多了。这里有个技巧参考示例最好用一段独立代码块包起来并且明确标注“这是示例不要原样照抄内容照着这个格式写”。这样既给模型提供了格式锚点又不会让它把示例内容当成真数据。4.4 执行太慢或 Token 消耗过大自动化跑着跑着有时候一个简单任务要好几分钟Token 消耗也很夸张。我排查后发现原因是 Agent 在设计自己的执行计划时把“读取文件”扩展成了“读取所有相关文件”把不必要的内容也读进了上下文。解决办法是在 Skill 里明确限制读取范围比如“只读取最近 7 天的项目数据”“只需要读取 state 字段”“每次最多读取 100 条记录”。如果数据量确实很大可以考虑先预处理一下再让 Agent 处理。还有一个小技巧把“先看目录结构再决定读哪个文件”作为默认行为能省不少 Token。我不希望 Agent 一上来就把数据目录里的所有文件都读一遍而是让它先“侦查”再“行动”就像一个人做事也是先了解全局再动手。4.5 常见问题速查表现象可能原因快速处理方式报 502 EACCES目录无写入权限更换到用户目录或chmod授权Skill 无响应目录放错/描述不清/未重新加载检查目录、优化描述、重启会话输出格式乱模板不够具体在 Skill 里加成品示例明确格式要求执行慢、Token 消耗大读取范围过大限制读取范围先看目录再读文件定时任务没跑环境变量 PATH 缺失使用绝对路径调用命令数据源临时不可用MCP 连接异常在 Skill 里写明“跳过并注明”策略5. 进阶把 WorkBuddy 变成你的数字员工5.1 用 Webhook 把结果推送到聊天工具日报生成之后如果要让团队里的人都能看到最好的方式就是推送到群机器人。我在前面已经展示过通过 curl 调 webhook 的脚本。WorkBuddy 的优势在于它可以在生成内容之后继续执行后续动作把“写日报”和“发日报”无缝衔接。我在实际配置中发现一个细节推送的文本长度不宜过长。群机器人对消息长度有要求日报太长会被截断。我的做法是让 WorkBuddy 在推送前先提取一个摘要摘要控制在 500 字以内完整版还是保留在本地文件里。这算是团队协作场景下的一个实用优化。5.2 多智能体协作各司其职当你的自动化任务越来越多你会希望不同的 Agent 负责不同的工作而不是一个 Agent 什么活都干。比如一个 Agent 负责数据采集一个负责内容生成一个负责质量检查最后再由一个主 Agent 汇总输出。这种多智能体协作的思路在 WorkBuddy 里完全可行。你可以为每个角色写一套独立的 Skill然后在主工作流里按顺序调度。ClawSwarm 这类多智能体协作框架我看过一些资料思路基本一致核心就是把复杂任务拆给不同的“专家”而不是让一个“全才”硬扛所有事情。我实际使用时的分工是数据采集 Agent 负责连接数据源并拉取原始数据日报 Agent 根据原始数据生成内容质检 Agent 检查日期、数字、格式是否正确。虽然配置起来比单个 Skill 复杂一些但整体的容错性和稳定性确实上了一个台阶。5.3 建立自己的自动化资产库用了几个月 WorkBuddy 之后我发现自己积累的 Skill 已经涵盖了日报、周报、竞品监控、会议纪要整理等多个场景。这些 Skill 就像一个个积木块遇到新任务时我不用从零开始配置而是看看能不能用现有 Skill 组合出新的工作流。我强烈建议你也这样做把每次成功跑通的 Skill 都整理到一个统一目录下分类命名加好描述。时间长了你会发现这已经成了你个人的自动化资产库。无论是换电脑、换工作还是带新人这套东西都能直接复用价值远比单个自动化任务大。还有一个小建议每周花十分钟回看一遍日志看看哪些任务跑得不好、哪些环节经常出问题。WorkBuddy 的日志文件是最好的优化指南。你可以基于日志调整 Skill 里的步骤描述这种持续迭代带来的收益比重新设计一个完美方案要高得多。写在最后回顾这一路搭下来的自动化流程我自己最大的感受是AI 智能体不是万能的但用对地方之后是真的省心。它的强项不是替你“发明”新的工作方式而是把你已经极其熟练的重复劳动接过去让你腾出精力去做更需要判断力和创造力的事。我踩过的最深的坑就是一上来想把所有事情都自动化结果配置得又复杂又脆弱。正确的方式是挑一件每天必做、又最让你烦躁的小事把它跑通、跑稳然后再逐步扩展。哪怕先从一天一份日报开始坚持两周你都会明显感觉到早上那十几分钟的“手忙脚乱”已经变成了“看一眼结果喝口咖啡开始干活”。