evals-analyze

evals-analyze

此技能的作用

根据 EDD 原则 VIII（闭合生产环路），通过深入分析轨迹失败记录并将其导向正确的解决途径，促进跨职能团队能力提升并实现闭环反馈。

输出：

1. 轨迹分析 - 全面分析多轮轨迹，包括工具调用和上下文保留（EDD 原则 V）
2. 失败路由：
   • 规范失败（Agent 逻辑缺失或含糊）→ 细分（EVAL-010）：
     • 机械性问题（固定、可检查的模式）→ 修复或扩展现有评分器，或添加单元测试——使用确定性检查，而非 CDR
     • 判断缺口（缺少意图、存在歧义、需要上下文）→ 自动触发对 team-levelup 的本地调用，在 adlc branch drafts/cdr/ 中提出新的上下文规则，以修正 Agent 行为
   • 泛化失败（评分器有缺陷或缺少边缘情况覆盖）→ 将评估器待办事项追加到项目待办列表，以便持续监控。
3. 跨职能 PR - 创建 team-ai-directives PR，包含分析结果和规则更新（EDD 原则 X）

应用的关键 EDD 原则：

• 原则 VIII：闭合生产环路 - 规范失败 → 修复指令；泛化失败 → 评估器待办事项
• 原则 V：轨迹可观测性 - 完整的多轮轨迹，而不仅是输出
• 原则 X：跨职能可观测性 - PM、领域专家和 AI 工程师协作

适用场景

• 运行 /evals-validate 后：分析并解决失败
• 闭合开发环路时：将评估失败洞察转化为规则或评估器修复
• 向利益相关者汇报时：为 PM 和领域专家生成易读的摘要

不适用场景

• 尚未运行评估：先运行 /evals-validate，在 evals/results/ 中生成结果
• 简单任务：对于简单功能，闭环分析会带来额外开销

流程

用户输入

$ARGUMENTS

• --focus AREA — 将分析重点放在特定领域（例如安全性、质量、性能）
• --dry-run — 分析结果并输出报告，但跳过 PR 创建和本地技能触发

执行步骤

阶段 1：加载评估结果

• 从 evals/results/ 读取结果 JSON。
• 提取失败案例和完整的多轮对话轨迹（包括工具调用）。

阶段 2：失败分类

对每条失败轨迹进行分类：

• 规范失败：Agent 相对于其上下文而言是正确的，但规则或指令缺失、含糊或不正确。细分（EVAL-010）：
  • 机械性问题：缺口属于固定、可检查的模式（禁用 API、导入形式、文件位置、语法形式）→ 属于确定性检查范畴
  • 判断缺口：缺口需要意图、上下文或跨文件判断 → 属于上下文规则范畴
• 泛化失败：规则正确，但 Agent 仍然犯错（产生幻觉、遗漏约束，或评分器缺少边缘情况覆盖）。

阶段 3：行动路由（闭合环路）

• 对于机械性规范失败：修复或扩展现有二元评分器，或添加用于约束该模式的单元测试。不要为可机械检查的缺口提出 CDR——一次性投入编写检查，而不是在每个会话中重新推导。
• 对于判断缺口型规范失败：自动触发本地技能 /team-levelup，并将失败轨迹作为输入。这会在 adlc branch drafts/cdr/ 中创建新的规则、角色设定或示例 CDR，以修正 Agent 行为。
• 对于泛化失败：将评估器待办事项追加到 evals/results/evaluator_backlog.md，详细说明所需的评分器边缘情况更新。

阶段 4：跨职能洞察与 PR

• 在 evals/results/team_insights.md 中生成面向特定利益相关方的报告（针对 PM、领域专家和 AI 工程师定制）。
• 如果 git remote 和 gh CLI 可用，则在 team-ai-directives 中提交规则/评估变更，并创建一个草稿 PR（底层使用 team-levelup 逻辑）。

验证

• 分析并分类轨迹失败跟踪
• 将机械规范失败转交给评分器/单元测试修复（确定性检查）；将判断差距失败转交给 /team-levelup（在 adlc branch drafts/cdr/ 中提议 CDR）
• 将泛化失败记录到 evals/results/evaluator_backlog.md
• 生成利益相关方报告 evals/results/team_insights.md
• 在 team-ai-directives 中创建草稿 PR（如适用）
• 呈现最终报告摘要，并附上 PR 链接和待办事项详情