mcpField
E
evals-clarify

evals-clarify

github.com/tikalk测试与质量143180 次安装今天更新
代码仓库

关于 evals-clarify

evals-clarify 面向维护评测流程的团队,将草拟的评测标准整理为有文档记录的 goldset。它聚类失败模式、生成对抗示例,并隔离留出数据,再将已接受的标准交给评分器实现。

主要功能

  1. 01聚类并细化评测标准
  2. 02生成对抗示例
  3. 03平衡通过与失败案例
  4. 04隔离留出数据
  5. 05发布 Markdown 和 JSON goldset
  6. 06交接评分器实现

适用场景

  1. 01将草拟标准整理为已接受的 goldset
  2. 02通过新增边界案例维护数据集
  3. 03留出示例以进行无偏验证

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/tikalk/adlc-team-skills --skill evals-clarify

安装后在 Claude Code 中输入/evals-clarify确认已加载。

附带文件scripts/bash/setup-evals-clarify.shscripts/powershell/setup-evals-clarify.ps1

详细介绍

evals-clarify

此技能的作用

按照 EDD Principles III & IX 进行轴心编码,将相关失败模式归类、完善评估标准、生成对抗样例,并将已验证的草稿纳入已发布的黄金集。

输出:

  1. 归类后的标准 — 将相关模式分组为连贯的评估主题
  2. 对抗样例 — 生成攻击场景和边缘情况,以检验鲁棒性
  3. 已发布的黄金集 — 将已接受的标准及完整文档写入 evals/{system}/goldset.md
  4. 留出数据集 — 保留 20% 作为测试集,用于无偏的评估验证
  5. JSON 配置 — 自动生成供系统使用的 goldset.json
  6. 自动交接给 /evals-implement 以生成评分器

应用的关键 EDD 原则:

  • 原则 III:错误分析与模式发现——轴心编码 → 理论关系
  • 原则 IX:将测试数据视为代码——生成对抗样例、划分留出集、进行版本控制
  • 原则 II:二元通过/失败——全程保持严格的二元评估
  • 原则 I:规范驱动的契约——标准用于验证是否符合规范

适用场景

  • 运行 /evals-specify 之后:完善并接受草稿标准,将其纳入黄金集
  • 维护数据集:平衡通过/失败样例,或添加对抗样例
  • 添加留出集划分:将验证数据与训练数据隔离

不适用场景

  • 没有草稿标准:先运行 /evals-specify 以发现模式
  • 生成评分器:使用 /evals-implement 将已接受的黄金集转换为代码

流程

用户输入
$ARGUMENTS
  • --accept IDS — 接受指定的草稿 ID(例如,“EVAL-001,EVAL-003”)
  • --merge IDS — 合并相关标准(例如,“EVAL-001+EVAL-002”)
  • --split ID — 将复杂标准拆分为多个重点明确的标准
  • --holdout-ratio RATIO — 留出比例(默认值:0.2,范围:0.1-0.3)
执行步骤
步骤 0:检测轻量草稿格式

检查正在审核的草稿是否使用轻量草稿模板(其特征是 frontmatter 中包含 type、evidence、source、revisit-when 字段,且正文中包含 ## Rejected Alternatives / ## Reason 部分,但没有完整正式模板的各个部分)。

如果是轻量格式:

  1. 读取草稿中记录的字段(Context、Decision、Rejected Alternatives、Reason)
  2. 转换为完整的正式模板:
    • ADR:完整的 MADR 格式,包含 Decision Drivers、Considered Options、Pros/Cons、Constitution Alignment、Related ADRs
    • PDR:完整的 PDR 格式,包含 Market Forces、Consequences、Alternatives Considered、Links
    • ChDR:完整的 ChDR 格式,包含 Issue Links、Commits、Consequences、Evidence
    • CDR:完整的 CDR 格式,包含 Context Type、Target Module、Descriptor、Evidence
    • EVAL:完整的评估格式,包含 Error Analysis、Pass/Fail Examples、Implementation Notes
  3. 根据会话上下文补充内容(添加轻量草稿中可能省略的细节)
  4. 提交补充完善后的草稿供审核

如果已是完整格式,则按常规流程审核。

阶段 1:轴心编码与归类
  • 将相关的草稿模式分组成连贯的主题。
  • 解决重叠或重复的标准。
阶段 2:完善与生成对抗样例
  • 为每项标准生成 3-5 个对抗(攻击)样例,以检验鲁棒性。
  • 平衡通过/失败样例(约为 50/50)。
阶段 3:隔离留出集
  • 将恰好 20% 的样例隔离为预留的留出集(保存到 .adlc/memory/evals/holdout.json——按照共享布局,机器数据保存在 .adlc/ 下)。
  • 确保留出集绝不用于实现或训练。
阶段 4:发布黄金集
  • 将已接受的草稿复制到 docs/adlc/memory/evals/(共享布局的记忆根目录;只有 holdout.json 保留在 .adlc/memory/evals/holdout.json),并将状态更新为 accepted。
  • 将已发布的黄金集编译为 evals/{system}/goldset.md(人类可读)和 evals/{system}/goldset.json(机器可读)。
阶段 5:自动移交

触发 /evals-implement 以生成代码。

验证

  • 已接受的草稿存储在 docs/adlc/memory/evals/EVAL-*.md
  • evals/{system}/goldset.md 和 goldset.json 均存在
  • 留出集 .adlc/memory/evals/holdout.json 已隔离并填充
  • 所有标准均为严格的二元标准(不使用置信度分数或李克特量表)
  • 移交摘要列出已接受的标准和对抗样本数量

评论

支持 Markdown