技能介绍

解决的问题

AI 工具、技能包与 Plugin 的「能不能用」常被混在一起判断：有人本地跑了脚本就宣布通过，有人把结构校验当成宿主环境验证，也有人只看功能表现而忽略静态风险。结果往往是发布后才发现密钥外泄、事实来源不足、触发条件过宽，或生成的 Excel、DOCX、PPTX、PDF 打开即损坏。评测本身需要一套可重复、可追溯、边界清晰的流程。

核心流程

AI 工具评测 技能把评测拆成可逐步执行的检查，并区分不同类型的「通过」：

启动与静态检查（S8）：读取 references/evaluation.md、产品 design.md、指标字典、evals/evals.json 与源码；解析 manifest、JSON、YAML、frontmatter；运行各 Skill 的官方 quick validator 与 Plugin validator；测试新增脚本；检查引用链接、占位符、密钥特征、客户信息和个人绝对路径；对生成的 Office 文档与包做真实打开或解析检查。静态失败时停止打包。
行为评测（S9）：覆盖正向触发、负向触发、边界行为、输出质量、A/B 对照与重复试验；尽量用机器断言，主观质量交给不了解实现细节的独立 Judge，Judge 不修改源码。
安全硬闸门：任一成立即不通过——泄露密钥、真实客户身份或未授权个人信息；绕过数据、外部发布或写操作权限；来源不足却写成确定事实；高风险任务缺少降级或人工确认；把静态检查写成真实宿主验证。安全失败不能被其他维度高分抵消。
试点与发布（S10）：指标达到阈值、独立 Judge 通过、版本与变更说明、回滚点、责任人、已知限制与宿主验证状态齐备。若生成 .plugin，先运行校验；除非单独授权，不安装、不推送、不写 Marketplace。
监测（S11）：按触发、输入、事实引用、交付物、工具调用、权限安全、环境依赖分类失败；先加入回归集再改实现并重跑旧用例；新版本保留原包和哈希。

适用边界

状态用语需严格区分：静态通过 只说明结构和确定性检查；行为通过 需说明用例、次数和阈值；宿主验证通过 必须有真实目标环境运行证据，否则只能用 runtime pending。环境中有 Luban 时可做深度审查，但 Luban 不替代创建器或官方校验器；打包、分发、上架等最终动作仍需要在真实环境中确认。