Skills 评估实践指南
> 来源：Philipp Schmid（Google DeepMind）在 AI Engineer World's Fair 2026 演讲，由"数字开物"记录。
> 核心信条：无评估，不发布（No evaluation, no release）。
SkillBench 索引 GitHub 超 5 万个 Skills，发现几乎所有都缺乏评估机制——AI Agent 行为非确定性，任务失败时无法判断是 Skills 质量低还是任务超模型能力。本技能把演讲的核心框架、原则、反模式和实战方法结构化提取，供编写和评估 Skills 时直接调用。
核心框架
框架一：渐进式信息披露（Progressive Disclosure）
Skills 的三层信息架构，最小化上下文开销：
| 层级 | 内容 | 何时加载 |
|---|---|---|
| 第一层 | 标题 + 描述（20–50 字） | 每次交互，硬塞上下文（100–200 Token 固定成本） |
| 第二层 | SKILL.md 主体 | 模型判断需要时加载 |
| 第三层 | 参考文件 | 模型按需探索获取 |
编写原则：描述精简且指令式（"为什么+怎么做"），不写模糊陈述；主体简明有层次；长内容拆到参考文件（如多云部署拆 AWS/GCP/Azure 独立文档）。
框架二：Skills 两类分法
| 类型 | 定义 | 生命周期 | 评估目的 |
|---|---|---|---|
| 能力型 | 教模型完成当前无法稳定胜任的任务 | 短期，随模型迭代终将废弃 | 明确下线时机 |
| 偏好型 | 固化团队/公司私有知识（规范、流程） | 长期 | 保护防性能退化 |
框架三：SkillBench 评估
- 索引 GitHub 超 5 万 Skills，深入分析发现几乎全部缺乏评估
- 关键指标：引入 Skills 平均 +15% 性能提升（跨语言近百种任务）
- 但 50% 的 Skills 调用失败源于触发逻辑异常（不是内容差，而是描述让模型误判了何时调用）
- 结论：描述质量 > 主体内容质量
框架四：评估 Harness 设计
Gemini 交互 API Skills 的实战案例：
- 资产：JSON 配置（prompt / language / should-trigger / 校验规则） + 极简 Python 脚本引擎
- 校验利器：正则表达式（SDK 正确性、版本号、方法名、旧范式检测）
- 成本极致：无需 LLM 裁判；新模型发布仅改 ID 即可无缝衔接
- DeepMind 内部流程：每 Skill 挂专属测试链路 → 沙箱隔离 → Diff 变更自动触发评估 → 未提升通过率则拒 Merge
→ 详见 references/evaluation-harness.md
关键原则
- 无评估，不发布——没有评估的 Skill 就是在盲烧 Token。
- 结果导向，不限制路径——无论第 1 轮还是第 5 轮触发，完成任务即可；反对僵化分步工作流（固定流程用传统脚本）。
- 手写优于 AI 生成——AI 生成的 Skill 可能"负面优化"；
skill.md应控制在 500 行或 500 字以内，超出需审查。 - 描述 > 主体——50% 失败归咎触发逻辑异常，描述必须指令式、清晰、不模糊。
- 测试多次应对非确定性——单用例须反复运行 3–6 次。
- 评估用例是资产——即使 Skill 下线，评估用例须长期保留，巡检模型性能退化，可随时重新启用。
- 删冗余指令 = 省 Token——每分钱不该花在无意义的 no-ops（无效操作）上。
- 手动调用被严重低估——工作流任务（创建 PR、暂存文档）最适合手动触发，不因上下文开销排斥。
→ 10 条最佳实践完整版见 references/best-practices.md
反模式
| 反模式 | 表现 | 正确做法 |
|---|---|---|
| 🚫 "凭感觉测试" | 跑几次觉得还行就上线 | 准备 10–20 用例（5 正常 + 5 反面），每条跑 3–6 次 |
| 🚫 AI 生成不审查 | 全文 AI 生成直接发布 | 手写核心逻辑，AI 辅助填充，500 行上限审查 |
| 🚫 僵化分步工作流 | Skill 里写死步骤 1→2→3 | 定义"目标与约束"，路径留模型自主判断 |
| 🚫 描述写模糊陈述 | "该 Skill 用于代码相关操作" | "当用户需要追踪日志时，使用此 Skill 逐行扫描错误模式" |
| 🚫 no-ops 冗余指令 | "请仔细思考后再回答" "务必确保准确性" | 用 Matt 开源工具剔除无效操作指令 |
| 🚫 评估随 Skill 下线而废 | Skill 下线后删掉评估 | 评估用例长期保留，持续巡检 |
| 🚫 单次测试就结论 | 跑一次通过就认为稳定 | 3–6 次重复运行，非确定性须量化 |
| 🚫 不做消融实验 | 从不对比开/关 Skill 的表现差异 | 定期消融实验，明确 Skill 的真实贡献 |
→ 数据与案例见 references/data-and-cases.md
快速决策指南
| 场景 | 推荐做法 |
|---|---|
| 写新 Skill | 手写核心 + 描述指令式 + 500 行上限 + 参考文件分层 |
| 怀疑 Skill 质量 | 10–20 用例测试 + 消融实验对比开/关 |
| Skill 触发失败 | 优先审查描述（50% 失败在此），改为指令式"为什么+怎么做" |
| Token 开销过大 | 剔除 no-ops + 描述精简到 20–50 字 + 参考文件外置 |
| Skill 应否下线 | 消融实验确认无贡献 → 下线，但保留评估用例 |
| 工作流类任务 | 用手动触发，不走模型自主触发 |
| 新模型发布评估 | Harness 换模型 ID → 跑全量用例 → 对比通过率 |
参考文件
- references/best-practices.md — 10 条最佳实践 + 8 条编写经验（完整版）
- references/evaluation-harness.md — 评估 Harness 设计模式 + Gemini API 实战案例
- references/data-and-cases.md — SkillBench 数据、关键指标、成本分析
适用场景与边界
适用：编写/评估/下线 AI Agent Skills、优化 Skills Token 开销、设计评估 Harness、消融实验。
不适用：模型训练调优、通用软件测试方法论（本技能聚焦 AI Agent Skills 的特殊问题）。
