每天早上的固定流程我猜你和我之前一样打开电脑先登录几个后台点签到翻一下昨天的日志整理几条待办再把几个数据源里的信息汇总成一段话丢进群里。这些事情单看不难但天天重复真的很消磨耐心。我后来把这一整套东西交给 WorkBuddy 去跑每天早上到工位打开电脑它已经把整理好的日报、签到结果、待办清单放在一个文件里等我了我只负责看一眼、改两笔、确认发送。整个过程从“手动折腾 30 分钟”变成“自动执行 10 分钟”注意这里的 10 分钟不是我操作的时间而是我写这些配置的时间。这篇就是把我的完整配置过程拆开来讲包含装好 WorkBuddy、配模型、写第一个自动化任务、自定义指令以及我踩过的几个坑。不管你是刚接触 AI 智能体的新手还是已经用过一阵子但没玩转定时任务的开发者照着做都能跑通。1. 准备阶段装好 WorkBuddy先把运行环境理清楚1.1 为什么选择本地化的 AI 智能体工具先说个很实际的问题现在网页版 AI 助手一大堆为什么我还要在本地装一个 WorkBuddy因为网页版只能“你问它答”它没法主动在固定时间帮你干活也没法直接读写你电脑上的文件。WorkBuddy 这类本地运行的 AI 智能体不一样它像一个住在你终端里的机器人能读文件、执行命令、调 API、按定时规则自动触发任务关键是可以把你日常工作流里那些机械环节全部串起来。我对比过几种方案自己写 Python 脚本配合 cron 计划任务灵活但每次改逻辑都要改代码门槛偏高用商业化 RPA 工具图形化拖拽确实友好但碰到复杂判断逻辑时反而别扭而且要钱。WorkBuddy 正好卡在中间——它有一个 Agent 核心做理解和规划又允许你用 YAML、Markdown 写技能和指令既保留了代码的灵活性又不用从头写调度框架。再加上它支持多种模型后端我还顺手接入了 DeepSeek 的 API成本比我想象中低很多。注意WorkBuddy 本质上是一个本地 CLI 工具不要把它理解成需要安装一堆依赖的重型平台。它的核心思路是“配置文件 模型调用 定时调度”装完就能用不适合的项目反而是那些需要图形界面或多人协同管理的场景。1.2 安装 WorkBuddy 的具体步骤我是在 Windows 上先装了一遍后来又在 Ubuntu 服务器上装了一次两边差异不大。前提是你机器上有 Node.js建议 18 以上版本太老的版本有些依赖装不上。Windows 用户直接打开 PowerShell执行npm install -g workbuddy装完以后验证一下workbuddy --version如果输出了版本号就说明核心程序没问题。Linux 和 macOS 用户也是一样的命令但 macOS 需要注意权限问题我建议用 Homebrew 或 nvm 管理 Node 环境避免直接往系统目录里写全局包遇到 EACCES。Ubuntu 上我试过从源码构建其实没必要官方 npm 包就很稳唯一要做的是把 npm 全局 bin 目录加入 PATH否则会报 command not found。首次启动时WorkBuddy 会让你选择模型供应商。我选了“自定义 OpenAI 兼容接口”然后把 DeepSeek 的 API 地址填了进去。具体配置写在~/.workbuddy/config.yaml里大致是model: provider: openai-compatible base_url: https://api.deepseek.com/v1 api_key: sk-你的密钥 model_name: deepseek-chat如果你手里有 OpenAI 的 key也完全兼容把 provider 改成 openaibase_url 删掉就行。这个设计我非常喜欢底层模型可以随意换技能、定时任务、自动化逻辑完全不用改。后续哪家模型便宜好用切过去就完了不绑定厂商。1.3 模型选型和成本估算选模型这件事别跟风一味追求最强。我实测下来跑 WorkBuddy 这类自动化任务DeepSeek 的 deepseek-chat 完全够用哪怕是最便宜的版本也能把日志整理、信息抽取、格式转换做得很好。复杂推理任务也可以换更高阶的模型通过指令级配置区分。成本方面我自己算过一笔账。正常工作流里每天定时任务大概消耗 2 万 token 输入、6 千 token 输出按 DeepSeek 的定价一天不到 1 块钱人民币。相比它省下来的时间和精力基本可以忽略。我的建议是先用便宜的模型把链路跑通确实遇到理解能力不足再升级不要一上来就开顶配。2. 第一个实战任务每天 9 点自动生成并推送工作摘要2.1 任务拆解自动化不是“让 AI 猜”而是“给 AI 流程”很多人用 AI 智能体失败问题不在工具而在任务描述太模糊。你说“帮我整理工作”模型只会给你一段泛泛而谈的回复。我把自动化的经验总结成一句话把任务拆到 AI 只需要做“处理”和“输出”不需要做“决策”和“探索”。以“每日工作摘要”为例我拆成四个子任务读取指定目录下前一天生成的日志文件例如D:\worklogs\2025-06-13.md。从日志中抽取完成了哪些事情、遇到什么问题、明天计划是什么。按照预设模板生成摘要模板包含“今日完成”“今日问题”“明日计划”“待跟进事项”四个板块。把摘要写入daily-summary/当天日期.md同时推送到群机器人 Webhook。这个拆解方式的好处是每一步都有明确的输入和输出即使模型偶尔有小偏差我检查起来也很容易。2.2 配置第一个定时任务WorkBuddy 的定时任务写在~/.workbuddy/jobs.yaml里。第一次写的时候参考了官方示例核心字段是name任务名、cron触发时间、task要做什么、target把结果给谁。我的配置是这样jobs: - name: daily-work-summary cron: 0 9 * * * task: 读取 D:/worklogs/ 目录下昨天日期对应的 .md 文件 按照默认摘要模板生成工作摘要 保存到 D:/daily-summary/ 目录下 并以文件名 当天日期.md 命名。 target: local看到这个配置你可能会疑惑AI 知道“昨天日期对应”是什么意思吗答案是它确实知道因为 WorkBuddy 在注入任务时会把当前系统时间、日期、星期几作为上下文传给模型。也就是说模型在执行时知道自己是在 2025 年 6 月 14 日早上 9 点它会自动去找 6 月 13 日的文件。这个细节很关键很多人配置失败就是因为没有理解“定时任务其实是一个带当前上下文的一次性任务”。配置好之后先不要干等定时触发手动执行验证workbuddy run daily-work-summary第一次跑的时候模型可能会问“日志里没有明确写出明天计划怎么办”这种情况我在指令里加了容错规则缺失字段就写“待补充”不要编造。这个原则我强烈建议你写进自己的任务描述里AI 生成内容时特别容易“脑补”自动化场景里一旦出现幻觉输出就全废了。2.3 让技能Skill复用起来如果只是每天生成一份摘要其实用上面的 task 描述就够了。但日常工作中相似的活儿不止一个比如每周要写周报月底要写月报格式和内容来源其实很接近。这时就用得上“技能Skill”。WorkBuddy 的技能本质是一组带指令的 Markdown 文件放在~/.workbuddy/skills/目录下每个技能一个子目录。我建了一个summary-writer技能目录结构如下~/.workbuddy/skills/summary-writer/ ├── SKILL.md └── templates/ └── default-template.mdSKILL.md 内容示例--- name: summary-writer description: 依据工作日志生成固定格式的摘要 --- 你是一个严谨的行政助理负责把工作日志整理成结构化摘要。 输入一个或多个 Markdown 日志文件。 输出严格遵循模板格式的 Markdown 文档。 规则 - 只使用输入文件中出现过的信息禁止编造。 - 缺失的内容填“待补充”。 - 不要修改时间、数字等客观数据。模板文件default-template.md里写的是输出格式。这样好处很明显之后不管是在定时任务里还是在交互式对话里只要说“用 summary-writer 技能总结一下这几篇日志”它就会自动套用模板。我再没手动粘贴过输出格式这个技能模型已经记死了。2.4 实测时间和效果配置完成后的实际效果我记录过一次手动执行任务从触发到输出文件生成大概花了不到 40 秒大部分时间消耗在模型 API 调用上。被它整理过的摘要我需要修正的地方其实很少偶尔需要调整一下某项任务的措辞但整体可用性很高。想想看你过去花 15 分钟翻日志、敲字现在它只花 40 秒就把初稿给你备好了。3. 进阶自定义指令和模型调优让 WorkBuddy 更懂你的业务3.1 自定义指令的两种写法WorkBuddy 的“自定义指令”可以写在两个层级。第一个是全局指令保存在配置文件的instructions字段里所有任务、所有对话都会携带第二个是项目级指令在某个目录下放一个workbuddy.md文件WorkBuddy 会在这个目录运行时自动加载。我自己的习惯是全局指令只写“普适价值观和工作底线”比如“不要删除用户文件”“遇到不确定的事先问再执行”“输出使用中文”项目级指令写“这个项目的领域规则”比如做数据抓取时指定字段名、格式、来源。很多人在全局指令里写太多行业细节结果每个任务都被冗长的上下文拖累响应速度很慢而且容易产生意想不到的副作用。3.2 三个可直接套用的自定义指令模板一是格式化约束指令。针对日常工作中要发给合作方的汇报加上这句所有输出内容中凡涉及项目名、日期、数据指标一律与输入保持一致不得改写或省略。二是角色约束指令。这个适合让 AI 从“通用助手”变成“行业助理”。比如你是一名工程资料管理员熟悉电力设计规范。用户上传规范文本后你要能够依据规范内容回答查询回答时先注明依据条款编号再给出解释。有朋友问过我“想用 AI 做一个智能体给他上传电力设计规范方便自己查询”本质上就是这种用法。不只是电力任何行业规范、产品手册、内部制度都可以通过这个角色约束实现“私有知识库问答”无损导入成本还低。三是操作边界指令。这一个最实用防止 AI 自作主张干不该干的事在执行任何可能修改文件、删除内容、发送消息的操作前先输出操作计划并等待确认。只有标记为 auto-ok 的任务可以跳过确认。3.3 抓取网页和平台内容的合规思路热搜词里好几个人在搜“WorkBuddy 抓取小红书”我分享下自己的实践思路但先说清楚边界抓取公开页面内容做个人研究、数据分析是可以的但绝不能做批量抓取、绕过登录、抓取用户非公开数据更不能拿去商用。合规红线一定要守住。WorkBuddy 本身没有内置爬虫但它可以调用我写的 Python 脚本来获取网页原始内容再交给模型做结构化抽取。我经常这样配置workbuddy run fetch-and-summarize --url https://example.com/article对应脚本的工作流程是请求网页获取 HTML提取正文文本传给模型做重点总结。这个方式更适合处理文章、公告、新闻页面不适合处理需要登录才能看的信息流。很多“一键抓取”的期望其实是拿普通请求去碰有反爬机制的站点我劝你别这么干又麻烦又容易出问题。4. 常见问题排查与体验优化说几个我实际踩过的坑4.1 启动报错 502 Write EACCES权限问题排查搜热词时我看到有不少人遇到workbuddy 502 write eacces这个报错我一开始也碰到过。EACCES 就是 Permission denied写权限被拒绝了。这个问题通常是因为 WorkBuddy 要写配置目录或日志目录但当前系统用户没有权限。我当时的处理方式很直接看看是不是自己用 sudo 安装的全局包导致目录归属混乱改成用 nvm 管理 Node 后重装问题就消失了。如果你已经出现这个报错先执行npm config get prefix查看全局包安装路径如果是/usr/lib或/usr/local/lib这类系统目录大概率就是权限问题。解决方案有两种要么用sudo chown -R $(whoami)修改目录归属权要么干脆重装 Node 环境把安装目录迁到用户目录下。我更推荐后者一劳永逸。4.2 WorkBuddy 占用 C 盘空间过大缓存迁移实战用着用着会发现 C 盘空间越来越小这也不稀奇。WorkBuddy 会缓存模型输出的历史记录、日志文件、可能还有临时文件默认路径在用户目录下。Windows 上一般在C:\Users\你的用户名\.workbuddy\。我的解决办法是把这个目录整体挪到另一个盘比如 D 盘。先关掉正在运行的 WorkBuddy 进程把.workbuddy文件夹剪切到D:\\.workbuddy然后创建一个软链接映射回去mklink /J C:\Users\你的用户名\.workbuddy D:\.workbuddy注意mklink /J是目录联接不用管理员权限也能建比mklink /D适用性更广。做完之后一切照常运行但占用的是 D 盘空间。顺带一提定时任务日志会随着时间增长得很快建议每个月清理一次~/.workbuddy/logs/目录下的旧文件。4.3 Linux 版本安装和使用时的特殊问题我在 Ubuntu 服务器上部署过一次。最大的坑不是安装而是定时任务的运行环境。如果你是用 SSH 登录服务器然后后台挂起 WorkBuddy定时任务可能不会按预期触发原因是有些 Linux 环境没有为后台会话开启完整的 cron 调度支持。我的做法是用系统级 cron 来驱动 WorkBuddy而不是依赖它内部的调度器。比如每天 9 点跑一次在 crontab 里加一行0 9 * * * /usr/bin/workbuddy run daily-work-summary /var/log/workbuddy.log 21这样更稳定也方便查看日志排查问题。另外Linux 下如果遇到“找不到 workbuddy 命令”多半是 PATH 环境变量的问题在 crontab 里最好写全路径或者在脚本开头执行source ~/.bashrc重新加载环境变量。4.4 任务执行不完全、输出内容不理想怎么办模型输出内容不稳定这几乎是无解但可缓解的问题。我的经验是三级降级策略第一级优化指令描述把要求写得更具体、更限制性第二级切更强的模型看复杂逻辑是不是当前模型理解力不足第三级任务拆得更细把一个复杂大任务拆成两个简单子任务分步执行。举个例子原来我想让它“读取多个日志文件并生成摘要和待办清单”它很容易漏项。后来我拆成两个任务第一个任务只负责汇总日志内容输出中间结果第二个任务读取中间结果分别生成摘要和待办清单。这样每一步的输入输出都更干净输出质量也提升了一个台阶。如果你在做复杂自动化时发现结果不稳定先别急着换模型把任务拆小试试。4.5 与 Obsidian 联动的笔记流水线不少人搜“workbuddy obsidian”这个方向我很推荐。我的工作日志是放在 Obsidian 仓库里的而 WorkBuddy 处理 Markdown 文件的能力很强两者连着用非常顺手。我的联动方案早上到工位先运行一个“收集”任务让 WorkBuddy 读取剪贴板、昨天的临时想法、邮件草稿整理成固定的日记模板存到 Obsidian 的每日笔记目录。这样白天我只需要专注于干活记录和归档是自动完成的到晚上写日志时也不会对着空白页面发呆。如果你也是 Obsidian 重度用户可以试试把 WorkBuddy 的输出目录直接指向 Obsidian 仓库自动化生成的摘要也会出现在你的知识库里长期积累下来就是一份很完整的个人工作档案。5. 个性化配置建议从“能用”到“好用”的三个优化方向5.1 把常用任务沉淀成技能库而不是反复写提示词我见过很多人的 WorkBuddy 配置任务描述几百行重复内容占了一半。一个更好的做法是把高频任务的固定逻辑做成技能然后任务描述里只写“变量部分”。比如“日报生成”这个技能只保留输出格式和规则每次触发时只需告诉它“今天的重点事项是 XXX”。这就像封装函数一样用多了之后新增一个自动化任务只需要几十字的描述不用再从头写长篇指令。5.2 建立“输出质量检查清单”让 AI 自己复查模型输出的初始质量很难一次到位但你可以通过指令让它在输出前先“自查”。我给 WorkBuddy 加了一个固定流程指令“生成内容后先检查一遍确认包含了所有必要字段、没有编造数据、格式与模板一致再输出最终版本。”这个方法听起来简单但对输出质量的提升非常明显。它相当于让模型在提交前做一次复核很多明显的错误能在自查环节被修复不用等你回头挑刺。5.3 探索社区和扩展方向如果你对 WorkBuddy 的开发能力感兴趣可以看看它的 SkillHub 社区上面有大量别人写好的技能可以直接导入。比从零开始自己写节省大量时间。那些搜“workbuddy 做软件”“workbuddy skill”的朋友我建议先去 SkillHub 搜一下有没有类似需求再决定要不要自己动手。我自己后续的计划是把 WorkBuddy 跟更多内部系统打通比如让定时任务在生成日报后自动把摘要发到团队协作工具或者让它在检测到特定关键词时触发告警。目前光是一个“定时日报 技能复用 多端部署”的组合就已经让我的日常重复劳动减少了八成。最后说一句非常个人的体会AI 智能体这类工具真正的分水岭并不是你用哪个模型、哪个框架而是你有没有把自己的工作流彻底拆解过。WorkBuddy 只是个执行器你能不能在 10 分钟内配好任务取决于你对自己工作模式的了解程度。我的建议是从最小的一件重复事开始比如“每天早上生成昨天的日志摘要”跑通之后再逐步加任务。自动化这件事慢慢来反而最快。
