OpenAI 评测 Skill 方法论
先定义成功，再写 Skill：Outcome / Process / Style / Efficiency 四个检查点，以及为什么负样本比正样本更关键。
开篇：先定义成功，再写 Skill
OpenAI 发布了一套方法论，讲如何评测 Skill 的效果。对于做 Skill 的人值得一看。GitHub 上也有一个理念相近的 Skill 评测器 agent-skills-eval（个人维护、非官方，github.com/darkrishabh/agent-skills-eval，理念基本参照 OpenAI 标准）。
四个检查点
OpenAI 把检查项分成这四个点：
就像给学生判作业，老师不只看答案对不对（Outcome），还看解题步骤（Process）、卷面格式（Style）、有没有绕远路（Efficiency）。四个都过，才是真学会。
负样本比正样本更关键
博客里的 test-04 是个经典反例：用户只是想给现有项目“加 Tailwind”，Skill 却新建了一整个 demo app。
这种误触发比不触发更危险——因为它会动你的工作区。这是 Agent 产品里最容易被忽略的验收口径。评论区猫神王（@catgodking1）说：我们踩过坑，Skill 写成更长的 prompt，一触发就乱改仓库。负样本比正样本更重要——误触发比不触发贵十倍。
就像请了个过度热情的钟点工：你说“把桌子擦一下”，他嫌桌子旧，直接给你换了一张新桌子。活儿干了，但你的东西没了。评测时只测“能不能干活”（正样本），不测“会不会乱动手”（负样本），等于没验收。
Trace 是第一性证据
用 codex exec --json 抓 JSONL 事件流：
- 确定性检查直接读事件：跑没跑
npm install？package.json生成没？——快、可解释、能进 CI； - 模型裁判（rubric grading）只做第二层“质量”补充，不替代规则。
就像查监控而不是问嫌疑人：JSONL 事件流是行车记录仪，每一步干了什么白纸黑字；让模型自评是问司机“你开得怎么样”——只能当参考，不能当证据。
小样本（10–20 条）起步
不需要大 benchmark，10–20 条起步，四类各放几条：
- 显式触发：直接点名用 Skill（“用 $setup-demo-app 建项目”）；
- 隐式触发：不提 Skill 名，靠 description 命中（“搭个最小 React demo”）；
- 上下文触发：带真实场景噪音（“给 Responses API 做个展示 demo”）；
- 负向控制：不该触发的（如 test-04 加 Tailwind），防误触发。
主张：从 prompt craft 走向 behavior engineering
原文作者的主张，也是评论区最高赞的共识：
评论区精华
- 猫神王 @catgodking1：「先定义成功再写 skill」这句话该钉墙上。我们踩过坑：Skill 写成更长的 prompt，一触发就乱改仓库。
- 南晚 @snwiki238337 回复：对了，这就是精髓，不应当只是一个简单的 prompt 可替代的东西。
- 星火API @junbug1221：最狠的不是 Skill 不触发，是它以为该触发、真去动仓库。加 Tailwind 结果新建 demo，这种负样本不写进验收等于没验收。
术语翻卡：点卡片看解释
自测一下：点问题展开参考答案
因为没有可测量的成功标准，就无法做版本管理、回归测试和 CI。四个检查点（Outcome/Process/Style/Efficiency）把“成功”变成能测量的条目，Skill 才从一份说明书变成可工程化的单元。
说明误触发比不触发更危险：Skill 会动你的工作区。负样本（不该触发的用例）比正样本更关键，是 Agent 产品最容易被忽略的验收口径。
codex exec --json 输出 JSONL 事件流，每一步命令白纸黑字，可直接读事件做确定性检查（快、可解释、能进 CI）；模型裁判（rubric grading）只做第二层质量补充，不替代规则。
显式触发（点名用 Skill）、隐式触发（不提名靠 description 命中）、上下文触发（带真实场景噪音）、负向控制（不该触发的，防误触发）。10–20 条即可起步。