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.1pom.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 ListContact result addressBookService.searchByName(张); // then assertThat(result).hasSize(2); assertThat(result).extracting(Contact::getName) .containsExactlyInAnyOrder(张三, 张四); } Test void should_return_empty_list_when_no_match() { ListContact result addressBookService.searchByName(不存在); assertThat(result).isEmpty(); }我检查一遍确认边界情况覆盖到了然后触发tdd-green让它基于这个测试写实现。它生成的searchByName方法会去查数据库或内存列表用like或contains匹配。跑一遍测试绿了收工。3.4 为什么这个技能值得长期用因为它改变的不只是速度而是代码质量的下限。以前赶进度的时候测试经常被跳过结果就是上线后各种边界问题。现在写测试的成本几乎为零你就没有理由不写了。我坚持用了两个月项目里的回归 bug 数量肉眼可见地下降。提示tdd-green生成的实现有时候会“过度设计”比如为了通过一个简单测试引入复杂的策略模式。我的经验是第一版实现越简单越好重构留到tdd-refactor阶段再做。4. 技能三MCP 协议对接的“外部工具桥接”技能4.1 MCP 到底解决了什么问题MCPModel 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统一返回体ResultT包含 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% 的代码块未使用的 import8.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 未使用的 importjava.util.Date8.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要转成文档里的“必填”“长度限制”。返回体的泛型ResultUserVO要展开成具体的字段列表。我生成的文档长这样### 查询用户详情 - **路径**: GET /api/users/{id} - **描述**: 根据用户 ID 查询用户详情 **请求参数** | 参数 | 位置 | 类型 | 必填 | 说明 | |------|------|------|------|------| | id | path | Long | 是 | 用户 ID必须为正整数 | **响应示例** json { code: 200, message: success, data: { id: 1, name: 张三, email: zhangsanexample.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依赖接口调试 MCPdesign2code依赖蓝湖 MCPreview依赖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 版。工具是磨出来的不是设计出来的。