如果你给 AI 编码助手装过技能包，大概遇到过同一个尴尬：装是装上了，可它该触发的时候不触发，不该管的事又抢着管。一个 25 个技能的包里，你想用的那个到底会不会被选中？
addyosmani/agent-skills 这个仓库给出了一个罕见的答案：它自带评测套件、把通过率写进 CI 当门禁。我把它 clone 下来跑了一遍——官方跑分 100%，我按真实用户的口吻出题，只剩 24%。差别不在项目好坏，在于它的评测用的是书面语，而你说话不是。
它是什么，凭什么 9.9 万 Star
一句话定位：把资深工程师的工作流、质量闸门和验收标准写成 25 个可自动触发的技能，让 AI 编码助手在每个开发阶段都照着做。作者 Addy Osmani 是 Google 的工程负责人，仓库 MIT 许可，JavaScript 为主，创建 220 天冲到 98,752 星、10,372 个 fork，一天前还有提交。
它的设计思路不是「教模型更聪明」，而是「给流程装栏杆」。开发被切成六段——定义、计划、构建、验证、审查、上线——对应 9 个斜杠命令，每个命令自动激活相关技能：
| 阶段 | 命令 | 核心原则 |
|---|---|---|
| 定义 | /spec |
先写规格再写代码 |
| 计划 | /plan |
任务切到原子级 |
| 构建 | /build |
一次只推进一薄片 |
| 验证 | /test |
测试就是证据 |
| 审查 | /review |
先提升代码健康度 |
| 上线 | /ship |
更慢反而更安全 |
技能本身不是空话。25 份 SKILL.md 合计 7,519 行，平均 301 行，最长的是 performance-optimization（496 行）。随手翻一份 doubt-driven-development，它先把「什么算非平凡决策」定义清楚——引入分支逻辑、跨模块边界、断言编译器验不了的属性、爆炸半径不可逆——再明确列出不该用的场景：重命名、格式化、用户已明确要求提速。「怀疑每一次按键就什么都发不了」写在正文里。这种自我设限，比多数「万能提示词」克制得多。
真正让它区别开的是 evals/ 目录：82 个文件、25 份用例、25 套 fixture，外加 13 个校验脚本。分三层——结构层查 frontmatter 和命名，路由层查触发准确率，行为层用真实 agent 跑用例打分。前两层免费且在 CI 里强制执行。
实测：100% 与 24% 之间差了什么
官方路由层评测的门槛写在 CI 里：node scripts/run-evals.js --min-rank1 95。我在这台机器上原样跑了一遍，结果是 88 条正向提示全部命中自己的技能，rank-1 准确率 100%，140 项检查零错误零警告。
这个数字很漂亮，但它是怎么来的？我读了 runner 的实现：它把所有技能描述做成词袋，用带词干还原的 TF-IDF 向量算余弦相似度，取最相近的那个。也就是说，它比的不是语义，是用词重叠。
于是我做了一件事：不看它的测试集，自己写题。同一批技能，换三种问法。
第一组是啰嗦口语，就是人真会说的话——「应用点保存就崩了，我也搞不清为啥」这种带噪声的长句。21 条里只对了 5 条，rank-1 准确率 24%。第二组换成中等长度的书面请求，12/15 命中，80%。第三组压到 3-6 个词的短语，9/10，90%。
为了排除「我写得太怪」的可能，我又做了一组严格对照：同一个意图，写成短语、标准句、啰嗦口语三种版本各 10 条。
| 问法 | rank-1 准确率 | top-3 命中 |
|---|---|---|
| 短语（3-6 词） | 90% | 90% |
| 标准书面句 | 100% | 100% |
| 啰嗦口语（带噪声） | 40% | 80% |
变量很清楚：提示越长、噪声越多，词法路由器越容易被无关词稀释掉关键信号。它认的是关键词密度，不是你想干什么。
还有一组更直接的证据。我把作者 88 条测试提示与对应技能描述的词汇重叠率算了出来：平均 56.2%，其中 57% 的条目重叠率超过一半——「write a failing test」对上描述里的 test，「pull request」对上描述里的 code review，几乎是原词照抄。我自己写的那 21 条，平均重叠率只有 12.6%。
最后是消融实验：把每条提示里与技能描述重叠的实词删掉，保留其余部分，重新路由。结果 rank-1 从 100% 掉到 2%，top-3 也只剩 7%。词一拿掉，路由器就不认识自己的技能了。
需要说清楚的是，这不等于项目在造假。它的评测文档把话讲得很明白：路由层是「词汇近似」，判不了语义，抓的是两种真实故障——描述缺了用户会说的词，或描述太宽泛挤掉了正确的技能。这套检查确实管用，而且它有个真本事：25 个技能描述两两比余弦，300 对里最高只有 0.260，离 0.5 的告警线还很远。也就是说，这套技能的边界互不打架，这在同类技能包里相当少见。
翻车点在别处。它的分词正则只保留 a-z0-9，中文字符会被整体清空——我用纯中文提问，分词结果直接是空数组，所有技能得分都是 0.0000，排序退化成按目录顺序。中文用户拿到的是一个完全失效的路由器。另外 25 个技能里有 5 个叫 *-driven-development（constraint / doubt / source / spec / test），命名高度雷同，靠名字区分基本不可能。行为层（Tier 3）要调真实模型、花 token，我在这个克隆里没找到任何历史结果文件，evals/skill-impact.md 是一张只有表头的空账本——「哪些改动被评测否掉了」，目前无从查证。
放到同类里看
技能路由这个题目，最近一个月已经有三篇值得对照。
reverse-skill（36.9k 星）同样是路由包，我实测它自己的 178 条路由全绿，而我出的 56 条错了 7 条——和这里的结论几乎一致：自测集通过率高，不等于你的问法能过。mattpocock/skills（254k 星，37 个小工具）走的是反面路线，明确拒绝流程绑架，不做统一编排。Spec Kit（13.7 万星）长成了插件市场，169 个社区扩展实测八成已休眠——规模上去之后，维护是另一回事。
适合谁：团队里用 Claude Code、Cursor、Codex、Copilot、Cline、Gemini 等 8 种以上助手，且希望把「先写规格、测试先行、上线前审查」变成默认动作的人。25 个技能可以整体装，也可以单装——npx skills add addyosmani/agent-skills --skill code-review-and-quality 这样点名取用。
不适合谁：技能内容全是英文，中文团队要用得自己重写描述；如果你只想要一两个技能，整包 7,519 行的体量反而增加上下文负担；如果你的诉求是「让 AI 更聪明」，这套东西治的是纪律，不是智力。
结论
9.9 万 Star、25 个技能、7,519 行内容、CI 里跑着 100% 的评测——这个仓库的工程质量在同类里是第一梯队。但它的路由评测是一把词法尺子，量的是「用户的用词和描述的用词有多像」，而不是「用户想干什么」。所以看到任何技能包宣称「触发准确率 100%」，值得多问一句：你的测试提示，是谁写的、照着什么措辞写的。
我的建议是放进观察清单并试用，但装完之后用自己的话测一遍你最常用的三个场景——如果它没触发，你要改的是技能描述，不是自己的说话方式。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：