skill-autobench

skill-autobench —— 根据实际使用编写评测

**约定：**参见 conventions/brain-first.md — 挖掘工作从 brain 开始。接触原始转录文件前，先搜索对话存档；未先查询 brain，绝不可声称“没有历史记录”。

**约定：**参见 conventions/model-routing.md — 默认使用低成本档进行挖掘和综合。完整的多模型评审流程需明确选择启用（见 Contract）。

自我改进循环包含三个部分：评测、变体生成器 （SkillOpt）以及回放 + 评审工具链（gbrain eval cross-modal）。生成器和评审器随 gbrain 一起提供。长期缺失的部分是评测编写者——必须有人编写评测，而根据规范生成的基准只能测试技能承诺了什么，无法测试用户实际提出了什么，或实际出了什么问题。这个技能基于现实而非臆想来编写评测。

流程

1. 挖掘——提取真实调用窗口

数据源按优先级排列：

1. Brain 对话存档——由对话存档技能填充的 conversations/ 下的页面（此数据源的硬性依赖：如果它还没有导入你的历史记录，请先运行该技能）。搜索目标技能的名称、触发短语和输出形式：

   gbrain search "<skill-name>"
   gbrain query "when did I use <skill-name> and what did I ask for"
   

2. 各工具链的会话转录（如有）——使用工具链提供的内容；不要假设目录结构。gbrain transcripts recent --full 会读取已配置的本地转录语料库（按设计仅限本地）。Claude Code 会在 ~/.claude/projects/ 下按项目保存会话 JSONL；其他工具链也有各自的会话存储。不存在的存储直接跳过即可。

针对每个匹配项，提取一个调用窗口：调用前的用户请求、调用本身，以及之后的 2 轮对话——因为修正通常出现在这里。调用后用户的修正是最有力的信号：它是真实观察到的失败模式，应成为一个 hard_fail 和一个可回放用例。

**失败即关闭：**如果所有数据源中都找不到目标技能的一次真实调用，就输出一份如实的无历史记录报告（列出检查过的数据源、执行过的查询、扫描过的窗口，以及零匹配结果），然后停止。不要编造“典型”调用。对于没有历史记录的技能，正确的工具是 gbrain skillopt <name> --bootstrap-from-skill（基于规范生成，并如实说明这一点）——见去重。

2. 综合——将窗口转化为拟议评测

根据挖掘到的窗口和当前的 SKILL.md，生成：

• 拟议的 eval_contract：目标、维度、hard_fails。维度来自观察到的请求；hard_fails 编码观察到的修正。
• 4-8 个可回放用例，每个用例的结构为 {input, expected_behavior, failure_mode_to_catch}——包含真实感的输入、可验证的预期行为，以及该用例旨在捕捉的命名失败模式。
• 规范与实际使用的差异：“规范写的是 X，用户却一再提出 Y。”

**必须添加诚实性标签。**每个维度和每个用例都要标注：

• HISTORY-IMPLIED——有真实挖掘窗口作为依据；注明对应的窗口。
• SPEC-DERIVED——仅根据 SKILL.md 推断；没有使用证据。

绝不可混淆两者。如果历史记录稀少或偏离目标，请在暂存文件顶部醒目说明（“GROUNDING WARNING：仅找到 N 个窗口，且没有窗口涉及核心路径”），不要用编造的证据凑数。

**暂存前清除隐私信息：**暂存的评测保存在技能仓库中，并可被分发。挖掘到的窗口包含真实姓名、公司和交易信息——写入文件前，将每个用例都改写为占位符 slug（alice-example、acme-example）。基于历史记录的用例应保留其结构和失败模式，但不能保留真实实体。

3. 阶段 — 始终需要人工把关

编写 skills/<name>/eval/autobench-<date>.md，并设置 frontmatter status: PENDING-HUMAN-APPROVAL。

此技能绝不会重写 SKILL.md——无论是 eval_contract、正文还是触发条件。是否合并暂存的 eval，由人工决定。（这是 Agent 必须遵守的工作流约定，并非通过机械方式强制执行的门槛。）

循环（批准后）

1. 人工审查、编辑并批准暂存的 eval；将获批的 eval_contract 明确合并到技能的 frontmatter 中。

2. 将获批的案例转换为 skills/<name>/skillopt-benchmark.jsonl 中的行， 并运行 gbrain skillopt <name>——这是 SkillOpt 表层扩展：以基于历史的基准替代从规范派生的引导基准。

3. 通过原生门槛评估输出：

   gbrain eval cross-modal --task "<what the output was meant to achieve>" --output <path>
   

4. 使用积累了更多记录后重新运行 autobench；与之前的暂存基线进行差异比较。

评审组完整性——不要轻信汇总结果

多模型评审的可靠性取决于评审组是否真实存在。容易被忽视的失败类型是：模型 ID 规范化器去掉了提供方前缀，导致每次“不同模型”调用都落到同一台主机上，于是所谓的“3 个前沿模型共识”其实只是一个模型披着外套发表意见。在信任任何多模型判定之前，请对结果对象执行以下断言：

1. 每个指定模型都返回了非空响应。 空响应或失败的槽位是评审组崩溃的首个信号。
2. 响应来自不同的提供方端点。 如果三个“不同模型”都报告同一个提供方，说明评审组已崩溃并落到同一台主机上。
3. 没有两个“不同模型”返回逐字节完全相同的输出。 如果两个名称不同的模型返回相同字节内容，它们就是同一个模型。即使提供方元数据缺失或被伪造，这项检查也能发现评审组崩溃。

当少于 2/3 的模型返回可解析分数时，gbrain eval cross-modal 已会以 2（INCONCLUSIVE）退出；字节完全相同的重复检查和不同端点检查是此技能在此基础上添加的独立后备措施。在将 PASS/FAIL 视为权威结果之前，请先对收据目录中的收据 JSON 运行这些检查。完整性检查只是针对现有结果的断言逻辑，不会自行调用模型：无需网络，也不会产生费用。

失败改进分类法——挖掘出的失败如何转化

根据成本最低且持久的修复方式，对每个挖掘出的纠正／失败案例进行分类：

类别	历史记录中的信号	持久修复
DETERMINISTIC-CODIFIABLE	LLM 后备方案反复处理相同形态的输入（正则表达式、解析、slug、日期）	转换为确定性代码，并添加永久测试用例。LLM 不是解决方案，而是为替代它的代码生成训练数据。
PROMPT-FIXABLE	纠正针对 SKILL.md 可以指定的语气、格式或遗漏内容	一个 eval 案例 + 一次 gbrain skillopt 运行
SPEC-GAP	用户持续要求规范从未承诺提供的内容	向人工反馈一条规范与使用情况之间存在差距的观察结果
ROUTING-MISS	技能针对错误的请求触发，或未能触发	一个 routing-eval.jsonl 案例，而非基准案例

改进方向：每个已修复的失败都会成为永久测试，确定性方案占比上升，LLM 后备方案占比下降。记录并改进；绝不悄悄丢弃挖掘出的失败案例。

合约

• 输入： skills/ 下存在的技能名称。
• 基底： conversations/ 归档页面（以脑记忆为先），然后是可用的各个运行环境会话记录（gbrain transcripts recent 按设计仅限本地）。没有可用基底 → 如实报告无历史记录， 绝不伪造证据。
• 输出： 一个暂存文件，路径为 skills/<name>/eval/autobench-<date>.md， status: PENDING-HUMAN-APPROVAL — 或无历史记录报告。绝不修改 SKILL.md、触发器或任何路由界面。
• 成本策略： 默认使用低成本模型进行挖掘和综合。完整的多模型评审流程（每个周期 3 个服务商槽位）须明确选择启用，且评审通过原生的 gbrain eval cross-modal 进行 — 不使用定制评审框架。
• 诚实性： 每个维度和案例都带有 SPEC-DERIVED 或 HISTORY-IMPLIED 标签；历史记录稀少时应明确标记，不得掩盖。
• 隐私： 暂存前，将挖掘出的案例改写为使用占位实体。

输出格式

---
skill: <name>
status: PENDING-HUMAN-APPROVAL
generated: <date>
substrate: { conversation_pages: N, transcript_files: M, windows: K, corrections: C }
---

# Autobench: <name> — <date>

## Grounding
<one paragraph: how much real history backs this eval; GROUNDING WARNING if thin>

## Proposed eval_contract
goal / dimensions (each labeled HISTORY-IMPLIED|SPEC-DERIVED) / hard_fails

## Cases (4-8)
### case-01 [HISTORY-IMPLIED — window ref]
input: ...
expected_behavior: ...
failure_mode_to_catch: ...

## Spec-vs-usage gaps
- spec says X; users ask Y (windows: ...)

## Fail-improve classification
- case-03 → DETERMINISTIC-CODIFIABLE (same date-format fallback, 4 windows)

失败时的处理

遇到任何 gbrain 错误 code、退出码、[AGENT] 块或通知块时，遵循代理操作者协议。本技能的具体要求：

• 如果没有任何基底能证明技能曾被真实调用：必须失败关闭。报告此情况，不得编写评估；绝不能凭空编造案例。
• 如果 gbrain eval cross-modal 或评审运行缺少密钥，或遇到 no_pricing：说明评估尚未经过评审；将草稿保留为 PENDING-HUMAN-APPROVAL。

反模式

• ❌ 自动将综合得出的评估合并到 SKILL.md。人工审核关卡是本合约的一部分。
• ❌ 将 SPEC-DERIVED 维度说成基于历史记录 — 伪造使用证据是不可饶恕的错误。
• ❌ 什么都没挖掘出来，却仍然给出信心满满的评估。要么明确失败，要么如实标记。
• ❌ 不检查三家服务商是否确实返回了彼此不同、非相同的响应，就相信“3 个模型给它打了 8/10 分”。
• ❌ 在面板完整性检查中调用模型 — 这只是针对结果对象运行的纯断言逻辑。
• ❌ 原生关卡是 gbrain eval cross-modal，却另行构建定制评审框架。
• ❌ 暂存含有真实人物或公司的挖掘案例。只能使用占位内容。

去重（明确边界）

• skill-optimizer (SkillOpt，主机端) — 针对现有基准优化技能正文；其 --bootstrap-from-skill 会根据规范派生任务。本技能根据实际使用情况编写基准，并将其送入 skills/<name>/skillopt-benchmark.jsonl — 它扩展 SkillOpt 的适用范围，绝不与之重复。交接前，请阅读 skill-optimizer SKILL.md（位于主机上，也就是其引擎所在的位置）。完全没有历史记录 → 使用 --bootstrap-from-skill，而不是本技能。
• BrainBench（gbrain eval 套件） — 评估引擎（检索、记忆一致性、校准）。本评估评估的是技能及其历史记录。
• skills/skillify/SKILL.md / skills/skill-creator/SKILL.md — 根据描述创建技能；它们不会挖掘实际使用情况。
• skills/cross-modal-review/SKILL.md / gbrain eval cross-modal — 运行评审面板；它们不编写评估。此处的面板完整性断言会验证其面板是否真实运行。
• skills/skillpack-check/SKILL.md — 审查技能结构和规范一致性，不审查行为质量。
• routing-eval.jsonl — 测试分派（是否触发了正确的技能）；autobench 测试分派之后的行为。ROUTING-MISS 发现应转至此处。