评估框架技能 是做什么的？
Claude Code 会话的正式评估框架，实现评估驱动开发（EDD）原则。
何时激活
- 为 AI 辅助工作流设置评估驱动开发（EDD）
- 为 Claude Code 任务完成定义通过/失败标准
- 使用 pass@k 指标衡量代理可靠性
- 为提示或代理变更创建回归测试套件
- 跨模型版本对代理性能进行基准测试
理念
评估驱动开发将评估视为“AI 开发的单元测试”：
- 在实现之前定义预期行为
- 在开发过程中持续运行评估
- 跟踪每次变更的回归
- 使用 pass@k 指标进行可靠性测量
评估类型
能力评估（Capability Evals）
测试 Claude 能否完成之前无法完成的任务：
[CAPABILITY EVAL: 功能名称]
任务: Claude 应完成的任务描述
成功标准:
- [ ] 标准 1
- [ ] 标准 2
- [ ] 标准 3
预期输出: 预期结果的描述
回归评估（Regression Evals）
确保更改不会破坏现有功能：
[REGRESSION EVAL: 功能名称]
基线: SHA 或检查点名称
测试:
- 现有测试-1: PASS/FAIL
- 现有测试-2: PASS/FAIL
- 现有测试-3: PASS/FAIL
结果: X/Y 通过 (之前 Y/Y)
评分器类型
1. 代码评分器（Code-Based Grader）
使用代码进行确定性检查：
# 检查文件是否包含预期模式
grep -q "export function handleAuth" src/auth.ts && echo "PASS" || echo "FAIL"
# 检查测试是否通过
npm test -- --testPathPattern="auth" && echo "PASS" || echo "FAIL"
# 检查构建是否成功
npm run build && echo "PASS" || echo "FAIL"
2. 模型评分器（Model-Based Grader）
使用 Claude 评估开放式输出：
[MODEL GRADER PROMPT]
评估以下代码变更：
1. 是否解决了所述问题？
2. 结构是否良好？
3. 是否处理了边缘案例？
4. 错误处理是否适当？
评分: 1-5 (1=差, 5=优秀)
理由: [解释]
3. 人工评分器（Human Grader）
标记以供人工审查：
[HUMAN REVIEW REQUIRED]
变更: 变更内容的描述
原因: 为何需要人工审查
风险等级: LOW/MEDIUM/HIGH
指标
pass@k
“在 k 次尝试中至少成功一次”
- pass@1: 首次尝试成功率
- pass@3: 3 次尝试内成功
- 典型目标: pass@3 > 90%
pass^k
“所有 k 次试验均成功”
- 更高的可靠性标准
- pass^3: 连续 3 次成功
- 用于关键路径
评估工作流程
1. 定义（编码前）
## EVAL DEFINITION: feature-xyz
### 能力评估
1. 可以创建新用户账户
2. 可以验证电子邮件格式
3. 可以安全地加密密码
### 回归评估
1. 现有登录仍正常工作
2. 会话管理未更改
3. 登出流程完整
### 成功指标
- pass@3 > 90% 用于能力评估
- pass^3 = 100% 用于回归评估
2. 实现
编写代码以通过已定义的评估。
3. 评估
# 运行能力评估
[运行每个能力评估，记录 PASS/FAIL]
# 运行回归评估
npm test -- --testPathPattern="existing"
# 生成报告
4. 报告
EVAL REPORT: feature-xyz
========================
能力评估:
create-user: PASS (pass@1)
validate-email: PASS (pass@2)
hash-password: PASS (pass@1)
总计: 3/3 通过
回归评估:
login-flow: PASS
session-mgmt: PASS
logout-flow: PASS
总计: 3/3 通过
指标:
pass@1: 67% (2/3)
pass@3: 100% (3/3)
状态: READY FOR REVIEW
集成模式
实现前
/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 # 回归基线
最佳实践
- 在编码前定义评估 - 强制清晰思考成功标准
- 频繁运行评估 - 尽早发现回归
- 跟踪 pass@k 随时间变化 - 监控可靠性趋势
- 尽可能使用代码评分器 - 确定性 > 概率性
- 安全性需人工审查 - 切勿完全自动化安全审查
- 保持评估快速 - 慢速评估不会被运行
- 将评估与代码版本化 - 评估是一等工件
示例：添加身份验证
## EVAL: add-authentication
### 阶段 1: 定义（10 分钟）
能力评估:
- [ ] 用户可以使用邮箱/密码注册
- [ ] 用户可以使用有效凭据登录
- [ ] 无效凭据被拒绝并返回适当错误
- [ ] 会话在页面重新加载后保持
- [ ] 登出清除会话
回归评估:
- [ ] 公共路由仍然可访问
- [ ] API 响应未更改
- [ ] 数据库模式兼容
### 阶段 2: 实现（时间不定）
[编写代码]
### 阶段 3: 评估
运行: /eval check add-authentication
### 阶段 4: 报告
EVAL REPORT: add-authentication
==============================
能力: 5/5 通过 (pass@3: 100%)
回归: 3/3 通过 (pass^3: 100%)
状态: SHIP IT
本地框架工具
机械工具随附在 scripts/lib/eval-harness/ 中：
node scripts/eval-harness.js example
- 封装（Capsule）: 基于哈希链的日志，包含五个谱系和本地完整性检查。
- 检查（Inspection）: 源码摘要、已验证的变体路径和语法警告。
- 重放（Replay）: 声明的工具和内容寻址的固定装置。缺失的固定装置失败关闭；SE3 及以上在重放中被拒绝。记录模式调用已注册的实现，因此仅注册受信任的函数。
- 收据（Receipt）: 对封装和工件字节的离线验证，附带命名检查。
- 回顾准备（Retrospective preparation）:
node scripts/eval-harness.js capsule group <dir> [<dir> ...]分组选择 1 到 100 个明确选定、已验证的本地封装快照，这些快照来自同一任务族，按声明的评估框架版本。重复的快照只计数一次；冲突的身份或无效封装会拒绝整个报告。这是只读记录计数，不包含新的发布、评分或升级。使用小型、静态的封装。有效载荷、目录参数和原始运行/封装 ID 被省略，但任务族/版本标签逐字保留，摘要引用可链接；在共享前审查它们。操作验证仍待定。
候选执行在所有操作系统上都被禁用，因为没有实现已验证的操作系统容器后端。gate run、runGate、runVariant、直接子进程启动以及已退役的效果预加载均拒绝，并显示 gate.isolation_required。没有信任标志或调用者提供的执行器可以绕过该拒绝。该示例记录了该拒绝，并检查源码而不执行或评分。
不要将静态警告、封装收据或成功的工具测试作为候选容器或升级证据呈现。未来的门控需要独立审查的操作系统边界、受保护检查器和审计通道，以及致命的基线拒绝。请参阅 docs/architecture/eval-harness-frameworks.md。
产品评估（v1.8）
当行为质量无法仅通过单元测试捕获时，请使用产品评估。
评分器类型
- 代码评分器（确定性断言）
- 规则评分器（正则/模式约束）
- 模型评分器（LLM-as-judge 评比表）
- 人工评分器（针对模糊输出的人工裁决）
pass@k 指南
pass@1: 直接可靠性pass@3: 在受控重试下的实际可靠性pass^3: 稳定性测试（所有 3 次运行必须通过）
推荐阈值：
- 能力评估：pass@3 >= 0.90
- 回归评估：发布关键路径 pass^3 = 1.00
评估反模式
- 过度拟合已知评估示例的提示
- 仅测量快乐路径输出
- 在追求通过率时忽略成本和延迟漂移
- 在发布门禁中允许不稳定的评分器
最小评估工件布局
.claude/evals/<功能名称>.md定义.claude/evals/<功能名称>.log运行历史docs/releases/<版本>/eval-summary.md发布快照