没有评测别发布技能——Philipp Schmid(Google DeepMind)

• Philipp Schmid（Google DeepMind Staff Engineer，主做 Gemini API 和 agent）上台先做了个三连举手：用 coding agent 写代码的举手——几乎全举；在用 skill 的举手——还是很多；给这些 skill 写过 eval 的举手——「就没几个了」。一句话戳破现状：人人都在用 skill，没人给 skill 做 eval。→ 详细
• 数据佐证：Skill Bench（一个评测基准，skill 的「跑分平台」）从 GitHub 索引了超过 5 万个 skill，逐一分析后发现几乎没有一个带 eval，且大部分是 AI 顺手写的、没经过真正测试。→ 详细
• 为什么这是真问题：agent 本身高度非确定性（同样的输入，两次结果可能不一样），所以任务失败时你根本分不清——是 skill 写得差，还是这个任务对模型来说本来就太难。没有 eval，你连「这个 skill 到底有没有用」都无法回答。→ 详细

• 你用的 agent（Claude Code、Cursor、Antigravity）：你自己就是工程师，清楚 skill 的存在。第一次没触发对，你立刻会察觉，然后停下重写 prompt、或用斜杠命令手动触发——触发不可靠的代价你自己当场兜着。→ 详细
• 你造的 agent（你在自己产品里给消费者/客户搭的 agent）：用户压根不知道 skill 是什么，不会在 prompt 开头写「请用退款 skill 帮我退款」。这时 skill 能不能被模型自动触发就成了生死线——而这，只能靠 eval 来保证。这也是全场 eval 部分的靶心。→ 详细

• 拆开看，skill 本质就是一个文件夹：里面一个 SKILL.md 文件，再加一些让它真正跑起来的附加资源。→ 详细
• 它靠渐进式披露（progressive disclosure，按需逐层展开、不一次性塞满上下文）工作，分三层：① 标题 + description（描述常驻模型上下文，告诉模型「何时该用」）；② skill 正文（更多指令、细节，最好带指向外部文件的引用）；③ 引用文件（模型要深入某个具体任务时才去读的完整上下文）。→ 详细

• 能力型 skill（capability）：教模型做它当前做不稳的事，比如追查日志、创建一个 React 应用。它是临时的——模型越强，这类 skill 越可能被移除，而「什么时候能让它退役」正是 eval 来告诉你的。→ 详细
• 偏好型 skill（preference）：更持久，编码的是只属于你的东西——团队特有的工作流、特定文风、公司专属约定。基础模型大概率不会内置这些知识，所以更要用 eval 把它保护起来，避免升级 agent 时悄悄把性能搞退化。Philipp 说偏好型「非常有价值」，正因如此才格外怕被无声改坏。→ 详细

• Skills Bench 1.1 在多个 harness（agent 运行框架）里评测了各种开闭源模型，结论：skill 平均把性能拉高约 15%；覆盖约 100 个编程+效率类任务、横跨多语言，完全开放、有排行榜、欢迎社区贡献。→ 详细
• 两条反直觉硬结论：人写的 skill 质量最好，AI 生成的 skill 反而可能让性能变差（别顺手让模型「创建个 skill」瞄一眼就接受）；且 SKILL.md 应控制在 500 行以内——超了，今天散会就该回去审它。→ 详细

• 模型触发（model-triggered）：模型根据上下文和 description 自己决定读不读某个 skill。用户主动调用（user-invoked）：由人显式触发，Philipp 说大家严重低估了它的威力，多数人只是默默接受把它塞进上下文的开销。→ 详细
• 他自己把大量偏工作流的活做成用户主动调用——创建 PR、发布文档等。经验法则：凡是能用脚本跑的常规开发工作，大概率都该做成用户主动调用的 skill。但给客户造 agent 时没有这条路，只剩模型触发——所以下面的 eval 全都围着模型触发转。→ 详细

• description 是命门：它就是你放进系统指令里的那两句话，是每次模型调用都要付的固定成本（那 100–200 个 token 你永远在付）。写太弱→要么过度触发、要么该触发时不触发。必须讲清为什么用、怎么用、什么时候用（例：「开发 React 应用时使用此 skill」）。→ 详细
• 写指令，不写散文（directives, not essays）：别写「Interactions API 适合多轮对话，因为它能处理会话状态」这种解释文；要直给——「做聊天类应用就用 Interactions API」。模型要的是明确的 directive，不是论文。→ 详细
• 精简 + 分层：description 短；SKILL.md 一旦被模型决定读取就整份进上下文（很贵），所以主文件只留核心，把深度内容甩进第三层引用文件按需取用。→ 详细

• 给对自由度：很多人在 skill 里把工作流写死（第一步、第二步、第三步）。如果流程每次都一模一样，那就别用 skill，写个脚本——何必浪费模型和 token。正确姿势是定义目标和约束、别微观管理模型（例：改配置别写「读配置→改端口→重部署」，只说「要改配置的话文件在这，改就是了」，模型知道该怎么做）。→ 详细
• 别漏反例（negative cases）：我们总在写「何时用」，很少写「何时别用」。「用于 Web 开发」会过度触发（React、Angular 都算）；写「只在 React 组件或 Tailwind CSS 时用」模型才知道边界。eval 能帮你揪出这类过度触发。→ 详细
• 尽早测：新建 skill 时就写 10–20 条 prompt——5 条正向（该触发）+ 5 条反向（不该触发，防过度触发把模型自己搞乱），有真实生产 trace 就一并塞进去，「没什么比真实数据更好」。→ 详细
• 杀掉 no-ops（功劳归 AI 教育者 Matt）：AI 生成的 skill 常塞满 no-ops——对 agent 行为毫无改变的废话，比如「实现前先确保代码易读」（模型本就会写清晰代码）。删了它 eval 不一定变好，但省 token = 省钱。→ 详细
• 知道何时退役：skill 不该永生（模型、行为、期望、环境都在变）。经常跑「开 skill / 关 skill」两组 eval，若不触发也能达标，就让它退役，省成本又免维护冗余。→ 详细

• 背景：Gemini Interactions API 是在 Gemini 上次训练之后才发布的新接口，所以 Gemini 3 / 3.1 / 3.5 对它「完全没有概念」——这正是能力型 skill 的典型用武之地（补模型不知道的新知识）。→ 详细
• 他们造了 117 个测试用例，三个来源：真实用户生成 Gemini 代码的数据、合成生成的用例、以及用户反馈（「都 3.0 了模型还在用 Gemini 2.0」这类）。结果：生成有效、且用上最新模型的 Interactions API 代码，成功率提升到接近 90%。→ 详细
• 整套 harness 只要两个东西：① 一份 JSON，每条用例结构极简——prompt（预期用户会输入的话）、language（在 TypeScript 和 Python 上都测）、should_trigger（这条该不该读这个 skill）、expected checks（几条极简断言）；② 一段基础 Python 脚本，跑一个 coding agent（他们用 Gemini CLI），解析并运行产出，看代码到底有没有效。→ 详细
• 大部分断言用正则就够（用 coding agent 写正则「水平高得惊人」），核查的就是几件事：SDK 对不对、模型对不对、方法对不对、有没有混进旧写法。跑起来极便宜、可反复跑；新模型一发布，把断言里的模型 ID 一换即可，完全不用 LLM 当裁判。→ 详细

• 复杂 skill（要审完整 trace 或多步执行）才上 LLM as a judge（让另一个模型当裁判）：配个 rubric（评分标准）写清要看什么，把输出丢给它判 pass/fail，fail 了就看数据、据此改 skill。→ 详细
• Google DeepMind 现在的做法：每个 skill 旁边都配 tests/evals，跑在干净 workspace 里（可定义环境、用 startup 命令预装依赖），既有脚本类 eval（正则扫 trace：skill 触发没、某命令/CLI 跑没）也有 LLM 裁判。→ 详细
• 最关键的一条——skill 每次改动都跑 eval，diff 一出 eval 就执行，改动没让测试用例变好就不给 merge。等于给每个 skill 上了回归测试：你只能在「改动提升了 eval / 补了新 eval」时才动它。这就是把软件工程里「不带测试不许 merge 代码」的纪律，原封搬到了 skill 上。→ 详细

• 50% 的失败都因为 skill 没被正确触发——用户 prompt 不够详细，模型没意识到该用它。给别人造 agent 时尤其致命：用户根本不知道你给 skill 写了什么 description。→ 详细
• 考核结果，不考核路径（outcomes, not paths）：别测模型是不是第一轮就加载 skill，要测它最终能不能完成任务——第五轮才加载也没关系。→ 详细
• 隔离运行：coding agent 很擅长「作弊」，在现有环境里跑会翻出旧对话/旧执行、不用 skill 也偷到上下文，把 eval 糊弄过去——所以每次都要在干净环境里跑。→ 详细
• 每个 case 多跑几次（2–6 个 trial）：模型非确定性，第一次成、第二次可能败，多跑才能量出可靠性。跨 harness 测：skill 可能配 Gemini 好、配 Codex 差，而你的客户偏偏用 Codex 就挂了——别只对着 Claude/Antigravity 测。→ 详细
• eval 比 skill 命长：模型强到不再需要某 skill 了，把 skill 扔掉、eval 留着——它继续盯着性能，一旦退化就把 skill 重新引入。这是唯一能让你放心退役 skill 的安全网。→ 详细

本场是纯演讲、没有 Q&A，收在一段「作业 + 一句话暴击」上：

• 一句话收尾：「别在没有 eval 的情况下发布 skill（Don't ship skills without evals）。」 ——把它当成「不带测试不许 merge 代码」的 skill 版。→ 详细
• 留给你的作业（周一上班就能做）：挑一个你用得最多的 skill，给它写 5 条测试 prompt。也可以直接让 coding agent 翻你的 trajectory（历史执行记录），找出最常用的 skill 再据此建测试。→ 详细
• 三个立刻能上手的动作：① 搭最小 eval harness（一个 JSON/YAML + 一段跑 agent 的 Python 脚本，看结果就行）；② 删 no-ops 省 token；③ 跑消融测试（ablation test）——同一任务分别在「加载 skill / 不加载 skill」下各跑一遍，这是唯一能判断「skill 到底有没有用、何时能退役」的方法。参考 Matt 在 GitHub 上的《writing great skills》。→ 详细