1. 为什么 WorkBuddy 的 Skill 体系值得认真对待WorkBuddy 这类工具刚出来的时候很多人把它当成一个“能聊天的命令行助手”装完就搁那儿了。我一开始也这么想直到有次赶一个 Spring Boot 项目的接口联调顺手让它帮我跑了一遍测试用例生成才发现这东西真正的价值不在“对话”而在Skill——也就是把重复性的、有固定套路的操作封装成可复用的能力单元。Skill 和 Agent 的区别用一句话说清楚Agent 是“帮你决定做什么”Skill 是“帮你把某件事按标准做完”。Agent 负责编排和决策Skill 负责执行和质量兜底。你如果只把 WorkBuddy 当 Agent 用那它就是个聪明点的搜索框但你把 Skill 配好了它才真正变成一个能嵌入你日常工作流的效率工具。这篇文章我打算聊十个我自己实际落地过、并且确实带来效率提升的 Skill 方向。覆盖的范围包括 Spring Boot 后端开发、MCP 协议对接、TDD 工作流、代码审查、文档生成这些场景。每个 Skill 我都会说清楚它解决什么问题、怎么配、踩过什么坑。不管你是刚装完 WorkBuddy 的新手还是已经在用但觉得“好像没发挥出全部实力”的老用户应该都能找到能直接抄作业的部分。提示Skill 的配置方式在不同版本里可能有差异我下面写的以我手头这个版本为准你实际操作时如果发现菜单项对不上先确认版本号。2. 先搞清楚 Skill 的加载机制和配置逻辑2.1 Skill 到底是什么它和普通指令的区别在哪很多人第一次接触 WorkBuddy Skill 的时候会把它和“自定义指令”搞混。自定义指令是你每次对话都要手动输入的一段 prompt而 Skill 是一个持久化的、有触发条件的、可以带外部依赖的能力包。打个比方自定义指令像是你每次做菜前口头告诉厨师“少放盐、多放辣”Skill 则是你直接给厨师一本写好的菜谱他照着做就行而且这本菜谱还能调用厨房里的各种设备。一个标准的 Skill 通常包含这几个部分触发描述什么情况下应该激活这个 SkillWorkBuddy 会根据你的输入自动匹配执行逻辑具体要做什么可以是 prompt 模板也可以是对外部工具的调用依赖声明需要哪些 MCP Server、哪些本地命令、哪些环境变量输出规范结果以什么格式返回是纯文本、JSON 还是直接写文件我实测下来Skill 的触发准确率跟“触发描述”写得好不好关系极大。你写得越具体误触发的概率越低。比如你写“处理代码”那它可能在你只是想聊聊代码的时候也触发你写“对 Spring Boot Controller 层代码进行 RESTful 规范检查并输出修改建议”那就精准得多。2.2 MCP 在 Skill 体系里扮演什么角色MCP 是 Model Context Protocol 的缩写你可以把它理解成 WorkBuddy 和外部世界之间的“标准插座”。没有 MCP 的时候Skill 只能做纯文本处理有了 MCPSkill 就能去读你的数据库、调你的接口、操作你的 Figma 文件、甚至控制 Blender。我目前用得比较多的 MCP Server 有这么几类MCP Server 类型典型用途在 Skill 中的角色文件系统类读写本地项目文件让 Skill 能直接改代码而不是只给建议数据库类查询表结构、执行 SQL生成实体类时自动对齐字段设计工具类读取 Figma 设计稿从设计稿生成前端代码骨架浏览器类页面截图、元素定位配合 Playwright 做端到端测试项目管理类读取任务状态自动更新工时和进度蓝湖 MCP 和 Figma MCP 是我在 UI 还原场景里用得最多的两个。蓝湖 MCP 的好处是它能直接拿到标注信息间距、字号、色值都是结构化的Skill 拿到这些数据之后生成的前端代码准确率比“看着截图猜”高出一个量级。2.3 配置 Skill 之前必须做的三件准备工作在开始配 Skill 之前有三件事我建议你先做完不然配到一半会卡住第一确认你的 WorkBuddy 版本支持 Skill 功能。早期版本只有基础的对话能力Skill 是后来才加进去的。你可以在设置里找“Skill”或者“能力”相关的入口如果没有先去更新。第二把常用的 MCP Server 先配好并测试连通。MCP 的配置通常是一个 JSON 文件里面写清楚 server 的启动命令和参数。我踩过的坑是配置文件写好了但 server 没启动Skill 调用的时候报错信息很模糊排查了半天才发现是进程没起来。第三给你的项目建一个清晰的目录结构。Skill 在执行文件操作的时候如果项目结构混乱它很容易改错文件。我一般会在项目根目录放一个.workbuddy文件夹里面放 Skill 的配置和上下文说明这样 WorkBuddy 一进项目就能知道这是什么类型的工程。{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /path/to/your/project] }, database: { command: npx, args: [-y, modelcontextprotocol/server-sqlite, /path/to/your.db] } } }上面这个配置是最基础的文件系统和数据库 MCP你可以根据自己的技术栈替换成对应的 Server。配完之后记得重启 WorkBuddy然后在对话里让它列一下可用的 MCP 工具确认连通。3. 十个真正能落地的 Skill 方向拆解3.1 Spring Boot 接口代码生成 Skill这个是我用得最频繁的一个。日常开发里写一个标准的 CRUD 接口其实没什么技术含量但就是费时间。一个 Controller、一个 Service、一个 Repository、再加上 DTO 和 Entity 的转换手写的话少说二十分钟。我的做法是配一个 Skill触发条件是“根据以下表结构生成 Spring Boot 接口”。Skill 内部会做这几件事读取我提供的建表 SQL 或者直接通过数据库 MCP 读取表结构生成 Entity 类字段类型自动映射比如varchar转Stringdatetime转LocalDateTime生成 Repository 接口继承JpaRepository生成 Service 层包含基本的增删改查方法生成 Controller 层带上标准的 RESTful 注解和参数校验最后跑一遍编译确认没有语法错误这里有个细节值得说字段类型映射我一开始是让 Skill 自己判断的后来发现它有时候会把decimal映射成Double这在金额场景下是致命的。后来我改成在 Skill 的配置里写死一张映射表让它严格按照我的规则来。// Skill 生成的 Controller 示例 RestController RequestMapping(/api/users) RequiredArgsConstructor public class UserController { private final UserService userService; GetMapping public ResponseEntityPageUserDTO list( RequestParam(defaultValue 0) int page, RequestParam(defaultValue 20) int size) { return ResponseEntity.ok(userService.list(page, size)); } PostMapping public ResponseEntityUserDTO create(Valid RequestBody CreateUserRequest request) { return ResponseEntity.status(HttpStatus.CREATED) .body(userService.create(request)); } }注意生成的代码一定要过一遍你的代码规范检查。我遇到过 Skill 生成的代码用了Autowired字段注入而不是构造器注入虽然能跑但跟团队规范不一致。3.2 TDD 工作流 SkillTDD 这个东西道理大家都懂但真正坚持下来的人不多。原因很简单先写测试再写实现心理上会觉得“慢”。但如果把 TDD 的流程固化成一个 Skill让 WorkBuddy 来推动你走完红绿重构三步事情就变得容易多了。我的 TDD Skill 是这样设计的红阶段我描述一个功能点Skill 生成对应的测试用例并确认测试是失败的绿阶段Skill 生成能让测试通过的最简实现重构阶段Skill 检查代码坏味道提出重构建议并执行关键点在于Skill 必须能真正运行测试并读取结果。这就需要 MCP 能执行本地命令。我配的是文件系统 MCP 加上一个自定义的命令执行 MCP让 Skill 能跑mvn test或者gradle test。实测下来TDD Skill 最大的价值不是“帮你写测试”而是强制你保持小步前进的节奏。人是有惰性的很容易一口气写一大堆代码然后再补测试但 Skill 会卡在红阶段不让你往下走这个约束反而提升了代码质量。3.3 代码审查 Skill代码审查这件事人工做当然更好但问题是没人有那么多时间。我的做法是配一个 Skill 做“第一轮筛查”把明显的问题先过滤掉人工只需要看 Skill 标记出来的重点区域。这个 Skill 的检查项我列一下命名规范类名是否大驼峰、方法名是否小驼峰、常量是否全大写下划线异常处理有没有吞异常、有没有用异常控制流程日志规范关键路径有没有打日志、日志级别是否合理空指针风险Optional 的使用是否恰当、集合操作有没有判空SQL 注入风险MyBatis 的${}有没有被滥用事务边界Transactional的传播行为和回滚规则是否明确我一般会把这个 Skill 配成“在提交代码前自动触发”这样每次 commit 之前都会过一遍。虽然不能替代人工审查但至少能保证低级问题不会流到 review 环节。3.4 MCP 协议对接 SkillMCP 本身是一个协议但“怎么对接一个 MCP Server”这件事是有套路的。我配了一个 Skill 专门用来做 MCP 对接的脚手架生成。当你需要接入一个新的 MCP Server 时这个 Skill 会根据 Server 的类型生成对应的配置 JSON生成一个测试用例验证连通性生成一个简单的调用示例让你知道怎么在 Skill 里引用这个 MCP 的能力如果 Server 需要认证生成环境变量的配置模板这个 Skill 帮我省了很多查文档的时间。尤其是当你要同时对接多个 MCP Server 的时候配置文件的格式很容易写错有个 Skill 帮你生成就稳很多。3.5 从 Figma 或蓝湖设计稿生成前端代码 Skill这个 Skill 需要 Figma MCP 或者蓝湖 MCP 的支持。流程是这样的你提供设计稿的链接或者文件 IDSkill 通过 MCP 读取设计稿的结构化数据提取组件树、样式属性、间距信息生成对应的前端代码React、Vue 或者纯 HTMLCSS 都行生成一份样式变量表方便后续维护我实测下来这个 Skill 生成的代码大概能覆盖 70% 的还原度剩下的 30% 需要人工调整。主要差距在响应式布局和交互动效上静态样式还原得还不错。提示蓝湖 MCP 读取标注信息的时候如果设计稿图层命名混乱提取出来的数据也会很乱。建议先让设计师把图层命名规范一下能省很多事。3.6 数据库迁移脚本生成 Skill每次迭代只要有表结构变更就得写迁移脚本。这个 Skill 的逻辑是对比当前数据库结构和目标结构自动生成ALTER TABLE语句。我一般会这样用先把新的建表 SQL 写好然后让 Skill 对比现有数据库生成差异化的迁移脚本。Skill 会处理这些细节新增字段时判断是否需要默认值修改字段类型时检查是否有数据丢失风险删除字段时生成备份语句索引变更单独列出这个 Skill 帮我避免过好几次“直接改表导致线上事故”的情况因为它会强制我走“生成脚本→审查→执行”的流程。3.7 日志分析与问题定位 SkillSpring Boot 项目的日志文件动辄几百兆用grep查虽然也行但效率不高。我配了一个 Skill专门用来做日志分析。触发方式很简单把日志文件路径给它然后描述你要找什么。比如“找出所有 NullPointerException 的堆栈并统计出现频率最高的前三个位置”。Skill 会做这几件事读取日志文件按时间窗口切分提取异常堆栈做聚合统计关联请求 ID还原完整的调用链路输出一份简明的分析报告这个 Skill 在排查线上问题的时候特别有用。以前可能要花半小时翻日志现在几分钟就能定位到关键行。3.8 单元测试覆盖率提升 Skill这个 Skill 的目标很明确找出覆盖率低的类生成补充测试用例。它会先跑一遍覆盖率工具JaCoCo 或者 Cobertura拿到报告然后找出覆盖率低于阈值的类和方法分析哪些分支没有被覆盖生成对应的测试用例再次运行覆盖率确认提升效果我一般会把这个 Skill 配成“每周跑一次”作为技术债清理的一部分。坚持了几个月之后项目的整体覆盖率从 40% 出头提到了 75% 左右。3.9 文档生成 Skill这个 Skill 解决的是“代码写了但没人写文档”的问题。它会扫描项目中的 Controller 和 Service提取接口签名、参数说明、返回值结构然后生成 Markdown 格式的 API 文档。我还会让它额外做一件事把文档和实际的接口测试结果做对比如果发现文档和实现不一致就标记出来。这个功能帮我发现过好几个“代码改了但文档没更新”的接口。3.10 工时统计与进度跟踪 Skill最后一个 Skill 偏向项目管理。它会通过 MCP 读取任务管理工具里的任务状态结合 Git 提交记录自动生成工时统计和进度报告。我一般会在每天结束的时候跑一下这个 Skill它会告诉我今天完成了哪些任务每个任务花了多少时间根据提交记录估算哪些任务卡住了明天的建议优先级这个 Skill 的价值在于“让进度可视化”。以前写周报要回忆半天现在直接让 Skill 生成初稿我改改就行。4. 实操从零配一个 Spring Boot 代码生成 Skill4.1 环境准备与依赖安装我以 Spring Boot 代码生成 Skill 为例完整走一遍配置流程。首先确认你的环境里有这些WorkBuddy 最新版支持 Skill 和 MCPJDK 17 或以上Maven 或 Gradle一个可用的 Spring Boot 项目或者空目录也行然后配置 MCP Server。我需要的 MCP 能力有两个文件系统读写和命令执行。文件系统 MCP 用官方的就行命令执行我用的是一个社区维护的 shell MCP。{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ${workspaceFolder}] }, shell: { command: npx, args: [-y, modelcontextprotocol/server-shell] } } }配好之后重启 WorkBuddy在对话里输入“列出当前可用的 MCP 工具”确认两个 Server 都正常加载。4.2 Skill 配置文件的编写Skill 的配置文件我一般放在项目根目录的.workbuddy/skills/下面一个 Skill 一个文件。Spring Boot 代码生成 Skill 的配置大概长这样name: spring-boot-codegen description: 根据数据库表结构生成 Spring Boot 的 Entity、Repository、Service 和 Controller 代码 trigger: - 根据表结构生成接口 - 生成 Spring Boot CRUD 代码 - 从 SQL 生成 Java 代码 dependencies: mcp: - filesystem - shell commands: - mvn - java output: format: files path: src/main/java/${packagePath}触发描述我写了三条覆盖不同的表达习惯。你写的时候可以根据自己的常用说法来调整。4.3 核心逻辑的实现与调试Skill 的核心逻辑我写在同目录下的prompt.md里。内容大致是你是一个 Spring Boot 代码生成助手。用户会提供建表 SQL 或者表名。 请按以下步骤执行 1. 解析 SQL提取表名、字段名、字段类型、约束条件 2. 将数据库类型映射为 Java 类型 - varchar/char/text - String - int/bigint - Integer/Long - decimal - BigDecimal - datetime/timestamp - LocalDateTime - boolean/tinyint(1) - Boolean 3. 生成 Entity 类使用 JPA 注解 4. 生成 Repository 接口 5. 生成 Service 类包含基本的 CRUD 方法 6. 生成 Controller 类使用 RESTful 风格 7. 将生成的文件写入对应的包路径下 8. 运行 mvn compile 验证编译通过 注意事项 - 使用构造器注入不要用 Autowired 字段注入 - Controller 返回值统一用 ResponseEntity 包装 - 分页查询使用 Spring Data 的 Pageable写完之后在 WorkBuddy 里触发一次看看生成结果。我第一次跑的时候遇到了两个问题一是包路径没对上二是生成的 Entity 缺少Table注解。后来在 prompt 里补充了“包路径从项目配置中读取”和“Entity 必须带 Table 注解”这两条就正常了。4.4 效果验证与迭代优化验证 Skill 是否好用我一般看三个指标首次生成可用率生成的文件直接能编译通过的比例。我目前这个 Skill 大概在 85% 左右剩下的 15% 主要是复杂关联关系处理得不够好。时间节省手写一个完整 CRUD 大概 20 分钟Skill 生成加人工调整大概 5 分钟节省 75% 的时间。误触发率不该触发的时候触发了。这个跟触发描述写得好不好直接相关我调了两轮之后基本没再误触发过。迭代优化的方向主要是补充边界情况的处理。比如联合主键、自增主键、软删除字段这些我都是遇到一次就补一条规则进去。5. 常见问题与排查技巧实录5.1 Skill 不触发或者触发错误怎么办这是最常见的问题。排查思路按这个顺序来第一检查触发描述是否太宽泛。如果你写的是“处理代码”那几乎任何跟代码相关的输入都会触发。改成具体的动作描述比如“生成 Spring Boot 接口代码”。第二检查是否有多个 Skill 的触发条件重叠。如果两个 Skill 都匹配上了WorkBuddy 可能会选错。解决办法是在触发描述里加上更明确的限定词。第三检查 Skill 是否被禁用了。有时候更新版本之后Skill 的启用状态会被重置去设置里确认一下。5.2 MCP 连接失败怎么排查MCP 连接失败的表现通常是 Skill 执行到一半报错说某个工具不可用。排查步骤确认 MCP Server 的进程是否在运行。可以在终端里手动执行配置里的命令看看能不能启动。检查配置文件里的路径是否正确。尤其是文件系统 MCP路径写错了会直接导致连接失败。检查环境变量是否传递到了 MCP Server。有些 Server 需要 API Key 或者认证信息这些通常通过环境变量传入。看 WorkBuddy 的日志。日志里一般会有 MCP 连接的详细错误信息比界面上的提示有用得多。5.3 生成的代码不符合项目规范怎么调整这个问题我遇到过很多次。根本原因是 Skill 不知道你项目的规范是什么。解决办法有两个一是在 Skill 的 prompt 里显式写明规范。比如“使用构造器注入”、“Controller 统一返回 ResponseEntity”、“日志用 Slf4j 注解”。二是在项目里放一个规范文件让 Skill 读取。我一般会在.workbuddy/下面放一个conventions.md里面写清楚项目的编码规范然后在 Skill 的 prompt 里加一句“请先读取 conventions.md 并遵守其中的规范”。5.4 性能问题Skill 执行太慢怎么办Skill 执行慢通常是因为它做了太多不必要的操作。比如生成代码的时候它可能把整个项目都扫描了一遍。优化方向在 prompt 里限定扫描范围比如“只读取 src/main/java 下的文件”减少 MCP 调用次数能一次拿到的数据不要分多次拿如果 Skill 需要跑测试考虑只跑相关的测试类而不是全量测试我实测下来一个配置良好的 Skill 执行时间应该在 10 到 30 秒之间。如果超过一分钟大概率是有优化空间的。5.5 常见问题速查表问题现象可能原因解决方法Skill 不触发触发描述太宽泛或被禁用细化触发词检查启用状态MCP 连接失败Server 未启动或路径错误手动启动 Server检查配置路径生成代码编译不过类型映射错误或缺少注解补充映射规则和注解要求执行超时扫描范围过大限定文件范围减少 MCP 调用输出格式不对输出规范未配置在 Skill 配置中指定 format 和 path多个 Skill 冲突触发条件重叠增加限定词区分触发场景提示每次修改 Skill 配置之后建议先在一个小项目或者测试分支上验证确认没问题再应用到主项目。6. 我个人的一些使用体会配了这么多 Skill 之后我最大的感受是Skill 的价值不在于“自动化”而在于“标准化”。自动化只是手段真正的收益是让每一次操作都按照同样的标准执行减少人为的随机性。另一个体会是Skill 不是配得越多越好。我一开始配了二十多个结果触发混乱反而降低了效率。后来精简到十个左右每个都打磨得比较成熟整体效率才真正提上来。建议你先从最痛的一两个场景开始跑顺了再扩展。还有一点Skill 的配置是需要持续维护的。项目在变规范在变Skill 也得跟着更新。我一般每个月会花半小时回顾一下现有的 Skill看看有没有需要调整的地方。这个投入是值得的因为一个过时的 Skill 比没有 Skill 更糟糕。最后分享一个小技巧如果你不确定某个操作该不该做成 Skill就问自己一个问题——“这件事我一周要做几次”如果超过三次那就值得配一个 Skill。如果一个月才做一次那手动做就行了没必要为了自动化而自动化。
