搜索并分析一下claude plugin eval

搜到最匹配的是 Anthropic 官方 skill-creator 插件里的 eval 能力，不是一个已经确认叫“claude plugin eval”的独立产品。下面按这个分析；如果你指的是其他项目，可以补链接。 官方原文： https://github.com/anthropics/claude-plugins-official/blob/main/plugins/skill-creator/skills/skill-creator/SKILL.md 它的核心价值是：验证“加了 Skill，究竟有没有比不加更好”，而不只是让 Claude 帮你写一份 Skill。 一、具体怎么评测 拿视频压制 Skill 举例，测试任务可以是： “把这段视频压到指定体积以内，保留两条音轨和软字幕，不覆盖源文件。” 同一个任务跑两组：一组使用 Skill，另一组不使用。修改已有 Skill 时，则可以用旧版本作为对照。 然后检查实际产物，而不是只看 Agent 有没有说“完成了”： 输出体积是否达标；音轨、字幕是否保留；文件能否正常解码；源文件是否未被修改。 这些是结合场景举的例子，不是插件自带的视频测试。 官方流程会记录断言通过情况、耗时、token 用量，再生成结果查看页面，让人检查产物、查看指标、填写反馈。之后根据反馈修改 Skill，重新跑对照。 所以它不是单纯的“LLM 打分器”，而是一套测试执行、评分、结果展示和迭代改进流程。文档明确建议：能用程序验证的断言，就写脚本检查，不要靠模型目测。 二、它实际评估两个不同的问题 第一个是执行质量：Skill 被使用之后，任务做得好不好？ 例如视频确实变小了，但字幕丢了，这就是执行失败。它会比较通过率、时间和 token，并支持进一步做不告知版本身份的盲评。 第二个是触发准确率：该用这个 Skill 时会不会用，不该用时会不会误用？ 官方描述优化流程要求准备约 20 条正反例，尤其强调容易混淆的反例。 例如“把视频压小并保留字幕”应该触发；“解释一下视频压缩原理”虽然关键词相近，却未必需要启动压制工作流。 这两件事必须分开看：强制给 Agent 一个 Skill 测成功了，不代表实际聊天时它能正确选择这个 Skill。 三、值得借鉴的设计 最重要的是有基线。 没有“不用 Skill”这一组，测试全通过也可能只是模型本来就会做。Skill 反而可能增加 token 和执行步骤，并没有带来收益。 其次，它会看执行轨迹，而不只看最终答案。 官方要求关注无效步骤和重复劳动。例如多个测试里 Agent 都临时写同一类辅助脚本，就考虑把它沉淀进 Skill 的可复用脚本，而不是继续堆提示词。 另外，它保留人工检查。 格式正确不等于业务正确，自动断言覆盖不到的细节，仍需要人看产物。官方查看页面同时展示结果、指标和人工反馈，避免只盯着一个总分。 四、局限在哪里 它更接近 Skill 开发阶段的轻量评测工作台，不应直接理解成“整个 Claude 插件生态的完整质量保障平台”。 这份文档重点覆盖 Skill；插件里的其他组件、多个 Skill 的冲突、真实长会话中的行为，需要另外设计测试，不能由单个 Skill 的成绩代替。 测试集质量仍然由你负责。官方从两三个真实任务起步是为了快速迭代，不代表这么几个任务就能证明生产可靠性。 反复围绕同一批样例改 Skill，也容易过拟合。更可信的验证需要保留未参与修改的测试样例，并对随机性较强的任务重复运行。报告展示均值和标准差，不等于自动获得了统计显著性。 模型评分也不是真值。尤其视频质量、合同风险这类问题，需要领域工具或专家标准参与，不能让模型凭输出描述自证成功。 五、我的判断 它最有价值的不是“自动写 Skill”，而是把 Skill 从经验性提示词变成可以做对照实验的工程资产。 但它提供的是评测机制，不是你的业务标准。真正有价值的部分，仍然是你积累的真实失败案例、能够判对错的检查方法，以及从执行轨迹里提炼出的可复用流程。 因此，Skill 不是越多越好：要测新增收益，也要检查重复、冲突和维护成本。模型升级后重新跑基线；原本有帮助、现在已经没有收益的 Skill，就应该精简或淘汰。