从触发信号到 A/B 基准，如何把 Skill 做成可回归工程单元
Skill 生命周期：把“写说明”变成“跑闭环”
skill-creator的价值不只是生成SKILL.md，而是把 Skill 从创建到改进的过程拆成四个环节：
图：Skill 从创建、评测、改进到多轮基准的反馈闭环
这套流程背后的设计判断很清楚：Skill 的质量不应该由作者自证，而应该由任务执行结果反推。创建阶段产出的是初始假设，Eval 阶段验证假设，Improve 阶段修正假设，Benchmark 阶段看修正是否在统计意义上站得住。
| 环节 | 核心产物 | 工程含义 |
|---|---|---|
| Create | SKILL.md初稿 | 把隐性流程显性化 |
| Eval | 测试用例与执行记录 | 验证 Skill 是否真的改变结果 |
| Improve | 修改后的 Skill | 从失败样本中抽象通用规则 |
| Benchmark | 通过率、耗时、Token 统计 | 判断收益是否覆盖成本 |
这个闭环让 Skill 不再像“经验贴”，而更接近一个可以持续回归的软件模块。
功能评测：同一任务下的因果对照
评测 Skill 最有力的方式不是单跑一次看结果，而是让两个 Agent 面对同一个任务：一个加载 Skill，一个不加载 Skill。两者在同一环境、同一输入下独立执行，再把输出交给评分器。
图：同一任务下有无 Skill 的因果对照流程
这里的重点是“因果对照”。单次成功只能说明 Agent 这次完成了任务，不能说明 Skill 有贡献；只有看到with-skill相比without-skill在可验证指标上稳定提升，才能说这个 Skill 产生了工程价值。
evals.json通常把每个任务拆成两部分：prompt描述要完成的事，expectations描述结果必须满足哪些条件。好的 expectation 必须能被机械检查，例如文件存在、字段值正确、目录结构符合约定、输出包含必要元数据，而不是“质量很好”“效果不错”这种不可复现判断。
{ "id": "video-product-ad", "prompt": "生成一段 9:16、5 秒的产品广告视频，并保存完整产物", "expectations": [ "video.mp4 存在且非空", "manifest.json 包含 model、ratio、duration、task_id", "prompt.md 保存最终英文提示词" ] }把主观质量收敛成可检查断言，是 Skill Eval 能规模化的前提。
图：Skill 的工程价值来自可测试、可对照与可回归的闭环。
Grader：评分器要像编译器一样稳定
skill-creator中的 Grader 本质上不是“另一个大模型裁判”，而是尽量用确定性脚本检查输出。文件大小、JSON 字段、目录结构、命令退出码、日志内容，这些都比 LLM 打分更便宜、更快，也更可复现。
典型评分结果需要保持稳定字段：
{ "expectations": [ { "text": "manifest.json 包含 ratio=9:16", "passed": true, "evidence": "Found ratio=9:16 in outputs/manifest.json" } ], "summary": { "passed": 1, "failed": 0, "total": 1, "pass_rate": 1.0 } }text / passed / evidence这类字段看似琐碎，实际是后续可视化、聚合与问题追踪的接口契约。只要字段名随意变化，评测查看器和统计脚本就会失效。
更重要的是，Grader 自身也需要被迭代。常见错误不是 Skill 没做好，而是评分器只在固定目录找文件、没有递归扫描、没有识别工具自动创建的日期目录，结果把正确输出判成失败。第一次 Eval 的意义，往往不只是测 Skill，也是在测试断言是否写对。
Benchmark：平均值不够，波动同样重要
一次 Eval 只能暴露单点问题，多轮 Benchmark 才能看出稳定性。聚合脚本通常会统计with-skill和without-skill的通过率、耗时与 Token 消耗，并给出均值与标准差。
With Skill: pass 86% ± 18%, time 210s ± 75s, tokens 42k ± 11k Without Skill: pass 51% ± 31%, time 160s ± 96s, tokens 28k ± 14k Delta: +35pp pass, +50s time, +14k tokens这里的Delta才是决策依据。一个 Skill 如果多消耗 50 秒和 14k Token，只换来 2 个百分点提升，可能不值得；如果把通过率从 0% 拉到 80%，再贵也可能是唯一可行路径。
标准差同样关键。86% ± 18%和86% ± 3%的工程含义完全不同：前者说明某些任务仍然很脆，后者说明 Skill 行为已经比较稳定。Skill 的目标不是偶尔做出惊艳结果，而是把 Agent 输出压到可预期区间。
图：稳定的 Grader 把输出质量压缩为可复用的接口契约。
Trigger Eval：Skill 首先要被读到
再好的 Skill，如果触发描述写得模糊，Agent 根本不会加载它。skill-creator因此把description当作一个独立入口来评测：给一组 should-trigger 和 should-not-trigger 查询，检测模型是否会调用 Skill 或读取对应文件。
图：通过命中率和误触率优化 Skill 触发描述
这类评测适合验证“何时该加载 Skill”。对于代码风格、写作偏好、发布流程、工具使用规范这类边界较清晰的 Skill，Trigger Eval 很有价值。
但它不是万能的。很多能力增强型 Skill 需要完整上下文才会自然触发，例如“生成视频”“调用私有平台”“跑内部发布流水线”。单句查询很容易让 Agent 误以为自己可以直接写脚本解决，从而不加载 Skill。对于这类 Skill，功能 Benchmark 比 Trigger Eval 更能说明问题。
与 Codex 评测思路的差异
OpenAI Codex 的评测方案更强调可脚本化执行、结构化输出和 CI 集成，适合把 Agent Skill 放进传统工程流水线。Claude Code 的skill-creator更强调因果对照：同一任务下，有 Skill 和无 Skill 的结果差异到底是什么。
| 能力维度 | Claude Codeskill-creator | Codex 系统化 Eval |
|---|---|---|
| With/without A/B 对比 | 原生支持 | 需要自行搭建 |
| 机械 Grader | 原生流程核心 | 可通过脚本实现 |
| 多轮统计聚合 | 标准化输出 | 可接入 CI 自建 |
| Trigger Eval | 有独立优化链路 | 非核心能力 |
| 输出 Schema 约束 | 不是主要抓手 | 重点能力 |
| CI 适配 | 可做但不是中心 | 更自然 |
两者并不是谁替代谁。Claude Code 的优势在于判断“Skill 是否真的有用”，Codex 的优势在于把检查嵌入自动化流水线。一个偏因果评估，一个偏工程集成。
Skill 的真实价值：把不稳定输出变成接口
很多人会把 Skill 的价值理解成“让 Agent 更聪明”。这只说对了一半。更准确的说法是：Skill 把 Agent 的随机性压缩成下游可以消费的接口。
没有 Skill 时，Agent 也许能完成任务，但输出目录、文件名、字段名、日志格式每次都不同。下游脚本、评审工具、监控系统很难依赖这种产物。有 Skill 后，输出可以稳定变成artifact + manifest + prompt/log这类结构，团队才有机会围绕它继续自动化。
这也是为什么很多 Skill 的收益不体现在“成功率提升多少”，而体现在“结果是否可接入流水线”。对于内部 API、私有平台、需要登录才能访问的文档、网页难以抓取的控制台，Skill 还承担了知识入口的角色：没有它，Agent 甚至不知道应该从哪里开始。
Grader 与 Skill 要一起演进
开发 Skill 时，失败信号大致有三类：
| 信号 | 暴露的问题 | 应该怎么用 |
|---|---|---|
| 断言失败 | 某个输出契约没满足 | 检查是 Skill 缺规则，还是 Grader 写错 |
| 人工反馈 | 结果能用但体验不好 | 抽象成更通用的行为约束 |
| 执行轨迹 | Agent 为什么走偏 | 找到触发、工具选择或上下文缺口 |
改 Skill 最忌讳为某个失败样本写窄补丁。更好的方式是从失败里抽象底层规则：是不是输出契约不够明确？是不是工具调用顺序缺约束？是不是示例太少导致模型误解？是不是应该把重复脚本沉淀进scripts/？
保持 Skill 精简也很重要。过长的说明会稀释注意力，让 Agent 抓不到关键约束。真正有效的 Skill 往往不是罗列所有细节，而是把不可违反的边界、可复用的流程和标准输出契约说清楚。