aep-gen-eval

生成器／评估器模式

一种可复用的设计模式，用于诚实地评估 Agent 生成的产物。将负责创建工作的 Agent（生成器）与负责评估工作的 Agent（评估器）分开，因为 Agent 总是倾向于称赞自己的工作。

“当被要求评估自己产出的工作时，Agent 往往会自信地称赞这项工作——即使在人类观察者看来，其质量显然平平。” — Anthropic，"Harness Design for Long-Running Application Development"

双重用途：使用此技能的使用方技能会读取其 references/ 文件——评分、契约、协议、恢复和发现结果的权威存放位置；而直接调用 /aep-gen-eval 则会针对任意产物运行完整的生成／评估循环。

---

其他技能如何使用它

技能	用途	参考文件
/aep-build Phase 5	评分框架＋评估协议	scoring-framework.md、eval-protocol.md、recovery-ladder.md
/aep-launch	用于头脑风暴的维度预设	scoring-framework.md（预设部分）
/aep-validate	Agent 提示词＋发现结果格式	agent-contracts.md、findings-format.md、scoring-framework.md
/aep-build、/aep-dispatch、/aep-wrap、/aep-autopilot	失败分类、验证层级／配方、核算	verification-economics.md

---

核心原则

生成器和评估器是不同的 Agent。 自我评估会产生虚高的分数，并为问题寻找合理化说辞（上文引用的发现结果）；独立评估器则能发现生成器视而不见的问题。

扩大规模： 生成器／评估器是_对抗式验证_的典型实现。当一项任务会产生许多需要独立核查的发现结果／主张时，/aep-workflow 可将这一模式推广为由 N 个验证者／反驳者组成的扇出结构——对每项发现结果复用此技能的评分框架和发现结果格式。

---

参考文件

这些文件是 gen/eval 契约的权威来源，所有使用方（/aep-build、/aep-validate、/aep-launch）都指向这些文件。根据分支需要阅读相应文件；每个文件都自成一体。

文件	内容	何时阅读
references/scoring-framework.md	维度定义（1-5 分制）、硬性失败阈值、维度预设（UI、API、安全、数据、混合）、少样本示例、反模式	设置评估标准、评分、校准评估器
references/agent-contracts.md	生成器/评估器的角色分离、提示词模板（生成器、评估器、协议检查器）、上下文组装规则	启动评估 Agent、组装提示词
references/eval-protocol.md	评估请求/响应格式、验证 JSON 模式、评估循环（请求 → 响应 → 修复 → 重新评估）、执行上下文（Task 子代理、codex exec、tmux、工作流）、需人工介入的关卡记录	运行评估循环、跟踪验证状态
references/recovery-ladder.md	两轮恢复阶梯（相同修复 → 重新建立依据 → 人工关卡提出启用新的生成器/拆解方案），适用于第 1 轮后仍未解决的 blocking 发现	第 1 轮后仍有 blocking 发现未解决
references/findings-format.md	严重性分类（blocking/important/minor）、去重协议、呈现格式、变更日志条目格式	汇总多个 Agent 的发现、呈现结果
references/verification-economics.md	验证器放置矩阵、失败分类法 + 分类权限、环境预检、验证层级 + 两点推导、验证方案、核算传感器、防篡改证据类别	路由 FAIL、推导验证深度、核算/记录验证开销

---

独立使用

直接调用时，此技能会对任意产物运行生成/评估循环。

步骤 1：识别产物

要评估什么？选项包括：

• 文档（产品上下文、架构、设计文档）
• 代码变更（实现、PR 差异）
• OpenSpec 变更（提案、设计、规范、任务）
• 结构化文件（YAML、JSON 配置、迁移计划）

步骤 2：选择执行模式

模式	Agent	适用场景
并行	同时启动生成器和评估器	文档、设计、产品上下文——Agent 独立工作
顺序	先运行生成器，再由评估器读取生成器的成果	代码审查——评估器需要查看实现
循环	生成器 → 评估器 → 修复 → 重新评估（最多 2 轮）	主动开发——生成器可以在各轮之间修复问题

步骤 3：配置维度

阅读 references/scoring-framework.md，选择与产物匹配的预设（UI 密集型、仅 API、安全敏感型、数据管道、混合/全栈、产品/设计或文档），或定义自定义维度。预设表、硬性失败阈值和少样本校准都位于该文件中。

步骤 4：启动 Agent

阅读 references/agent-contracts.md 获取提示词模板。根据以下内容自定义模板：

• 产物内容
• 技术约束
• 验证清单（评估器应对照代码库检查的内容）

步骤 5：处理结果

阅读 references/findings-format.md，整合、分类并呈现发现，然后收敛到以下两种可核查的最终状态之一：

• **已应用修复并重新评分：**生成器应用修复，且产物通过新一轮评估，不再有任何阻塞性发现。最多进行两轮；第 2 轮后仍未解决的 blocking 发现将按照 references/recovery-ladder.md 升级处理。
• **已移交发现：**将整合后的发现写入指定路径（例如 <artifact-dir>/eval-findings.md>），供下游负责人处理。

---

设计决策

Gen/eval 作为独立的可调用技能打包，同时充当参考库，而不是并入 /aep-validate 或 /aep-launch。原因：docs/decisions/gen-eval-rationale.md。

---

下一步

运行 gen/eval 后，根据评估内容继续操作：

• 产品上下文 → /aep-dispatch
• 设计产物 → /aep-launch
• 代码 → 创建 PR 或继续执行 /aep-build
• 文档 → 发布或分享