Test：把验证与持续评估织进实现

传统 QA 常在阶段末集中发现问题；代理式开发需要更短的反馈环。每次有意义的编辑后运行相关检查，缺陷先被写成失败测试，任务完成前给出新鲜工具输出。除此之外，团队还要评估“引导代理的配置”本身：模型、提示、CLAUDE.md、Skills 或 Hooks 改变后，代理是否仍能稳定完成真实任务？

学习目标

• 能区分代码测试、任务级评估（eval）和人工判断。
• 能设计失败测试先行、持续反馈、完成前验证的闭环。
• 能从真实工作与生产事故建立可维护的 eval 集合。

核心概念

代码测试验证产品行为，例如 API 在无权限时是否拒绝；eval 验证代理在给定任务和配置下是否产生可接受结果。一个 eval 通常包含真实任务提示、隔离环境和多种接受检查：既可看测试/静态检查，也可看是否遵守策略、是否保持既有行为。它不是用另一个模型简单判断“回答好不好”。

官方手册建议从近期工作中收集约 20–50 个真实任务及已接受结果，按计划或在代理配置变化时非交互运行。通过率下降就阻止配置合并；生产事故转成永久 eval，随着模型与工作内容变化持续更新区分度。团队也可按风险与成本选择离线定期运行，而不是所有用例每次都跑。

实现内环仍应遵守可证伪顺序：先写能复现问题的失败测试并确认失败原因，再修代码而不篡改测试，随后运行相关测试、构建和静态检查。对 UI 工作，可用浏览器或截图让代理实现—观察—调整。工具的原始输出才是证据，“我检查过了”不是证据。

实践步骤

1. 把仓库的构建、测试、静态检查和必要的视觉验证命令写入 CLAUDE.md，明确完成前必须运行。
2. 缺陷任务先创建失败测试，核对错误是否来自预期症状；在修复阶段限制修改该测试。
3. 从已合并工作中抽取不同风险、语言和任务形态的 eval，不只选择容易成功的案例。
4. 为每个 eval 写独立接受条件：确定性断言优先，必须判断的部分才使用人工或独立评审代理。
5. 在 CLAUDE.md、Skills、Hooks、模型或关键提示变化时运行；保存配置版本、结果和成本。
6. 每次生产事故进入测试或 eval，并指定所有者定期淘汰失去区分度的用例。

以下是 AIKnow 自行创作的 illustrative eval card（示意评估卡），不是 Anthropic 的评估题或课程测验：

{
  "id": "expense-authz-regression",
  "task": "为报销单据检查接口增加批量模式，不改变单笔权限语义",
  "fixture": "fixtures/expense-small-repo.tar.zst",
  "checks": [
    "make test-contract 返回 0",
    "未授权批量请求全部返回 403",
    "git diff 不包含 tests/fixtures/accepted/**",
    "日志扫描不出现 receipt_text"
  ],
  "owner": "expense-platform"
}

常见误区

• 把单元测试数量当 eval 覆盖。 代码测试可能全绿，但代理仍可能误解任务、改错范围或违反策略。
• 用生产任务的提示，却没有独立接受条件。 如果期望由被测代理自己生成，评估会变成自我确认。
• 修复失败时改测试。 除非需求本身经过批准改变，否则这会抹掉证据。
• 永久冻结 eval 集合。 模型和工作分布都会变化，套件必须吸收新事故并淘汰无效用例。

动手练习

从最近三个 PR 中各抽一个任务，写成 eval 卡。为每个任务至少定义两个确定性检查和一个范围限制，再故意把一条关键 CLAUDE.md 指令改错，验证是否至少有一个 eval 会失败。最后估算全量运行成本，并设计“PR 冒烟子集 + 每夜全量”的分层策略。

要点回顾

AI 原生测试包含两个反馈环：产品代码用测试证明行为，代理配置用 eval 证明工作质量。真实任务、独立标准、故障先复现、新鲜工具输出和事故回灌让速度获得可信基础。评估结果是门禁证据，不是用来装饰仪表板的分数。

参考来源

• Anthropic / Claude 官方文章：The AI-Native SDLC playbook，重点参见 “Stage 4 — Test” 与 “Continuous evals in CI”，核验日期：2026-08-26。
• Claude 官方文档：Run Claude Code programmatically，用于核验 claude -p 非交互执行及结构化输出能力，核验日期：2026-08-26。