Experiment Craft 是一个用于系统化运行、调试和迭代科研实验的技能。其核心观点是：最关键的研究技能不是运行更多实验，而是理解实验为什么会失败。如果不分析结果，容易导致两种失败模式：一是盲目运行随机实验、不理解失败原因而导致进展缓慢；二是由于遗漏了激活技巧而放弃本可奏效的好方法。因此目标不是运行更多实验，而是运行正确的实验，即那些能够隔离原因、检验特定假设的实验。
使用时机 当用户的实验不工作或产生意外结果时；当用户需要帮助诊断某个方法为何在特定数据上失败时；当用户希望用结构化日志整理实验过程时；以及当用户询问调试研究代码或迭代方法时，均可使用本技能。该技能通常在 experiment-pipeline 的某个阶段尝试失败时被加载；调试完成后，应返回流水线的阶段门结构继续推进。它也可以独立用于任何实验调试。
五步诊断流程 第一步，收集失败案例：收集具体的不良结果示例，查看实际输出而非仅仅看聚合指标，判断失败是系统性的还是随机的。第二步，寻找可工作的版本：需要一个可用的基线，可以通过简化任务（降低数据复杂度、放宽任务设置、增加监督、使用更简单的输入）或从基线方法出发逐一移除自己的算法改进来实现。如果找不到任何可工作的版本，就继续简化，直到某个足够简单的版本能够工作为止。第三步，弥合差距：从可工作的版本出发，逐步增加复杂度直到它失败；每次只增加一个因素（更复杂的数据、一个算法改动、一个约束），找出导致失败的那个单一因素。识别出的原因越原子化，诊断就越有用。第四步，假设并验证：基于隔离出的原因，列出可能的解释，按可能性排序，设计针对性实验来验证或排除每个假设，并通过实验确认真正原因，而不能只依赖直觉。第五步，提出并实施修复：基于已确认的原因，搜索针对该原因的技术（可使用 research-ideation 技能中的文献树），设计针对已确认原因而非表面症状的修复方案，在原始失败案例上验证修复有效，并检查修复不会破坏此前可工作的案例。
反直觉实验规则 在实验工作中应优先遵循以下规则：一次只改变一个变量——如果同时改变两个因素且实验成功，你不知道是哪一个起了作用；如果失败，也不知道是哪一个有问题；单变量改动虽然每次实验更慢，但总体上更快。快速迭代依赖有效的实验而非更多的实验——盲目实验会让情况更糟，一个设计良好的诊断实验胜过十次随机尝试。某些优秀技术无法单独奏效，它们需要特定的激活技巧，例如学习率调度、初始化方案、数据预处理步骤；不要在一次失败后就放弃某项技术，应检查相关论文中未公开的技巧。查阅相关论文中的技巧——解决相似技术挑战的论文往往把关键实现细节埋在补充材料或代码中，这些技巧可能决定一项技术成败。“排除所有不可能之后，剩下的必然是真相”——系统化排除优于直觉；调试时应明确列出所有可能原因，然后用针对性实验逐一排除。
实验日志 每个实验都应记录五个部分，可使用 assets/experiment-log-template.md 中的模板。目的：为什么运行这个实验，期望学到什么。设置：数据、算法改动、超参数等一切复现所需信息。结果：定量指标、定性观察以及具体的好案例或失败案例。分析：结果是否符合预期；如果不符合，按可能性排序的假设原因。下一步：基于分析该做什么，你就是项目负责人。其中“下一步”部分最重要：不要等待别人告诉你下一步做什么，而要分析自己的结果并自行提出下一个实验，这是研究者与技术人员的区别。跨周期学习方面，如果使用 experiment-pipeline，实验日志会输入 evo-memory 的 ESE（Experiment Strategy Evolution）机制；可用 [Reusable] 标记可复用策略，以便 ESE 提取供未来周期使用。
返回 experiment-pipeline 完成五步诊断流程后，携带以下内容返回 experiment-pipeline：已确认的失败原因（来自第四步）、提出的修复及其验证状态（来自第五步）、更新后的实验日志条目。
移交给论文写作 当实验成功并拥有完整结果集时，将以下产物传递给 paper-writing：最终实验结果（表格与图，来源于实验日志，用于 Experiments 章节）、消融研究结果（来源于诊断实验，用于消融表）、失败案例分析（来源于第一步和第三步，用于局限性讨论）、关键实现细节与技巧（来源于第三至五步，用于方法章节或补充材料）、基线对比结果（来源于第二步，用于对比表）。
参考导航 调试方法论见 debugging-methodology.md，用于诊断实验为何失败；实验日志模板见 experiment-log-template.md，用于记录实验细节。