
拿到 WorkBuddy 的第一天我干的第一件事特别蠢把它当成 ChatGPT 的又一个网页入口问了一堆帮我写个周报解释一下这段代码之类不上不下的问题。用了一个星期后我意识到这个工具真正值钱的地方根本不是聊天而是它把 AI 从你有问题我来答的被动对话推到了给我需求我来干的主动执行。换句话说用好了它是一个能帮你接活、跑流程、交付成果的同事不是一个只会耍嘴皮子的网友。这篇教程我不打算给你念产品文档而是按我自己的上手路径来写先搞清楚 WorkBuddy 到底是干什么的再讲安装配置、Skill 机制、实战案例最后把踩过的坑一次性交代清楚。全程没有废话带你从装了不会用走到真的能干活。1. 先搞清楚 WorkBuddy 到底是干什么的1.1 它不是又一个聊天框而是一个 Agent 工作台很多人第一次打开 WorkBuddy会误以为它就是个 AI 聊天软件。界面有对话窗口能打字能多轮问答看起来跟 ChatGPT、文心一言之类的没有区别。但用两天就会发现不对劲它能读你本地文件能调起命令行能按你设定的流程去操作外部工具甚至能在没人盯着的情况下把一件多步骤的任务跑完。WorkBuddy 的核心定位是 AI Agent 工作台也就是把大模型从大脑升级成手脚并用的人。它在对话能力之上叠加了三样东西工具调用能力可以读写本地文件、执行脚本、调用 HTTP 接口、操作浏览器插件任务编排能力支持把一个大任务拆成多个步骤按条件分支、按顺序执行记忆与上下文管理不只是记住当前对话还能把历史任务、知识库、Skill 配置持久化下来这套组合下来它就从一个问答窗口变成了一个能接活的人。你给它一个目标它能自己规划步骤、调用工具、产出结果而不是每次都需要你手把手把话喂到嘴边。1.2 和传统对话工具的三大本质区别我用过不少 AI 产品说实话单看生成能力各家差距没那么大。真正拉开体验的恰恰是 WorkBuddy 这种从聊天到干活的工程化能力。具体差别我列个表对比维度传统对话 AIWorkBuddy核心交互一问一答目标驱动的任务执行文件处理靠上传附件直接读取本地目录持续访问工具调用通常不支持支持脚本、接口、插件联动流程复用每次重新说明通过 Skill 沉淀为可复用能力任务深度单轮生成多步编排自动校验与重试看完这个表你就明白WorkBuddy 不是来抢聊天 AI 饭碗的它是带着这些大模型的能力去啃真实工作场景里那些脏活累活。以前让 AI 写一段代码你得把需求反复描述再把代码复制回 IDE 测试现在它可以自己读项目代码、定位问题、改完跑测试、把结果拿给你看——这才是干活。1.3 适合谁来用能解决什么场景根据我这段时间的实践下面几类人从 WorkBuddy 里获得的收益最大研发人员做代码审查、写单元测试、梳理项目文档、自动化处理重复的工程杂事技术管理者自动汇总团队周报、分析项目风险、生成会议纪要和待办事项专利与知识工作者这个场景很多人忽略但 WorkBuddy 特别擅长做文献检索辅助、专利对比分析、交底书初稿撰写后面第四章我会给一个完整案例文档工程师批量格式化文档、自动生成接口说明、维护知识库一句话总结凡是输入一堆材料、需要输出一份结构化成果的工作都适合交给 WorkBuddy 干。它解决的核心痛点是 AI 以前只是个咨询顾问现在终于能当一个把活干完的同事了。2. 动手前安装与初始配置2.1 三种安装方式怎么选WorkBuddy 目前的常见使用形态有三种对应不同使用习惯千万别装错桌面客户端适合个人日常使用安装后可以管理多个项目工作区图形界面友好我建议第一次接触的人用这种浏览器插件适合配合网页办公场景比如在网页上选一段内容直接丢给 WorkBuddy 处理轻量但功能受限本地部署适合团队或对数据敏感的场景把 WorkBuddy 服务和模型跑在自己服务器上好处是数据不出内网坏处是得自己维护环境我第一次用的时候图省事装了插件版结果发现很多 Skill 功能跑不了因为插件模式对本地文件系统的访问权限非常有限。后来换到桌面客户端才真正体验到它的完整能力。如果你打算认真用我建议直接上桌面客户端或本地部署插件当辅助可以当主力就有点委屈自己了。2.2 初始配置的三个关键项装好之后第一次打开会进入配置向导很多人急着跳过结果后面处处碰壁。有三个配置项必须认真填第一模型接入。WorkBuddy 本身不带模型它需要接一个大模型的 API。常见的选择是接入 OpenAI 兼容接口如果你是通过 Spring AI 这类框架做的统一接入也可以直接把 WorkBuddy 接到自己的模型网关。这里有个经验不要一味追求大参数模型日常任务用中等模型就够跑得快也省钱只有复杂任务再切大模型。第二工作目录授权。WorkBuddy 要读文件、跑命令必须给它指定一个可操作的工作目录并在授权里允许它读取、修改这个目录下的文件。这块是很多人忽略的点你授权路径太小AI 就找不到项目文件授权路径太宽又有安全风险。我的做法是每个项目建独立工作区只授权给当前项目目录。第三安全边界设置。建议把自动执行高风险命令这类选项关掉让 AI 在执行删除、批量修改等操作前先征求你的确认。毕竟它是同事不是主人关键动作还是得人来拍板。2.3 项目目录里那个隐藏的 .workbuddy 是什么如果你在项目目录下执行ls -a会看到一个叫.workbuddy的隐藏目录。很多第一次用的人看到这个目录一头雾水甚至以为是病毒或者安装残留。这个目录其实是 WorkBuddy 在每个项目里的大脑皮层里面存放了该项目专属的配置、Skill、上下文记忆和运行日志。目录结构大致如下.workbuddy/ ├── config.yaml # 项目级配置可以覆盖全局配置 ├── skills/ # 该项目可用的 Skill 列表 ├── memory/ # 长期记忆AI 会把重要信息存到这里 └── logs/ # 运行日志排查问题最先看这里所以如果你的 Skill 在这个项目里不生效先去看看是不是放错了目录如果 AI 老是忘记你们的约定去 memory 里看看是不是记忆写入失败了。这个隐藏目录就是 WorkBuddy 干活的地盘理解了它你就掌握了排查问题的钥匙。3. Skill 机制把 AI 训练成干活同事的关键一步3.1 Skill 到底是个什么东西在配置完基础环境之后WorkBuddy 还是个什么都会一点、什么都不精的杂工。你想让它高效干某类活就得靠 Skill。可以把它理解成给 AI 写的岗位说明书告诉它面对什么任务、按什么步骤做、调用哪些工具、最后交什么格式的成果。如果没有 Skill你每次都要把需求从头到尾描述一遍AI 还不一定理解你的行业术语和交付标准。而有了 Skill它就像老员工一样接到任务就知道该按什么路子来产出的东西也稳定。打个比方同样让人写一份会议纪要没培训的新人可能给你流水账但一个有 SOP 的秘书会按背景、结论、决议、待办的结构整理得清清楚楚。Skill 就是那份 SOP。3.2 五步写一个自己的 Skill很多人卡在不会写 Skill这一步其实没那么玄乎。以研发周报自动生成为例我一共分了五步第一步规划目录结构。在.workbuddy/skills/下新建一个文件夹比如weekly_report里面放 Skill 定义文件和提示词模板。第二步创建 Skill 定义文件skill.yaml。最简可用的配置长这样name: weekly_report description: 根据本周 git 提交记录和任务清单自动生成结构化周报 version: 1.0.0 triggers: - 写周报 - 生成周报 - weekly report steps: - action: run_command command: git log --since7 days ago --prettyformat:%h %ad %s --dateshort - action: read_files path: ./tasks.md - action: llm_generate prompt_template: ./prompt.md output: - file: weekly_report_{{date}}.md第三步写提示词模板prompt.md。这是决定输出质量的核心模板里写清楚周报的结构、详略要求、语气风格请根据以下 git 提交记录和任务清单生成一份周报。 要求 1. 按本周完成、进行中、风险与阻塞、下周计划四段组织内容 2. 每条事项用一句话说清做了什么、有什么产出 3. 风险项必须标注影响范围和当前状态 4. 语气客观不要夸大成果 git 提交记录 {{git_log}} 任务清单 {{tasks}}第四步在 WorkBuddy 里重载 Skill。配置改完后不用重启整个应用直接在对话里输入重载 Skill就行。第五步写几条高质量示例放进 Skill 的examples/目录。这一步很多人偷懒跳过但相信我示例是让 AI 稳定输出高质量内容的最有效手段。给它看一段你认可的周报范例它产出的质量会立刻上一个台阶。3.3 我每天都在用的几个 Skill 模板这里分享几个我自己打磨过的 Skill 模板可以直接抄作业会议纪要 Skill输入会议录音转写文本或笔记输出含结论、决议事项、负责人、截止时间的结构化纪要。关键在提示词里写好不确定的内容标注为待确认不要编造。代码审查 Skill先让 AI 读取指定 diff再让它按潜在 Bug、性能问题、代码规范、安全风险四类输出审查意见每条意见要标注文件位置和修改建议。专利辅助检索 Skill输入技术交底要点它先拆解技术特征再生成检索式最后输出对比分析和交底书初稿。这个场景我后面详细展开。你不需要一上来就写很多 Skill先把最高频的 3 到 5 个场景做精比追求数量有效得多。3.4 Skill 不生效先查这四个地方Skill 机制用久了难免遇到写了不生效的情况。按我排错的经验99% 是下面四个原因一是触发词没匹配上。WorkBuddy 靠触发词判断什么时候启用哪个 Skill如果你在对话里的说法跟触发词不一致它就当普通聊天处理了。解决方法是把触发词写宽泛些同一个意思多写几种表达。二是目录放错了。Skill 要放在 .workbuddy/skills 下面不是放在项目根目录随便建个文件夹。我之前就犯过把 Skill 定义文件放到工作区根目录结果重载了十次都不生效。三是定义文件格式错误。YAML 对空格特别敏感一个缩进错了整个文件都解析失败。建议写完用 YAML 校验工具检查一遍别靠肉眼。四是记忆冲突。如果旧版本 Skill 的执行结果已经写入了 memory新版本可能被记忆里的旧信息干扰。这种情况删掉 memory 里对应的旧记忆再试试。4. 实战用 WorkBuddy 跑通一个真实任务流程4.1 选个场景专利辅助检索与交底书初稿理论讲完必须来一个完整案例。我从热搜词里挑了一个非常有代表性、又常被忽视的场景专利相关辅助链接与 AI 辅助。很多做研发、写专利的人每天都要面对一个痛苦流程——先做专利检索再看一堆对比文件然后憋一份技术交底书。这个场景特别适合 WorkBuddy 干因为它的痛点不是没有创意而是重复劳动多、格式要求严、检索对比费时间。下面我用一个基于现有技术方案生成专利检索报告和交底书初稿的任务带你把整个流程跑一遍。4.2 把目标拆成 AI 能执行的步骤我在实战之前习惯先在纸上把任务拆清楚。这个专利辅助任务我拆成了四步第一步输入技术方案把我自己写的一段技术描述扔给 AI让它先理解这个方案的核心创新点第二步生成检索式AI 把自然语言描述转换成关键词组合和分类号方便去专利库检索第三步对比分析把检索到的几篇对比文件内容整理出来和我们的方案做差异对比第四步输出交底书初稿按照专利交底书的标准章节生成初稿拆完之后我建了一个patent_assist的 Skill把这些步骤固化成可复用流程。这里有个关键点不要一个 Skill 干完所有事我把检索式生成和交底书撰写拆成了两个独立 Skill因为它们的输入输出差异太大混在一起会让提示词变得很臃肿效果反而不稳定。4.3 完整跑通从一段描述到一份初稿实际执行的时候我在对话里输入了这样一句指令请用 patent_assist 处理以下技术方案 本方案提出一种基于动态阈值调节的传感器数据清洗方法 解决现有方法在数据剧烈波动时误删有效数据的问题。 核心创新在于根据滑动窗口内的数据方差动态调整清洗阈值。WorkBuddy 调起patent_search_keywordsSkill 后输出了这样一组检索式(传感器 OR 数据清洗 OR 异常检测) AND (动态阈值 OR 自适应阈值) AND (滑动窗口 OR 方差) AND (数据过滤 OR 数据修正) 分类号G01D3/00、G06F16/2458接着我给它喂了两篇对比文件的摘要它按技术特征对比表的格式生成了差异分析最后自动套用交底书模板写出了初稿。整段流程大概用了 6 分钟其中大部分时间花在检索和生成上我不需要动脑子。初稿质量大概到 60 分拿给资深的专利代理人改一遍就能用比从零开始写节省了至少两个小时。4.4 从单次问答到业务化复用跑通一次不算本事能反复复用才是真正回本。我做完这个案例后把patent_assist的两个 Skill、提示词模板、输出样例一起放到了团队的共享目录里。现在团队里任何人写专利直接在 WorkBuddy 里调用这个 Skill 即可输入自己的技术描述就能得到一份结构完整的初稿。这就是 Skill 机制的复利效应。一次投入长期复用。你的知识资产沉淀在 .workbuddy/skills 目录里换项目、换团队、换机器都能带走。我自己现在维护了十几个 Skill每个 Skill 都是围绕着真实业务场景反复打磨出来的从能用迭代到好用到像专门定制的工具。5. 常见问题与排查技巧实录5.1 本地部署和插件环境的坑如果你选了本地部署路线第一个遇到的坑大概率是模型加载慢或频繁超时。排查思路很简单先确认模型服务有没有独立跑通再用一个最简单的对话测试 WorkBuddy 和模型服务的连接是否正常。曾经我这边有个案例本地部署怎么都跑不通最后发现是模型服务的端口配置在容器里WorkBuddy 连的是宿主机端口网络没打通。插件版则容易遇到权限问题。表现为 AI 想读本地文件却只弹出一个空目录。这不是 Bug是插件权限模型限制解决方案就是切到桌面客户端或本地部署模式。记住一句话插件适合做轻量文本处理凡是涉及文件系统、命令行执行的任务一律回到完整环境里跑。5.2 上下文丢失和记忆混乱用 WorkBuddy 跑长任务时偶尔会遇到AI 干到一半忘了前面的需求。这通常不是智商问题而是上下文窗口被撑爆了或者是多轮对话太长早期信息被挤出了窗口。我的应对方法有三个第一大任务拆小每次只让它干一步这样可以大幅压低上下文压力。第二关键需求写成文件放进工作目录让 AI 从文件读而不是从对话里猜。第三利用 memory 机制把项目的关键约定用记住本项目输出文档均需中英双语这样明确的话术告诉它长期记忆可以跨会话保留。5.3 内容安全与合规使用提醒WorkBuddy 再能干它也只是一个工具数据安全这根弦不能松。我的建议是不把敏感的个人隐私数据、未公开的商业数据、客户专属信息直接灌给远端模型服务除非你确认数据链路是安全的或者干脆用本地部署的模型处理敏感内容。另外提醒一点网上有人整理的WorkBuddy 大学清单之类的资料很多是热心用户自己总结的学习路线并不是官方发布的认证或课程体系参考可以别把它当成官方标准。学习 WorkBuddy 最好的资料源永远是官方文档加自己的项目实践。5.4 几个让效率翻倍的小习惯最后分享几个我实操下来觉得特别提升体验的小技巧给每个长期项目建独立工作区和独立 .workbuddy 目录避免串味把高频操作固化成 Skill哪怕很简单比如格式化日志文件生成数据库变更说明用请先输出你的执行计划指令让 AI 先列计划你确认后再执行这一步能有效避免 AI 跑偏定期清理 logs日志文件膨胀会影响加载速度我一般每周归档一次遇到重复性报错先看 .workbuddy/logs 里的记录比重新问 AI 快得多6. 写在最后的经验和建议如果你从头看到这里说明你是真的想认真用 WorkBuddy不是随便玩两下就扔。那我再啰嗦两句真心话。我踩过最大的坑是一开始就想搭一个万能助理结果把时间全花在配置各种复杂流程上反而没有解决眼前的具体问题。后来转换思路从一个每天都要重复的小任务开始比如从 git 记录生成周报先保证它好用再用同样的模式复制到其他场景。这个策略见效最快也最容易积累信心。WorkBuddy 这类 AI Agent 工作台目前还处在高速迭代的时期今天觉得麻烦的配置明天可能一个按钮就搞定了。但它背后的思路是确定的AI 从聊天到干活靠的不是模型参数变大而是把人的经验、流程、知识结构工程化地沉淀下来让 AI 能照着做。我的建议是你不需要一次学完所有功能也不用等自己准备好了再开始。找一个这周就会遇到的重复性任务把它做成第一个 Skill跑通一次然后持续打磨。用不了两周你就会有属于自己的AI 同事团队。