第一次打开 WorkBuddy 的时候我的第一反应是这不就是套壳聊天工具吗直到我花了一个周末把常用的几种工作流做成 Skill 之后才意识到这东西的正确打开方式。它真正吸引人的地方不是多聪明的模型而是可以把 AI 从“你问一句、它答一句”的一次性对话变成“你交代任务、它按标准交付”的长期协作伙伴。这篇教程我会从安装、配置、Skill 编写到实战流程完整过一遍适合正在用 AI 但觉得效率没有本质提升的人也适合做 AI Agent、AI 编程、内容创作时想把工具真正用起来的朋友。1. 先搞明白WorkBuddy 不是一个聊天框1.1 它和普通 AI 网页工具的核心区别普通 AI 工具的工作方式很简单你输入一段 Prompt它基于模型上下文生成一段回答。这个过程其实很像临时找一个朋友支招每次都要重新交代背景、说明语气、强调格式聊完就忘下次永远从零开始。WorkBuddy 则把 AI 当成一个有固定职责的“同事”。你可以提前给这位“同事”做入职培训告诉它你的业务流程、写作规范、代码风格、交付格式甚至给它挂上一堆可复用的“技能(Skill)”。当你需要它干活时只需要说一声“今天帮我跑一下日报生成”或者“把这份会议记录变成待办清单”它就会自动走一遍你预设好的流程最后给你一个符合验收标准的交付物。我说个比较夸张但真实的类比网页版 AI 像在大街上随机抓一个路人咨询你得把前因后果讲一遍WorkBuddy 像你公司里经过培训的同事知道你的业务习惯甚至知道你讨厌在报告里看到空话。两者的差距不在“是不是 AI”而在“有没有上下文和流程沉淀”。1.2 它到底解决了什么问题过去几年我见过大多数人用 AI 的方式想到什么问什么结果都是用一阵子就放弃觉得 AI 不靠谱。真实原因往往是 Prompt 太随意、任务太笼统、输出没有标准。WorkBuddy 这种工具解决的就是“把 AI 用成生产工具”的问题。它有三个层级的能力记忆层通过全局自定义指令设定角色、语气、回答规则让 AI 保持一致行为。技能层通过 Skill 把重复性任务打成“包”比如写周报、做数据分析、生成专利初稿、拆解需求。自动化层通过 Pipeline / Agent 把多个 Skill 串成一条工作流让 AI 自己处理中间步骤。如果你日常有固定类型的文字处理、数据分析、代码片段生成任务或者你想把一个 AI Agent 嵌入到团队工作流里WorkBuddy 会非常合适。但如果只是偶尔问一两个生活小问题那确实用不上它。2. 5 分钟把“工位”搭起来安装和初始配置2.1 安装方式和系统要求WorkBuddy 目前的安装方式比较灵活官方推荐的是命令行安装同时也提供了 Windows / macOS / Linux 下的桌面客户端。我自己用的是 macOS装了命令行工具之后发现日常工作都够用所以后面讲的会以命令行版本为主。Windows 上需要注意一点某些版本依赖 VS Code 的运行时环境如果你以前没装过开发工具第一次启动可能会报缺少组件。我的排查经验是先装好 Git for Windows 和 Node.js LTS再跑安装命令基本能避开 80% 的坑。安装命令大概是这样的这里根据常见实践做示例具体以官方文档为准curl -fsSL https://workbuddy.example/install.sh | bash装完以后执行workbuddy init --workdir ~/workbuddy这个命令会在你的用户目录下创建~/workbuddy文件夹里面默认会有skills、agents、config三个子目录。skills目录放所有技能文件agents目录放自动化工作流配置config目录存全局配置和密钥信息。2.2 配置模型API Key、本地模型和默认参数WorkBuddy 本身不绑定某个特定模型它设计成了一个“模型无关”的框架。你可以在配置里指定使用 OpenAI 兼容接口、Anthropic 接口也可以连本地 Ollama 跑开源模型。我的建议是刚开始不要折腾本地模型先把远端 API 跑通。你只需要在配置里填一个 API Key 和 Base URL 就行。# ~/workbuddy/config/model.yaml provider: openai_compatible base_url: https://api.your-provider.com/v1 api_key: ${WORKBUDDY_API_KEY} model: gpt-4o-mini temperature: 0.3注意我习惯把 API Key 写到环境变量里而不是直接写进配置文件避免以后共享配置时不小心泄露。配置好之后在终端随便跑一句workbuddy run 你好介绍一下你自己如果正常返回说明基础环境 OK可以进入下一步。2.3 界面和目录结构别忽略初始文件夹很多人装完就急着问“怎么打开界面”其实命令行版本的 WorkBuddy 会同时启动一个本地 Web UI默认地址是http://localhost:8080浏览器打开就能用。Web UI 适合交互式对话和调试 Skill命令行更适合跑脚本、挂自动化任务。我刚开始用的时候最大的失误是不看目录结构把 Skill 文件乱放导致加载不出来。这里建议你先看一眼初始结构~/workbuddy/ ├── config/ │ ├── model.yaml │ └── global_prompt.md ├── skills/ │ └── example/ │ ├── skill.md │ └── template.md └── agents/ └── demo_agent.yaml理解这个目录之后后面所有操作都会轻松很多。3. 把 AI 变成“干活同事”Skill 才是核心3.1 Skill 是什么一份“工位说明书”Skill 是 WorkBuddy 里最重要的概念。你可以把它理解成给 AI 写的一本“工作手册”。一本合格的工作手册应该包含三部分这个技能是做什么的、输入参数是什么、输出格式是什么。我举个例子假设你要做一个“日报生成技能”。你希望 AI 每天根据你提供的几条工作碎片生成一篇带“今日进展、明日计划、风险点”的日报。这个流程很固定但每次都写 Prompt 很烦。把它固化为 Skill 后你只需要在对话里输入/daily_report 今天完成了登录模块重构处理了一个线上 bug明天计划做性能优化AI 就会自动套用你预设的输出结构。一个典型的 Skill 文件结构是这样的~/workbuddy/skills/daily-report/ ├── skill.md # 技能描述和参数定义 └── template.md # 提示词模板用 {{input}} 接收输入3.2 手把手做一个“日志分析”Skill我带大家完整做一个“日志分析”技能因为这个场景几乎所有人都能用上。假设你经常要处理几百行应用日志想快速定位报错原因传统做法是把日志复制给 AI让它“帮我看看有没有异常”结果往往输出又长又空。第一步创建技能目录mkdir -p ~/workbuddy/skills/log-analyze第二步编写skill.md--- name: log-analyze description: 分析应用日志提取错误、耗时趋势和关键警告输出结构化报告 input: type: text required: true description: 原始日志内容 --- 你是一个资深 SRE 工程师。你擅长从原始日志中分析异常。 请按以下格式输出 1. 错误统计按错误类型排序给出出现次数。 2. 关键错误提取最重要的3条说明可能原因。 3. 耗时分析如果日志中包含耗时信息给出 p50/p95 耗时。 4. 处理建议针对每个关键错误给出下一步排查方向。 输入日志 {{input}}第三步在 WorkBuddy 对话里调用/log-analyze 2025-01-01 10:00:12 ERROR TimeoutException ...这里有个很重要的心得提示词模板里一定要给输出格式示例或明确的“分节要求”。没有格式约束时AI 输出会比较发散一旦你规定了“错误统计、关键错误、耗时分析、处理建议”四个部分输出的稳定性和实用性会大幅提升。3.3 全局自定义指令给同事立规矩除了每个 Skill 里的局部指令WorkBuddy 还支持一个全局指令文件类似给所有“同事”立规矩。这个文件在~/workbuddy/config/global_prompt.md里。我的全局指令就三行核心原则你是一个严谨的助手。对每个问题先给结论再给解释。 如果信息不足主动说明缺少什么不要编造。 回答中文问题时默认使用简体中文技术名词保留英文原文。别小看这几行。之前我让 AI 帮我写一个技术方案它洋洋洒洒写了两千字开头全是“随着业务发展”被我全局指令一约束后立刻变成直接给结论。这就是“同事”和“工具”的区别。多加一条经验全局指令不要写太长否则模型会迷失重点。最好控制在 5 条以内而且是硬性规则比如“禁止说空话”“先给数据再给结论”。4. 实战三条工作流把 AI 变成生产力4.1 日常运营会议纪要到待办清单我身边很多运营朋友每天都在做“会议记录 - 整理纪要 - 拆待办 - 跟进进度”这种脏活。时间都花在整理格式上而不是思考事情本身。我的解决方法是做了一个“会议纪要转待办”的 Skill。流程是这样的先用语音转文字工具拿到会议原始文本。调用 WorkBuddy 的/meeting_to_todo技能输入原始文本。技能内部会先提取“决策、结论、负责人、截止时间”再按一个模板输出待办清单。技能模板的核心部分如下你是团队协作助手。从会议记录中提取以下内容 - 决策用一句话概括团队做出哪些决定。 - 待办事项每项待办必须包含任务描述、负责人、截止日期。 - 风险会议中提到的潜在问题。 会议记录 {{input}} 输出为Markdown表格负责人为空时写“未指定”。这个技能我用下来最大的价值不是省时间而是逼着所有会议都按同一套标准输出。以前每个人写的会议纪要风格完全不同现在 AI 统一格式化后续找信息特别方便。4.2 技术开发让 WorkBuddy 和 CodeBuddy 搭档做开发的人会关心 WorkBuddy 能不能写代码。我的意见是它不是用来替代你写代码的编辑器它更适合做“需求拆解、方案设计、测试代码生成”这种偏规划和辅助的工作。真正落到代码生成和编辑器补全可以搭档 CodeBuddy 这类工具一起用。我目前的开发流是这样接到一个需求后先用 WorkBuddy 的“需求拆解”技能把需求转成功能清单和边界条件。让 WorkBuddy 生成设计文档包括模块划分、数据流、接口定义。把设计文档交给 CodeBuddy 做代码实现让它按接口生成初版。最后我人工 review再让 WorkBuddy 根据代码写单元测试。举个例子我之前写过一个 Verilog 模块需求是“实现一个 FIFO支持同步读写带满空标志”。我先把需求发给 WorkBuddy它生成了接口说明和测试计划然后我让 CodeBuddy 补 RTL 代码并用 WorkBuddy 生成了一段简单的 testbench 代码。module fifo #( parameter DATA_WIDTH 8, parameter DEPTH 16 ) ( input wire clk, input wire rst_n, input wire wr_en, input wire [DATA_WIDTH-1:0] wr_data, input wire rd_en, output wire [DATA_WIDTH-1:0] rd_data, output wire full, output wire empty ); // RTL implementation here endmodule这段代码虽然是 AI 补全的但我会明确告诉它只写逻辑骨架不写具体实现细节避免它“自由发挥”导致方向错误。核心经验是AI 写代码时上下文里的约束比模型大小更影响结果。你把接口定义写清楚它生成的东西才会接近你的预期。4.3 内容创作从灵感标题到成稿内容创作是 WorkBuddy 用得最爽的场景之一。我自己写公众号和技术博客以前从选题到成稿最怕的就是面对空白文档发呆。现在我会建两个技能“选题库扩充”和“文章起草”。“选题库扩充”技能输入一个关键词输出 10 个选题方向每个方向附带目标读者、切入角度、预估价值。这个 Skill 的模板里我会强调“不要给通用建议要给出具体差异化的角度”。“文章起草”技能更进一步输入大纲标题它会按照“场景引入 - 问题拆解 - 操作步骤 - 避坑经验”的结构输出初稿。注意我坚决不要求它直接生成终稿因为 AI 生成的“完美文章”往往缺乏个人风格。它的价值是给我提供一份有结构的草稿我再加入自己踩过的坑和实际数据最后成稿速度至少快一半。5. 进阶玩法本地部署和 Agent 编排5.1 本地部署到底图什么有些人问为什么要本地部署直接连云端 API 不是更方便吗本地部署的核心诉求主要是三条数据隐私、调用成本、离线可用。比如你要处理的内部文档不能出内网就不可能把所有内容发给外部 API。这时候可以在本地装 Ollama拉一个开源模型然后在 WorkBuddy 里把模型地址改成http://localhost:11434所有推理都在本机跑。我实测过用 7B 级别的模型处理文档摘要、标题生成这类任务速度还行但跑复杂 Agent 编排时小模型经常思维链断掉表现明显不如云端大模型。所以我现在的建议是“混合调用”敏感数据走本地小模型复杂推理走云端 API。WorkBuddy 支持按 Skill 指定不同模型这一点非常实用。配置大概长这样# ~/workbuddy/config/model.yaml provider: ollama base_url: http://localhost:11434 model: qwen2.5:7b5.2 Agent 编排把多个 Skill 串成一条流水线当你积累了足够多的 Skill 之后下一步就是把它们串成 Agent。WorkBuddy 的 Agent 机制也很直白通过一个 YAML 文件定义“一步步做什么”。我举一个实际的例子做竞品分析报告。过去我需要手动搜索竞品信息、整理功能列表、分析差异、输出报告。现在我把四个 Skill 串成一个 Agent# ~/workbuddy/agents/competitor_analysis.yaml name: competitor_analysis steps: - skill: web_search params: query: {{input}} 竞品 功能 动态 - skill: extract_info params: source: {{steps.web_search.output}} - skill: compare_features params: feature_list: {{steps.extract_info.output}} - skill: generate_report params: diff_data: {{steps.compare_features.output}}实际跑起来时你只需要输入一个产品名这个 Agent 会自动执行检索、信息提取、功能对比、报告生成四个步骤最后生成一份结构化的竞品报告。这就是把 AI 从“会聊天”变成“会干活”的直观体现。5.3 和外部系统打通WorkBuddy 支持通过 API 或 Webhook 方式接入你自己的系统。比如你可以写一个脚本当收到邮件时自动调用 WorkBuddy 的接口让 AI 生成回复草稿或者把工单系统的新工单抓取过来先做一次优先级分类。这里有一个安全提醒凡是涉及密钥、Token、数据库连接串的信息一定要通过环境变量传入不要让 Skill 文件里出现真实凭证。另外Agent 调用外部 API 时我建议在中间加一层人工确认尤其是涉及发送邮件、修改数据这类写操作。AI 的逻辑再完善也值得你最后看一眼。6. 常见问题与排查技巧实录6.1 技能不生效怎么办这是新手问得最多的问题。我自己的排查顺序通常是这样的先检查技能目录路径。WorkBuddy 默认只会加载~/workbuddy/skills/下的一级目录每个目录里必须有skill.md文件。检查skill.md里的name字段和调用名称是否一致。比如文件名是log-analyze调用时就要用/log-analyze中间不能有多余空格。看终端日志。WorkBuddy 启动时会打印加载了哪些 Skill如果加载失败会带具体报错一般是 YAML 语法错误或者模板文件缺失。6.2 模型输出不稳定、格式总变如果你发现同一个 Skill 每次输出结构都不一样大概率是温度参数太高或者模板里的约束不够强。建议先把temperature调到 0.2 以下同时在模板最后加一句“严格按上述格式输出不要输出额外内容”。另外一个常见问题是上下文太长导致模型“忘记”格式要求。解决办法是尽量把输入内容截断处理或者让 Skill 先做一步“输入清洗”提取关键部分再交给后续流程。6.3 网络依赖和安装失败安装时很多人遇到“下载依赖失败”或“请求外部模型超时”。这个问题通常出在目标服务器不可达。我只建议一个稳妥做法为下载源配置国内镜像。比如官方提供的下载地址如果很慢可以换成镜像地址或者用已经打包好的桌面客户端安装包。涉及外部模型 API 时检查一下 Base URL 是否填对API Key 是否带了多余空格。6.4 本地部署时显存不足如果你本地跑模型遇到显存不足最简单的处理是换用量化版本模型比如qwen2.5:7b-instruct-q4_K_M。其次可以降低输入长度限制或者把模型部署到远程服务器上WorkBuddy 只要支持远程 HTTP 地址就行不一定非得本机。最后分享一点个人经验WorkBuddy 这类工具的价值不在于它本身的 AI 能力有多强而在于你愿不愿意花时间给它写“说明书”。我自己花了两个周末把日报、周报、竞品分析、开发需求拆解等流程做成 Skill之后日常工作里的重复劳动减少了一大半。建议新手在创建第一个 Skill 时一定要手动给一两个示例输出这个动作能让 AI 的稳定性提高很多。哪怕只是一个“会议纪要转待办”这种小技能用上一个月你也会明显感觉到 AI 从一个偶尔灵光的聊天工具变成了真正能托付任务的同事。
WorkBuddy 实战：从 Skill 到 Agent，把 AI 变成你的效率同事
第一次打开 WorkBuddy 的时候我的第一反应是这不就是套壳聊天工具吗直到我花了一个周末把常用的几种工作流做成 Skill 之后才意识到这东西的正确打开方式。它真正吸引人的地方不是多聪明的模型而是可以把 AI 从“你问一句、它答一句”的一次性对话变成“你交代任务、它按标准交付”的长期协作伙伴。这篇教程我会从安装、配置、Skill 编写到实战流程完整过一遍适合正在用 AI 但觉得效率没有本质提升的人也适合做 AI Agent、AI 编程、内容创作时想把工具真正用起来的朋友。1. 先搞明白WorkBuddy 不是一个聊天框1.1 它和普通 AI 网页工具的核心区别普通 AI 工具的工作方式很简单你输入一段 Prompt它基于模型上下文生成一段回答。这个过程其实很像临时找一个朋友支招每次都要重新交代背景、说明语气、强调格式聊完就忘下次永远从零开始。WorkBuddy 则把 AI 当成一个有固定职责的“同事”。你可以提前给这位“同事”做入职培训告诉它你的业务流程、写作规范、代码风格、交付格式甚至给它挂上一堆可复用的“技能(Skill)”。当你需要它干活时只需要说一声“今天帮我跑一下日报生成”或者“把这份会议记录变成待办清单”它就会自动走一遍你预设好的流程最后给你一个符合验收标准的交付物。我说个比较夸张但真实的类比网页版 AI 像在大街上随机抓一个路人咨询你得把前因后果讲一遍WorkBuddy 像你公司里经过培训的同事知道你的业务习惯甚至知道你讨厌在报告里看到空话。两者的差距不在“是不是 AI”而在“有没有上下文和流程沉淀”。1.2 它到底解决了什么问题过去几年我见过大多数人用 AI 的方式想到什么问什么结果都是用一阵子就放弃觉得 AI 不靠谱。真实原因往往是 Prompt 太随意、任务太笼统、输出没有标准。WorkBuddy 这种工具解决的就是“把 AI 用成生产工具”的问题。它有三个层级的能力记忆层通过全局自定义指令设定角色、语气、回答规则让 AI 保持一致行为。技能层通过 Skill 把重复性任务打成“包”比如写周报、做数据分析、生成专利初稿、拆解需求。自动化层通过 Pipeline / Agent 把多个 Skill 串成一条工作流让 AI 自己处理中间步骤。如果你日常有固定类型的文字处理、数据分析、代码片段生成任务或者你想把一个 AI Agent 嵌入到团队工作流里WorkBuddy 会非常合适。但如果只是偶尔问一两个生活小问题那确实用不上它。2. 5 分钟把“工位”搭起来安装和初始配置2.1 安装方式和系统要求WorkBuddy 目前的安装方式比较灵活官方推荐的是命令行安装同时也提供了 Windows / macOS / Linux 下的桌面客户端。我自己用的是 macOS装了命令行工具之后发现日常工作都够用所以后面讲的会以命令行版本为主。Windows 上需要注意一点某些版本依赖 VS Code 的运行时环境如果你以前没装过开发工具第一次启动可能会报缺少组件。我的排查经验是先装好 Git for Windows 和 Node.js LTS再跑安装命令基本能避开 80% 的坑。安装命令大概是这样的这里根据常见实践做示例具体以官方文档为准curl -fsSL https://workbuddy.example/install.sh | bash装完以后执行workbuddy init --workdir ~/workbuddy这个命令会在你的用户目录下创建~/workbuddy文件夹里面默认会有skills、agents、config三个子目录。skills目录放所有技能文件agents目录放自动化工作流配置config目录存全局配置和密钥信息。2.2 配置模型API Key、本地模型和默认参数WorkBuddy 本身不绑定某个特定模型它设计成了一个“模型无关”的框架。你可以在配置里指定使用 OpenAI 兼容接口、Anthropic 接口也可以连本地 Ollama 跑开源模型。我的建议是刚开始不要折腾本地模型先把远端 API 跑通。你只需要在配置里填一个 API Key 和 Base URL 就行。# ~/workbuddy/config/model.yaml provider: openai_compatible base_url: https://api.your-provider.com/v1 api_key: ${WORKBUDDY_API_KEY} model: gpt-4o-mini temperature: 0.3注意我习惯把 API Key 写到环境变量里而不是直接写进配置文件避免以后共享配置时不小心泄露。配置好之后在终端随便跑一句workbuddy run 你好介绍一下你自己如果正常返回说明基础环境 OK可以进入下一步。2.3 界面和目录结构别忽略初始文件夹很多人装完就急着问“怎么打开界面”其实命令行版本的 WorkBuddy 会同时启动一个本地 Web UI默认地址是http://localhost:8080浏览器打开就能用。Web UI 适合交互式对话和调试 Skill命令行更适合跑脚本、挂自动化任务。我刚开始用的时候最大的失误是不看目录结构把 Skill 文件乱放导致加载不出来。这里建议你先看一眼初始结构~/workbuddy/ ├── config/ │ ├── model.yaml │ └── global_prompt.md ├── skills/ │ └── example/ │ ├── skill.md │ └── template.md └── agents/ └── demo_agent.yaml理解这个目录之后后面所有操作都会轻松很多。3. 把 AI 变成“干活同事”Skill 才是核心3.1 Skill 是什么一份“工位说明书”Skill 是 WorkBuddy 里最重要的概念。你可以把它理解成给 AI 写的一本“工作手册”。一本合格的工作手册应该包含三部分这个技能是做什么的、输入参数是什么、输出格式是什么。我举个例子假设你要做一个“日报生成技能”。你希望 AI 每天根据你提供的几条工作碎片生成一篇带“今日进展、明日计划、风险点”的日报。这个流程很固定但每次都写 Prompt 很烦。把它固化为 Skill 后你只需要在对话里输入/daily_report 今天完成了登录模块重构处理了一个线上 bug明天计划做性能优化AI 就会自动套用你预设的输出结构。一个典型的 Skill 文件结构是这样的~/workbuddy/skills/daily-report/ ├── skill.md # 技能描述和参数定义 └── template.md # 提示词模板用 {{input}} 接收输入3.2 手把手做一个“日志分析”Skill我带大家完整做一个“日志分析”技能因为这个场景几乎所有人都能用上。假设你经常要处理几百行应用日志想快速定位报错原因传统做法是把日志复制给 AI让它“帮我看看有没有异常”结果往往输出又长又空。第一步创建技能目录mkdir -p ~/workbuddy/skills/log-analyze第二步编写skill.md--- name: log-analyze description: 分析应用日志提取错误、耗时趋势和关键警告输出结构化报告 input: type: text required: true description: 原始日志内容 --- 你是一个资深 SRE 工程师。你擅长从原始日志中分析异常。 请按以下格式输出 1. 错误统计按错误类型排序给出出现次数。 2. 关键错误提取最重要的3条说明可能原因。 3. 耗时分析如果日志中包含耗时信息给出 p50/p95 耗时。 4. 处理建议针对每个关键错误给出下一步排查方向。 输入日志 {{input}}第三步在 WorkBuddy 对话里调用/log-analyze 2025-01-01 10:00:12 ERROR TimeoutException ...这里有个很重要的心得提示词模板里一定要给输出格式示例或明确的“分节要求”。没有格式约束时AI 输出会比较发散一旦你规定了“错误统计、关键错误、耗时分析、处理建议”四个部分输出的稳定性和实用性会大幅提升。3.3 全局自定义指令给同事立规矩除了每个 Skill 里的局部指令WorkBuddy 还支持一个全局指令文件类似给所有“同事”立规矩。这个文件在~/workbuddy/config/global_prompt.md里。我的全局指令就三行核心原则你是一个严谨的助手。对每个问题先给结论再给解释。 如果信息不足主动说明缺少什么不要编造。 回答中文问题时默认使用简体中文技术名词保留英文原文。别小看这几行。之前我让 AI 帮我写一个技术方案它洋洋洒洒写了两千字开头全是“随着业务发展”被我全局指令一约束后立刻变成直接给结论。这就是“同事”和“工具”的区别。多加一条经验全局指令不要写太长否则模型会迷失重点。最好控制在 5 条以内而且是硬性规则比如“禁止说空话”“先给数据再给结论”。4. 实战三条工作流把 AI 变成生产力4.1 日常运营会议纪要到待办清单我身边很多运营朋友每天都在做“会议记录 - 整理纪要 - 拆待办 - 跟进进度”这种脏活。时间都花在整理格式上而不是思考事情本身。我的解决方法是做了一个“会议纪要转待办”的 Skill。流程是这样的先用语音转文字工具拿到会议原始文本。调用 WorkBuddy 的/meeting_to_todo技能输入原始文本。技能内部会先提取“决策、结论、负责人、截止时间”再按一个模板输出待办清单。技能模板的核心部分如下你是团队协作助手。从会议记录中提取以下内容 - 决策用一句话概括团队做出哪些决定。 - 待办事项每项待办必须包含任务描述、负责人、截止日期。 - 风险会议中提到的潜在问题。 会议记录 {{input}} 输出为Markdown表格负责人为空时写“未指定”。这个技能我用下来最大的价值不是省时间而是逼着所有会议都按同一套标准输出。以前每个人写的会议纪要风格完全不同现在 AI 统一格式化后续找信息特别方便。4.2 技术开发让 WorkBuddy 和 CodeBuddy 搭档做开发的人会关心 WorkBuddy 能不能写代码。我的意见是它不是用来替代你写代码的编辑器它更适合做“需求拆解、方案设计、测试代码生成”这种偏规划和辅助的工作。真正落到代码生成和编辑器补全可以搭档 CodeBuddy 这类工具一起用。我目前的开发流是这样接到一个需求后先用 WorkBuddy 的“需求拆解”技能把需求转成功能清单和边界条件。让 WorkBuddy 生成设计文档包括模块划分、数据流、接口定义。把设计文档交给 CodeBuddy 做代码实现让它按接口生成初版。最后我人工 review再让 WorkBuddy 根据代码写单元测试。举个例子我之前写过一个 Verilog 模块需求是“实现一个 FIFO支持同步读写带满空标志”。我先把需求发给 WorkBuddy它生成了接口说明和测试计划然后我让 CodeBuddy 补 RTL 代码并用 WorkBuddy 生成了一段简单的 testbench 代码。module fifo #( parameter DATA_WIDTH 8, parameter DEPTH 16 ) ( input wire clk, input wire rst_n, input wire wr_en, input wire [DATA_WIDTH-1:0] wr_data, input wire rd_en, output wire [DATA_WIDTH-1:0] rd_data, output wire full, output wire empty ); // RTL implementation here endmodule这段代码虽然是 AI 补全的但我会明确告诉它只写逻辑骨架不写具体实现细节避免它“自由发挥”导致方向错误。核心经验是AI 写代码时上下文里的约束比模型大小更影响结果。你把接口定义写清楚它生成的东西才会接近你的预期。4.3 内容创作从灵感标题到成稿内容创作是 WorkBuddy 用得最爽的场景之一。我自己写公众号和技术博客以前从选题到成稿最怕的就是面对空白文档发呆。现在我会建两个技能“选题库扩充”和“文章起草”。“选题库扩充”技能输入一个关键词输出 10 个选题方向每个方向附带目标读者、切入角度、预估价值。这个 Skill 的模板里我会强调“不要给通用建议要给出具体差异化的角度”。“文章起草”技能更进一步输入大纲标题它会按照“场景引入 - 问题拆解 - 操作步骤 - 避坑经验”的结构输出初稿。注意我坚决不要求它直接生成终稿因为 AI 生成的“完美文章”往往缺乏个人风格。它的价值是给我提供一份有结构的草稿我再加入自己踩过的坑和实际数据最后成稿速度至少快一半。5. 进阶玩法本地部署和 Agent 编排5.1 本地部署到底图什么有些人问为什么要本地部署直接连云端 API 不是更方便吗本地部署的核心诉求主要是三条数据隐私、调用成本、离线可用。比如你要处理的内部文档不能出内网就不可能把所有内容发给外部 API。这时候可以在本地装 Ollama拉一个开源模型然后在 WorkBuddy 里把模型地址改成http://localhost:11434所有推理都在本机跑。我实测过用 7B 级别的模型处理文档摘要、标题生成这类任务速度还行但跑复杂 Agent 编排时小模型经常思维链断掉表现明显不如云端大模型。所以我现在的建议是“混合调用”敏感数据走本地小模型复杂推理走云端 API。WorkBuddy 支持按 Skill 指定不同模型这一点非常实用。配置大概长这样# ~/workbuddy/config/model.yaml provider: ollama base_url: http://localhost:11434 model: qwen2.5:7b5.2 Agent 编排把多个 Skill 串成一条流水线当你积累了足够多的 Skill 之后下一步就是把它们串成 Agent。WorkBuddy 的 Agent 机制也很直白通过一个 YAML 文件定义“一步步做什么”。我举一个实际的例子做竞品分析报告。过去我需要手动搜索竞品信息、整理功能列表、分析差异、输出报告。现在我把四个 Skill 串成一个 Agent# ~/workbuddy/agents/competitor_analysis.yaml name: competitor_analysis steps: - skill: web_search params: query: {{input}} 竞品 功能 动态 - skill: extract_info params: source: {{steps.web_search.output}} - skill: compare_features params: feature_list: {{steps.extract_info.output}} - skill: generate_report params: diff_data: {{steps.compare_features.output}}实际跑起来时你只需要输入一个产品名这个 Agent 会自动执行检索、信息提取、功能对比、报告生成四个步骤最后生成一份结构化的竞品报告。这就是把 AI 从“会聊天”变成“会干活”的直观体现。5.3 和外部系统打通WorkBuddy 支持通过 API 或 Webhook 方式接入你自己的系统。比如你可以写一个脚本当收到邮件时自动调用 WorkBuddy 的接口让 AI 生成回复草稿或者把工单系统的新工单抓取过来先做一次优先级分类。这里有一个安全提醒凡是涉及密钥、Token、数据库连接串的信息一定要通过环境变量传入不要让 Skill 文件里出现真实凭证。另外Agent 调用外部 API 时我建议在中间加一层人工确认尤其是涉及发送邮件、修改数据这类写操作。AI 的逻辑再完善也值得你最后看一眼。6. 常见问题与排查技巧实录6.1 技能不生效怎么办这是新手问得最多的问题。我自己的排查顺序通常是这样的先检查技能目录路径。WorkBuddy 默认只会加载~/workbuddy/skills/下的一级目录每个目录里必须有skill.md文件。检查skill.md里的name字段和调用名称是否一致。比如文件名是log-analyze调用时就要用/log-analyze中间不能有多余空格。看终端日志。WorkBuddy 启动时会打印加载了哪些 Skill如果加载失败会带具体报错一般是 YAML 语法错误或者模板文件缺失。6.2 模型输出不稳定、格式总变如果你发现同一个 Skill 每次输出结构都不一样大概率是温度参数太高或者模板里的约束不够强。建议先把temperature调到 0.2 以下同时在模板最后加一句“严格按上述格式输出不要输出额外内容”。另外一个常见问题是上下文太长导致模型“忘记”格式要求。解决办法是尽量把输入内容截断处理或者让 Skill 先做一步“输入清洗”提取关键部分再交给后续流程。6.3 网络依赖和安装失败安装时很多人遇到“下载依赖失败”或“请求外部模型超时”。这个问题通常出在目标服务器不可达。我只建议一个稳妥做法为下载源配置国内镜像。比如官方提供的下载地址如果很慢可以换成镜像地址或者用已经打包好的桌面客户端安装包。涉及外部模型 API 时检查一下 Base URL 是否填对API Key 是否带了多余空格。6.4 本地部署时显存不足如果你本地跑模型遇到显存不足最简单的处理是换用量化版本模型比如qwen2.5:7b-instruct-q4_K_M。其次可以降低输入长度限制或者把模型部署到远程服务器上WorkBuddy 只要支持远程 HTTP 地址就行不一定非得本机。最后分享一点个人经验WorkBuddy 这类工具的价值不在于它本身的 AI 能力有多强而在于你愿不愿意花时间给它写“说明书”。我自己花了两个周末把日报、周报、竞品分析、开发需求拆解等流程做成 Skill之后日常工作里的重复劳动减少了一大半。建议新手在创建第一个 Skill 时一定要手动给一两个示例输出这个动作能让 AI 的稳定性提高很多。哪怕只是一个“会议纪要转待办”这种小技能用上一个月你也会明显感觉到 AI 从一个偶尔灵光的聊天工具变成了真正能托付任务的同事。
