guoguohui先记录这一次实验要回答什么
一份有用的实验记录，首先需要一个可以被结果推翻的问题。例如，比较两种方法时，先说明比较的是误差、运行时间还是内存占用，以及什么结果才算支持当前判断。一次改变太多因素，通常会让结果难以解释。
开始运行前写下基线、预期和停止条件，再记录实际发生了什么。事先的判断与事后的解释应当分开保存，避免只留下符合预期的故事。
把输入和环境当作结果的一部分
记录代码版本、实际启动命令、完整参数和依赖版本；需要时补充操作系统、硬件与数值精度。输入数据要说明来源、版本、预处理和划分方法。不能公开的数据，可以记录获取条件及脱敏后的结构说明，而不是为了复现泄露访问凭据或个人信息。
仅写“使用默认参数”往往不够，因为默认值会随版本变化。对于随机过程，记录随机种子和重复次数有助于排查差异，但固定种子并不自动保证跨设备、跨版本完全一致。有些并行计算还会引入额外的不确定性。
用简单目录连接配置与结果
给每次运行一个唯一标识，让参数、原始输出和阅读用摘要能互相对应。不要用新的结果覆盖旧文件；若修正统计脚本，应记录修正原因，并指出哪些结果需要重算。目录的复杂程度可以逐步增加，关键是能回答某张图究竟来自哪次运行。
experiment/
README.md # 问题、基线、评价规则
configs/run-001.json
runs/run-001/
environment.txt # 版本与环境
command.txt # 实际命令，不含密钥
metrics.csv # 原始指标
notes.md # 现象、异常与下一步
analysis/ # 汇总与作图脚本汇总时保留差异与失败
有随机性的实验，应根据任务成本选择合理的重复方案，报告单次结果或汇总量的含义，并说明波动是怎样计算的。不要只保留最好的一次，也不要把调参时反复观察过的数据当作完全独立的最终验证。
失败记录也有价值：输入是否缺失、计算是否中断、参数是否无效？将运行失败与方法表现不佳分开，才能避免错误归因。一个可以解释的失败，比没有上下文的成功截图更容易帮助下一次决策。
最后做一次最小重跑
从一个干净目录开始，照着说明获取允许使用的输入、安装环境并运行最小例子，检查能否产生预期格式的输出。若无法逐位复现，就说明允许的误差、统计比较方式和已知差异。复现的标准应写在前面，而不是等结果不一致之后临时改变。