Eval-First 是 Agentic Engineering Skill 的核心，它要求在 AI 动手写代码前，必须先定义可量化的完成标准（done criteria）和对应的自动化评测方法。通过将大任务分解为 15 分钟内的可验证单元，并按任务复杂度在 Haiku、Sonnet、Opus 等模型间进行成本路由，这套工程模式让 AI Agent 专注于实现，而工程师掌控质量与成本，实现高效、可控的 AI 辅助编程。

AI Agent 工程模式：Eval-First 执行、任务分解与成本路由完整指南 #

让 AI 编程助手真正像工程师一样工作，而非盲目输出，需要一套严格的工程纪律。Agentic Engineering Skill 提供的正是这样一套操作模型：以 Eval-First 为前提，以任务分解为骨架，以成本路由为血脉。本指南将拆解这一模式的完整流程，并引入 Agent Eval Skill 作为横向对比的利器，帮助你将 Claude Code、Codex 等工具纳入系统化工程轨道。

1. 核心原则：Eval-First 在前，实现在后 #

传统“写完再测”的模式在 AI 编程中风险极高，容易产出大量看似正确却隐含缺陷的代码。Agentic Engineering 的首要纪律是 Eval-First：在启动任何实现之前，必须完成两件事。

第一，用结构化语言明确任务的 完成标准（Done Criteria）。这并非模糊的“实现某功能”，而是精确的、可验证的行为描述。第二，制定对应的评测方法（Eval Methods），通常是自动化测试或明确的判分命令。

例如，实现一个用户注册API，其定义应如下：

{
  "task": "实现用户注册 API",
  "done_criteria": [
    "支持邮箱和密码注册",
    "注册失败时返回明确错误码",
    "通过所有边界条件单元测试"
  ],
  "eval_methods": [
    "接口功能自动化测试",
    "安全性回归测试"
  ]
}

这个定义是后续所有工作的“契约”。AI Agent 的所有努力都必须围绕满足这份“契约”展开。

2. 实践第一步：用 YAML 任务定义构建评测契约 #

将 Eval-First 原则落地的最佳实践，是使用标准化的 YAML 格式定义任务。这不仅是给人看的文档，更是驱动自动化评测和横向对比的输入。以下是一个为 Agent Eval Skill 设计的典型任务定义：

name: add-retry-logic
description: 为 HTTP 客户端添加指数退避重试逻辑
repo: ./my-project
files:
  - src/http_client.py
prompt: |
  为所有 HTTP 请求添加指数退避重试逻辑。最多重试3次，初始延迟1秒，最大延迟30秒。
judge:
  - type: pytest
    command: pytest tests/test_http_client.py -v
  - type: grep
    pattern: "exponential_backoff|retry"
    files: src/http_client.py
commit: "abc1234"  # 固定到特定 commit，确保评测基线一致

这份 YAML 清晰定义了：

• 任务目标（prompt）
• 代码作用域（files）
• 客观的判分标准（judge）。这里混合使用了两种判分类型：pytest 用于运行自动化测试（代码型，最推荐），grep 用于检查关键模式是否存在（模式型，辅助验证）。
• 可复现的基线（commit）

将这类 YAML 文件纳入版本管理，就形成了团队的 AI 编程评测基准集。

3. 第二步：遵循 15 分钟规则进行任务分解 #

有了明确的评测契约，接下来需要将大任务拆解为 AI Agent 能独立完成的单元。核心原则是 15 分钟单元规则：每个子任务应足够小，让 AI Agent 能在约 15 分钟内完成实现并通过其独立的评测。

这种分解旨在：

• 聚焦风险：每个单元只解决一个主要风险点或功能点。
• 独立验证：每个单元完成后都可立即运行 judge，快速获得反馈。
• 便于路由：为后续为不同单元选择不同模型奠定基础。

以前面的注册 API 为例，可分解为：

1. 设计 API 路由与参数校验（低复杂度，可路由到 Haiku）
2. 实现数据库写入逻辑（中复杂度，需路由到 Sonnet）
3. 编写注册失败的错误处理（低复杂度，可路由到 Haiku）
4. 补充测试用例（中复杂度，需路由到 Sonnet）

4. 第三步：成本敏感的模型路由 #

不是所有任务都需要最强（也最昂贵）的模型。Agentic Engineering 要求根据任务单元的复杂度，智能选择模型，实现成本与效果的平衡。这需要建立一张 模型路由表。

成本控制的关键规则：始终从低成本模型（如 Haiku）开始。只有当低阶模型在预设的 judge 中明确“能力不足”，并能定位到具体的能力缺口时，才升级到更高阶模型。避免因猜测任务“可能很难”就默认使用昂贵模型。

5. 第四步：执行、评测与迭代循环 #

这是工程模式的核心执行阶段，形成一个 Eval Loop。

1. 基线评测：在 AI 实现前，先对现有代码或空实现运行一次 judge，记录失败特征作为基准。
2. 执行实现：将分解后的子任务交给路由好的 AI Agent 执行。
3. 结果评测：实现后，重新运行 judge，对比前后差异（delta）。
4. 迭代决策：若未通过，分析失败原因。是任务描述不清？是模型能力不足？还是评测标准有误？根据原因调整任务、升级模型或优化 judge，然后重复循环。

每次执行都应记录结构化日志，便于后续分析：

{
  "unit": "数据库写入",
  "baseline_eval": "无法连接数据库",
  "post_impl_eval": "插入数据成功，但未处理唯一键冲突",
  "model_used": "Sonnet",
  "token_used": 1800,
  "status": "partial_success",
  "next_action": "细化需求，增加对唯一键冲突的错误处理子任务"
}

6. 第五步：多 Agent 横向对比与持续验证 #

当项目引入多个 AI 编程助手（如同时测试 Claude Code 和 Aider）时，需要科学的横向对比工具。此时，Agent Eval Skill 与 Agentic Engineering 模式完美结合。

你可以使用之前定义的 YAML 评测基准集，对不同 Agent 进行自动化隔离测试：

agent-eval run --task tasks/add-retry-logic.yaml --agent claude-code --agent aider --runs 3

每个 Agent 会在独立的 Git worktree 中执行，确保环境纯净。最终生成的对比报告是数据驱动的决策依据：

Task: add-retry-logic (3 runs each)
┌──────────────┬───────────┬────────┬────────┬─────────────┐
│ Agent        │ Pass Rate │ Cost   │ Time   │ Consistency │
├──────────────┼───────────┼────────┼────────┼─────────────┤
│ claude-code  │ 3/3       │ $0.12  │ 45s    │ 100%        │
│ aider        │ 2/3       │ $0.08  │ 38s    │  67%        │
└──────────────┴───────────┴────────┴────────┴─────────────┘

这张表清晰展示了通过率（Pass Rate）、API成本、执行时长和一致性（多次运行稳定性），为你的团队在具体项目场景下选择最合适的 Agent 提供了铁证。当模型或 Agent 版本升级后，重跑评测即可进行回归验证。

7. 第六步：人工 Review 的聚焦点 #

在 Agentic Engineering 模式下，AI 生成了大量实现代码，人工 Review 的焦点必须转移。不要浪费时间在格式、命名等可通过 Lint 自动化处理的问题上。工程师应专注于：

• 不变量与边界条件：核心逻辑是否可能被破坏？极端输入如何处理？
• 错误处理与安全假设：故障场景是否被妥善处理？安全假设是否成立？
• 隐性耦合与发布风险：改动是否引入了不可见的依赖？上线回滚方案是否就绪？

这套模式也推动了团队协作范式的进化。对于那些 AI 生成代码占主导的团队，可以进一步引入 AI-First Engineering Skill，系统性地重构需求规划、架构设计、代码评审和测试流程，使其完全适配 AI 主导实现的新现实。

8. 会话管理与成本追踪 #

• 会话管理：强相关的任务单元建议在同一会话连续处理，以维持上下文。完成一个阶段性里程碑（如一个完整功能）后，应开启新会话，避免上下文过长导致质量下降。
• 成本追踪：为每个子任务记录模型类型、Token 消耗、重试次数、耗时和最终状态。定期分析这些数据，可以持续优化任务分解粒度和模型路由策略，形成持续改进的闭环。

通过 Agentic Engineering Skill 定义的这套工程模式，你将 AI 编程助手从一个不可预测的“灵感工具”，转变为一个可靠、可审计、可优化的“AI 工程师”。它结合了自动化效率与工程纪律，是当前利用 AI 进行生产级软件开发的最优实践路径之一。若想全面了解 Everything Claude Code 的生态，可参阅完全指南。

FAQ #

Q: Eval-First 和传统的“测试驱动开发（TDD）”有什么区别？ A: 目的相似，但阶段和重点不同。TDD 是在人类编码前写测试，驱动实现。Eval-First 是在 AI 编码前，为 AI 定义包含完成标准和评测方法的“契约”，驱动 AI 的整个实现过程，评测范围也更广（可能包含 LLM 判分）。

Q: 15 分钟规则是必须严格遵守的时间限制吗？ A: 不是绝对的物理时间，而是一个原则性指导。它旨在强调任务单元必须“小而聚焦”，确保 AI 能在合理的上下文窗口和注意力范围内完成一个可独立验证的工作包，避免范围蔓延。

Q: 如何开始为自己的项目构建第一个评测任务（YAML）？ A: 从一个你非常熟悉、中等复杂度的功能点或修复工单开始。严格遵循 YAML 结构，judge 部分优先使用你项目已有的自动化测试命令（如 npm test、pytest）。先跑通一个完整流程，再逐步扩充基准集。