这段时间我一直在用 WorkBuddy 跑一些比较琐碎又绕人力的任务发现身边很多人其实都把它当成了“高级版搜索引擎”问一句答一段不满意再回车再问再答。不是说这种用法有错但它真的浪费了 WorkBuddy 最值钱的部分——它压根不是一个聊天框而是一个能接任务、能按流程走、能持续产出的 AI Agent 工作台。这篇指南是我最近从“聊天心态”切到“协作心态”之后整理的完整 WorkBuddy 使用教程。我会从它跟普通 AI 聊天工具的本质区别讲起然后覆盖环境准备、安装部署、Skill 与自定义指令、工作流设计以及我在本地跑 Ubuntu 和网页版时踩过的一堆坑。想快速上手的可以直接跳去看第三章和第四章想搞明白“为什么以前用不好”的建议从头读。1. 先搞清楚WorkBuddy 和我之前用的 AI 聊天工具有什么本质区别1.1 “能聊天”不等于“能干活”这句话到底什么意思我第一次用 WorkBuddy 的时候习惯性地把它当成对话框问它“帮我写个周报提纲”它给我一段漂亮的文字我很满意。但第二天我发现周报这个任务并不是“一段文字”就结束的——我要的数据散落在三个文档里格式要求藏在团队模板里上周的进度和这周的安排又有连带关系。我用聊天工具反复复制粘贴、多次追问半小时没了产出还是一堆半成品。这就是典型“聊天工具”的局限它只有短对话记忆输出是文本没有任务状态没有工具调用也不关心你到底想要一个“回答”还是一个“结果”。而 WorkBuddy 这类 Agent 工作台的设计思路完全不同。它管的不只是“这句怎么回”而是“这个活怎么干完”。它会拆任务、按步骤执行、调用 Skill、保存中间产物最后交付一个完整的输出物。我打个生活化的比方。搜索引擎是查资料聊天 AI 是请了个话痨陪聊而 WorkBuddy 是那种你把需求讲清楚、它自己去翻材料、做整理、出草稿、再找你确认的实习生。你要做的不是“不断追问”而是“派活、验收、纠偏”。刚上手的人最容易踩的坑就是继续拿聊天的姿势去用 WorkBuddy每个任务都从头描述一遍不建工作台不定义 Skill不给它上下文。结果它给你的东西永远像“第一版草稿”因为你压根没给它建立“持续工作”的条件。1.2 WorkBuddy 和 CodeBuddy、其他 AI 工具到底怎么选很多人在搜 WorkBuddy 教程的时候会顺手搜到 CodeBuddy然后疑惑这两个到底有啥区别。我的理解是CodeBuddy 更偏代码场景像 AI 结对编程、IDE 里的代码补全和问答它解决的是“写代码”这件事WorkBuddy 更像一个通用 Agent 工作台它解决的是“把一个多步骤的活儿交给 AI 去推进”这件事。换句话说如果我的需求是“IDE 里面帮我解释这段代码、帮我补个函数”CodeBuddy 更顺手如果我的需求是“把这三份资料整合成一份调研报告按固定格式输出并且下次类似任务还能复用同一套流程”那 WorkBuddy 这种工作台思路更合适。两者不是替代关系是场景互补。我自己现在是文本和流程类任务统一扔给 WorkBuddy写代码时再用 IDE 侧的 AI 辅助。还有一个容易被忽略的选择维度是部署方式。网页版适合快速体验本地部署适合对数据敏感、想深度定制 Skill 和模型配置的人。两种方式我在后文都会展开写别急着做选择先看自己的场景偏重哪边。2. 跑起来之前环境准备与三种常见部署方式2.1 网页版想快速上手的人直接走这条路如果你的目标只是先跑通一个完整任务建议直接用网页版。注册账号后它把模型、环境、依赖全都托管好了你只需要关心任务本身。我一开始坚持本地部署结果浪费了一个下午查各种依赖报错后来想想挺没必要的——体验核心功能网页版是最短路径。网页版建议先认真做两件事。第一把工作台结构摸一遍看看任务状态、输出物、会话记录分别在哪个位置别连“活干到一半放哪了”都找不到。第二找到自定义指令或全局设置的入口先把“你是谁、要什么、别怎么干”写进去。很多网页端用户遇到的问题不是工具不行而是产品面板都没摸清就开始狂问功能全浪费在临时对话里。2.2 本地部署Ubuntu / Linux 实战记录本地部署确实比网页版灵活能自定义模型接入、断网可用、数据不出门但代价是环境折腾。我这里记录一下我在 Ubuntu 22.04 LTS 上的实际部署过程给想自己跑的人一个参考。第一步是准备基础依赖。WorkBuddy 这类 Agent 框架一般基于 Python 3.10 或 Node 18我建议先确认版本python3 --version node -v版本太老的话先装依赖。Ubuntu 上我遇到过缺 build-essential 导致编译某个依赖失败的情况所以建议先执行一次sudo apt update sudo apt install -y build-essential python3-venv git第二步是获取代码并创建虚拟环境git clone 项目仓库地址 workbuddy cd workbuddy python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt第三步是配置文件。项目目录下一般会有一个.env.example或config.example.yaml复制成.env后重点要改的是模型 API 的 Key 和 Base URL以及默认模型名cp .env.example .env vim .env我自己本地跑的时候模型有两种接法一种是接云端 API配 API Key另一种是接本地模型服务比如 Ollama。接本地模型的好处是完全离线但对显存要求高接云端 API 省本地资源但要保证网络稳定。开始的时候建议先用云端 API 把流程跑通等熟悉了再切本地模型。最后启动服务python main.py或者项目里有 Docker 方案的话也可以直接docker compose up -d。启动完后访问本机端口看到健康检查通过界面基本就成功了。Ubuntu 这边常见问题集中在 Python 版本冲突和端口被占用后面我会在常见问题部分集中说。2.3 模型配置不同任务该用什麼参数这一步最容易被新手忽略但影响特别大。我在 WorkBuddy 里调试时会关注两个参数temperature 和 max tokens。简单理解temperature 控制“随机性”。处理代码、生成固定格式的表格、整理规范文档时我会把它调到 0.2 到 0.4输出稳定少跑偏做头脑风暴、写营销文案、起标题这类创意任务时再调到 0.7 以上。max tokens 控制单次输出长度如果你让它生成一份万字报告而只给 512 token它写一半就断了哪怕你再问“继续”质量也会大打折扣。我一般根据任务复杂度按需设置报告类会调到 4000 以上。如果你刚开始不知道用什么值套用我后端的一个简易对照表即可任务类型建议 temperature建议 max tokens代码生成 / 代码审查0.1 ~ 0.32048 或更高结构化文档 / 周报 / 表格0.2 ~ 0.42048 ~ 4096邮箱 / 公文 / 正式通知0.3 ~ 0.51024 ~ 2048创意文案 / 头脑风暴0.7 ~ 0.92048长文本改写 / 摘要0.3 ~ 0.5输入长度的一半以上3. 核心功能拆解工作台、Skill、自定义指令3.1 工作台管理“正在干的活”而不是“聊天记录”我刚开始用 WorkBuddy 时习惯性把每个需求都在单独的会话框里问完就走后来发现任务一多就完全失控哪个做到一半了哪个已经交付了上次的结论是在哪个对话里说的全记不住。后来我强迫自己切换到工作台思维。工作台里每一个“任务”对应一个具体交付物它有自己的状态、上下文、关联文件和输出结果。我通常的做法是接到一个需求先在 WorkBuddy 里新建一个任务卡片把目标、背景资料、参考模板、验收标准都挂在卡片上然后再开始派活。工作台的意义在于它把 AI 从“临时工”变成了“有工位的正式员工”。每个任务都有独立的工作区它知道你在这个任务里的所有上下文不会因为换了个会话就把关键信息全忘光。如果你发现 WorkBuddy 给的结果老是接不上前文大概率是因为你还在用聊天框模式而没有把任务正式挂到工作台里跑。3.2 Skill把偶尔用一次的能力变成可以复用的手上功夫如果说工作台解决的是“任务管理”问题那 Skill 解决的是“能力沉淀”问题。我举个最简单的例子。我们团队每周都要出一个项目周报格式有固定套路本周重点、数据变化、风险项、下周计划。一开始我每次都在对话框里重新讲一遍这些要求AI 给出来的结构时好时坏。后来我把这套要求封装成了一个 Skill名字就叫“项目周报生成器”里面写清楚输入需要哪些内容、输出按什么章节组织、语气风格是什么、哪些地方必须保留原文数据。从那以后每周只需要把素材丢进去它输出的第一版结构就已经有 80% 可以直接用。Skill 本质上就是一个结构化的指令包里面包含提示词模板、可绑定的工具、输入输出约定。WorkBuddy 新建 Skill 时通常有两种方式一种是在界面上用表单创建适合不想碰代码的人另一种是写原生配置适合想精细控制的人。原生方式的逻辑大致形如name: weekly_report description: 根据本周工作日志生成结构化周报 input: - work_log: 本周工作记录文本 - extra_data: 可选的数据补充 output: format: markdown sections: - 本周重点 - 数据变化 - 风险项 - 下周计划 instructions: | 请先提取工作日志中的关键项目再按 output.sections 组织内容。 如果某个章节没有对应信息明确写“暂无”不要编造。我在实际使用中总结出三个建 Skill 的要点。第一输入字段要尽量简单明确不要让 AI 去猜你要喂什么数据第二输出结构必须写死宁可板一点也不要自由发挥第三每一条约束都应该是“必要规则”不要堆一堆废话指令否则反而降低执行准确率。Skill 是 WorkBuddy 最值得花时间琢磨的功能真把它打磨好了你会发现很多重复劳动从此再也不需要亲手做。3.3 自定义指令把团队规范和个人偏好写进默认上下文自定义指令相当于给 AI 设置“出厂性格”。你可以在里面写明白你是什么角色、平时偏好什么语气、最忌讳什么、默认输出格式是什么。它和 Skill 的区别在于Skill 是某一个任务的专用流程而自定义指令是全局生效的“工作准则”。我的自定义指令大致包含这几块内容第一是身份定位告诉它“你是我的工作助手不是聊天机器人”第二是输出风格比如“默认使用简体中文、用 Markdown 格式、先给结论再给解释”第三是能力边界比如“不确定的信息不要编造要明确标注”第四是协作偏好比如“收到任务后先花一分钟给出执行计划再开始动手”。这里有一个很容易踩的坑自定义指令写得太死反而会让 AI 变得僵硬。比如你硬性规定“所有回复必须不超过 100 字”那么让它做详细调研的时候也会憋成一句话任务压根没法完成。我的建议是指令要区分“铁律”和“偏好”。铁律是必须遵守的底线比如不得编造数据偏好是默认如此但可调整的倾向比如语气风格。别把偏好写成了铁律。还有一个使用技巧自定义指令可以设置多组针对不同场景切换。比如我有一套“日常办公”指令语气温和、默认用中文还有一套“代码审查”指令语气直接、要求更严格、回复更技术化。用的时候切换一下比一套指令打天下要精准得多。4. 把它当同事三个能落地的实操案例4.1 案例一从零做一个完整的技术调研报告很多人让 AI 做调研方式是“帮我查一下某某技术最近怎么样”。这种问题扔给谁都答不好因为范围太大了。我把任务派给 WorkBuddy 时会主动把调研的范围收窄。比如我要调研 Spring AI 这个方向我会把任务拆成五步第一步明确背景与目标——为什么现在要调研最终要支持什么决策第二步列出核心问题清单——Spring AI 的核心能力是什么、和同类框架相比优缺点如何、社区活跃度如何、典型落地场景有哪些第三步把已知信息源贴进去包括文档链接、项目仓库地址、一些已读过的文章摘要第四步让 WorkBuddy 根据自己的知识补齐框架但要求它区分“基于给定资料”和“基于通用知识”第五步输出限定为一份带目录和结论摘要的 Markdown 报告。实际跑的时候我会在工作台里把这些步骤写成一个任务描述并且在最后加一句“先给我列一个执行计划我确认后你再继续”。这一步特别关键。AI 先列计划相当于先交一份目录你随时可以在动手前纠偏避免它高高兴兴跑偏五千字。报告出来后我不会直接拿去用而是先做“事实抽查”让它标注每一个结论的信息来源无来源的内容单独列出来。这个过程看起来多了一步实际上是在训练自己的 AI 同事“有依据地说话”长期收益非常大。4.2 案例二代码审查与问题修复建议写代码的场景里WorkBuddy 也能干实事但前提是你会给它“审查规则”而不是简单丢一句“帮我看看这段代码”。我有一次把一个 Python 模块丢进去只说了“看看这段代码有没有问题”它给我回了一堆正确但没用的废话“这段代码结构清晰逻辑简洁……”我当场就想退出去。后来我学乖了把审查清单写得很具体类型注解是否完整、异常处理是否合理、是否存在性能隐患、是否遵守单一职责原则、命名是否清晰然后明确要求“按这些问题逐项检查发现的问题标出严重级别”。用 WorkBuddy 做代码审查时的提示词我建议至少包含四个要素语言与框架背景、审查重点、输出格式、禁止事项。这里最实用的技巧是给“主动圈定上下文”。我一开始把整个项目文件夹路径传给工作台让它“自己去看”结果它只凭着路径猜了一通产出质量很差。后来我改成把单个文件或函数片段贴进去并补充相关依赖模块的关键信息准确率立刻上来了。不是这个 Agent 能力弱而是它的工作方式需要你给它一个明确的“注意力边界”。4.3 案例三把每周汇报从半小时压到五分钟这是我最推荐的入门练习因为周报是每个人都绕不开的低价值劳动也是 WorkBuddy 最容易见效的场景。我以前写周报是这样的翻聊天记录、翻邮件、翻项目板梳理这周干了啥然后对着上周的模板逐条填。零零碎碎加起来三十到四十分钟。现在我把流程改成了这样工作日每天花两分钟在 WorkBuddy 的“工作日志”任务里丢几条要点比如“完成了登录模块重构”“客户 A 反馈了一个数据问题待跟进”到周五把本周日志一键丢进“项目周报生成器” Skill它按模板输出本周重点、数据变化、风险项、下周计划。我再花两三分钟改一改表述没了。这个流程看起来很平淡但为什么很多人复现不了问题通常出在前面那步没有坚持记录工作日志。AI 再强也没法从空白的历史里变出你的周报。你长期喂给它什么质量的数据它还你什么质量的报告。我自己试过的进阶玩法是让 WorkBuddy 每周自动总结日志并在日志里标注“风险项”和“下周预告”相当于让 AI 帮我把下周计划提前预生成周一上班直接调整确认效率比之前翻倍都不止。5. 常见问题与排查技巧实录5.1 模型连接失败、响应超时如果你用的是本地部署模型连接失败是最常见的问题。排查时我一般按这个顺序推进先确认本地服务端口还活着再看 API Key 是否过期然后检查网络是否能正常访问模型提供方。一个稍微隐蔽的坑是本地模型服务虽然启动了但 WorkBuddy 配置里填的模型名和实际拉取的模型不一致。比如 Ollama 里拉的是 llama3.1配置里却填了 llama3两边对不上状态看着正常但一调用就报错。这个我在 Ubuntu 上遇到过几次建议统一用一个模型别名不要混填。5.2 Skill 不生效或加载不到Skill 建好了但调用时没反应绝大多数情况不是产品的问题而是你的触发描述写得太模糊。WorkBuddy 靠描述来匹配 Skill如果你给 Skill 起的描述是“周报”触发时说的是“帮我总结一下这周的工作”匹配不上很正常。建议把 Skill 的触发词写得贴近真实口语场景。比如“周报生成器”的描述写成“根据工作日志或要点生成符合团队模板的项目周报包含本周重点、风险项和下周计划”。这样用户哪怕没有提到“Skill”这个词AI 也能按语义把它从工具清单里捞出来。改了描述之后还不行就检查一下 Skill 有没有被当前任务启用有些工作台会把 Skill 设计成需要手动绑定到任务才能生效。5.3 生成质量忽高忽低怎么稳定输出很多人反馈同一个任务跑两次结果差很多。这个现象有两个主要来源一是 temperature 设置偏高随机性大二是上下文不一致你在不同会话里用的背景资料不一样。稳定输出最直接的做法是把关键信息固化到 Skill 或自定义指令里让每次执行时 AI 都拿到同一套规则。另外我强烈建议把任务拆小。一个大而全的任务AI 很容易在中间环节开始“自由发挥”拆成小步骤每步只做一件事输出的稳定性会好得多。比如“写一份完整的竞品分析报告”听起来很爽但它涉及调研、框架、写结论、排版混在一起大概率翻车。拆成四个子任务分别执行最后再合成效果完全不一样。5.4 WorkBuddy 问题排查速查表现象可能原因排查 / 解决建议模型响应超时网络环境不稳 / 模型推理过长确认网络连通拆分长任务调高请求超时时间回复内容总接不上前文没使用工作台上下文割裂新建任务并挂到工作台下利用任务上下文Skill 未被调用描述与用户意图匹配度低重写 Skill 描述加入常见口语触发词输出太随意、格式混乱未定义输出格式 / temperature 过高在指令中写死 Markdown 结构调低 temperature报告出现编造内容没有要求标注信息源在指令中加入“无依据内容不得编造需单独标注未知信息”本地部署启动失败端口被占用 / 依赖缺失换端口补齐系统依赖检查 Python 版本最后再分享一个小技巧用 WorkBuddy 这段时间我最大的体会是它不会替你解决所有问题但能把你的精力从“重复劳动”里捞出来放到真正值得判断和决策的事情上。前提是你要愿意花前期那一点点时间去搭工作台、建 Skill、写自定义指令。这就像招了个实习生头几天你肯定要花时间带但如果因为“嫌麻烦”就一直不放权那这实习生永远帮不上忙最后累的还是你自己。WorkBuddy 也不例外你前期投入得越多后期它给你省的时间就越夸张。最后送大家一个我用下来最有用的习惯每天结束前花两分钟打开 WorkBuddy把当天做的事和明天要干的活各写三行。这比任何参数调优都重要因为一个 AI 同事靠不靠谱很多时候取决于你有没有坚持给它一个清晰、连续的工作上下文。