用途：设计能给出结论的实验，并诊断实验为何不 work——从表面症状推到本质技术原因后再动手修改。效率判据是每次循环是否产出一条经过验证的本质技术原因；没有则等于随机梯度。
设计实验：核心是减少 exploration points，把结果做到可归因。两种分解常同时使用：分解 pipeline（从可控组件起步，逐步加入探索性模块）与分解实验设置（从简单 setting 逐步增加难度）。简单实验只保留 core technical challenge，先找或构造不含额外 challenge 的数据，顺序为简单数据验证正确性、简单数据上改进、真实数据上调 work。
探索性实验的最小可行性三步：一，定义二元、明确、可测量的可行性标准；写不出就说明还没想清楚。二，用“如果只有一天时间，我能做的最简单的验证是什么？”逼出最小实验。三，对照标准判定，只导向成功、失败、模糊三种结果：成功则扩大规模并增加复杂度；失败则分析是想法错还是实现错，据此 pivot 或终止；模糊则回到第一步重定义标准，而不是再多跑几个 setting。
诊断不 work：三步走完。一，找出表面原因，即哪个变量一改就变差，方法是列出 work 与不 work 两组配置的具体差异。二，追问为什么，列出尽量多的候选本质原因，分两类——代码有 bug，或某算法在某数据上确实有问题（超参、缺 tricks、算法本身不行）；可参考相关论文的实现细节与 ablation，注意某些 idea 需要加上 tricks 才 work。三，用实验逐个证伪，跳过验证直接改算法等于猜梯度。输出诊断表，包含现象、表面原因、对照差异、候选原因（支持证据、反对证据、证伪实验）、只验证一条的下一个实验，以及还需用户提供的信息。候选排查顺序按成本排，十分钟能排除的先做。
论文实验规划：倒推自三个问题——comparison（与相关且较新的 baseline 比，任务新时构造自身 variants）、ablation（大表列 core contributions 与重要 components，小表覆盖各 module 的 design choices）、在更有挑战的数据上做 demo 以展示上限。缺 ablation、缺重要 baseline、缺重要 metric、数据太简单是常见拒稿理由。
限制：资料未提供安装命令、运行环境、收费方式与具体平台支持。页面提到的 references/diagnosis-example.md 实例文件内容与 experiments/LOG.md、PROJECT.md 的落盘规则未在资料中给出细节。