既要少误触，也要少漏触
Trigger Precision 衡量被激活的任务中有多少真的需要它；Trigger Recall 衡量应该使用时有多少成功出现。正样本、负样本与模糊样本必须同时存在。
准确率 = 正确触发 ÷ 总触发召回率 = 正确触发 ÷ 应触发评价 Skill，不能只看最后一段答案
一个结果看起来不错，不代表 Skill 值得复用。评测要穿过触发、执行、输出、成本与安全，观察整个能力闭环是否可靠。
结果是否真正完成目标
完全成功、基本成功、部分成功和失败需要预先定义。判断标准来自任务，而不是来自语言是否流畅。
下游能否可靠消费
Schema 校验、字段完整、类型正确与状态明确，决定 Skill 是一段漂亮文本，还是一个可以继续组合的接口。
结构有效率 = 通过校验的输出 ÷ 总输出同一输入重复执行，关键部分不应漂移
重复三至五次，观察字段、结论、固定步骤和格式。稳定不等于措辞完全相同，而是任务契约不被随机性破坏。
异常输入是否进入可解释状态
空输入、超长输入、缺失字段、错误格式、矛盾要求和上游残缺输出，应该触发保守推断、补充信息或明确失败，而不是安静地产生错误结果。
质量提升是否值得额外代价
记录运行时间、模型调用、Tool 调用、Token、外部 API、重试和人工修改耗时。成本不能被藏在“自动化”三个字后面。
它是否像软件资产一样可以演进
职责、版本、测试集、参考资料分离和历史失败案例，决定修改一条规则时是否会污染全部能力。
先判断能不能运行，再讨论分数
可执行脚本、环境变量、网络访问、文件修改、外部发送和安装来源都需要审查。来自新仓库的 Skill 应按外部代码与依赖处理。
最小对照思想
真正要回答的是：Skill 是否比临时 Prompt 更稳定，自动选择是否接近人工指定，多 Skill 组合是否抵消了额外成本。
普通 Prompt
观察未经封装的方法能达到什么水平。
手动指定 Skill
隔离 Skill 本身的能力增益。
自动选择与组合
同时检验路由、接口、顺序和冲突处理。
评测集不是一堆正常示例
只有成功案例，会让触发、鲁棒性和恢复能力全部失去可见性。
覆盖主要使用方式，建立任务成功与结构有效的基础分布。
观察 Skill 会保守推断、追问补充，还是擅自填满缺失信息。
任务看起来相近但不应触发，用来测量误触与能力边界。
空内容、错误格式、矛盾要求、缺失字段和上游残缺输出。
重复执行每个样本运行三至五次
没有重复，标准差与稳定性没有意义；只跑一次无法区分方法问题和随机波动。
同时记录触发、完成、结构、遗漏、时间与人工修改
最终质量只是一个结果，额外重试和人工修复决定它是否具有生产价值。
历史回流失败案例进入下一版本评测集
每次修复都应留下可复现样本，让版本迭代不是凭感觉改 Prompt。