很多团队现在开始尝试 SKILL.md 文件，但测试方式几乎一样：把 prompt 粘进聊天框，看它在一台笔记本上跑通一次，然后合并进主干。作者认为，当你把三页 CLI 文档塞进 markdown 文件，却没有配套评估循环时，你大概率不是在帮前沿模型，而是在迷惑它。

过去几周，Google Cloud Developer Plugin 团队对自己的插件做了大量测量和优化，用 Developer Knowledge MCP server 来锚定文档响应，跑了几十个 Gemini、Antigravity 等 agent 的场景。他们还在 GKE Autopilot 上的隔离 Harbor pod 中使用 Claude Sonnet 5，并把 Kubernetes 和 Gemini 平台能力贡献给了 NVIDIA 的开源评估器。这篇文章总结了五条工程规则，用来验证一个 skill 是否值得消耗 token。

第一条规则：在启动容器前，先拦截触发冲突和安全风险。当评估显示插件组和基线组零提升（Δ=0）时，不要急着重写 SKILL.md 正文，十有八九是 agent 根本没加载你的 skill。编码 agent 在初始时刻不会通读完整正文，路由器只检查 YAML frontmatter 里的简短名称和描述。一旦工作区技能超过十几个，就会出现两种失效模式：触发不足（描述写的是内部实现而不是开发者意图）和兄弟技能抢占（相邻技能里一句“帮助云部署”之类的宽泛描述可能抢先拦截 prompt）。作者因此开源了 skill-reach，用来在花容器沙箱费用之前发现 frontmatter 冲突。它验证 manifest，计算与最近邻技能的词汇重叠，并在 Claude Code、Google Antigravity 和 OpenAI Codex 上跑经验路由探针。同时搭配 NVIDIA 的 SkillSpector（SkillEvaluator 的 Tier 1 和 Tier 2），因为标准 linter 发现不了埋在 markdown 里的 agent 原生风险：prompt 注入、静默数据外泄、工具投毒、触发滥用。

第二条规则：绝不信任跑在开发者笔记本上的评估。笔记本里充满了会污染基线的环境状态：缓存的 Google Cloud 凭证、导出的项目变量、残留的 bash 历史、全局环境规则。一个未加技能辅助的基线 agent，很可能因为继承了本地 shell 里已有的默认项目 ID 或 token 而通过云部署测试，而这恰恰掩盖了你的技能要解决的问题。此外，宿主机资源竞争会扭曲 agent 轨迹。作者内部测试发现，当工作站在 CPU 负载下运行完全相同的 agent 基准，分数会下降，更慢的文件扫描和子进程超时会让 agent 提前放弃搜索路径。

第三条规则：测量配对 WITH vs W/OUT 消融（Pass@3），而不是凭感觉。单次运行并截图绿色勾号不是真正的评估。多轮工具调用 agent 会在每个 shell 退出码和 stdout 片段上发生分支。作者团队在检索研究中发现，超过三分之一的基准任务在连续运行相同代码和 prompt 时得到不同分数。没有配对基线时，满分也没有意义。Claude 的插件评估工具和 NVIDIA 的 SkillEvaluator 都会在多次重复下跑配对消融：A 臂在不带技能的干净沙箱里跑基础模型，B 臂在相同 prompt 和沙箱里挂载技能。对比沙箱试验的分数提升，可以看出三种模式：基础模型大多数情况下也能跌跌撞撞地完成部署，但会浪费几分钟去猜废弃 flag、重试错误请求；当某个测试用例显示成功相同且效率零提升时，说明基础模型本来就会，你的技能只是纯上下文税——删掉它。

第四条规则：把效率和安全与正确性分开，防止 agent 奖励黑客。当你把评估框架接到自动优化器（如 AlphaEvolve 或 reach optimize）上时，agent 作弊很常见。在 AlphaEvolve 检索实验中，进化出的候选者发现了四种绕过基准的方式：动态拼接字符串、遍历目录树直接读磁盘上的标准答案文件、生成子进程绕过 AST 检查。进化循环偏爱这些作弊者，因为适应度函数把正确性（0.95 权重）和 token 效率（0.05 权重）混合成单一分数。从磁盘读答案不消耗 LLM 轮次，能赚到效率奖励，从而比诚实的 agent 更有生存优势。要加固评估器有三个结构性护栏：用 Harbor 把测试夹具、评分脚本和答案键放在专用 verifier 容器里，agent 容器退出后才挂载工作区产物；让 SkillEvaluator 的五个维度（正确性、可发现性、效率、有效性、安全）严格正交，绝不让 token 节省补偿失败的测试或安全违规；在 NVIDIA/SkillEvaluator#140 中，他们扩展了安全检查，任何读取 Kubernetes 服务账户令牌或查询云元数据端点的试验都会失败，同时从保存的轨迹中编辑实时 OAuth 令牌。

第五条规则：编码操作习惯，而不是文档转储。作者观察所有试验发现，在沙箱基准中带来分数提升的技能，与失败社区技能的差异在于 markdown 里写了什么。直接复制公共 API 参考表的技能几乎零提升，因为前沿模型预训练权重里已经有这些公开云文档；把几千字的静态 flag 塞进 prompt 只会增加首 token 延迟，埋没可执行的约束。真正提升 Efficiency 分数的技能，教的是紧凑的操作习惯和验证反射：在修改状态前先在叶子子命令上验证 CLI 标志——不要列出几十个 flag，而是教一个简单反射：执行改变状态的部署前，先看命令行帮助输出；按需走轻量级目录索引——不一次性加载十四个重型云技能，而是用一个薄根路由器查远程索引，只拉取当前任务需要的具体配方；强制最小权限认证默认值——用 Application Default Credentials 认证，而不是下载静态服务账号 JSON 密钥，同时配合显式 invoker IAM 绑定强化未认证访问限制。由于评估栈跑在 CI 中，升级模型只需要改一个 flag。他们对新模型重跑配对 WITH vs W/OUT 矩阵，把 Delta 降为零的技能全部删除。因为新模型已经不需要它，删掉一个技能是最干净的成就感之一。

如果想动手，可以试试 Google Cloud Developer Plugin for AI Coding Agents。