WorkBuddy Skill 实战：10 个高效开发场景与 MCP 配置指南

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 通常包含这几个部分：

• 触发描述：什么情况下应该激活这个 Skill，WorkBuddy 会根据你的输入自动匹配
• 执行逻辑：具体要做什么，可以是 prompt 模板，也可以是对外部工具的调用
• 依赖声明：需要哪些 MCP Server、哪些本地命令、哪些环境变量
• 输出规范：结果以什么格式返回，是纯文本、JSON 还是直接写文件

我实测下来，Skill 的触发准确率跟“触发描述”写得好不好关系极大。你写得越具体，误触发的概率越低。比如你写“处理代码”，那它可能在你只是想聊聊代码的时候也触发；你写“对 Spring Boot Controller 层代码进行 RESTful 规范检查并输出修改建议”，那就精准得多。

2.2 MCP 在 Skill 体系里扮演什么角色

MCP 是 Model Context Protocol 的缩写，你可以把它理解成 WorkBuddy 和外部世界之间的“标准插座”。没有 MCP 的时候，Skill 只能做纯文本处理；有了 MCP，Skill 就能去读你的数据库、调你的接口、操作你的 Figma 文件、甚至控制 Blender。

我目前用得比较多的 MCP Server 有这么几类：

蓝湖 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 内部会做这几件事：

1. 读取我提供的建表 SQL 或者直接通过数据库 MCP 读取表结构
2. 生成 Entity 类，字段类型自动映射（比如varchar转String，datetime转LocalDateTime）
3. 生成 Repository 接口，继承JpaRepository
4. 生成 Service 层，包含基本的增删改查方法
5. 生成 Controller 层，带上标准的 RESTful 注解和参数校验
6. 最后跑一遍编译，确认没有语法错误

这里有个细节值得说：字段类型映射我一开始是让 Skill 自己判断的，后来发现它有时候会把decimal映射成Double，这在金额场景下是致命的。后来我改成在 Skill 的配置里写死一张映射表，让它严格按照我的规则来。

// Skill 生成的 Controller 示例 @RestController @RequestMapping("/api/users") @RequiredArgsConstructor public class UserController { private final UserService userService; @GetMapping public ResponseEntity<Page<UserDTO>> list( @RequestParam(defaultValue = "0") int page, @RequestParam(defaultValue = "20") int size) { return ResponseEntity.ok(userService.list(page, size)); } @PostMapping public ResponseEntity<UserDTO> create(@Valid @RequestBody CreateUserRequest request) { return ResponseEntity.status(HttpStatus.CREATED) .body(userService.create(request)); } }

注意：生成的代码一定要过一遍你的代码规范检查。我遇到过 Skill 生成的代码用了@Autowired字段注入而不是构造器注入，虽然能跑，但跟团队规范不一致。

3.2 TDD 工作流 Skill

TDD 这个东西，道理大家都懂，但真正坚持下来的人不多。原因很简单：先写测试再写实现，心理上会觉得“慢”。但如果把 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 协议对接 Skill

MCP 本身是一个协议，但“怎么对接一个 MCP Server”这件事是有套路的。我配了一个 Skill 专门用来做 MCP 对接的脚手架生成。

当你需要接入一个新的 MCP Server 时，这个 Skill 会：

1. 根据 Server 的类型生成对应的配置 JSON
2. 生成一个测试用例，验证连通性
3. 生成一个简单的调用示例，让你知道怎么在 Skill 里引用这个 MCP 的能力
4. 如果 Server 需要认证，生成环境变量的配置模板

这个 Skill 帮我省了很多查文档的时间。尤其是当你要同时对接多个 MCP Server 的时候，配置文件的格式很容易写错，有个 Skill 帮你生成就稳很多。

3.5 从 Figma 或蓝湖设计稿生成前端代码 Skill

这个 Skill 需要 Figma MCP 或者蓝湖 MCP 的支持。流程是这样的：

1. 你提供设计稿的链接或者文件 ID
2. Skill 通过 MCP 读取设计稿的结构化数据
3. 提取组件树、样式属性、间距信息
4. 生成对应的前端代码（React、Vue 或者纯 HTML+CSS 都行）
5. 生成一份样式变量表，方便后续维护

我实测下来，这个 Skill 生成的代码大概能覆盖 70% 的还原度，剩下的 30% 需要人工调整。主要差距在响应式布局和交互动效上，静态样式还原得还不错。

提示：蓝湖 MCP 读取标注信息的时候，如果设计稿图层命名混乱，提取出来的数据也会很乱。建议先让设计师把图层命名规范一下，能省很多事。

3.6 数据库迁移脚本生成 Skill

每次迭代只要有表结构变更，就得写迁移脚本。这个 Skill 的逻辑是：对比当前数据库结构和目标结构，自动生成ALTER TABLE语句。

我一般会这样用：先把新的建表 SQL 写好，然后让 Skill 对比现有数据库，生成差异化的迁移脚本。Skill 会处理这些细节：

• 新增字段时判断是否需要默认值
• 修改字段类型时检查是否有数据丢失风险
• 删除字段时生成备份语句
• 索引变更单独列出

这个 Skill 帮我避免过好几次“直接改表导致线上事故”的情况，因为它会强制我走“生成脚本→审查→执行”的流程。

3.7 日志分析与问题定位 Skill

Spring Boot 项目的日志文件动辄几百兆，用grep查虽然也行，但效率不高。我配了一个 Skill，专门用来做日志分析。

触发方式很简单：把日志文件路径给它，然后描述你要找什么。比如“找出所有 NullPointerException 的堆栈，并统计出现频率最高的前三个位置”。

Skill 会做这几件事：

1. 读取日志文件，按时间窗口切分
2. 提取异常堆栈，做聚合统计
3. 关联请求 ID，还原完整的调用链路
4. 输出一份简明的分析报告

这个 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 代码生成 Skill

4.1 环境准备与依赖安装

我以 Spring Boot 代码生成 Skill 为例，完整走一遍配置流程。

首先确认你的环境里有这些：

• WorkBuddy 最新版（支持 Skill 和 MCP）
• JDK 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 执行到一半报错，说某个工具不可用。排查步骤：

1. 确认 MCP Server 的进程是否在运行。可以在终端里手动执行配置里的命令，看看能不能启动。
2. 检查配置文件里的路径是否正确。尤其是文件系统 MCP，路径写错了会直接导致连接失败。
3. 检查环境变量是否传递到了 MCP Server。有些 Server 需要 API Key 或者认证信息，这些通常通过环境变量传入。
4. 看 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 配置之后，建议先在一个小项目或者测试分支上验证，确认没问题再应用到主项目。

6. 我个人的一些使用体会

配了这么多 Skill 之后，我最大的感受是：Skill 的价值不在于“自动化”，而在于“标准化”。自动化只是手段，真正的收益是让每一次操作都按照同样的标准执行，减少人为的随机性。

另一个体会是，Skill 不是配得越多越好。我一开始配了二十多个，结果触发混乱，反而降低了效率。后来精简到十个左右，每个都打磨得比较成熟，整体效率才真正提上来。建议你先从最痛的一两个场景开始，跑顺了再扩展。

还有一点：Skill 的配置是需要持续维护的。项目在变，规范在变，Skill 也得跟着更新。我一般每个月会花半小时回顾一下现有的 Skill，看看有没有需要调整的地方。这个投入是值得的，因为一个过时的 Skill 比没有 Skill 更糟糕。

最后分享一个小技巧：如果你不确定某个操作该不该做成 Skill，就问自己一个问题——“这件事我一周要做几次？”如果超过三次，那就值得配一个 Skill。如果一个月才做一次，那手动做就行了，没必要为了自动化而自动化。