eval-harness

eval-harness

热门

Claude Code 会话的正式评估框架,实现评估驱动开发(EDD)原则

23万Star
3.5万Fork
更新于 2026/7/14
SKILL.md
readonly只读
name
eval-harness
description

Claude Code 会话的正式评估框架,实现评估驱动开发(EDD)原则

评估工具技能

一个用于 Claude Code 会话的正式评估框架,实现评估驱动开发(EDD)原则。

何时激活

  • 为 AI 辅助工作流设置评估驱动开发(EDD)
  • 定义 Claude Code 任务完成的通过/失败标准
  • 使用 pass@k 指标衡量代理可靠性
  • 为提示或代理变更创建回归测试套件
  • 跨模型版本对代理性能进行基准测试

理念

评估驱动开发将评估视为“AI 开发的单元测试”:

  • 在实现之前定义预期行为
  • 在开发过程中持续运行评估
  • 跟踪每次变更的回归
  • 使用 pass@k 指标衡量可靠性

评估类型

能力评估

测试 Claude 是否能完成之前无法完成的任务:

[能力评估:功能名称]
任务:描述 Claude 应完成的内容
成功标准:
  - [ ] 标准 1
  - [ ] 标准 2
  - [ ] 标准 3
预期输出:描述预期结果

回归评估

确保变更不会破坏现有功能:

[回归评估:功能名称]
基线:SHA 或检查点名称
测试:
  - 现有测试-1:通过/失败
  - 现有测试-2:通过/失败
  - 现有测试-3:通过/失败
结果:X/Y 通过(之前 Y/Y)

评分器类型

1. 基于代码的评分器

使用代码进行确定性检查:

# 检查文件是否包含预期模式
grep -q "export function handleAuth" src/auth.ts && echo "通过" || echo "失败"

# 检查测试是否通过
npm test -- --testPathPattern="auth" && echo "通过" || echo "失败"

# 检查构建是否成功
npm run build && echo "通过" || echo "失败"

2. 基于模型的评分器

使用 Claude 评估开放式输出:

[模型评分器提示]
评估以下代码变更:
1. 是否解决了所述问题?
2. 结构是否良好?
3. 是否处理了边界情况?
4. 错误处理是否恰当?

评分:1-5(1=差,5=优秀)
理由:[解释]

3. 人工评分器

标记需要人工审核:

[需要人工审核]
变更:描述变更内容
原因:为何需要人工审核
风险等级:低/中/高

指标

pass@k

“在 k 次尝试中至少成功一次”

  • pass@1:首次尝试成功率
  • pass@3:3 次尝试内成功
  • 典型目标:pass@3 > 90%

pass^k

“所有 k 次试验均成功”

  • 更高的可靠性标准
  • pass^3:连续 3 次成功
  • 用于关键路径

评估工作流

1. 定义(编码前)

## 评估定义:功能-xyz

### 能力评估
1. 可以创建新用户账户
2. 可以验证邮箱格式
3. 可以安全地哈希密码

### 回归评估
1. 现有登录仍然有效
2. 会话管理不变
3. 登出流程完整

### 成功指标
- 能力评估的 pass@3 > 90%
- 回归评估的 pass^3 = 100%

2. 实现

编写代码以通过定义的评估。

3. 评估

# 运行能力评估
[运行每个能力评估,记录通过/失败]

# 运行回归评估
npm test -- --testPathPattern="existing"

# 生成报告

4. 报告

评估报告:功能-xyz
========================

能力评估:
  创建用户:     通过 (pass@1)
  验证邮箱:     通过 (pass@2)
  哈希密码:     通过 (pass@1)
  总体:         3/3 通过

回归评估:
  登录流程:     通过
  会话管理:     通过
  登出流程:     通过
  总体:         3/3 通过

指标:
  pass@1:67% (2/3)
  pass@3:100% (3/3)

状态:准备审核

集成模式

实现前

/eval define feature-name

.claude/evals/feature-name.md 创建评估定义文件

实现期间

/eval check feature-name

运行当前评估并报告状态

实现后

/eval report feature-name

生成完整评估报告

评估存储

将评估存储在项目中:

.claude/
  evals/
    feature-xyz.md      # 评估定义
    feature-xyz.log     # 评估运行历史
    baseline.json       # 回归基线

最佳实践

  1. 在编码前定义评估 - 迫使对成功标准进行清晰思考
  2. 频繁运行评估 - 尽早捕获回归
  3. 随时间跟踪 pass@k - 监控可靠性趋势
  4. 尽可能使用代码评分器 - 确定性优于概率性
  5. 安全相关需人工审核 - 永远不要完全自动化安全检查
  6. 保持评估快速 - 慢速评估不会被运行
  7. 将评估与代码版本化 - 评估是一等工件

示例:添加身份验证

## 评估:添加身份验证

### 阶段 1:定义(10 分钟)
能力评估:
- [ ] 用户可以使用邮箱/密码注册
- [ ] 用户可以使用有效凭据登录
- [ ] 无效凭据被拒绝并返回适当错误
- [ ] 会话在页面重新加载后保持
- [ ] 登出清除会话

回归评估:
- [ ] 公共路由仍然可访问
- [ ] API 响应不变
- [ ] 数据库模式兼容

### 阶段 2:实现(时间不定)
[编写代码]

### 阶段 3:评估
运行:/eval check add-authentication

### 阶段 4:报告
评估报告:添加身份验证
==============================
能力:5/5 通过 (pass@3: 100%)
回归:3/3 通过 (pass^3: 100%)
状态:可以发布

产品评估(v1.8)

当行为质量无法仅通过单元测试捕获时,使用产品评估。

评分器类型

  1. 代码评分器(确定性断言)
  2. 规则评分器(正则/模式约束)
  3. 模型评分器(LLM 作为评判标准)
  4. 人工评分器(对模糊输出进行人工裁定)

pass@k 指导

  • pass@1:直接可靠性
  • pass@3:受控重试下的实际可靠性
  • pass^3:稳定性测试(所有 3 次运行必须通过)

推荐阈值:

  • 能力评估:pass@3 >= 0.90
  • 回归评估:对于发布关键路径,pass^3 = 1.00

评估反模式

  • 过度拟合提示到已知评估示例
  • 仅测量快乐路径输出
  • 在追求通过率时忽略成本和延迟漂移
  • 在发布关卡中允许不稳定的评分器

最小评估工件布局

  • .claude/evals/<feature>.md 定义
  • .claude/evals/<feature>.log 运行历史
  • docs/releases/<version>/eval-summary.md 发布快照