eval-skills

评估技能

把技能当作正在测试的函数。在隔离环境中向它提供示例输入，根据优质结果的标准检查产物，并根据失败情况进行修改。只有在盲测时，评估才是可信的：执行技能的 Agent 不能带有本次对话的任何上下文，也绝不能看到预期输出。泄露任何一项，都是在教它应付测试。

所需输入——缺少就拒绝

启动任何操作前，先确认以下三项。如果有任何一项缺失或无法确定，就停下来，明确告诉用户缺的是哪一项，并说明合格的版本应是什么样。不要编造案例、猜测意图，也不要根据模糊愿望进行评估。

• 目标技能——必须能找到一个真实的 SKILL.md。如果找不到，请列出你能看到的技能，并询问用户指的是哪一个。
• 至少一个黄金案例——技能实际会收到的具体输入：屏幕截图、提示词、文件、场景。「改进 write-spec」但没有附带输入，不算案例。
• 每个案例的评判标准——说明优质产物应达到什么效果，以及哪些问题会让它变得糟糕，而不是罗列详尽的组成部分。要测试的是技能的判断力，所以不要预先列出每一项要求——那会把评估变成符合性检查，也无法测试技能能否做出良好判断。「切分后的每个部分都应能独立构建和验证，粒度应符合有能力的从业者的判断——草率地合成一个大块和毫无意义地过度拆分都算失败」就是评判者可据以判断的标准；「切分得好」则过于含糊，无法评分。不要规定固定的预期切分方案，让评判者根据标准做判断。例外情况是符合性测试类技能，它确实要求精确完成指定任务——此时明确的标准就是评判依据；标准的形式应与技能的性质相匹配。如果无法判断属于哪种情况，就询问用户。如果用户只表达了模糊愿望，却没有给出评判标准，请先引导用户明确标准，并在调用 Agent 前复述确认。

工作流

1. 验证输入并明确第一原则。 确认技能并阅读其第一原则——它的用途以及它对自身的要求；评审者会以此为依据进行评估，因此如果技能没有清楚说明这些内容，应向用户确认，而不是自行编造。在此处也确定评估模式：判断（评审者应用的标准）还是符合性（精确完成指定任务）——如果有歧义，就询问用户。然后明确每个案例的评判标准——包括结果和需要留意的问题，保持在用户关心的层面；除非技能属于符合性类型，否则绝不要把标准扩展成规定的组成部分清单。当你能用一句话说明技能的第一原则，并且每个案例都有具体输入和胜任的评审者可据以评估产物的标准时，即为完成。

2. 盲测，每个案例使用一个全新的 Agent。 隔离每次运行，避免行为异常的技能触及当前检出内容，并确保每个案例都从干净状态开始。优先从运行者的最终消息中获取产物——如果技能的输出是计划或文本，就要求它直接在消息中提供，不要写入磁盘，以免造成泄漏。如果技能必须写入文件，就给运行者一个一次性沙盒目录，作为唯一可写入的根目录，而不要使用实时仓库的工作树（工作树隔离只能保护 Git 状态，无法阻止对绝对路径或逃逸路径的写入）。每次运行后都检查实时检出内容（git status），清理运行泄漏的任何内容——隔离只能尽力而为，检查才是保障。只向运行者提供输入和使用目标技能的指令——绝不要提供评判标准、需要留意的问题、其他案例或提问的原因。当你为每个案例都拿到一个来自无上下文运行的产物，且检出内容干净时，即为完成。

3. 交由独立评审者进行判断评估。 给一位全新的评审者提供产物、评判标准和技能的第一原则——让评审者依据技能自身的意图评分，而非个人偏好；但绝不要提供预期输出，也不要说“让它通过”。评审者以这些原则为依据，作为胜任的从业者，判断作品是否达标，并明确可以指出工作过于粗略或过于细致的问题。每项判定都必须引用具体证据——引用原文或指出位置，而不是给出数字。只有当评判标准的每个部分都有基于产物的判定时，才算完成。

4. 考虑非确定性。 Agent 的表现会波动。单次通过不能作为证明。对于任何重要案例或判定处于临界状态的案例，都要重新进行盲测 2–3 次，并报告通过率。一个技能 3 次只通过 1 次，就不算修复成功。

5. 将每项失败诊断为技能缺陷还是案例不当。 未通过意味着两种情况之一：技能未能引导出预期行为（可在此处修复），或者评判标准有误——它要求技能不应做或无法表达的内容，或惩罚了技能有理由作出的合理判断（告知用户；不要为了迎合错误的标准而修改技能——那只会把错误的现实编码进去）。根据 write-skills 的失败模式指出缺陷：过早完成、完成标准模糊、缺少规则、缺少引导词、重复、沉积、战争故事、无操作。

6. 通过 write-skills 修订。 修复已指出的缺陷——同时遵守这些编写规则：先明确完成标准，再考虑增加内容；优先使用一个引导词，而不是增加更多句子；不要添加无操作内容。失败本身就是修改依据；只改失败所指向的部分。

7. 重新评估所有案例，而不只是失败的案例。 修复可能导致原本通过的案例退化。持续迭代，直到每个案例都达到其通过率标准；或者能够证明该技能在结构上无法表达某个案例——此时应报告这一点，而不是强行修改。

输出

一份简短报告：逐个案例列出通过率和指出的差距；每个失败对应的缺陷；你所做的修改（或者，如果用户要求先审核，则列出你建议的差异）；以及重新评估的结果。清楚呈现前后变化——这正是证明技能确实有所改进的依据。

规则

• 盲测不可妥协。 运行器只能看到输入。评审者只能看到产物、标准和技能的第一原则。一旦任何一方看到预期输出，评估就毫无价值。
• 测试判断力，而非符合度。 标准是工作必须达到的要求，不是答案清单。如果你发现自己在列出预期的具体内容，那就已经不是在评估技能了。
• 隔离尽力而为；全面检查才是保障。 每次运行后都要检查当前检出内容并清理泄漏，无论运行时采用了何种沙箱隔离。
• 每个案例的每次运行都使用一个全新的 Agent——不共享上下文，避免跨案例学习抬高后续案例的表现。
• 根据标准评分，而不是与其他产物比较，也不要用掩盖标准中哪些部分未达标的数字分数评分。
• 不要为了通过一个你无法辩护的案例而扭曲技能。若失败案例揭示的是标准有问题，那是一个发现，不是缺陷。