Skill 的价值不在提示词，而在可测试、可对照、可回归的工程闭环。
原文链接：AI 小老六
Agent Skill 正在变成一种新的工程资产。它看起来只是一个带有触发描述的 Markdown 文件，实际承担的是把领域经验、操作流程、工具约束和团队偏好注入 Agent 执行链路的职责。
真正的问题不在于“能不能写出一个 Skill”，而在于：这个 Skill 是否稳定改善了 Agent 的输出？它改善了什么，代价是什么，改善是否可复现？如果只能靠体感判断，一个 Skill 很容易停留在手工作坊阶段；如果能被测试、对比、统计和迭代，它才有机会进入工程体系。
Claude Code 的 skill-creator 给出的关键启发正在这里：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 的工程价值来自可测试、可对照与可回归的闭环。
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，也是在测试断言是否写对。
一次 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 把输出质量压缩为可复用的接口契约。
再好的 Skill，如果触发描述写得模糊，Agent 根本不会加载它。skill-creator 因此把 description 当作一个独立入口来评测：给一组 should-trigger 和 should-not-trigger 查询，检测模型是否会调用 Skill 或读取对应文件。
图：通过命中率和误触率优化 Skill 触发描述
这类评测适合验证“何时该加载 Skill”。对于代码风格、写作偏好、发布流程、工具使用规范这类边界较清晰的 Skill，Trigger Eval 很有价值。
但它不是万能的。很多能力增强型 Skill 需要完整上下文才会自然触发，例如“生成视频”“调用私有平台”“跑内部发布流水线”。单句查询很容易让 Agent 误以为自己可以直接写脚本解决，从而不加载 Skill。对于这类 Skill，功能 Benchmark 比 Trigger Eval 更能说明问题。
OpenAI Codex 的评测方案更强调可脚本化执行、结构化输出和 CI 集成，适合把 Agent Skill 放进传统工程流水线。Claude Code 的 skill-creator 更强调因果对照：同一任务下，有 Skill 和无 Skill 的结果差异到底是什么。
| 能力维度 | Claude Code skill-creator |
Codex 系统化 Eval |
|---|---|---|
| With/without A/B 对比 | 原生支持 | 需要自行搭建 |
| 机械 Grader | 原生流程核心 | 可通过脚本实现 |
| 多轮统计聚合 | 标准化输出 | 可接入 CI 自建 |
| Trigger Eval | 有独立优化链路 | 非核心能力 |
| 输出 Schema 约束 | 不是主要抓手 | 重点能力 |
| CI 适配 | 可做但不是中心 | 更自然 |
两者并不是谁替代谁。Claude Code 的优势在于判断“Skill 是否真的有用”，Codex 的优势在于把检查嵌入自动化流水线。一个偏因果评估，一个偏工程集成。
很多人会把 Skill 的价值理解成“让 Agent 更聪明”。这只说对了一半。更准确的说法是：Skill 把 Agent 的随机性压缩成下游可以消费的接口。
没有 Skill 时，Agent 也许能完成任务，但输出目录、文件名、字段名、日志格式每次都不同。下游脚本、评审工具、监控系统很难依赖这种产物。有 Skill 后，输出可以稳定变成 artifact + manifest + prompt/log 这类结构，团队才有机会围绕它继续自动化。
这也是为什么很多 Skill 的收益不体现在“成功率提升多少”，而体现在“结果是否可接入流水线”。对于内部 API、私有平台、需要登录才能访问的文档、网页难以抓取的控制台，Skill 还承担了知识入口的角色：没有它，Agent 甚至不知道应该从哪里开始。
开发 Skill 时，失败信号大致有三类：
| 信号 | 暴露的问题 | 应该怎么用 |
|---|---|---|
| 断言失败 | 某个输出契约没满足 | 检查是 Skill 缺规则，还是 Grader 写错 |
| 人工反馈 | 结果能用但体验不好 | 抽象成更通用的行为约束 |
| 执行轨迹 | Agent 为什么走偏 | 找到触发、工具选择或上下文缺口 |
改 Skill 最忌讳为某个失败样本写窄补丁。更好的方式是从失败里抽象底层规则：是不是输出契约不够明确？是不是工具调用顺序缺约束？是不是示例太少导致模型误解？是不是应该把重复脚本沉淀进 scripts/？
保持 Skill 精简也很重要。过长的说明会稀释注意力，让 Agent 抓不到关键约束。真正有效的 Skill 往往不是罗列所有细节，而是把不可违反的边界、可复用的流程和标准输出契约说清楚。
长期看，Skill 可能会从“告诉模型怎么做”转向“定义什么算做对”。当模型能力足够强，领域专家也许不再需要写一页页执行步骤，只要提供任务边界、成功标准、失败样例和评测集，模型就能自己推导执行方法。
在这个方向上，Eval 不再只是 Skill 的测试工具，而会逐渐成为 Skill 的一部分。SKILL.md 描述操作经验，evals.json 描述成功标准，Grader 描述可验证契约，Benchmark 描述稳定性。四者合在一起，才是一个完整的 Agent Skill 工程单元。
| 术语 | 含义 |
|---|---|
| Eval | 单个测试用例，通常由任务输入和期望断言组成 |
| Benchmark | 多个 Eval 的多轮运行与统计聚合 |
| Grader | 根据断言检查输出的评分器 |
| Comparator | 对不同输出做盲评或差异分析的评审组件 |
| Trigger Eval | 验证 Skill 是否在正确场景被加载 |
| Workspace | 存放每轮评测中间产物的临时目录 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。