result-diagnosis

结果诊断

诊断实验结果对项目意味着什么。这项技能用于结果出现后的决策，尤其适用于结果为负、出人意料、不稳定或难以解读的情况。

在以下情况下使用这项技能：

• 某种方法没有优于基线
• 结果在不同随机种子间差异很大
• 某项指标有所改善，但另一项指标变差
• 基线意外胜出
• 图表看起来可疑
• 结果可能由实现错误、指标错误、数据问题或不公平的比较造成
• 初步实验表明需要修订算法或论文中的论断
• 用户询问“这个结果意味着什么？”或“下一步该怎么做？”

不要使用这项技能来撰写润色后的报告。诊断明确后，再与 experiment-report-writer 配合使用。

将这项技能与以下技能配合使用：

• 当诊断需要更新论断、证据、风险、行动或工作树状态时，配合 research-project-memory
• 当结果需要整理成可分享的报告时，配合 experiment-report-writer
• 当诊断指向方法修订时，配合 algorithm-design-planner
• 当诊断需要新的受控实验时，配合 experiment-design-planner
• 当下一步是重新运行、合理性检查或消融实验时，配合 run-experiment
• 当正确做法是收窄或重新界定论文论断时，配合 conference-writing-adapter

技能目录结构

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── diagnosis-taxonomy.md
    ├── evidence-audit.md
    ├── next-decision-rules.md
    ├── report-template.md
    └── triage-protocol.md

渐进式加载

• 始终阅读 references/diagnosis-taxonomy.md、references/triage-protocol.md 和 references/next-decision-rules.md。
• 检查日志、配置、指标、图表、运行记录或代码状态时，阅读 references/evidence-audit.md。
• 撰写完整诊断报告时，使用 references/report-template.md。
• 如果结果取决于当前 SOTA、基准惯例或近期基线表现，请通过网络搜索或用户提供的论文核实最新资料。

核心原则

• 先诊断，再优化。
• 将观测到的结果与解读区分开。
• 在耗费大量资源重新运行之前，优先进行简单的合理性检查。
• 将负面结果视为有价值的信息：它们可能推翻某项论断，但不一定会终结整个项目。
• 在检查实现、数据、指标、基线和选择规则之前，不要归咎于算法。
• 当反复的受控证据证伪某项论断时，不要永远归咎于实现。
• 每次诊断都应以明确决策收尾：调试、重新运行、进行消融实验、修订方法、收窄论断、撰写、搁置或终止。
• 明确记录不确定性。

第 1 步 - 明确结果和预期行为

提取以下信息：

• 实验问题及其关联的论断
• 方法和基线
• 数据集/划分
• 指标和预期方向
• 观测到的结果
• 随机种子/重复次数
• 配置、提交记录、日志、表格和图表
• 预期结果及其原因
• 该结果是否影响论文论断，还是仅用于内部调试

将模糊的输入改写为：

Expected [method] to improve [metric/diagnostic] over [baseline] on [setting], but observed [result] under [controls].

如果从未定义预期行为，请返回 experiment-design-planner。

第 2 步 - 对症状分类

阅读 references/diagnosis-taxonomy.md。

对主要症状进行分类：

• 没有改善
• 性能退化
• 不稳定或方差较大
• 指标冲突
• 增益大得可疑
• 基线意外地强
• 诊断指标与性能不一致
• 训练失败或发散
• 可复现性失败
• 图表/表格不一致
• 结果与论文叙述相矛盾

然后对可能的诊断类别进行分类：

• 实现错误
• 指标/评估错误
• 数据/划分/预处理问题
• 基线不公平或调参问题
• 随机种子方差或重复次数不足
• 优化/超参数问题
• 方法机制失效
• 规模/运行区间不匹配
• 论断/证据不匹配
• 符合预期的负面结果

第 3 步 - 收集证据

阅读 references/evidence-audit.md。

优先检查一手材料：

• 配置差异
• 运行命令
• Git 提交记录
• 日志和标准错误输出
• 指标文件
• 检查点
• 随机种子
• 数据集版本和划分哈希
• 图表和表格
• 先前的基线运行记录
• 实现改动

对缺失的证据明确标记，不要凭空猜测。

步骤 4 - 运行分类诊断

阅读 references/triage-protocol.md。

按以下顺序进行：

1. 可复现性与来源：正确的提交、配置、数据、随机种子、输出路径。
2. 指标与评估：指标方向、聚合方式、数据集划分、数据泄漏、后处理。
3. 基线公平性：预算、调参、检查点规则、数据、采样器和代码路径是否相同。
4. 实现合理性：功能标志、张量形状、梯度流、损失尺度、训练/评估模式。
5. 统计稳定性：随机种子、方差、置信区间、离群值。
6. 机制诊断：预期机制是否发生了变化。
7. 主张一致性：结果是支持、削弱还是证伪论文主张。

只有发现阻断性错误或无效比较时，才提前停止。

步骤 5 - 构建相互竞争的解释

对于每种合理的解释，请说明：

• 支持该解释的证据
• 反对该解释的证据
• 能够区分各解释的最低成本测试
• 如果该解释成立，应做出的决定

至少考虑：

• 错误
• 指标不当
• 实验设计薄弱
• 基线过强或调参不足
• 超参数问题
• 机制不成立
• 主张过于宽泛

步骤 6 - 选择下一步决策

阅读 references/next-decision-rules.md。

选择一个主要决策：

• debug：在解决错误或来源问题前，结果不可信
• rerun：结果看似合理，但统计功效不足或缺少对照
• ablate：需要隔离并检验机制
• revise-method：机制可能需要重新设计
• narrow-claim：证据支持范围更小或不同的主张
• write：证据可信度足以用于报告
• park：结果尚无定论，暂不值得投入计算资源
• kill：在公平对照下，主张或研究方向已被证伪

若基本来源信息或公平性问题尚未解决，请勿选择 write。

步骤 7 - 撰写诊断

完整报告请使用 references/report-template.md。

如果要保存到项目中且未指定路径，请使用：

docs/diagnosis/result_diagnosis_YYYY-MM-DD_<short-name>.md

必需输出：

# Result Diagnosis: [Short Name]

## Result Snapshot
## Expected vs Observed
## Symptom Classification
## Evidence Checked
## Competing Explanations
## Most Likely Diagnosis
## Decision
## Next Checks or Actions
## Claim Impact
## Project Memory Writeback

步骤 8 - 回写项目记忆

如果项目使用 research-project-memory，请更新：

• memory/evidence-board.md：记录观测结果、局限性和来源路径
• memory/provenance-board.md：当诊断取决于来源有效性时，将结果来源标记为已验证、过时、矛盾或缺失
• memory/claim-board.md：将主张标记为已支持、已削弱、已修订、需补充证据、暂定、暂缓或删除
• memory/risk-board.md：记录错误、指标风险、基线风险、机制风险或主张风险
• memory/action-board.md：记录调试、重新运行、消融、方法修订、撰写、暂缓或终止等操作
• memory/handoff-board.md：当诊断改变后续工作时，向方法设计、实验设计、论文证据或写作环节创建交接
• memory/phase-dashboard.md：当诊断推动证据产出，或使项目退回调试、方法修订或缩小主张范围时，更新当前关卡
• 工作树 .agent/worktree-status.md 中的 "Local Hot Results"：若在代码工作树中，先在此处更新；在晋升结果前，先在本地标记其已确认、已失效或已被取代
• <ProjectRoot>/memory/hot-results.md：仅当结果已确认且会改变项目级主张时，才将其晋升至此；诊断仍在进行时请勿写入此文件
• memory/decision-log.md：记录终止某项主张、改变方法或缩小范围等持久性决策

对已验证结果使用 observed，对解释使用 inferred。明确标记过时的主张。

最终检查

完成前，请确认：

• 已将观测结果与解释区分开
• 已检查来源和配置，或列明缺失项
• 已说明指标方向和聚合方式
• 已评估基线公平性
• 已考虑实现合理性检查
• 已考虑随机种子方差和重复实验
• 相关时已检查机制诊断
• 已将结果对应到具体决策
• 已明确说明对论文主张的影响
• 如存在项目记忆，已完成更新