其他

当技能评估出现回归、未激活或「无显著改进」时…

用于诊断和修复技能评估失败（回归、功效不足、未激活、超时、无结果），先定位真实原因再决定改内容、改评估还是退役。

被复用0 次

复用有效—

置信度55%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 oliver.lin 的小呱沉淀

GDI C 35/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 37/100 ×0.15

适用场景

当技能评估出现回归、未激活或「无显著改进特定

解决思路

先获取证据再形成假设：阅读 InvestigatingResults.md 了解如何下载产物和读取 results.json；对每个失败刺激提取：权威的刺激投票 W/T/L 与单独的重复运行 W/T/L、isolated 与 plugin 两个 arm 各自的激活状态、每个失败 trial 上评判者的原话理由、是否有 trial 报错/超时/输出为空。在能引用失败 trial 和评判者理由之前不要改技能内容；harness 失败从 job log 和 spec 诊断，功效问题从 trial 记录诊断，这两类没有失败 trial 可引用，强行要求引用会误导人去改文案。
按顺序分类失败，命中第一行即停止：fixture 不构建/未被 git 跟踪/因错误原因失败/自相矛盾 → Step 4；无 results.json、'produced no results' 或 spec 从未加载 → Step 3；trial 报错、超时或输出为空 → Step 3；轨迹不匹配、trial 报错或 summary 不一致导致结论 inconclusive → Step 3（可靠性而非功效）；正向记录（如 16W/8T/1L）、比较结论明确但判定仍非通过 → Step 5；skilled arm 与 baseline arm 按构造相同 → Step 6；已激活且质量落败、评判者指出具体缺陷 → Step 7；isolated 激活但 plugin 未激活 → Step 8；两个 arm 都未激活 → Step 8；获胜但成本远高于 baseline → Step 7。只有比较结论明确（adapt.mjs 要求零报错 trial、零不匹配轨迹、summary 一致）时判定才是'已测量'结果。
排除 harness 与可靠性原因：spec 同时声明 config: 和 defaults: 会被 vally 拒绝但 job 仍退出 0，PR 评论会归咎于'瞬时基础设施'——合并为单个 defaults: 块；报错 trial 不一定是 fixture 问题，评判侧认证和 session.idle 失败从判定看完全相同，需要修 harness 而非锁 SDK 版本；对咨询性问题使用 expect_tools: [bash] 会强制 restore 或 build，把回答变成超时且无质量收益；真正的代码生成刺激约需 360s，超时产生空输出会让所有 grader 失败并掩盖真实质量信号；轨迹不匹配、trial 报错或 summary 不一致会使比较 inconclusive，剩余匹配 trial 有偏，不能当作已测量的零结果来读作功效或内容问题。

适用边界 · 注意事项

不要用于从零搭建新技能（应使用 create-skill）。
不要用于从零创建新的 eval.yaml（应使用 create-skill-test）。
不要用于修改 harness 本身（eng/skill-validator、eng/vally-adapter、evaluation*.yml）。

经验正文

当技能评估出现回归、未激活或「无显著改进」时，先分类失败原因再修复技能【适用场景】用于诊断和修复技能评估失败（回归、功效不足、未激活、超时、无结果），先定位真实原因再决定改内容、改评估还是退役。【核心做法】 1. 先获取证据再形成假设：阅读 InvestigatingResults.md 了解如何下载产物和读取 results.json；…