写了个 SkillAI 有时候用、有时候不用、用了效果也一般问题不在 Skill 本身在于你没有训练它。这篇讲一套完整的 Skill 训练循环写初版 → 跑 Eval → 看数据 → 改进 → 再跑 Eval让 Skill 从能用进化到精准。写在前面大多数人写 Skill 的方式是这样的1写一份 SKILL.md2试了两次“好像能用”3收工一个月后发现有时候 AI 该触发的时候没触发不该触发的时候乱触发。输出质量时好时坏全看运气。问题在哪你没有用数据驱动地训练它。Skill 不是写完就结束的静态文档。它是一个需要持续训练、度量、迭代的模型行为规范。好消息是Claude Code 的 skill-creator 工具已经把整个训练循环自动化了——你只需要理解原理然后让工具帮你跑。一、Skill 的两个核心指标训练 Skill 要优化的只有两件事1. 触发率Triggering Accuracy“该触发的时候触发了吗不该触发的时候没乱触发吗”这取决于description字段写得好不好。AI 根据 description 判断这个 Skill 跟当前任务相关吗。description 写得模糊就会漏触发或误触发。2. 输出质量Output Quality“触发之后AI 按 Skill 干活的效果好不好”这取决于 SKILL.md 正文的规则写得好不好。规则太模糊 AI 会自由发挥规则没覆盖到的地方 AI 会按自己的默认行为来——未必是你想要的。训练的目标把触发率从 ~65% 拉到 95%把输出质量从勉强能用拉到稳定可靠。二、训练循环4 步闭环整个训练过程是一个循环反复跑直到满意写/改 Skill → 跑 Eval → 看数据 → 改进 → 再跑 Eval → …第 1 步写初版 Skill初版不用追求完美能表达核心意图就行。重点关注description写清楚什么时候用以 “Use when” 开头正文写 3-5 条核心规则给 1 个完整示例name: commit-message-zhdescription: Use when 用户完成代码修改准备提交时生成中文 commit message中文 Commit Message规则commit message 用中文格式类型(范围): 描述类型包括feat/fix/refactor/docs/test/chore描述不超过 50 字不要写更新了代码这种废话要写具体改了什么示例feat(auth): 添加 GitHub OAuth 登录fix(payment): 修复月度订阅扣费金额计算错误refactor(api): 将 user 路由拆分为独立文件第 2 步跑 Eval——让 skill-creator 帮你测这一步是关键。用 skill-creator 跑评估需要先安装从github.com/anthropics/skills仓库把skill-creator目录放到~/.claude/skills/下帮我评估 commit-message-zh 这个 skill 的触发准确率和输出质量skill-creator 会自动做这些事以下为简化示意实际输出包含更多细节触发率测试1生成 20 个模拟查询10 个应该触发、10 个不应该触发2逐个测试 Skill 的 description 能否正确判断3输出触发率分数触发率评估结果应触发的 10 个查询8/10 正确触发 ✓不应触发的 10 个查询9/10 正确未触发 ✓综合触发率85%误判案例“帮我写个 PR 描述” → 错误触发PR 描述 ≠ commit message“提交代码” → 未触发应该触发输出质量测试1用 3-5 个真实场景测试 Skill 的输出2对比有 Skill和没 Skill的输出差异3评分第 3 步看数据定位问题根据 Eval 结果问题通常归为两类触发率低→ 改 description常见原因太宽泛“Use when writing commit messages”写什么都可能触发太窄“Use when using git commit -m”只有精确匹配才触发有歧义“Use when committing code”PR 描述也算committing吗输出质量差→ 改正文规则常见原因规则太模糊“写好 commit message”什么叫好缺少反面示例AI 不知道什么不该做缺少边界情况多文件修改时怎么写破坏性变更怎么标注第 4 步改进并重跑根据第 3 步的诊断做针对性修改。然后再跑一次 Eval看数字有没有涨。比如触发率从 85% 要拉到 95%description 改成改前description: Use when 用户完成代码修改准备提交时生成中文 commit message改后description: Use when 用户说提交、“commit”、写 commit message或完成一轮代码修改后要求生成提交信息时。不适用于 PR 描述、changelog、release note。关键改动加了正面触发词 加了负面排除词。这样 AI 就不会把写 PR 描述误判为需要这个 Skill。三、让 Skill 自进化3 个机制训练一次只是起点。真正厉害的是让 Skill持续自动进化机制 1用户反馈驱动迭代每次 Skill 的输出不符合你的预期时直接告诉 AI“这个 commit message 不对多文件修改时应该写最主要的改动不要列所有文件”AI 会自动把这条反馈存入记忆。下次再遇到同样情况行为就会改变。但更进一步——把这条反馈写回 Skill 本身边界情况多文件修改只描述最主要的改动意图不逐一列举文件名修改超过 5 个文件用重构 xx 模块代替逐一描述反馈 → 记忆 → 写回 Skill → 永久生效。这就是自进化。机制 2定期跑 Eval 回归测试每两周跑一次 Eval。原因你的项目在演变规范可能已经变了你装了新的 Skill可能跟旧的冲突AI 模型更新后行为可能变化把它当成单元测试——代码改了要跑测试Skill 改了也要跑 Eval。机制 3description 自动优化skill-creator 有一个杀手级功能自动优化 description 的触发准确率。帮我优化 commit-message-zh 的 description提高触发准确率它会1生成 20 个测试查询2跑当前 description 的触发率baseline3自动改写 description加触发词、加排除词、调措辞4再跑一遍测试5对比 before/after选分数更高的版本根据社区实测分享Reddit、Medium 上多位开发者的反馈触发率从 ~70% 提升到 ~90% 是可预期的。四、实战案例一个 Skill 的 3 次进化以我自己的code-reviewSkill 为例v1初版第一次跑 Eval 结果触发率 65%输出质量 Cname: code-reviewdescription: Use when reviewing codeCode Review检查安全性检查性能检查可读性问题description 太模糊reviewing code太宽泛规则太抽象检查安全性具体查什么。v2跑 Eval 后优化触发率 82%输出质量 Bname: code-reviewdescription: Use when 用户说review、“检查代码”、“看看有没有问题”或在 git commit/push 之前要求审查代码质量。不适用于功能讨论或架构设计。Code Review检查项按优先级安全硬编码密钥SQL 注入未转义用户输入错误处理Promise 有 catch 吗边界值处理了吗类型安全有 any 吗类型断言合理吗可读性命名能表达意图吗嵌套超过 3 层了吗重复有可提取的公共逻辑吗输出格式每个问题标明严重程度高 中 低给出具体修复建议不只是指出问题改进description 加了具体触发词和排除场景规则从抽象变具体。v3用户反馈 自动优化后触发率 95%输出质量 Aname: code-reviewdescription: Use when 用户在代码修改完成后要求审查质量触发词review、检查、看看有没有问题、帮我过一遍或在 /commit 之前自动触发。不适用于功能需求讨论、架构设计、写新代码。Code Review铁律每次 review 必须至少指出一个改进点。如果真的没问题说明为什么没问题。不要只说看起来没问题——这等于没 review。检查项按优先级**安全**硬编码密钥SQL 注入XSS未验证的用户输入**错误处理**Promise 有 catch外部 API 调用有超时错误信息对用户友好**类型安全**有 any类型断言有根据泛型用对了**逻辑**边界值测试了空值处理了并发安全**可读性**命名表达意图嵌套 ≤ 3 层函数 ≤ 30 行输出格式严重程度必须修 建议修 锦上添花每个问题位置 问题描述 修复建议 修复代码反面案例不要这样输出❌ “代码看起来还行” → 没有价值❌ “建议加注释” → 太模糊具体哪里加什么注释❌ 列出 20 个低优先级问题 → 信息过载先说最重要的 3 个改进加了铁律防止偷懒、加了反面案例防止废话输出、description 经过自动优化触发率到 95%。五、Skill 数量多了之后的管理当你有 10 个 Skill 时新问题出现Skill 之间互相冲突或抢触发。问题 1多个 Skill 同时触发比如你有code-review和security-review两个 Skill用户说帮我检查下这段代码——两个都想触发。解决方案在 description 里明确划分边界code-reviewdescription: … 不适用于专门的安全审查安全审查用 /security-reviewsecurity-reviewdescription: Use when 用户明确要求安全审查、渗透测试、威胁建模…问题 2Skill 过时了项目从 REST 迁到 tRPC 了但你的api-designSkill 里还写着 REST 的规范。解决方案每月做一次Skill 年检帮我检查所有 Skill看哪些跟当前项目的技术栈/规范已经不匹配了问题 3不确定该不该新建 Skill判断标准你是否在不同会话中重复给 AI 同一条纠正指令了如果你发现自己反复说不对我们项目应该这样做——就值得写成 Skill。一次性的、只在特定调试场景出现的指令不需要。问题 4什么内容该写在 CLAUDE.md什么该写成独立 Skill分层策略CLAUDE.md放是什么——项目技术栈、目录结构、常用命令、团队规范等静态事实Skill放怎么做——具体工作流程、输出格式、检查清单、边界情况处理等动态行为规范举例“我们用 vitest 做测试” → 写在 CLAUDE.md“写测试时用 AAA 模式、describe 对应一个函数、mock 尽量少用” → 写成 test-conventions SkillCLAUDE.md 给 AI 背景知识Skill 给 AI 执行手册。两者配合不要混在一起。六、什么时候停止迭代不是无限跑 Eval 就是好的。收敛标准触发率 ≥ 90% 就可以停。100% 不现实——有些边界查询本来就有歧义帮我看看这段代码到底是 review 还是解释追求 100% 反而会让 description 变得过度具体、丧失泛化能力。输出质量连续 2 次 Eval 没有提升就停。说明当前规则已经到达了这个 Skill 能覆盖的上限。再想提升要么拆成多个 Skill要么接受现状。一个 Skill 的迭代轮数通常不超过 3-4 轮。如果 4 轮还不收敛大概率是 Skill 的定义范围太大了——拆成 2 个更窄的 Skill 比硬优化一个宽 Skill 效果更好。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】