从触发信号到 A/B 基准，如何把 Skill 做成可回归工程单元

Skill 生命周期把“写说明”变成“跑闭环”skill-creator的价值不只是生成SKILL.md而是把 Skill 从创建到改进的过程拆成四个环节图Skill 从创建、评测、改进到多轮基准的反馈闭环这套流程背后的设计判断很清楚​Skill 的质量不应该由作者自证​而应该由任务执行结果反推。创建阶段产出的是初始假设Eval 阶段验证假设Improve 阶段修正假设Benchmark 阶段看修正是否在统计意义上站得住。环节核心产物工程含义CreateSKILL.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 包含 ratio9:16, passed: true, evidence: Found ratio9: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 EvalSkill 首先要被读到再好的 Skill如果触发描述写得模糊Agent 根本不会加载它。skill-creator因此把description当作一个独立入口来评测给一组 should-trigger 和 should-not-trigger 查询检测模型是否会调用 Skill 或读取对应文件。图通过命中率和误触率优化 Skill 触发描述这类评测适合验证“何时该加载 Skill”。对于代码风格、写作偏好、发布流程、工具使用规范这类边界较清晰的 SkillTrigger Eval 很有价值。但它不是万能的。很多能力增强型 Skill 需要完整上下文才会自然触发例如“生成视频”“调用私有平台”“跑内部发布流水线”。单句查询很容易让 Agent 误以为自己可以直接写脚本解决从而不加载 Skill。对于这类 Skill功能 Benchmark 比 Trigger Eval 更能说明问题。与 Codex 评测思路的差异OpenAI Codex 的评测方案更强调可脚本化执行、结构化输出和 CI 集成适合把 Agent Skill 放进传统工程流水线。Claude Code 的skill-creator更强调因果对照同一任务下有 Skill 和无 Skill 的结果差异到底是什么。能力维度Claude Codeskill-creatorCodex 系统化 EvalWith/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 往往不是罗列所有细节而是把不可违反的边界、可复用的流程和标准输出契约说清楚。从 Skill 到 Spec