别再裸奔：为AI智能体技能编写评估的完整实践指南

在 AI 编程工具已成为开发者标配的今天，一个尴尬的现实浮出水面：几乎所有人都在使用「技能（Skills）」，但几乎没有人为它们编写评估（evals）。来自 Google DeepMind 团队的 Philip 在一次分享中直言：不要在没有评估的情况下发布智能体技能。这不仅是一句口号，而是他基于大规模数据分析和内部实践得出的核心结论。

本文将系统梳理这场分享的要点，帮助你理解为什么技能需要评估、如何写出好的技能，以及如何用最低成本搭建自己的评估流程。

一个被忽视的现实：技能在裸奔

Philip 在演讲开场做了一个小调查：使用编程智能体写代码的请举手——几乎全场举手；使用技能的请举手——依然很多；为技能编写了评估的请举手——寥寥无几。

这个反差恰恰揭示了当前的行业问题。知名基准测试 SkillBench 从 GitHub 上索引了超过 5 万个技能，发现其中几乎没有一个附带评估。绝大多数技能是由 AI 生成的，从未经过真正的测试。

问题在于，智能体本质上是非确定性的。当一个任务失败时，你很难判断究竟是因为技能写得糟糕，还是因为任务本身对模型太过困难。没有评估，你就是在盲目发布。

我们「使用」的智能体 vs 我们「构建」的智能体

Philip 强调了一个关键区分：

• 我们使用的智能体：如 Cursor、Claude Code、Antigravity 等编程工具。此时你就是工程师，对技能了如指掌。如果技能没有在第一次被正确调用，你会立刻察觉并重新提示，或用斜杠命令手动触发。
• 我们构建的智能体：嵌入到应用中面向消费者或客户的智能体。用户根本不知道「技能」是什么，他们不会说「请用退款技能帮我处理问题」。

这个区别至关重要——因为面向客户的智能体只能依赖**模型触发（model-invoked）**的技能，而这正是评估最需要覆盖的场景。

技能的底层机制与分类

技能本质上是一个包含 skills.md 文件的文件夹，外加一些辅助资源。它的核心机制是渐进式披露（progressive disclosure）：

1. 第一层：标题与描述。描述通常存在于模型上下文中，让模型知道何时使用该技能。
2. 第二层：技能主体，包含更详细的指令和对外部文件的引用。
3. 第三层：引用文件，模型在需要时才深入探索的完整上下文。

Philip 进一步将技能分为两类：

• 能力型技能（Capability Skills）：教会模型当前做不好的事情，比如日志追踪、创建 React 应用。这类技能是临时的——随着模型变强，它们终将被淘汰，而评估会告诉你何时可以退役它们。
• 偏好型技能（Preference Skills）：更持久，如团队特定的工作流、代码风格、领域偏好。这类技能需要评估来保护，因为基础模型很难内化这些高度专属的知识。

那么技能到底有没有用？答案是肯定的。SkillBench 1.1 版本评估了各种开源与闭源模型，覆盖约 100 个编码与生产力任务，结果显示技能平均能提升约 15% 的性能。

但一个警示是：人类编写的技能质量最高，AI 生成的技能反而可能损害性能。此外，skills.md 文件应控制在 500 行以内——如果你的技能超过这个长度，请务必尽快检查。

写好智能体技能的八条实践

对于模型触发的技能，最重要的就是描述（description）。它通常只有两句话，写进系统指令中，决定了模型何时该用这个技能。描述太弱，技能要么频繁误触发，要么该用时不触发。

1. 明确 Why、How 和 When

描述要清晰说明模型为什么用、如何用、何时用。例如「在处理 React 应用时使用该技能」。

2. 写指令而非散文

不要写「Interactions API 因为能处理会话状态所以推荐用于多轮对话」这种模糊表述，而要写「在构建聊天应用时使用 Interactions API」——给模型明确的指令性引导。

3. 保持精简，分层组织信息

描述是你在每次模型调用时都要支付的成本（约 100–200 token）。技能主体在被读取时也会进入上下文。因此要尽量精简，把深度内容放进引用文件。比如多云部署场景，应把 AWS、Google Cloud、Azure 的部署说明分别做成引用文件，而非塞进主文件。

4. 设定恰当的自由度

如果流程是固定不变的「第一步、第二步、第三步」，那就不该用技能，而该写脚本。技能应该定义目标和约束，而不是精确的操作步骤——模型知道该怎么做。

5. 不要跳过负面案例

我们总在关注「何时使用技能」，却忽视「何时不该使用」。如果描述写成「用于 Web 开发任务」，模型可能过度触发；如果写成「仅用于 React 组件或 Tailwind CSS」，模型就能精准判断。

6. 尽早测试

每创建一个新技能，就写 10–20 个测试提示：5 个正面路径（应触发），5 个负面路径（不应触发），如果有生产环境的真实数据就更好——没有什么比真实世界数据更宝贵。

7. 消灭 No-ops

这条来自 AI 教育者 Matt 的发现：AI 生成的技能往往包含大量「空操作（no-ops）」——那些对智能体行为毫无改变的指令，比如「请编写清晰高质量的代码」。这些本就是模型的默认预期，纯属浪费 token。

8. 知道何时退役技能

技能不是永生的。模型会变强，行为会改变，环境会变化。始终运行启用与不启用技能两种评估，如果模型不触发技能也能达到目标性能，就可以放心退役它，节省 token 和维护成本。

实战案例：Gemini Interactions API 技能评估

Philip 分享了一个真实案例。团队想为 Gemini Interactions API 创建技能，由于该 API 在 Gemini 最后一次训练之后才发布，Gemini 3、3.1 甚至 3.5 对它一无所知，生成代码时还在使用旧的 Gemini 2.0。

团队为此创建了 117 个测试用例，数据来源包括真实用户生成 Gemini 代码的行为、合成用例以及用户反馈。最终，生成有效 Interactions API 代码的准确率提升到接近 90%。

只需两个简单资产

实现这套评估只用了两个东西：

1. 一个 JSON 文件，结构清晰：包含 prompt（用户输入）、language（测试 TypeScript 和 Python）、should_trigger（是否应读取技能）、以及若干 expected_checks（简单断言）。
2. 一个基础 Python 脚本，运行编程智能体（这里用的是 Gemini CLI），获取输出并解析。

关键在于，大多数检查都可以用正则表达式完成：是否用了正确的 SDK？正确的模型？正确的方法？是否使用了旧模式？这些断言运行成本极低，可以反复执行。当新模型发布时，只需更新模型 ID 即可。对于更复杂的技能，也可以引入 LLM 作为评判者（LLM as a judge），用评分标准对完整轨迹做通过/失败判定。

DeepMind 内部的技能评估机制

在 Google DeepMind 内部，每个技能都配有评估。每个测试都在干净的工作空间中运行，可定义环境、启动命令、脚本验证器，以及 LLM 评判者。

最关键的一点是：每次对技能文件的改动都会触发评估，如果评估结果没有改善，改动就不会被合并。这形成了严格的回归测试机制——你只能在改善评估或新增评估的前提下修改技能。

十条最佳实践总结

Philip 最后给出了浓缩的最佳实践清单：

1. 技能描述至关重要——50% 的失败源于技能未被正确触发，尤其在面向客户的场景中，用户提示往往过于简略。
2. 写指令而非被动信息——明确告诉智能体做什么或不做什么。
3. 包含负面测试——这是最容易被遗忘的一步。
4. 从小做起——哪怕 10–20 个样本也胜过没有。
5. 测试结果而非路径——不要测试模型是否第一轮就加载技能，而要测试它最终能否完成任务。
6. 隔离运行——编程智能体擅长「作弊」，可能从历史对话中偷取上下文而不真正使用技能。
7. 多次试验——智能体是非确定性的，每个用例跑 3–6 次以衡量可靠性。
8. 跨 harness 测试——同一技能在 Gemini 上表现优异，在 Codex 上可能很差；如果客户用不同工具，务必都要覆盖。
9. 保留评估——即使退役了技能，也别丢掉评估，用它监控模型性能，一旦发现退化就重新引入技能。
10. 检测何时退役——你会惊讶于随着模型迭代，六个月前必需的技能如今已可淘汰。

立即行动：给你的作业

Philip 给听众留了一份实操作业：挑出你最常用的技能，写 5 个测试提示（可以让编程智能体帮你分析历史轨迹找出高频技能）；搭建一个简单的评估 harness（一个 JSON/YAML 文件加一段 Python 脚本）；尝试移除 no-ops 以节省成本；并运行消融测试（ablation tests）——始终对比加载技能与不加载技能的评估结果，只有这样你才能真正判断技能是否有用、何时该退役。

核心信息只有一句：不要在没有评估的情况下发布技能。