使用skill-creator创建和优化Skills

张开发
2026/5/11 13:47:13 15 分钟阅读

分享文章

使用skill-creator创建和优化Skills
Info官方资源•GitHubhttps://github.com/anthropics/skills/tree/main/skills/skill-creatorskill-creator是 Claude Code 的官方 Skill用于创建、优化和评估 Skills。它通过科学的方法帮助改进 Skill 的触发准确率和执行效果。核心工作流程skill-creator 遵循迭代的开发流程SummarySkill 开发循环1. 捕获意图理解用户想要实现什么功能确定 Skill 的触发场景和预期输出2. 编写草稿创建 SKILL.md编写 Skill 的核心指令和触发描述3. 创建测试设计 2-3 个真实场景的测试用例4. 运行评估同时运行有 Skill 和无 Skill 的基准测试收集性能数据5. 定性定量分析使用 eval-viewer 查看结果运行断言测试收集用户反馈6. 迭代改进基于反馈重写 Skill扩展测试集重复直到满意7. 描述优化使用触发评估集优化 Skill 的触发准确率创建 Skill1. 捕获意图在编写 Skill 前先回答以下问题问题说明Skill 要实现什么Claude 使用该 Skill 后能完成哪些任务何时触发用户会说什么样的话或处于什么上下文时应该触发预期输出格式生成什么类型的文件或内容是否需要测试用例客观可验证的功能代码生成、数据提取适合测试用例主观输出写作风格、艺术通常不需要2. 编写 SKILL.mdSKILL.md 的核心结构--- name: your-skill-name description: 什么时候使用这个 Skill它完成什么任务。这是主要的触发机制 要包含何时使用的所有信息而不是放在正文。注意Claude 倾向于触发不足 所以描述要稍微主动一些。 --- # Skill 标题 ## 使用场景 当用户...时使用此 Skill ## 执行步骤 1. 第一步... 2. 第二步... ...Tip描述编写技巧与其写如何构建简单的快速仪表板不如写如何构建简单的快速仪表板。每当用户提到仪表板、数据可视化、内部指标或想要显示任何类型公司数据时一定要使用此 Skill即使他们没有明确要求仪表板3. 编写原则•使用祈使语气直接告诉模型做什么•解释为什么今天的 LLM 很聪明解释原因比僵硬的规则更有效•保持精简移除不起作用的内容不要让模型浪费时间•提供示例用真实示例说明期望的输入/输出格式•控制篇幅SKILL.md 保持在 500 行以内必要时使用分层结构测试与评估测试用例格式{ skill_name: example-skill, evals: [ { id: 1, prompt: 用户的任务提示, expected_output: 预期结果的描述, files: [] } ] }运行测试流程1.并行启动所有测试为每个测试用例同时启动两个子代理有 Skill 和无 Skill2.捕获时序数据记录每个任务的 token 数量和执行时间3.编写断言在测试运行时起草可验证的断言4.评分和聚合运行聚合脚本生成 benchmark.json5.启动查看器使用 eval-viewer 让用户审查结果描述优化触发优化Skill 的 description 字段是决定 Claude 是否调用 Skill 的主要机制。优化流程1. 生成触发评估集创建 20 个评估查询混合应该触发和不应该触发的案例[ {query: 用户提示, should_trigger: true}, {query: 另一个提示, should_trigger: false} ]评估集设计要点•真实场景使用真实用户会输入的具体、详细的请求包含文件路径、列名、URL 等•应该触发8-10 个覆盖不同表达方式包括正式/非正式、未明确命名 Skill 的情况•不应该触发8-10 个最有价值的是近失误——共享关键词但实际需要不同功能的查询2. 运行优化循环python -m scripts.run_loop \ --eval-set path-to-trigger-eval.json \ --skill-path path-to-skill \ --model model-id \ --max-iterations 5 \ --verbose该脚本会• 将评估集分为 60% 训练集和 40% 测试集• 评估当前描述每个查询运行 3 次获得可靠的触发率• 调用 Claude 提出改进建议• 迭代最多 5 次选择测试集上得分最高的描述实战案例优化 dev-design Skill评估集示例以下是为dev-designSkill 设计的触发评估集[ {query: 帮我写一个技术设计文档, should_trigger: true}, {query: 为这个功能写个 dev design, should_trigger: true}, {query: 根据 Kaptain 事项生成技术设计文档, should_trigger: true}, {query: DEVOPS-1234 这个需求的技术设计文档怎么写, should_trigger: true}, {query: https://kaptain.qunhequnhe.com/project/detail/issue?projectId123key 帮我生成设计文档, should_trigger: true}, {query: 分析代码库并生成架构设计文档, should_trigger: true}, {query: 为新 API 接口写技术设计, should_trigger: true}, {query: 从 Confluence 文档生成技术设计, should_trigger: true}, {query: 用户认证功能的技术设计方案, should_trigger: true}, {query: 前端技术设计文档模板, should_trigger: true}, {query: 写一个函数, should_trigger: false}, {query: 帮我修复这个 bug, should_trigger: false}, {query: 怎么写单元测试, should_trigger: false}, {query: 代码审查, should_trigger: false}, {query: 部署到生产环境, should_trigger: false}, {query: 数据库优化建议, should_trigger: false}, {query: git 合并冲突怎么解决, should_trigger: false}, {query: npm install 失败了, should_trigger: false}, {query: Vue 组件怎么写, should_trigger: false}, {query: Docker 容器配置, should_trigger: false} ]最佳实践Tip避免过度拟合不要为了通过几个测试用例而编写过于狭窄或僵化的规则。尝试从反馈中泛化出通用原则使用不同的隐喻或工作模式来解决问题。Tip重复利用脚本如果多个测试用例都导致子代理编写相似的辅助脚本考虑将其打包到 Skill 的 scripts/ 目录中。这可以避免每次都重新造轮子。Tip解释而非强令如果发现自己在写 ALWAYS 或 NEVER 这样的全大写规则这是警告信号。尝试重新构建并解释推理过程让模型理解为什么你要求的事情很重要。Tip评估集维护定期更新评估集添加新的边界案例和实际使用中发现的误判案例。特别关注那些近失误——容易混淆但应该区分的场景。理解 Skill 触发机制了解触发机制有助于设计更好的评估查询•Skill 列表Skills 出现在 Claude 的 available_skills 列表中包含 name description•触发条件Claude 根据描述决定是否咨询 Skill•重要特点Claude 只在无法轻松处理任务时才咨询 Skills• 简单的一步查询如读取此 PDF可能不会触发即使描述完美匹配• 复杂、多步或专业化的查询在描述匹配时会可靠地触发Note评估查询设计建议评估查询应该足够实质性使 Claude 实际上受益于咨询 Skill。读取文件 X这样的简单查询是糟糕的测试用例——无论描述质量如何它们都不会触发 Skills。相关资源• Claude Skills 官方仓库• Skills 官方文档• skill-creator 完整文档

更多文章