WorkBuddy 效率翻倍：10 个可复用技能实战指南-育师

1. 为什么“技能”才是 WorkBuddy 真正的效率杠杆

很多人第一次接触 WorkBuddy，注意力都放在“它能连什么模型”“支持哪些平台”“安装包多大”这些表层问题上。我一开始也这样，折腾了半天环境，结果真正用起来发现效率提升非常有限。后来才想明白一件事：WorkBuddy 这类工具的核心价值不在于它本身有多强，而在于你给它挂了多少可复用的技能（Skill）。技能才是把通用能力变成专属生产力的那个转换器。

打个比方，WorkBuddy 像一台刚出厂的工程车，底盘、发动机、液压系统都有了，但如果你不给它装上挖掘臂、破碎锤、抓斗这些属具，它就只能当一辆普通卡车用。Skill 就是这些属具。你装什么属具，它就干什么活。装十个属具，它就能在十个场景里替你干活。

那为什么是“10 个技能”而不是 20 个、50 个？因为技能这东西有个很现实的规律：前几个技能带来的效率提升最明显，越往后边际收益递减，而且维护成本递增。你挂 50 个技能，光是记住每个技能什么时候用、怎么触发、参数怎么填，就已经消耗掉你大量注意力了。我实测下来，10 个左右是一个比较舒服的平衡点——覆盖了日常 80% 的高频场景，又不至于让自己变成“技能管理员”。

这篇文章要聊的，就是我从大量实践中筛出来的、真正值得落地的 10 个技能方向。不是那种“看起来很酷但用两次就吃灰”的花架子，而是我几乎每天都在用的。每个技能我都会讲清楚：它解决什么问题、为什么这样设计、具体怎么配、实测中会遇到什么坑。你不需要全部照搬，挑三四个先跑起来，效率翻倍是很快能感受到的。

提示：Skill 的落地效果高度依赖你的实际工作流。同一个技能，在 A 的工作流里是神器，在 B 的工作流里可能完全用不上。所以下面每个技能，我都会先讲“适合谁”，你对照自己的情况判断。

2. 技能一：代码生成与补全的“上下文注入”技能

2.1 为什么裸用代码生成效果差

大部分人用 WorkBuddy 写代码的方式是：打开对话框，输入“帮我写一个 Spring Boot 的地址簿管理接口”，然后等结果。这样能用，但效果很一般。生成的代码经常缺字段、少校验、命名风格和你项目不一致，你还得手动改半天。

根本原因在于：模型不知道你的项目上下文。它不知道你用的是 Spring Boot 2.7 还是 3.2，不知道你的包名结构，不知道你团队用的是 Lombok 还是手写 getter/setter，不知道你的统一返回体长什么样。它只能按“最通用的写法”给你，而“最通用”往往意味着“最不贴合”。

2.2 上下文注入技能的设计思路

这个技能的核心就一件事：在触发代码生成之前，自动把项目关键上下文塞进提示词。具体来说，我让它做三件事：

读取项目根目录的pom.xml或build.gradle，提取 Spring Boot 版本、关键依赖（MyBatis-Plus、Lombok、Validation 等）
读取一个我维护的project-context.md文件，里面写清楚包名规范、返回体结构、异常处理约定、命名习惯
读取当前打开文件所在目录的相邻文件，推断出这个模块的代码风格

然后把这些信息拼成一段结构化的前缀，再附上我的具体需求。实测下来，生成代码的“一次通过率”从大概三成提升到了七成以上。

2.3 具体配置与触发方式

我用的触发词是@code，后面跟具体需求。技能内部的处理逻辑大致是这样：

name: context-aware-codegen trigger: "@code" steps: - read: "pom.xml" extract: ["spring-boot.version", "dependencies"] - read: "project-context.md" - read: "{{current_file_dir}}/*.java" limit: 3 - compose_prompt: template: | 项目上下文： - Spring Boot 版本：{{spring_boot_version}} - 关键依赖：{{dependencies}} - 代码规范：{{project_context}} - 相邻代码风格参考：{{adjacent_files}} 需求：{{user_input}}

这里有个细节值得说：相邻文件只读 3 个。读太多会撑爆上下文窗口，而且引入噪声。3 个足够让模型感知到风格了。

2.4 实测中的坑与调优

第一个坑是project-context.md容易写得太长。我一开始把整个团队的编码规范都贴进去了，结果模型反而抓不住重点。后来压缩到 200 字以内，只保留“包名格式、返回体字段、异常类名、日期格式”这四条最关键的，效果反而更好。

第二个坑是版本冲突。有次项目从 Spring Boot 2.7 升到 3.1，pom.xml读出来的版本变了，但project-context.md里还写着旧的javax.validation，导致生成的代码 import 错了包。后来我在技能里加了一步：如果检测到 Spring Boot 3.x，自动把javax.*替换成jakarta.*。这个小判断省了我不少事。

注意：这个技能对“新写一个接口”效果最好，对“修改现有复杂逻辑”帮助有限。改逻辑的时候，上下文注入反而可能干扰模型对原有逻辑的理解。我的做法是改逻辑时关掉这个技能，纯手动描述。

3. 技能二：TDD 循环驱动的“测试先行”技能

3.1 TDD 在 AI 辅助下的新玩法

TDD（测试驱动开发）这个概念不新鲜，红-绿-重构的循环大家都听过。但传统 TDD 有个现实问题：写测试本身就很耗时，很多人坚持不下来。而 WorkBuddy 这类工具恰好把“写测试”这件事的成本降到了极低，这就让 TDD 重新变得可行了。

我的做法是把这个循环做成一个技能：你说需求，它先写测试，你确认测试合理，它再写实现，最后跑测试验证。整个过程你只需要做两次判断：测试写得对不对、实现跑没跑通。

3.2 技能的三段式结构

这个技能我拆成三个触发词，对应 TDD 的三个阶段：

触发词	阶段	输入	输出
`@tdd-red`	写失败测试	需求描述	测试类 + 测试方法
`@tdd-green`	写最小实现	测试类路径	实现类
`@tdd-refactor`	重构	实现类路径	优化后的实现

@tdd-red的关键在于：要求模型只写测试，不写实现。我试过让它一次把测试和实现都写了，结果它经常“为了让测试通过而写实现”，测试就失去了独立性。分开之后，测试的质量明显更高。

3.3 一个完整的 TDD 实例

假设我要给地址簿加一个“按姓名模糊查询”的功能。我先触发@tdd-red，输入“地址簿按姓名模糊查询，返回匹配的联系人列表，空结果返回空列表”。

技能生成的测试大致是这样：

@Test void should_return_matching_contacts_when_search_by_name_fuzzy() { // given addressBookService.add(new Contact("张三", "13800000001")); addressBookService.add(new Contact("张四", "13800000002")); addressBookService.add(new Contact("李五", "13800000003")); // when List<Contact> result = addressBookService.searchByName("张"); // then assertThat(result).hasSize(2); assertThat(result).extracting(Contact::getName) .containsExactlyInAnyOrder("张三", "张四"); } @Test void should_return_empty_list_when_no_match() { List<Contact> result = addressBookService.searchByName("不存在"); assertThat(result).isEmpty(); }

我检查一遍，确认边界情况覆盖到了，然后触发@tdd-green，让它基于这个测试写实现。它生成的searchByName方法会去查数据库或内存列表，用like或contains匹配。跑一遍测试，绿了，收工。

3.4 为什么这个技能值得长期用

因为它改变的不只是速度，而是代码质量的下限。以前赶进度的时候，测试经常被跳过，结果就是上线后各种边界问题。现在写测试的成本几乎为零，你就没有理由不写了。我坚持用了两个月，项目里的回归 bug 数量肉眼可见地下降。

提示：@tdd-green生成的实现有时候会“过度设计”，比如为了通过一个简单测试引入复杂的策略模式。我的经验是，第一版实现越简单越好，重构留到@tdd-refactor阶段再做。

4. 技能三：MCP 协议对接的“外部工具桥接”技能

4.1 MCP 到底解决了什么问题

MCP（Model Context Protocol）这个词最近很热，但很多人没搞明白它到底干嘛的。用一句话说：MCP 让 WorkBuddy 能够调用外部工具和数据源，而不只是聊天。

没有 MCP 的时候，WorkBuddy 是个“只会说话的大脑”，它知道很多，但碰不到你的实际系统。有了 MCP，它就能去查你的数据库、调你的接口、读你的文件、操作你的浏览器。这才是“技能”从“建议”变成“执行”的关键一步。

4.2 我实际在用的三个 MCP 连接

我目前挂了三个 MCP Server，都是高频使用的：

数据库 MCP：让 WorkBuddy 能直接查开发库的表结构和数据。写 SQL 的时候不用再手动贴表结构了，它自己会去查。
接口调试 MCP：对接本地的接口测试工具，WorkBuddy 生成接口代码后可以直接发请求验证，不用我手动复制到 Postman。
文件系统 MCP：限定在项目目录内，让 WorkBuddy 能读写项目文件。这是代码生成技能的基础。

配置方式各平台略有差异，但核心都是填一个 Server 地址和认证信息。以数据库 MCP 为例，配置大概长这样：

{ "mcpServers": { "dev-database": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-mysql"], "env": { "MYSQL_HOST": "localhost", "MYSQL_PORT": "3306", "MYSQL_DATABASE": "address_book_dev", "MYSQL_READONLY": "true" } } } }

4.3 权限控制是重中之重

这里必须重点说：MCP 连接一定要做权限隔离。我见过有人直接把生产库的读写权限挂上去，这是非常危险的。我的原则是：

数据库 MCP 只连开发库，且设为只读
文件系统 MCP 限定在项目根目录，不允许访问上级目录
接口调试 MCP 只允许访问 localhost，不允许打外网

这些限制在配置里都能做。多花五分钟配置，能避免很多后悔事。

4.4 MCP 技能的进阶用法：组合调用

单个 MCP 是工具，多个 MCP 组合起来就是工作流。我有个技能叫@verify-api，它的逻辑是：先用文件系统 MCP 读取刚生成的 Controller 代码，提取出接口路径和参数，然后用接口调试 MCP 发一个真实请求，最后把响应结果和代码预期做对比。整个过程我只需要说一句“验证一下这个接口”。

这个技能帮我省掉了大量“生成代码→手动测试→发现参数不对→回去改”的来回。实测下来，接口联调的效率大概提升了三倍。

注意：MCP Server 的稳定性参差不齐。我遇到过某个 Server 在长时间运行后内存泄漏，导致 WorkBuddy 整体变卡。建议定期重启 MCP Server，或者用进程监控工具盯着。

5. 技能四：蓝湖 MCP 驱动的“设计稿转代码”技能

5.1 设计稿到代码的那段“脏活”

前端开发里最烦的活之一，就是把设计稿上的样式一点点翻译成 CSS。间距多少、圆角多少、字号多少、颜色值多少，全靠肉眼量。蓝湖这类工具虽然能标注，但你还是得手动抄。一个中等复杂度的页面，抄样式能抄一两个小时。

蓝湖 MCP 的出现改变了这个局面。它让 WorkBuddy 能直接读取蓝湖上的设计稿数据——图层结构、尺寸、颜色、字体，全都结构化地拿到。然后结合代码生成技能，直接输出组件代码。

5.2 我的“设计稿转代码”技能配置

这个技能我命名为@design2code，触发后它会：

通过蓝湖 MCP 拉取指定设计稿的图层树
过滤掉隐藏图层和辅助线
按图层层级生成对应的组件结构
把样式属性映射成 CSS 或 Tailwind 类名
输出一个可运行的组件文件

我用的映射规则是这样的：

设计稿属性	输出形式
固定宽高	`width: 120px; height: 40px`
颜色	优先用项目已有的 CSS 变量
字号字重	映射到项目的 typography scale
间距	映射到 4px 基准的 spacing scale
圆角	映射到预设的 radius 值

5.3 实测效果与人工介入点

说实话，这个技能做不到 100% 自动化。设计稿里有很多“设计意图”是数据表达不出来的，比如“这个按钮在移动端要变成全宽”“这个卡片在数据为空时要显示占位图”。这些还是得人工补。

但即便如此，它已经帮我省掉了 70% 的机械劳动。我的实际流程是：技能生成一版基础代码，我在此基础上调整交互逻辑和响应式规则。一个页面的开发时间从半天压缩到一两个小时。

5.4 一个容易忽略的细节：命名

设计稿里的图层命名往往很随意，什么“矩形 1”“编组 23”“Frame 456”。直接拿这些名字当组件名和类名，代码会很难维护。我在技能里加了一步：用 WorkBuddy 的语义理解能力，根据图层内容和位置重新生成有意义的命名。比如“矩形 1”在导航栏位置，就重命名为nav-item-bg。这一步让生成的代码可读性提升了一个档次。

6. 技能五：Spring Boot 项目脚手架的“一键生成”技能

6.1 为什么需要这个技能

每次开新项目，都要重复一遍：建目录、配pom.xml、写启动类、配application.yml、加统一返回体、加全局异常处理、加日志配置……这些活不难，但很烦，而且容易漏。漏了日志配置，上线后排查问题就抓瞎。

我把这套流程固化成了一个技能，触发词@scaffold，输入项目名和几个关键选项，它就把整个骨架搭好。

6.2 技能覆盖的脚手架内容

我定义的骨架包含这些部分：

基础依赖：Spring Boot Web、Validation、MyBatis-Plus、Lombok、Hutool
目录结构：controller / service / mapper / entity / dto / config / common
统一返回体：Result<T>包含 code、message、data 三个字段
全局异常处理：@RestControllerAdvice捕获业务异常和系统异常
日志配置：logback-spring.xml，按天滚动，保留 30 天
接口文档：集成 SpringDoc OpenAPI
基础测试：一个ApplicationTests确保上下文能加载

6.3 生成后的验证步骤

技能生成完不是就完事了，我会跑一个验证流程：

# 1. 编译 mvn clean compile # 2. 跑测试 mvn test # 3. 启动应用 mvn spring-boot:run # 4. 访问健康检查 curl http://localhost:8080/actuator/health

四步都过了，才算脚手架可用。这个验证流程我也做进了技能里，生成完自动跑，有问题直接报出来。

6.4 踩过的坑：版本兼容性

Spring Boot 3.x 和 2.x 的差异比想象中大。javax变jakarta、Spring Security 配置方式变了、SpringDoc 的依赖坐标也变了。我一开始的脚手架技能只按 2.x 生成，结果在 3.x 项目里各种报错。后来我在技能里加了版本判断分支，根据用户选的 Spring Boot 版本走不同的模板。这个改动之后，脚手架的一次成功率基本是 100%。

提示：脚手架技能不要追求“大而全”。我见过有人把消息队列、缓存、分布式锁全塞进去，结果新项目根本用不上，反而增加了理解成本。我的原则是：只放“每个项目都需要的”，可选的依赖让开发者自己加。

7. 技能六：日志分析与问题定位的“排错助手”技能

7.1 排错时最耗时的不是修，是找

线上出问题，日志一大堆，真正有用的那几行淹没在几万行输出里。传统做法是grep加肉眼扫，效率很低。尤其是分布式系统，一个请求跨好几个服务，日志散落在不同文件里，拼起来特别费劲。

我做了个技能叫@trace，输入一个 traceId 或关键词，它自动去各个日志文件里捞相关行，按时间排序，然后总结出“这个请求经历了什么、在哪一步出错、错误原因是什么”。

7.2 技能的处理链路

这个技能的逻辑分四步：

收集：根据输入的 traceId，在配置的日志目录下搜索所有匹配行
排序：按时间戳排序，还原请求的完整时间线
分析：识别出 ERROR 和 WARN 级别的行，提取异常堆栈
总结：用自然语言描述问题链路，指出最可能的出错点

第三步是关键。异常堆栈往往很长，模型容易抓不住重点。我的做法是：只把堆栈的前 5 行和Caused by那几行喂给模型，其余截断。这样它反而能更快定位到根因。

7.3 一个真实的排错案例

有次线上接口超时，日志里全是TimeoutException。我用@trace捞了一个请求的完整链路，发现它在调用某个下游服务时卡了 30 秒。继续往下看，下游服务的日志显示它在等一个数据库连接，连接池满了。再往下，发现有个慢查询没走索引，把连接占住了。

整个定位过程不到五分钟。如果手动翻日志，估计得半小时。这个技能的价值在“快”，而排错这件事，快就是一切。

7.4 配置上的注意事项

日志目录的路径要配准，而且要支持多个目录（比如多个服务的日志在不同路径）。我用的是一个配置文件：

log_sources: - name: order-service path: /var/log/order-service/*.log - name: user-service path: /var/log/user-service/*.log - name: gateway path: /var/log/gateway/*.log

另外，日志文件可能很大，全量读取不现实。我的做法是只读最近 24 小时修改过的文件，而且每个文件最多读最后 10000 行。这样既覆盖了近期问题，又不会把技能跑挂。

8. 技能七：代码审查的“规范检查”技能

8.1 人工 Code Review 的瓶颈

Code Review 很重要，但很耗人。一个中等规模的 PR，认真看下来得半小时。而且人看代码会疲劳，看到后面就容易漏。更麻烦的是，有些规范问题（比如命名、注释、日志级别）反复出现，每次都要提，提了还不一定改。

我把这部分“机械性审查”交给了技能。触发词@review，输入 PR 的 diff 或文件路径，它按我定义的规则清单逐条检查，输出问题列表。

8.2 审查规则清单

我的规则清单分三类：

必须修复（Blocker）

空指针风险：未做 null 判断的直接调用
资源泄漏：未关闭的流、连接
SQL 注入风险：字符串拼接 SQL
敏感信息硬编码：密码、密钥写在代码里

建议修复（Major）

命名不规范：方法名不是动词开头、类名不是名词
日志级别错误：业务异常用 error、系统异常用 warn
魔法数字：未提取成常量的数字
过长方法：超过 50 行的方法

可选优化（Minor）

注释缺失：公共方法没有 Javadoc
重复代码：相似度超过 80% 的代码块
未使用的 import

8.3 技能的输出格式

输出我要求结构化，方便直接贴到 PR 评论里：

## Code Review 结果 ### Blocker (2) - `UserService.java:45` 空指针风险：`user.getAddress().getCity()` 未判空 - `OrderMapper.xml:12` SQL 注入风险：`${orderId}` 应改为 `#{orderId}` ### Major (3) - `UserController.java:23` 方法名 `userList` 应为 `listUsers` - `OrderService.java:67` 日志级别：业务异常应使用 `warn` - `PaymentService.java:89` 魔法数字：`0.05` 应提取为 `TAX_RATE` ### Minor (1) - `UserService.java:12` 未使用的 import：`java.util.Date`

8.4 实测中的调优经验

第一个经验是：规则不能太多。我一开始列了 30 条规则，结果每次审查输出一大堆 Minor 问题，把 Blocker 淹没了。后来精简到 15 条，重点突出 Blocker 和 Major，实用性大增。

第二个经验是：误报要能标记。有些规则在特定场景下不适用，比如测试代码里的魔法数字是合理的。我在技能里加了个机制：如果文件路径包含test，自动跳过魔法数字检查。这种“上下文感知”的规则豁免，能减少很多无效告警。

注意：这个技能是辅助，不是替代。它查的是“规范”，查不了“逻辑正确性”。业务逻辑对不对，还是得人来判断。我的用法是：技能先跑一遍，把机械问题清掉，然后人专注看逻辑。

9. 技能八：文档生成的“代码即文档”技能

9.1 文档为什么总是滞后

几乎每个项目都有这个问题：代码更新了，文档没更新。过几个月，文档和代码对不上，新人看了反而被误导。根本原因是写文档和写代码是两件事，人天然倾向于只做一件。

我的思路是：让文档从代码里长出来。代码是唯一的事实来源，文档只是它的一个视图。代码变了，重新生成文档就行。

9.2 技能覆盖的文档类型

我做了三个子技能：

@doc-api：从 Controller 生成接口文档，包含路径、方法、参数、返回示例
@doc-db：从 Entity 和 Mapper 生成数据字典，包含表名、字段、类型、说明
@doc-readme：从项目结构和配置生成 README，包含启动方式、依赖说明、目录结构

9.3 接口文档的生成细节

@doc-api是我用得最多的。它会扫描所有@RestController类，提取@RequestMapping、@GetMapping等注解，结合方法的参数和返回类型，生成 Markdown 格式的接口文档。

关键是要从代码里提取出足够的信息。比如参数校验注解@NotBlank、@Size，要转成文档里的“必填”“长度限制”。返回体的泛型Result<UserVO>，要展开成具体的字段列表。

我生成的文档长这样：

### 查询用户详情 - **路径**: `GET /api/users/{id}` - **描述**: 根据用户 ID 查询用户详情 **请求参数** | 参数 | 位置 | 类型 | 必填 | 说明 | |------|------|------|------|------| | id | path | Long | 是 | 用户 ID，必须为正整数 | **响应示例** ```json { "code": 200, "message": "success", "data": { "id": 1, "name": "张三", "email": "zhangsan@example.com" } }

### 9.4 保持文档更新的机制 光生成一次没用，得让它持续更新。我的做法是把这个技能挂到 Git 的 pre-commit hook 上：每次提交前，如果检测到 Controller 或 Entity 有改动，自动重新生成对应文档，一起提交。这样文档永远和代码同步。 这个机制刚上的时候，团队里有人嫌它慢（每次提交多等几秒）。但用了两周后，大家都习惯了，因为再也不用回答“这个接口参数是什么”这种问题了。 ## 10. 技能九：定时任务与自动化的“签到与巡检”技能 ### 10.1 重复性工作的自动化 有些事每天都要做，但做起来毫无成就感：检查服务是否存活、拉取昨天的数据报表、清理临时文件、发送日报。这些事的特点是有固定流程、有明确判断标准、不需要创造力。这正是技能最擅长的。 我做了个 `@routine` 技能，把这类日常巡检和签到任务都收进去。触发后它按预设的清单逐项执行，输出一份巡检报告。 ### 10.2 巡检清单示例 我的巡检清单包含这些项： | 检查项 | 检查方式 | 异常处理 | |--------|----------|----------| | 服务健康 | 请求 `/actuator/health` | 失败则告警 | | 磁盘空间 | `df -h` 检查使用率 | 超过 80% 告警 | | 日志错误 | 统计最近 1 小时 ERROR 数量 | 超过 10 条告警 | | 数据库连接 | 执行 `SELECT 1` | 失败则告警 | | 定时任务状态 | 检查上次执行时间 | 超过预期间隔告警 | ### 10.3 自动签到的实现 “自动签到”这个词听起来有点灰色，但在合法合规的范围内，它其实就是“定时执行某个固定操作”。比如每天定时提交工作日志、定时同步数据、定时触发构建。这些操作本身是正当的，只是重复。 我的做法是用技能封装一个 HTTP 请求，带上必要的认证信息，定时触发。关键是要**把认证信息放在安全的地方**，不能硬编码在技能配置里。我用的是环境变量加本地加密存储，技能运行时动态读取。 ### 10.4 巡检报告的输出 巡检完输出一份 Markdown 报告，我让它直接发到团队频道。报告格式： ```markdown ## 每日巡检报告 - 2024-01-15 ### 正常项 (4) - 服务健康：OK - 数据库连接：OK - 磁盘空间：45% - 定时任务：正常 ### 异常项 (1) - 日志错误：最近 1 小时有 15 条 ERROR，超过阈值 - 主要错误：`ConnectionTimeoutException` (12 条) - 建议：检查下游服务连接池配置

这份报告每天早上九点自动发出来，我扫一眼就知道系统状态。有异常就点进去看，没异常就继续干别的。

提示：自动化巡检的阈值要定期调整。系统刚上线时错误少，阈值可以设低；业务增长后错误基数变大，阈值要相应放宽。我每季度 review 一次阈值，避免告警疲劳。

11. 技能十：知识沉淀的“经验捕获”技能

11.1 最容易被忽略的技能

前面九个技能都是“干活”的，这第十个是“记录”的。听起来不那么酷，但我觉得它是最重要的一个。因为你解决过的问题，如果不记下来，下次遇到还得重新解决一遍。

我做过统计，一个开发者在一年里遇到的问题，大概有 60% 是之前遇到过的。如果每次都能快速找到上次的解决方案，效率提升是巨大的。但现实是，解决方案散落在聊天记录、邮件、脑子里，找起来很费劲。

11.2 技能的工作方式

这个技能叫@capture，它的逻辑是：在每次排错或解决一个非平凡问题后，自动生成一条结构化的经验记录。

记录包含这些字段：

问题现象：一句话描述症状
触发条件：什么情况下会出现
根因：根本原因是什么
解决方案：怎么修的
验证方式：怎么确认修好了
相关文件：涉及哪些代码文件
标签：用于检索的关键词

11.3 经验库的检索

记录只是第一步，能用起来才是关键。我把这些记录存成一个本地的 Markdown 文件库，每条一个文件，文件名是“日期-问题简述”。然后用一个检索技能@recall，输入关键词，它去文件库里搜相关记录，返回最匹配的几条。

实测下来，这个检索比全文搜索好用，因为记录是结构化的，模型能理解“问题现象”和“根因”的区别，检索更精准。

11.4 坚持使用的技巧

这个技能最大的挑战是“坚持”。人解决问题后往往想赶紧干下一件事，不想花时间记录。我的应对办法是降低记录成本：技能触发后，我只需要口述几句，它自动整理成结构化记录。整个过程不超过一分钟。

另外，我会定期（每月一次）回顾经验库，把重复的记录合并，把过时的删掉。保持库的“新鲜度”，检索效果才好。

12. 技能组合使用的实战场景

12.1 一个完整的需求交付流程

把上面这些技能串起来，一个完整的需求交付流程是这样的：

@scaffold搭好项目骨架（如果是新项目）
@design2code把设计稿转成前端组件
@tdd-red写测试，@tdd-green写实现
@code补充业务逻辑代码
@verify-api验证接口
@review做代码审查
@doc-api更新接口文档
@capture记录本次开发中的经验

这个流程跑下来，我个人的感受是：机械性工作被压缩到了极致，我的时间主要花在“判断”和“决策”上。判断测试写得对不对、判断代码逻辑是否符合业务、判断审查意见是否合理。这些才是真正需要人的地方。

12.2 技能之间的依赖关系

这些技能不是孤立的，它们之间有依赖：

@code依赖文件系统 MCP 和上下文注入
@verify-api依赖接口调试 MCP
@design2code依赖蓝湖 MCP
@review依赖@code生成的代码规范上下文
@capture依赖前面所有技能产生的“事件”

所以落地的时候，建议先装基础技能（MCP 连接、上下文注入），再装上层技能。顺序反了会各种报错。

12.3 技能数量的控制

回到开头说的“10 个”这个数字。我实际维护的技能大概有 15 个，但常用的就是这 10 个。另外 5 个是特定场景才用的，比如处理 Excel 数据、生成图表、做数据迁移。

我的建议是：先落地 3 个，用顺了再加。一次性装 10 个，你记不住触发词，也搞不清每个技能的边界，反而添乱。技能这东西，少而精比多而杂强。

13. 落地这些技能时我踩过的坑

13.1 触发词冲突

最开始我给每个技能起了很长的触发词，比如@generate-spring-boot-code。结果打字太累，而且容易打错。后来统一改成短词：@code、@tdd、@review。短词好记好打，冲突也少。

但短词有个问题：容易误触发。比如我在正常聊天里打了“@code”这个词，技能就启动了。解决办法是要求触发词必须出现在行首，或者用特殊符号包裹。我现在的规则是：触发词必须独占一行，或者前面有空格。

13.2 上下文窗口的争夺

每个技能都要往提示词里塞上下文，塞多了就超窗口。我遇到过最夸张的一次，@code技能读了 20 个文件，直接把上下文撑爆，模型开始胡言乱语。

后来我定了条规矩：每个技能最多读 5 个文件，总 token 不超过窗口的 30%。剩下的留给用户输入和模型输出。这个比例是我试出来的，比较稳。

13.3 技能更新的版本管理

技能配置也是代码，也需要版本管理。我一开始直接改配置文件，改坏了没法回滚。后来把技能配置放进 Git，每次改动都提交，出问题就回滚。这个习惯救过我好几次。

另外，技能配置里引用的外部依赖（比如 MCP Server 的版本）也要锁定。我有次没锁版本，MCP Server 自动升级后接口变了，技能直接挂掉。现在我在配置里写死版本号，升级手动来。

13.4 不要过度自动化

最后一个坑，也是最重要的：不是所有事都值得自动化。我一度想把所有重复操作都做成技能，结果花在“做技能”上的时间比“做正事”还多。

后来我想明白了：一个操作如果每周发生少于 3 次，就不值得做成技能。因为技能的维护成本（更新、调试、记触发词）会超过它节省的时间。只有高频操作才值得自动化。

这个判断标准帮我砍掉了一半的“想做但没必要”的技能，让我能专注在真正高频的那 10 个上。

提示：技能落地是个迭代过程。第一版不用追求完美，先跑起来，用着用着就知道哪里要改。我现在的 10 个技能，每个都改过至少 5 版。工具是磨出来的，不是设计出来的。