很多团队开始做 AI 评估时，会掉进两个极端。
一种是完全不测：先上线，看用户反馈，有问题再修。这个做法短期省事，长期代价很高。AI Skill 的问题往往不是"完全不能用"，而是 80% 情况看起来正常，20% 边界场景悄悄出错。
另一种是一上来就想做完整平台：黄金数据集、LLM-as-Judge、线上监控、人工复核、CI 门禁、报表系统全都规划进去。结果三个月过去，第一批可执行用例还没跑通。
对 AI Skill 来说，更合理的路线不是先建一个庞大的"评估平台"，而是先把最小闭环跑起来：
text
规则能不能被测？
测评能不能自动跑？
结论能不能用于发布？
线上失败能不能回流？这篇给出一条从 0 到 1 的路线图。它不是通用 ML benchmark 的路线，而是面向 AI Skill 的测评体系搭建方法。
四步路线图总览
text
Step 1：规则可测化
把 SKILL.md 里的规则变成 EvalCase
↓
Step 2：离线执行闭环
executor 执行，grader-report 独立评审，报告结构化输出
↓
Step 3：可信发布门禁
用 exact_match、IFR、Delta、PASS/FAIL 做发布判断
↓
Step 4：regression 活水机制
把线上失败回流成下次发布前必跑的用例这四步不是四个工具，而是四个能力层级。
你可以不用 SkillSentry，也可以自己用脚本、pytest、Langfuse、Braintrust 或 OpenAI Evals 搭类似流程。但如果你做的是 AI Skill，而不是传统模型任务，核心顺序建议不要反过来。
先让规则可测，再让流程可跑，然后让结论可信，最后让测评集持续变活。
Step 1：规则可测化
目标
把 Skill 里的自然语言规则，改造成可以被执行、被验证、被复用的测评用例。
这一步不是"先堆 50 条黄金数据"，而是先回答一个更基础的问题：
这个 Skill 到底有哪些行为必须发生，哪些行为绝对不能发生？
如果这个问题答不清，后面的通过率、报告、CI 都没有意义。
为什么第一步不是黄金数据集
传统 AI 评估常常从黄金数据集开始：
text
输入 prompt
人工标准答案
模型输出
对比得分但 AI Skill 的评估对象不是一个普通问答模型，而是一组可触发、可执行、可约束的能力规则。
所以第一步应该从 SKILL.md 出发，把规则拆成 EvalCase：
text
触发条件：什么请求应该调用这个 Skill？
排除条件：什么请求不应该调用这个 Skill？
工具调用：必须调用哪个 MCP/API/脚本？
参数约束：字段、状态、金额、时间、ID 是否正确？
输出约束：最终回复必须包含什么，不能包含什么？
失败处理：接口失败、权限不足、数据缺失时应该怎么做？黄金数据集可以是产物之一，但不是第一性目标。第一性目标是让每条关键规则都有对应的可验证场景。
具体怎么做
text
1. 通读 SKILL.md，标出所有强制规则
- 必须做什么
- 禁止做什么
- 什么时候触发
- 什么时候不触发
2. 把规则改写成 EvalCase
- prompt：用户会怎么说
- expected_behavior：期望行为
- assertions：可验证断言
- tier：事故级别
- source：来自规则、线上失败还是人工补充
3. 给断言分级
- exact_match：工具名、参数、状态码、字段值等硬标准
- semantic：解释是否合理、语气是否清楚、是否给出正确建议
- existence：只检查是否出现某类内容，不能单独作为准入依据
4. 加入负向用例
- 不该触发时不能触发
- 不该提交时不能提交
- 不该编造时不能编造最小产物
text
inputs/<skill-name>/
├── cases.md # 人读版本，方便审查
├── cases.json # 机器读版本，方便执行
└── README.md # 覆盖范围、断言口径、风险分层如果刚开始做，不需要一口气写 100 条。先写 10 到 20 条高风险用例就够：
- 核心 happy path
- 关键边界条件
- 明确禁止行为
- 线上最可能翻车的场景
验收标准
| 检查项 | 最低要求 |
|---|---|
| 核心规则覆盖 | 每条高风险规则至少 1 条用例 |
| exact_match 断言 | 能硬判的地方必须硬判 |
| 负向用例 | 至少覆盖主要误触发场景 |
| 事故分层 | 标出哪些用例失败后不能上线 |
| 可复用 | 用例能被下一步自动执行 |
独立价值
即使你暂时没有自动化执行，规则可测化本身也有价值。
它会迫使团队把"这个 Skill 应该表现好"改成"这个 Skill 在这些场景下必须做对这些事"。这一步完成后，你已经有了一套可以讨论、可以评审、可以回归的质量基准。
Step 2：离线执行闭环
目标
让测评从"人工看几条样例"变成"一条命令跑完整个闭环"。
这个闭环至少包括四件事：
text
读取用例
↓
执行 Skill
↓
保存 transcript
↓
独立评审并生成报告这里的关键不是自动化本身，而是证据链。
测评报告不能只写"模型回答得不错"。它必须能回到原始 transcript，看到模型到底读了什么、调用了什么工具、拿到了什么结果、最后怎么输出。
SkillSentry 对应机制
| 能力 | SkillSentry 中的对应 |
|---|---|
| 用例执行 | executor step / sentry-executor |
| 原始证据 | transcript 双分离格式 |
| 独立评审 | grader-report |
| 结构化结果 | grading-summary.json / session.json |
| 历史记录 | history.json |
| 回归流程 | regression 工作流复用已有用例 |
这里要特别注意：执行者不能评审自己。
如果 executor 运行完之后自己总结"我完成得很好"，这不是测评，只是自述。可信的测评必须让独立 Grader 读取证据，再按断言逐项判断。
具体怎么做
text
1. 固定输入
每次测评读取同一批 EvalCase，不临时凭感觉挑样例。
2. 固定执行
executor 对每个 case 生成独立 transcript，失败也要留下证据。
3. 固定评审
grader-report 按断言逐项判断，不允许只给总体印象分。
4. 固定输出
报告里同时保留自然语言解释和结构化 JSON 字段。产出物
text
runs/<run-id>/
├── session.json
├── transcripts/
│ ├── case-001.with_skill.md
│ └── case-002.with_skill.md
├── grading-summary.json
└── report.md验收标准
| 检查项 | 最低要求 |
|---|---|
| 一条命令跑完 | 不需要人工逐条复制粘贴 |
| 每个 case 有 transcript | 成功和失败都能追溯 |
| 评审独立 | executor 不给自己打分 |
| 结构化结果 | CI 和历史分析能读取 |
| 可重复运行 | 同一批用例能跨版本比较 |
独立价值
做到这一步，你已经能回答一个最基础但很重要的问题：
我改了 Skill 之后，有没有把原来能做对的事情改坏？
很多团队不需要一开始就做在线监控。先把离线闭环跑起来，就已经能挡住大部分"改一行 prompt，坏一片行为"的回归事故。
Step 3：可信发布门禁
目标
让测评结论真正能用于发布决策。
这一步要解决的问题不是"能不能打分"，而是：
这个分数够不够可信，能不能决定上线？
AI Skill 测评最危险的地方，是看起来有报告、看起来有通过率、看起来有结论，但这些结论其实来自模糊判断或执行者自评。
可信门禁要做三件事：
text
硬标准用代码判。
语义标准让独立 Grader 判。
发布结论读结构化指标，而不是读自然语言感觉。门禁指标怎么设计
| 指标 | 解决的问题 | 用法 |
|---|---|---|
authoritative_pass_rate |
核心通过率到底是多少 | 发布准入主指标 |
| exact_match pass rate | 硬断言有没有过 | 能脚本判就不交给 LLM |
| IFR | 事故级失败是否为 0 | S 级红线 |
| Delta | 有 Skill 是否真的更好 | 防止 Skill 帮倒忙 |
| stability | 多次运行是否稳定 | 防止单次运气好 |
不是每次测评都要跑全量指标。smoke/quick 可以更轻，full 发布前要更完整。
和通用 LLM-as-Judge 的区别
很多评估体系会把 Step 3 写成"引入 LLM-as-Judge"。这句话不够准确。
SkillSentry 的原则不是"多用 LLM Judge"，而是"只在该用的地方用"：
| 判断类型 | 推荐方式 |
|---|---|
| 工具名是否正确 | exact_match / 脚本判断 |
| 参数值是否正确 | exact_match / 脚本判断 |
| 状态码是否正确 | exact_match / 脚本判断 |
| 是否遵守流程 | transcript 证据 + Grader |
| 回复是否解释清楚 | semantic Grader |
| A/B 哪个更好 | 盲测 Comparator |
| 失败原因归因 | Analyzer 解盲分析 |
一句话：LLM Judge 不是地基，证据和断言才是地基。
发布结论
最终不要只输出"通过率 87%"。发布决策应该落到明确结论：
| 结论 | 含义 |
|---|---|
| PASS | 核心指标达标，没有事故级失败，可以发布 |
| CONDITIONAL PASS | 主路径可用，但有明确条件或低风险问题 |
| FAIL | 事故级失败、核心指标不足或明显退化，不应发布 |
CI 怎么接上
CI 不应该解析自然语言报告，而应该读取结构化结果：
text
grading-summary.json
session.json
history.json然后用确定性脚本做判断：
text
if IFR > 0:
FAIL
elif authoritative_pass_rate < threshold:
FAIL
elif delta < 0:
FAIL
else:
PASS or CONDITIONAL PASSSkillSentry 里对应的是 sentry_ci.py。它的价值不是"把测评放进 GitHub Actions"，而是把 AI Skill 的质量结论变成 CI 能识别的 exit code。
验收标准
| 检查项 | 最低要求 |
|---|---|
| exact_match 不靠 LLM 判断 | 硬断言有脚本或结构化证据 |
| 发布结论结构化 | PASS / CONDITIONAL PASS / FAIL |
| 事故级失败一票否决 | S 级 IFR 必须为 0 |
| 历史可比较 | 能看出新版本是否退化 |
| CI 可读取 | 不依赖 grep 自然语言报告 |
独立价值
做到这一步，测评体系才真正从"辅助观察"变成"发布门禁"。
它能回答管理层最关心的问题：
text
这次能不能上？
不能上，卡在哪？
如果要条件发布，条件是什么？Step 4：regression 活水机制
目标
让测评集随着真实失败持续进化。
前面三步解决的是上线前质量保障。但上线后还会遇到新的问题：
- 用户输入方式和设计时不一样；
- MCP/API 返回了没见过的异常；
- 上游字段变了；
- 模型服务更新后行为漂移；
- 某个边界场景在线上第一次出现。
这些问题不能只靠事后修复。每一次真实失败，都应该变成下一次发布前会自动执行的 regression 用例。
最小闭环
不需要一开始就搭完整线上监控平台。最小版本只要做到：
text
线上失败
↓
保存 trace / transcript
↓
人工归因
↓
补充 regression case
↓
下次发布前自动执行这就是测评集的活水机制。
回流用例怎么写
一条线上失败不应该直接复制成用例。需要先归因：
| 失败类型 | 回流方式 |
|---|---|
| 触发失败 | 补 trigger / negative case |
| 工具调用错 | 补 exact_match 参数断言 |
| 输出格式错 | 补输出模板断言 |
| 流程跳步 | 补 e2e case |
| 用户表述长尾 | 保留脱敏后的原始表达 |
| 上游异常 | 补 fallback / error handling case |
和 Step 1 的关系
Step 1 不是一次性工作。Step 4 会不断把新失败送回 Step 1。
text
初始规则 → 初始 EvalCase
线上失败 → regression EvalCase
版本迭代 → history 对比
CI 门禁 → 发布前拦截这就是闭环。
验收标准
| 检查项 | 最低要求 |
|---|---|
| 失败可追溯 | 有 trace / transcript |
| 失败可归因 | 知道是触发、执行、评审还是输出问题 |
| 用例可回流 | 能变成 regression case |
| 发布前必跑 | regression 不只是文档记录 |
| 历史可见 | history.json 能看到修复前后变化 |
独立价值
做到这一步，测评体系不再是静态资产，而是会随着真实使用不断变强的质量系统。
真正有价值的测评集，不是第一天写得多完整，而是每次线上踩坑之后都能多拦住一个坑。
四步之间的依赖关系
text
Step 1 → Step 2
规则可测化之后，离线流程才知道要执行什么、验证什么。
Step 2 → Step 3
有 transcript 和结构化结果之后，发布门禁才有可靠输入。
Step 3 → Step 4
有明确门禁之后，regression 用例才知道应该拦截什么。
Step 4 → Step 1
线上失败回流之后，初始用例集持续扩充。这四步不是线性项目，而是一个循环。
团队规模怎么适配
| 团队情况 | 建议路径 | 目标 |
|---|---|---|
| 独立开发者 | Step 1 精简版 + Step 2 手动/半自动 | 先有 10 到 20 条核心用例 |
| 2 到 3 人小组 | Step 1 到 Step 3 | 建立离线门禁和发布结论 |
| 5 人以上团队 | Step 1 到 Step 4 | 建立回流、CI、历史追踪 |
| 已有测试团队 | 从 Step 1 重审规则可测性，再接 Step 2 | 把传统用例改造成 Skill EvalCase |
最小可行版本可以很小：
text
10 条核心用例
1 条执行命令
1 份结构化报告
1 条发布红线这已经比"上线后祈祷"强很多。
SkillSentry 在四步中的位置
SkillSentry 不是把传统评估体系包装一下，而是把 AI Skill 的测评闭环产品化。
| 路线图能力 | SkillSentry 对应能力 |
|---|---|
| 规则可测化 | 从 SKILL.md 提炼规则，设计 EvalCase |
| 离线执行闭环 | executor + transcript + grader-report |
| 可信发布门禁 | authoritative_pass_rate / IFR / Delta / PASS-FAIL |
| regression 活水机制 | regression workflow / history.json / CI gate |
| 成本与效率控制 | smoke / quick / full、缓存、Token 计量 |
| 可信评审 | exact_match 脚本判断、semantic 独立 Grader、盲测对比 |
如果不用 SkillSentry，也可以照这个表自己搭。但不要跳过前两步直接做"评估平台"。没有可测规则和离线证据链，平台越复杂，结论越不可信。
常见问题
Q：我的 Skill 很简单，也需要这四步吗？
需要，但可以缩小规模。
只有 3 条规则的 Skill，也值得写 10 条 EvalCase。因为 AI Skill 的风险往往不在规则数量，而在边界场景：什么时候不该触发、什么时候不能提交、什么时候必须等待用户确认。
小 Skill 的最小版本是：
text
5 条 happy path
3 条 edge case
2 条 negative caseQ：是不是一定要先有 50 条人工黄金数据？
不一定。
对 AI Skill 来说，第一步不是追求样本量，而是追求关键规则可测。10 条高风险用例，比 100 条没有断言强度的泛泛样例更有价值。
当你的 Skill 进入稳定维护阶段，再逐步把线上失败、人工经验、真实用户输入沉淀成 Golden Set。
Q：LLM-as-Judge 到底什么时候用？
只在需要语义判断时用。
工具名、参数、状态码、字段值这些硬标准，应该优先用脚本或结构化断言判断。LLM Grader 适合判断解释是否充分、是否遵守业务语义、是否遗漏关键风险提示。
不要让 LLM Judge 做它不擅长的事，更不要让执行 Agent 给自己判卷。
Q：CI 里要跑 full 吗？
通常不建议每次 PR 都跑 full。
更实用的做法是：
| 场景 | 推荐模式 |
|---|---|
| 日常小改 | smoke |
| 合并前关键改动 | quick |
| 正式发布前 | full |
| 修线上事故后 | regression |
CI 的价值是快速拦截明显退化，不一定要替代发布前完整测评。
Q：线上监控是不是必须一开始就做？
不是。
一开始先做最小回流就够：线上出现失败后，保存 trace，人工归因，补一条 regression case。等这个闭环跑顺，再考虑抽样评估、质量日报、自动告警。
总结
从 0 到 1 搭建 AI Skill 测评体系，不要从"大而全平台"开始。
更稳的顺序是：
| Step | 核心问题 | 核心产出 |
|---|---|---|
| 1. 规则可测化 | 这个 Skill 到底测什么？ | EvalCase / 断言 / 风险分层 |
| 2. 离线执行闭环 | 能不能自动跑并留下证据？ | transcript / grader-report / report |
| 3. 可信发布门禁 | 结论能不能决定上线？ | authoritative_pass_rate / IFR / Delta / PASS-FAIL |
| 4. regression 活水机制 | 线上失败能不能反哺测评？ | regression case / history / CI gate |
一句话记住：
AI Skill 测评体系的起点不是数据量，而是规则能不能被验证；终点不是一份报告，而是每次失败都会变成下一次发布前的拦截器。