决定装哪个 Skill，先问它能否改善你的一项真实任务，而不是要凑齐几件“必装神器”。本文以虚构的社区植物图鉴项目为例：团队需要把获准的观察记录整理成可追溯条目，保留未知物种，并核对图片来源。我们将装前质量验评、能力发现、装后效果对比分开，给出可复用的验收路径，不声称已进行原文所说的真人实测。
把选择问题变成验收问题
写一个最小任务：输入十条虚构观察记录与来源清单，输出统一字段、缺失项和来源引用，不猜测未确定物种、不覆盖原始记录、不自动公开图片。列出正确性、完整性、触发行为、操作边界、耗时与调用成本。十条是演示样本数量，不是统计可靠性的充分保证。
同时保存不使用候选 Skill 的基线。原有 Agent 已能完成时，候选的价值可能是稳定格式、减少遗漏或维护流程，而不是新增能力。没有任何改进也可以选择不安装。安装数量没有适用于所有人的固定最佳值，五六个足够或五十个更强都需要任务依据。
开始前在 GitHub 检索成熟开源评估方法，参考 Promptfoo 的断言、用例与评分校准工作流。它适合维护明确行为的回归套件，采用前仍要核对维护、许可、依赖、目标连接和结果存储。配置通过不等于评估运行，模型评分也会调用实际供应商。本文提供评测设计，没有下载运行工具或替读者安装候选。
场景一：装前检查结构、来源与运行边界
先核对候选公开页、源仓库、固定版本、许可证和维护记录。名称与描述只能说明宣称用途，不能证明实际能力。读取入口文档以及它引用的脚本、资源和依赖，确认文件路径、网络目的地、凭据、写入位置、成本与失败行为。来源静态核对与运行时测试分开记录，不把“检查了文档”写成通过安全扫描。
结构检查包括元数据、清晰的触发条件、输入输出、缺失前提、引用文件能否找到，以及失败时如何报告。运行验证在隔离测试位置，用虚构数据、受限目录与明确预算，避免原图、真实名单或生产服务成为试验对象。需要安装依赖或执行外部代码时按主机要求与授权处理，格式合法不提供运行权限。
给图鉴候选设计正常、缺字段、重复来源、未知物种与无法访问图片五类输入。检查是否保留未知，是否伪造来源，是否静默丢记录，是否覆盖源文件。成功生成一个漂亮文档不足以证明完成；对照输入逐条核对字段与引用，记录预期、实际和证据。
可以用五个维度做快速筛查：任务匹配、行为正确、前提明确、操作边界和维护成本，但不要用平均分掩盖硬性失败。一个会泄露私有素材或无条件改写源文件的候选，不能靠排版高分补回来。评分细则与拒绝条件在看结果前写好，减少为了喜欢的工具调整标准。
场景二：先发现能力缺口，再寻找候选
把“帮我装好用的技能”改成具体缺口：是观察记录字段提取不稳定、图片引用不能验证、还是主机没有写文件能力？前两项可能由方法与工具改善，最后一项需要主机能力与权限，不能靠一份说明文档创造。现有功能能解决时优先复用。
检索记录包含查询词、目录、日期、候选、排除原因和待核实项。发现工具负责扩大候选范围，选择工具负责按明确任务比较，两者的角色可能重叠，不能因为名字不同就认定一定互补。找不到匹配项时如实写缺口，不用近似名称补成已核验安装链接。
对候选逐项比较前提：要求的运行环境、应用连接、支持语言、图片处理方式、数据是否出站与费用。通用 Skill 格式不表示每个主机都支持同样脚本、hook 与依赖。先检查当前主机的发现机制，再在最小任务上观察是否触发；将漏触发与误触发分开，避免只看“它提到了技能名”。
本轮 SkillPI 对 self-improving 的检索没有匹配记录；此前 prompt 查询中的候选也不能仅凭描述当作通用质量评测器。本文不将原文中的 skill-tester、skillscope 或其他名称冒充已核验平台条目。以后目录增加质量评测能力时，再核对固定来源、许可、用途与实际覆盖步骤。
场景三：装后比较触发、执行与结果
分三层验收。触发层：应该使用的任务是否激活，不相关任务是否避免加载。执行层：是否读对输入、按边界调用工具、保留失败与未知。结果层：条目是否完整、来源是否可回查、输出是否符合任务。只测结果文风无法判断技能是否真的被调用，也看不到中间副作用。
对相同任务运行基线与候选，固定模型、输入、环境和预算。保留未用于调优的新样本，必要时预算内重复运行观察波动。记录通过、失败、传输或评分错误、实际执行数量、成本、耗时与人工返工；测试一个子集后不要宣称全套通过。对照同一时段和设置，避免把模型更新收益算到 Skill 上。
优先用确定性断言检查字段、记录数、来源标识和文件范围。需要语义评分时给明确标准、单独的来源与候选输出，用已知正确和故意错误答案校准。一个裁判把错误答案也判通过，就先修裁判。评分器异常单独报告，mock 裁判只能检验接线，不能替代真实质量判断。
例如未知植物记录的正确输出应明确未知并列待补证据；自动补一个物种名即失败，即使名称格式正确。图片链接不可访问时，正确行为是标记不可核验，而不是编一个新链接。保留逐项证据，使另一个维护者能复查判定，不只交一张总分图。
特别检验“自我改进”承诺
若候选声称从错误中学习，先制造一个可控错误并给明确纠正，再开新任务测试。区分记录写入、检索命中、行为应用和最终正确四层；只看 corrections 文件追加成功，不能证明改进。加一个无关项目和一条过期规则，检验是否污染其他任务或固化旧结论。
比较无记忆、相关记忆与错误记忆的结果，记录回查与副作用。自我反思不是独立事实来源，框架、反馈质量与执行关卡都可能决定表现。没有可靠证据就不引用人物研究“证明”某个具体安装包有效，也不声称记忆方案必然比框架更快见效。
决策、保留与版本维护
给每个候选明确决定：接受、限定试用、补证或拒绝，附适用范围和证据。多个包同时写规则或触发任务可能冲突，先单个比较再测组合，不以安装多为目标。接受后保留固定版本与回滚，更新模型、依赖或技能时重跑相关回归。
不使用的候选可按主机支持方式停用或移出当前作用域，备份配置并记录位置，不未经授权批量删目录。定期复核仍在使用的能力、来源和许可。SkillPI 新增用途匹配且可验证条目后再更新关联，保留选择理由，不按热度自动替换。
FAQ 与验收报告
评测 Skill 自己可靠吗？也需要校准、来源核对与已知反例，不能因下载多就免测。能装到所有 Agent 吗？格式可移植不等于运行前提相同，主机、工具、依赖与权限都要验证。卸载容易是否说明装错没风险？不，运行造成的外部变更与数据传输不会因卸载自动撤销。
应该留几个？留能覆盖实际任务且有可解释收益的最小组合，没有统一数量。报告至少写任务、候选版本、主机、数据、评分标准、实际执行范围、失败样本、费用、决定与未解决项。本文是方法指南，未执行对候选的运行认证。
来源
三类场景依据中英文原文重新组织，使用原创植物图鉴案例，不沿用社区规模、安装量、用户引语或未经核实的效果比较。评测与裁判边界参考 Promptfoo 官方评估说明。引用资料不等于授权安装，结果共享关闭也不代表模型和评分调用不会发送数据。