主题
07 - 结果分析
把运行结果转成可辩护发现
目标
结果分析不是“把几个数字抄到表里”，而是回答：
这些结果究竟支持了什么、不支持什么、哪些结论仍然站不住？
本章的目标是：
- 把 pilot 和主实验输出统一整理为可比较结果
- 针对
EXPERIMENT_PLAN.md里的目标 claim 做逐条判断 - 把异常、失败模式和边界条件从“感觉”变成结构化记录
- 输出一份可交给 08-自动迭代循环 和 09-论文结构 的
ANALYSIS_REPORT.md - 避免把微弱趋势、偶然结果或工程事故误写成研究结论
本章回答的问题是：
哪些 claim 已被支持，哪些仍然不充分，下一轮应该修什么、补什么、砍什么？
完成标准
完成本章，不等于“我已经有几张图”，而是至少做到：
- 你有一份经过人类复核的
ANALYSIS_REPORT.md - 你能把每条目标 claim 标成
SUPPORTED / WEAKLY_SUPPORTED / INCONCLUSIVE / UNSUPPORTED - 你能指出 strongest evidence、关键异常和失败模式
- 你能说明哪些结论只能弱说，哪些结论现在不能说
- 你能把结果交给后续 review loop 和论文结构设计
输入与标准产物
输入
建议直接使用 04-06 章的标准产物和原始结果：
| 输入 | 作用 |
|---|---|
PROBLEM_NOTE.md | 防止分析结论漂离原始问题 |
NOVELTY_REPORT.md | 回看本轮真正要支撑的 claim |
EXPERIMENT_PLAN.md | 作为分析时的对照基准 |
PILOT_LOG.csv | 提供首轮信号、重跑原因和去留决策 |
| 原始实验结果 | 训练日志、评估脚本输出、图表数据、checkpoint 记录 |
| baseline 结果 | 用于相对比较和异常校验 |
标准产物
| 产物 | 作用 | 后续会在哪用到 |
|---|---|---|
ANALYSIS_REPORT.md | 汇总 claim 状态、关键发现、异常、边界和下一步建议 | 08, 09, 11 |
这些 artifact 的统一命名、建议路径和状态定义见：附录 E
人类-智能体协作
| 阶段 | 智能体适合做什么 | 人必须负责什么 | 常见风险 |
|---|---|---|---|
| 结果归档 | 整理表格、汇总日志、统一字段 | 判断哪些结果应被视为有效证据 | 机械汇总错误结果 |
| 对比分析 | 计算 delta vs baseline、画趋势图、罗列异常项 | 决定哪些差异有研究意义 | 把统计浮动当成真实提升 |
| claim 归类 | 草拟 SUPPORTED / INCONCLUSIVE 等标签 | 对最终 claim 状态签字 | 过度乐观地给出支持结论 |
| 报告起草 | 生成发现摘要、异常说明、下一步建议 | 控制表述强度和边界 | 用流畅叙事掩盖证据不足 |
本章默认的工作方式是：
智能体可以高效整理和比较结果，但“这能不能写进论文”必须由人类决定。
结果分析真正依赖什么
好分析不是从图开始，而是从 EXPERIMENT_PLAN.md 里预先写下的问题开始。
分析时优先回到三件事：
- 本轮想回答的 claim 是什么
- 预先定义的 success / failure / invalid 是什么
- 最危险的 closest work 和 strongest objection 是什么
如果脱离这三个问题单独看数字，很容易出现“结果很多，但没有结论”的情况。
工作流
Phase 0: 先回到计划，再读结果
开始分析之前，先把 EXPERIMENT_PLAN.md 中每个 Exp ID 对应到实际运行结果。
建议建立一个最小映射：
| 字段 | 说明 |
|---|---|
exp_id | 计划中的实验编号 |
claim_id | 它服务于哪条 claim |
result_source | 原始日志、表格或脚本输出位置 |
status | completed / crashed / invalidated |
这一步能避免后面把不相关的结果也塞进主要叙事。
Phase 1: 先归一化结果，再做解释
分析的第一步不是解释，而是把结果变成统一格式。
建议至少整理成下面这种比较表：
markdown
| Exp ID | Claim | Method | Baseline | Setting | Primary Metric | Delta | Status |
|--------|-------|--------|----------|---------|----------------|-------|--------|
| E1 | C1 | Ours | Base-A | setting-1 | 86.4 | +1.8 | completed |
| E2 | C1 | Ours | Base-A | setting-2 | 84.9 | +0.3 | completed |
| E3 | C2 | Ours | Base-B | setting-3 | N/A | N/A | invalidated |统一格式后再分析，能显著减少 cherry-pick。
Phase 2: 对每条 claim 给状态，而不是只写总体感受
建议对每条目标 claim 只给以下四种状态之一：
| 状态 | 含义 | 典型行动 |
|---|---|---|
SUPPORTED | 现有证据已足以支撑当前强度的表述 | 进入写作主线 |
WEAKLY_SUPPORTED | 有趋势，但还不足以支撑强表述 | 降强度或补证据 |
INCONCLUSIVE | 当前证据不能说明问题 | 补更有判定力的实验 |
UNSUPPORTED | 现有结果不支持该 claim | 删除、缩小或重写 claim |
这里的关键是：
claim status 应由证据强度决定，而不是由你对 idea 的期待决定。
Phase 3: 识别 strongest evidence 和 weakest point
每条 claim 都应至少回答两件事：
- strongest evidence 是哪一项结果
- weakest point 是哪一个异常或未覆盖条件
建议用下面结构记录：
markdown
## Claim C1
- Status: WEAKLY_SUPPORTED
- Strongest evidence: ...
- Weakest point: ...
- Reviewer will likely ask: ...
- Next action: ...这比单纯写“总体上效果不错”更可执行。
Phase 4: 单独记录异常与失败模式
异常不是坏事，掩盖异常才是坏事。
建议至少分三类记录：
| 类别 | 你在找什么 |
|---|---|
| Engineering anomaly | NaN、超时、日志错位、评估脚本错误 |
| Statistical anomaly | 某个 seed 异常、波动过大、均值不稳定 |
| Research anomaly | 某个 setting 明显失效、边界条件与预期相反 |
只有第三类才直接构成研究发现。前两类要先排除，再讨论研究意义。
Phase 5: 写成 finding blocks
对于每个值得保留的发现，建议都写成固定结构，而不是散句：
markdown
### Finding F1: [标题]
- Observation: 结果中客观发生了什么
- Comparison: 相比哪个 baseline / prior work 有何变化
- Interpretation: 当前最稳妥的解释是什么
- Boundary: 这个解释在哪些条件下不成立
- Next action: 该补实验、降表述，还是可直接进入论文主线固定结构的好处是：它会逼你把“观察”和“解释”分开。
一个可选的结果分析图（LaTeX/TikZ）
如果你想在本章放一张“从实验输出到 claim 判断”的图，可以直接使用下面的 LaTeX 代码：
使用时需要：
latex
\usepackage{tikz}
\usetikzlibrary{positioning,arrows.meta}Phase 6: 写成 ANALYSIS_REPORT.md
一份好的分析报告应该能让后续章节直接拿来用，而不是重新从日志里捞信息。
ANALYSIS_REPORT.md 模板
markdown
# Analysis Report
## Scope
- Linked problem note:
- Linked novelty report:
- Linked experiment plan:
## Executive Summary
- Main conclusion:
- What is supported:
- What remains weak:
- What should stop:
## Normalized Result Table
| Exp ID | Claim | Method | Baseline | Setting | Primary Metric | Delta | Status |
|--------|-------|--------|----------|---------|----------------|-------|--------|
| ... | ... | ... | ... | ... | ... | ... | ... |
## Claim Status
| Claim ID | Status | Strongest Evidence | Weakest Point | Recommended Action |
|----------|--------|--------------------|---------------|--------------------|
| C1 | SUPPORTED | ... | ... | move to writing |
| C2 | INCONCLUSIVE | ... | ... | add diagnostic |
## Key Findings
### Finding F1
- Observation:
- Comparison:
- Interpretation:
- Boundary:
- Next action:
## Anomalies and Failure Modes
- ...
## Recommendations
1. ...
2. ...
3. ...工具接入建议
这一章更适合吸收 附录 D 里“结果解释、假设生成和异常归因”的经验：
| 工具 / 来源 | 更适合做什么 | 不要直接拿来做什么 |
|---|---|---|
ARIS analyze-results | 汇总结果、组织 finding blocks、推动下一轮修复 | 自动决定论文主张强度 |
| HypoGeniC / hypothesis-generation | 帮你针对异常生成候选解释和诊断假设 | 直接把解释当成结论写入论文 |
| The AI Scientist | 总结多轮实验分支和结果差异 | 代替你判断哪个结果最可信 |
这一节强调的是来自现有自动化科研系统的“结果如何被结构化解释”的实践，而不是泛泛的传统“多画图、多分析”建议。
质量控制
1. 观察和解释必须分开写
“提升了 1.2”是观察；“因为机制更强所以提升了 1.2”是解释。二者不能混写。
2. 一切结论都应回到 baseline 和 prior work
没有对比的绝对数字，很难构成可辩护发现。
3. 弱证据只能支撑弱表述
WEAKLY_SUPPORTED 的 claim 不能按 SUPPORTED 的强度写进摘要和引言。
4. 先排除工程事故，再讨论研究意义
如果结果受日志错误、数据问题或评估脚本影响，优先修链路。
5. 负结果也有研究价值
只要它清楚地界定了方法失效边界、closest work 的适用范围或一个重要假设不成立，它就值得进入分析报告。
常见错误
错误 1：只报告最好的一次结果
表现：只挑最漂亮的 seed 或 setting 写进表里。
解决：先做统一结果表，再讨论 strongest evidence。
错误 2：把 pilot 趋势直接写成最终结论
表现：pilot 的微弱提升被直接升格为主 claim 支撑。
解决：按 SUPPORTED / WEAKLY_SUPPORTED / INCONCLUSIVE / UNSUPPORTED 分类，控制表述强度。
错误 3：异常不单独记录
表现：失败 run、反常 setting、超时结果都散落在聊天记录里。
解决：在 ANALYSIS_REPORT.md 中单列 Anomalies and Failure Modes。
错误 4：把解释写得比证据更强
表现：一个趋势被解释成机制性结论。
解决：所有解释都必须配上 Boundary 和 Next action。
错误 5：没有给后续动作
表现：分析报告写完后，团队仍不知道下一步补什么。
解决：每条 claim 和每个 finding 都给出明确 action。
检查清单
完成本章后，你应至少能回答：
| 问题 | 状态 |
|---|---|
| 我是否把计划中的实验和实际结果一一对齐了？ | [] |
| 我是否对每条 claim 给出了明确状态？ | [] |
| 我是否分开写了 observation 和 interpretation？ | [] |
| 我是否单独记录了 anomalies 和 failure modes？ | [] |
| 我是否明确写出下一步动作？ | [] |
小结
结果分析的关键不是“把数字堆出来”，而是：
- 从
EXPERIMENT_PLAN.md和PILOT_LOG.csv出发整理统一结果 - 逐条判断 claim 状态
- 明确 strongest evidence、weakest point 和 failure modes
- 把观察、解释、边界和下一步动作写进
ANALYSIS_REPORT.md - 为 08-自动迭代循环 和 09-论文结构 提供稳定输入
下一步：08-自动迭代循环 - 把审稿、修复和重审做成状态机
引用 ARIS：本章的结果汇总、finding block 和下一轮修复导向，主要来自 ARIS 的
analyze-results技能。扩展来源：这一版还吸收了 HypoGeniC 与 The AI Scientist 中关于假设生成、异常归因和多轮结果组织的可执行经验。完整来源见：附录 D