这次我们来看 WorkBuddy 的 Skill 玩法。如果你看过不少资料一直没搞懂 Skill、工作台、Agent 这三者怎么串起来那这篇文章正好把链路补全。WorkBuddy 本身不只是一个聊天窗口它的核心价值在于把常用的 AI 工作流固化成 Skill然后用自然语言触发。换句话说Skill 就是一组“结构化的指令包 处理流程”写好以后可以反复调用不用每次都从头写提示词。网络上的 WorkBuddy 教程偏零散这次我把 Skill 的查找、安装、创建、使用和优化放在一篇文章里完整走一遍。先说判断如果你平时用 AI 做内容整理、报告生成、代码片段生成或者多步骤任务WorkBuddy 的 Skill 机制值得上手。它的门槛不在“模型多聪明”而在于你是否愿意花一点时间把重复流程变成一个可复用的 Skill。这篇文章会按顺序演示四件事去哪里找现成 Skill、怎么安装、怎么自己创建、怎么在实际任务里调参和优化。适合三类读者刚接触 WorkBuddy 的入门用户、想把重复工作流程固化下来的内容型用户以及想通过接口调用 Skill 做批量任务的技术用户。环境方面要提前说明WorkBuddy 多数场景是“客户端 模型服务”配合使用模型可能跑在本地也可能走云端。具体显存要求和依赖版本要看版本与所选模型不要因为教程里写“一键启动”就默认所有设备都能流畅运行。下面先从规格开始再讲安装和操作最后给排错清单和工程建议。1. 核心能力速览先看一张表格把 WorkBuddy 和 Skill 的关键信息一次性列出。表格里有些参数需要按实际安装版本确认原因后文会说明。能力项说明项目类型AI 工作台 / Agent 技能管理工具核心概念Skill即技能包把提示词、输入参数、处理流程、输出格式打包复用主要功能Skill 查找、安装、创建、使用、参数调整、复用与优化与 CodeBuddy 的关系社区常一起讨论WorkBuddy 偏工作流管理CodeBuddy 偏代码生成方向常见启动方式客户端一键启动或命令行启动具体以版本为准显存要求取决于接入的模型服务小模型显存门槛较低大模型需要更高显存支持平台Windows / macOS / Linux 常见国际版与国内版功能有差异需以官方渠道为准接口能力一般支持本地或远程调用接口路径与鉴权方式按实际版本确认批量任务可通过 Skill 脚本或外部调度触发推荐先单条验证再批量安全边界涉及人脸、声音、版权资料或个人数据时必须获得授权从表格能看出WorkBuddy 的核心不是某个特定模型而是把模型调用方式标准化。很多人第一次用 Skill 会误以为它是一个提示词模板实际上 Skill 比提示词模板更完整它可以包含触发词、输入字段、处理逻辑、输出格式和示例。这个设计让普通用户能够把一套“自己用着顺手的工作流”固定下来而不是每次打开对话框重新给模型解释任务背景。另一个值得注意的点是WorkBuddy 当前的资料里经常和 CodeBuddy 一起出现。社区讨论比较保守的说法是CodeBuddy 更偏向代码补全和工程任务WorkBuddy 更像一个通用工作台把写作、备课、科研、语言学习、内容生成等场景拆成一个个 Skill。如果你已经有 CodeBuddy 的编码习惯把 WorkBuddy 当作另一个组织任务的入口这样理解不会错得太远。2. 适用场景与使用边界2.1 适合谁WorkBuddy 的第一类用户是内容型用户。比如每周要写周报、做 PPT 大纲、拆解文档、整理读书笔记这些任务本质是“同一套流程 不同的输入材料”。把流程写进 Skill 后每次只需要换输入内容即可。第二类用户是教育科研用户。热词里能看到 AI 备课 Skill、科研 Skill、语言学习 Skill说明社区里已经有人把“备课流程”“文献阅读流程”“语言练习流程”封装成 Skill。这类用户不一定要会写代码只需要理解 Skill 里的字段含义就能通过社区包直接体验。第三类用户是工程型用户。他们不仅使用 Skill还会把 Skill 挂到命令行或外部程序中用脚本批量调用。比如把 Skill 当作一个数据处理节点传入一批文本输出结构化结果。这类用户需要重点看后文的接口与批量任务部分。2.2 不适合什么WorkBuddy 不适合那些“只想聊几句不想维护任何配置”的用户。如果只是偶尔让 AI 写一段文案直接打开对话框更省事没必要引入 Skill 的维护成本。它也不适合把 Skill 当成万能黑盒的情况。Skill 本质上还是把模型能力包装了一下不是新的推理引擎。如果底层模型不支持某类任务或者你的输入材料本身格式混乱Skill 只靠提示词优化也很难扭转结果。遇到这种情况先调整输入材料比不断改提示词更有效。2.3 使用边界和合规提醒无论 WorkBuddy 里的 Skill 来自官方还是社区都要注意几个底线第一不要直接使用未经授权的版权文本、图片、音视频素材去改造成自己的内容第二涉及真实人物肖像、声音或个人信息时必须获得明确授权第三Skill 本身如果来自第三方打开前先看内容不要盲目运行未知脚本尤其是带有可执行代码或外部请求的 Skill。另外WorkBuddy 的“国际版”和国内版可能存在服务差异。安装和下载尽量走官方渠道避免来路不明的整合包。这部分不属于模型能力问题而是使用边界问题建议养成先看来源、再看功能的使用习惯。3. 环境准备与前置条件3.1 基础环境检查开始安装和创建 Skill 之前先按清单过一遍本机环境。不需要每一项都满足但确认之后能少走很多弯路。检查项说明操作系统Windows 10/11、macOS、Linux 常见版本均可Win7 建议谨慎Python 环境如果使用脚本型 Skill建议 Python 3.9 以上Node.js 环境部分接口或插件可能需要按项目说明安装模型服务确认 WorkBuddy 连接的是云端模型还是本地模型GPU / CPU本地模型需要关注显存仅调用 API 则对 GPU 要求不高磁盘空间预留至少 10GB 到 20GB模型缓存会逐步占用空间网络状态下载模型或依赖时需要稳定网络不涉及任何代理工具端口占用常见端口如 7860、8000、3000 可能被占用启动前检查3.2 显存、缓存与端口如果你准备完全本地跑模型显存是第一个需要确认的指标。不要听别人说 4GB 显存能跑就盲目下大模型不同量化版本、不同上下文长度实际占用差别很大。更稳妥的做法是先用小参数测试再逐步增加输入长度和批量数量。WorkBuddy 系统本身也可能有缓存目录。热词里有人问“怎么更改系统缓存目录”这是因为模型或 Skill 运行时会产生缓存。如果系统盘空间紧张可以在设置里把缓存迁移到其他盘。具体迁移方式不同版本不一样通常是在配置文件或设置界面中找到缓存路径把它指向新目录然后重启客户端。端口问题同样容易被忽略。启动 WorkBuddy 服务时如果页面打不开先看端口是否被占用。可以用下面的命令检查某个端口是否被占用返回结果里有进程 PID 就说明端口被占用了。# 通用端口检查命令Windows 也可以用 netstat -ano | findstr 端口号 lsof -i :78604. 安装部署与一键启动4.1 安装方式选择WorkBuddy 的安装方式按版本不同有三种常见情况官方安装包、压缩包解压运行、命令行运行。官方安装包一般会提供图形化引导压缩包含一键启动脚本。命令行方式适合后续要接接口的工程型用户。安装完成后第一次启动通常会做两件事检查模型服务连接初始化 Skill 目录。建议启动时保持日志窗口可见因为很多错误信息只出现在控制台日志里不会直接弹到界面上。下面是一个通用的命令行启动示例。实际路径和参数需要替换成你本机安装目录下的真实值# 通用启动模板请按实际安装目录调整 cd /path/to/workbuddy python main.py --host 127.0.0.1 --port 7860如果你是小白用户优先使用官方安装包。双击启动、在设置里选择模型服务、确认 Skill 目录这个过程比命令行温和很多。但要注意即便界面是一键启动首次运行仍然需要下载依赖或模型文件等待时间取决于网络和磁盘速度。4.2 启动后的第一件事启动成功后不要急着安装 Skill。先做两个验证第一确认 WorkBuddy 能正常和模型服务通信。在输入框发一句最简单的测试内容比如“请回复连接正常”。这能快速判断问题是出在 WorkBuddy 本身还是模型服务。第二找到 Skill 管理页面或目录。常见情况下Skill 会以文件夹或文件形式存放在一个固定目录中。如果不确定目录位置可以在设置里查看“Skill 路径”或“技能目录”。把这个路径记下来后面的查找、安装、自建都围绕它进行。启动后如果页面打不开优先检查端口冲突和服务日志。如果日志里有“module not found”“connection refused”这类信息说明依赖没装好或模型服务没启动。先解决依赖再看功能不要在界面未正常打开的情况下强行安装 Skill。5. Skill 的查找、分类与安装5.1 去哪里找现成 SkillSkill 的获取渠道主要有四个官方市场、社区分享、网盘资源、自己创建的私密 Skill。官方市场质量相对稳定社区分享更新速度快网盘资源适合整包下载但来源需要自行判断。从热词内容看社区里已经有大量分类AI 备课 Skill、科研 Skill、语言学习 Skill、狗头军师 Skill、打斗动作提示词 Skill、像素动画 Skill 等。这些名字说明用户已经把 Skill 用到了教育和创作领域。比较稳妥的查找方式是先搜“WorkBuddy Skill 合集”“book to skill”“agent skill 教程”找到社区推荐的清单再按自己的场景筛选。5.2 Skill 的常见形态一个 Skill 往往不是单文件而是一个包含配置和脚本的小目录。常见形态包括形态说明纯提示词型只包含系统提示词和输出格式适合写作、翻译参数化配置型使用 YAML/JSON 定义输入字段和输出模板脚本型带 Python/JavaScript 脚本可执行数据处理工作流型组合多个步骤先解析输入再分步生成结果安装前先看这个 Skill 是哪种形态。纯提示词型可以手动复制到配置里脚本型需要额外维护依赖。很多人安装后觉得没用是因为选择了脚本型却漏装了依赖。5.3 安装流程安装 Skill 的通用流程是三步下载 Skill 文件放到 Skill 目录重启或刷新。以手动放置方式为例典型目录结构如下skills/ ├── weekly-report/ │ ├── skill.yaml │ ├── prompt.txt │ └── README.md ├── essay-outline/ │ ├── skill.yaml │ └── prompt.txt安装完成后在 WorkBuddy 里打开 Skill 列表应该能看到新增的名称和描述。如果看不到最常见原因是文件放置层级不对或者 YAML 格式写错。可以先打开配置文件用文本编辑器确认第一行的字段名是否和官方模板一致。如果 WorkBuddy 自带命令行工具也可以用命令行方式安装# 通用安装命令模板具体命令以 WorkBuddy 版本为准 workbuddy skill install ./weekly-report.zip执行后查看反馈信息。成功时会有安装完成提示失败时会打印路径或解析错误。如果命令不存在说明这个版本没有提供对应 CLI回到手动放置即可。6. 创建自定义 Skill从零到可用6.1 确定一个最小场景创建 Skill 的第一步不是写提示词而是确定一件“你反复做但还没固化”的事。拿写周报举例你每周都要把工作内容整理成五段式周报。这个任务有明确的输入、处理流程和输出格式非常适合做成 Skill。输入可以写为“本周工作流水”处理流程是“先分类再提炼成果最后突出问题”输出格式是“五段式周报”。弄清楚这三件事再打开 Skill 配置编辑器。6.2 Skill 配置字段不管 WorkBuddy 界面长什么样Skill 里通常会有这些字段字段作用nameSkill 名称用于识别和触发description描述适用场景帮助系统判断何时调用inputs定义输入参数例如标题、文本、文件路径prompt核心提示词模板可以包含变量占位符output_format固定输出结构例如 Markdown、JSONexample给出一组输入输出示例方便模型理解version版本号方便后续更新和回滚以周报 Skill 为例可以写成下面的简化配置。注意不同版本可能会修改字段名这里只是通用模板实际需要对照 WorkBuddy 的官方样例调整。name: weekly-report description: 把本周工作流水整理成结构化周报 inputs: raw_text: type: string description: 本周工作流水用逗号或换行分隔 prompt: | 你是项目管理助理请将下面的工作流水整理成周报。 周报包含四个部分本周完成、数据变化、遇到问题、下周计划。 不要补充输入中没有提到的内容。 输入内容 {{ raw_text }} output_format: | ## 本周完成 ## 数据变化 ## 遇到问题 ## 下周计划 example: raw_text: 完成首页改版注册转化提升1.2%发现接口超时问题实际运行时WorkBuddy 会把{{ raw_text }}替换成你输入的内容。这种“变量占位 固定格式”的设计是 Skill 比普通提示词更可控的核心原因。6.3 创建后先测试Skill 创建完成不代表能用。第一轮先给最简输入比如只给一句话。目的是验证配置能被解析、变量能正确替换、输出结构是否稳定。如果第一轮就输入一整篇长文出了问题很难判断是配置问题还是内容问题。测试时可以重点看几个位置Skill 列表里有没有出现新名称选择该 Skill 后输入框是否显示需要填写的参数生成结果是否遵循output_format。只要这三条都通过就说明 Skill 的最小闭环已经打通。7. Skill 的使用、调试与效果验证7.1 使用 Skill 的标准流程WorkBuddy 里使用 Skill 通常有两条路径手动选择和自然语言触发。手动选择适合调试自然语言触发适合日常使用。比如创建了“测试用例生成”Skill就可以直接输入“用测试用例生成 Skill 处理下面这段需求”让系统自己匹配。对于新手建议先手动选择再输入参数。这样做的好处是能清楚地看到每个字段如何影响结果。技能调通之后再切换到自然语言触发。7.2 验证功能是否达标判断一个 Skill 好不好用看三个维度稳定性、可控性、效率。稳定性指同样输入多次运行结果风格是否一致。如果同一条输入每次输出差别很大说明 prompt 约束不够需要补充输出格式或示例。可控性指参数是否真正生效比如“字数限制 500 字”能不能真的控制住长度。效率指完成一次任务需要多少轮交互理想情况是一轮生成最多两轮微调。7.3 常见失败原因Skill 输出质量不稳定的原因通常集中在三处第一prompt 太模糊。不要只写“帮我总结”要写清楚“按主题分类总结每条不超过 50 字”。第二没有给示例。模型的推理能力虽然强但在没有示例的情况下它对输出格式的理解仍然可能跑偏。第三输入参数和实际输入不一致。比如配置里用的变量名是raw_text但输入界面没有对应的输入框导致变量替换失败。遇到失败时先检查输入是否成功传入了 Skill再检查输出是否偏离格式最后才去改提示词。很多人一上来就改提示词反而把问题弄复杂。8. 接口 API、批量任务与运行观察8.1 把 Skill 暴露为接口工程型用户关心的是 WorkBuddy 能不能提供接口。从常见工作台设计来看Skill 一般会被封装为可调用的服务接口调用方式类似于 POST 请求。由于不同版本接口路径差异较大下面只给一个通用模板。实际路径需要在你本机日志或官方文档中确认。# 通用接口调用模板请按实际地址和端口替换 curl -X POST http://127.0.0.1:7860/api/skills/weekly-report/run \ -H Content-Type: application/json \ -d { raw_text: 完成首页改版注册转化提升1.2%发现接口超时问题 }接口返回通常包含生成结果和状态码。如果返回结构是 JSON可以用 Python 继续解析把结果写入数据库或文件。8.2 批量任务设计批量任务的关键是先确认单个请求能否稳定返回。不要在单条都没跑通的情况下直接循环 100 次否则错误信息会被淹没。批量处理时建议做好三件事输入文件按行或按 JSON 组织保证每条记录独立输出结果逐条写入文件避免程序中断导致全部丢失增加失败重试和日志同一个请求失败后等待几秒再试一次。import json import time import requests url http://127.0.0.1:7860/api/skills/summary/run # 每条输入独立成一行 with open(inputs.jsonl, r, encodingutf-8) as f: items [json.loads(line) for line in f if line.strip()] results [] for item in items: try: resp requests.post(url, jsonitem, timeout120) data resp.json() results.append({input: item, output: data}) time.sleep(1) # 防止请求过密 except Exception as e: results.append({input: item, error: str(e)}) with open(outputs.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)这个示例里的url和字段名是占位符实际运行时要按 WorkBuddy 的接口文档调整。批量任务出现超时或内存增长时先降低单批数量再看日志定位。8.3 运行观察与资源占用资源占用重点关注四个指标CPU 使用率、内存占用、显存占用和磁盘读写。使用任务管理器或系统监视器观察不要在 WorkBuddy 界面最小化后盲跑大批量任务。如果运行过程很卡优先降低一次处理的数量而不是升级硬件。对于本地模型上下文越长显存占用越高。如果显存吃紧可以尝试缩短输入文本、降低输出长度或使用量化版本模型。另外缓存目录也会影响性能。缓存塞满后可能拖慢启动速度建议定期清理无效缓存并把缓存目录放到剩余空间充足的磁盘。保持服务端和客户端版本一致也能减少很多莫名其妙的报错。9. 常见问题、性能优化与最佳实践9.1 高频问题排查下面这张表整理了 WorkBuddy 使用过程中的高频问题可以作为排查入口。问题现象可能原因排查方式解决方案页面打不开端口被占用或服务未启动查看日志和端口占用更换端口或重启服务Skill 列表里看不到新装技能目录层级不对 / YAML 解析失败检查配置文件和目录路径按官方模板重新放置输出格式不稳定缺少示例或 prompt 约束不足多次同输入测试补充输出格式和示例显存占用过高上下文太长、模型量化程度低观察任务管理器缩短输入、调低输出长度接口返回 404接口路径和文档不一致查看日志中的路由记录使用实际接口路径批量任务卡住单条请求超时或日志未记录检查单条超时时间和日志增加超时和失败重试启动很慢缓存目录空间不足检查磁盘剩余空间清理缓存或迁移缓存目录结果质量差底层模型能力不足 / 输入格式乱换模型或清洗输入先调整输入再改提示词排查顺序建议是先看日志再看网络/端口最后看 Skill 配置。不要把顺序反过来。9.2 性能优化建议性能优化不需要一开始就做先保证单条功能正确再谈优化。第一步给常用 Skill 设置最小参数。输出长度、生成步数、上下文窗口都先设成保守值跑通后再逐步放大。第二步把模型缓存和 Skill 缓存分开管理避免一个任务把目录写满。第三步批量任务使用有限队列。不要一次性把所有文件丢进队列先跑 5 条观察耗时再决定是否加大批量。如果在 CLI 里运行建议保留一份可复制的启动脚本并把它保存为.bat或.sh文件。这样每次启动不用重新输入命令也方便同事复现。9.3 工程化最佳实践这里给出几条比较实用的工程化习惯所有 Skill 使用版本号管理。改到第三版才发现问题的时候能快速回滚到第一版。输入、输出、临时文件分目录存放。比如inputs/、outputs/、temp/防止混乱。关键 Skill 保留 README 说明写清楚“这个 Skill 解决什么问题输入格式是什么”。接口服务只监听本机或内网地址不要直接暴露到公网。涉及真实用户数据时先在脱敏数据上验证再处理真实数据。发布或商用前做一次效果复核不要直接拿 AI 输出当最终成品。9.4 从 10 分钟学到长期使用标题说 10 分钟学会其实指的是“用最小步骤跑通一个 Skill 生命周期”。最快路径是找一个现成 Skill安装后用一个输入测试然后修改它的 prompt 和输出格式把它变成自己的版本。整个过程花的不是建模时间而是配置和测试时间。如果你是第一次接触 WorkBuddy建议从“周报 Skill”或“文章大纲 Skill”开始因为这两个任务输入输出清楚失败也容易定位。跑通后再尝试更复杂的科研、备课、语言学习 Skill那时候你对 Skill 的工作机制已经有了基本判断。更长期的做法是把自己手里重复两次以上的任务都列成清单挑其中一件做成 Skill。每周做一个一个月后你就会拥有一个小型个人工作流库。到这一步WorkBuddy 对你来说就不再是一个聊天工具而是一个真正被组装起来的 AI 工作台。