42k+ 安装的 Claude Code 评测框架，让我重新思考 AI 开发的质量管控

为什么你的 Claude Code 需要「单元测试」

写代码前先写测试，这个理念 TDD 时代就有了。但 AI 编程时代有个新问题：怎么给 AI 的输出写「测试」？

最近我发现了一个叫 eval-harness 的 Skill，安装量 42k+，专门解决这个问题的——它把「评测」做成了 AI 开发的一等公民。

什么是 EDD？为什么它值得你认真对待

EDD（Evaluation-Driven Development，评测驱动开发）的核心思路很直接：在动手写功能之前，先定义清楚「怎样算成功」。

听起来像 TDD，但关键区别在于评测对象。传统 TDD 测的是代码本身，EDD 测的是 AI 行为——你的 Claude Code 在这个任务上到底靠不靠谱？

它的评测类型分三种：

• 能力评估：测 AI 能否完成新功能，比如「能否正确处理边界输入」
• 回归评估：确保改动不破坏已有能力，跑一遍历史测试用例
• 产品评估：当单元测试不够用时，用模型来评判输出质量

pass@k：比「成不成功」更深的指标

普通评测只问「成功还是失败」，但 eval-harness 引入了 pass@k 指标——k 次尝试中至少成功一次的概率。

• pass@1：第一次就做对，这是直接可靠性
• pass@3：3 次内成功，这是受控重试下的实际可靠性
• pass^3：连续 3 次成功，这是稳定性门槛，适合关键路径

作者建议：能力评估的 pass@3 最好超过 90%，关键路径发布要求 pass^3 = 100%。这个量化标准非常实用。

评分器：三种裁判

谁来判定 AI 做得对不对？eval-harness 给了三种方案：

• 代码评分器：用脚本做确定性检查，比如 grep 文件内容、跑 npm test。确定性最高。
• 模型评分器：让另一个 AI 来评判开放式输出，适合没有标准答案的场景。
• 人工评分器：高风险操作打上 [HUMAN REVIEW REQUIRED] 标签，强制人工复核。

实际工作流长什么样

在 Claude Code 里集成的流程很顺滑：

• /eval define feature-name：在 .claude/evals/ 下创建评测定义文件
• /eval check feature-name：运行评测，看当前状态
• /eval report feature-name：生成完整评测报告

报告里会写明：能力评测通过了几项、回归评测通过了几项、pass@k 指标是多少、状态是「可以发布」还是「需要修复」。

值得用吗

如果你经常用 Claude Code 做重要功能开发，这个 Skill 能帮你建立一套科学的评测体系。特别是做 prompt 迭代或者引入新工具时，pass@k 指标能告诉你改动的实际影响，而不是凭感觉。

GitHub 仓库里还有完整的中文文档，地址贴在下面。

GitHub 仓库

GitHub: https://github.com/affaan-m/everything-claude-code/tree/main/docs/zh-CN/skills/eval-harness