1.论文进行实验的时候总是有注意不到的点
-
实验难以管理，进行了A测试，B测试后整体全部放仓库？
-
Ai在舒适区死循环，一直给你改参数，从1搜到1w不肯给你结果
-
Ai擅自减少实验规模，把你给的完整数据集拿一个小数据开始测就一直用小数据？
-
Ai把测试集放到训练集你会明令禁止，它当然也不会干，但是你防的住他把最终的公式改掉吗？或者把中间过程改成模型可以偷看答案？
-
不想在说了，每一个都对应我浪费的几小时几十个小时，还附带一点点社会的小小毒打，和一点点小骂。抗住压力写这个skill，核心是让和我一样可能经历过机器学习，但是没有真正的做过机器学习项目的人。少踩一点坑
这个 Skill 的目标是让实验像一棵树一样可追踪：每个分支为什么开、怎么跑、何时停、证据在哪、是否晋级，都必须写清楚。
核心设计思路
1.实验管理系统
- 这个系统设计之初我觉得我就抽象的可以的，一图举例：
-
这就是我抽象的数据模型，我觉得就是不断地试错过程
-
skill的核心就是
-
起点终点的管理。比如起点是搭建什么模型，终点是某个指标达到要求。
-
过程的管理，必须是完整训练+完整测评+测评公式实现来源于可信的github仓库，
这对应我的一个事故，我们自己实现的指标。造成指标虚高很多
-
退出设计，什么时候退出这个分支值不值得的设计。有很多ai偷懒的倾向已经写了遇见的情况，这个你可以自行更新
-
到达的设计，强制Ai必须按给定要求，必须每次跑一个完整数据集，不然他就拿1/100数据跑训练，一直陪你兜圈子。把参数A从0.01调到0.99陪你玩几个小时。最后没效果
-
数据泄露防御，中间态管理。
- 想象这是一棵树，对训练集的明令禁止包含测试集，任何中间偷看都是数据泄露的防御，就像外界的风，不断吹这棵树。如果没有这个，风吹的时候真的会断的。提前吹风。
-
代码简洁，这个在需要解耦的时候很麻烦，真的也不能纯vibecoding，还是要考虑有其他人要看你的代码。
-
内存管理，venv管理，版本管理，注意云端训的时候优先创建私有环境，然后数据一定备份一份在本地。-已救我一次。
-
提醒模型可以通过直接看结果图判断当前缺陷在哪里进行修正模型，最终还要尝试导出onnx并测试。
-
升级方向，参考fire给的卡帕西的自动跑实验的Autoresearch，把模块思想给到Ai，让ai自己试错自己组合？-后续考虑做一个图像领域的自动实验skill。
-
看起来这种分支在我用的过程中自动进行归档对我而言还是很舒服的，自动启用C1，C2，C3.在C2上改的自动有C2d，C2a等。
设计梳理
-
起点和终点管理：起点是当前 baseline，终点是 final gate。
-
过程管理：每个实验必须有完整训练/完整评测的定义。
-
退出设计：提前写清什么时候 freeze 分支，防止 AI 无限调参。
-
到达设计：强制报告目标差距，而不是只说“涨了”。
-
数据泄露防御：训练集、验证集、测试集、benchmark、GT 输入边界必须清楚。
-
中间态管理：cache、manifest、raw data、checkpoint 分开记录。
-
代码清晰：训练入口、测试入口、数据准备入口、指标入口、导出入口必须可查。
-
环境管理：venv、GPU 可见性、命令、run dir、checkpoint 都是证据。
-
可视化诊断：允许看结果图定位缺陷，但不能替代最终指标。
-
部署前置：需要 ONNX/部署时，先验证边界，别训练完才发现不能导。
使用步骤
-
在项目里建立
EXPERIMENT_TREE.md。 -
写当前目标、baseline、final gate。
-
每开一个分支，用模板记录 hypothesis、数据、cache、代码入口、指标、成功/失败门槛。
-
每次实验结束，立刻写 verdict。
-
如果连续两轮只在局部涨、最终门禁不涨，冻结该分支。
效果
使用前：
模型 A 有点涨，模型 B 好像也有点涨，C 又换了 loss。
最终 benchmark 没跑，数据是不是泄露也说不清。
使用后：
B2: debug only, no final gate.
B3: frozen, subset-loop.
B4: promoted, final benchmark passed, checkpoint and metric version recorded.
实战截图，一个做实验会自动唤醒的skill，这很重要。
补充1：不要相信Ai！！！
补充2：一份中文版本skill.md入口，相信你能更直观感受它：
- 附：这本身也是一种上下文管理工程，实验类项目的树型上下文管理系统skill。
# 实验树记录 Skill 中文说明
这个 Skill 用来管理机器学习、论文实验、工程试错中的实验树。
核心不是“写 todo”，而是防止实验在压力下失控：
- AI 一直在舒适区调参数，不愿意给最终结果。
- 明明要求完整数据，AI 偷偷只跑小数据。
- 测试集被明令禁止训练，但中间过程或指标公式被改坏。
- 指标实现出 bug，历史结果虚高。
- cache、原始数据、manifest、权重混在一起说不清。
- 代码包交给别人审查，入口脚本缺依赖。
- 训练很久后才发现 ONNX 或部署边界跑不通。
## 最小模型
把项目想象成一棵树：
```text
目标 -> 当前基线 -> 分支实验 -> 证据 -> 判定 -> 下一分支
```
每个分支必须说明：
```text
从哪里开始
改了什么
没改什么
用了什么数据
禁止用了什么数据
最终用什么门禁判断
什么时候退出
结果证据在哪里
```
## 最重要的规则
1. 先定义终点，再开始实验。
2. 小批次只用于证伪，不用于证明最终成功。
3. 每次必须报目标差距，不只报相对提升。
4. benchmark 不能训练、调参、early stopping。
5. GT 只能做 target/metric，不能进入推理输入。
6. 指标代码必须有来源或 sanity check。
7. cache 不是原始数据，必须有 lineage。
8. 代码入口必须清楚，审查包必须能 import。
9. 云端环境、GPU 可见性、venv、版本必须记录。
10. 若最终要部署，ONNX/export 边界必须提前验证。
## 分支模板
```md
### [>] B1 - 分支名
- Parent:
- Status:
- Goal:
- Hypothesis:
- Changed axis:
- Fixed baseline:
- Input evidence:
- Why this is not an escape:
- Data:
- train:
- validation:
- held-out test:
- external benchmark:
- forbidden:
- Cache:
- path:
- source manifest:
- regenerable:
- Code:
- data entry:
- train entry:
- eval entry:
- metric file:
- export entry:
- Metrics:
- target:
- formula/source:
- sanity check:
- Run budget:
- Success gate:
- Failure gate:
- What failure means:
- Evidence files:
- Result:
- Verdict:
- Next:
```
## 判定词
只用这些词：
- `promoted`
- `continue bounded`
- `debug only`
- `pending final gate`
- `frozen`
- `failed`
- `invalid due leakage`
- `invalid due metric`
- `invalid due environment`
不要写：
- “看起来不错”
- “应该有希望”
- “可以继续试试”
## 常见坑位
- `subset-loop`：大数据项目反复训小子集。
- `metric-bug`：指标公式或实现错误。
- `benchmark-leakage`：benchmark 进入训练或调参。
- `gt-leakage`：GT 进入推理输入。
- `cache-lineage-missing`：cache 说不清来自哪里。
- `missing-code-dependency`：代码包缺依赖，无法运行。
- `local-metric-trap`：局部验证涨，最终 benchmark 不涨。
- `environment-invalid`：GPU/环境/依赖不可信。
- `export-late-failure`：训练后才发现不能导出部署。
补充3：skill源
https://my.feishu.cn/sync/Qhv8dh9bZseSYbbW1KRcvHkInxe
补充4，可能要升级的点，没有包含的点。
-
Human Pressure Guard
记录“老板催、DDL 很近、想马上冲结果”时的保护规则。核心是：可以加速，但不能跳过 final gate、数据边界、metric sanity。这个很实用，也更通用。 -
Visual Diagnosis Protocol
你提到“直接看结果图判断缺陷”。可以抽象成：什么时候看图、看哪些图、如何把视觉问题归类为 data / model / metric / postprocess / deployment 问题。 -
Artifact Handoff Checklist
给别人审查或交付时用：必须包含训练入口、测试入口、metric 文件、数据 split 表、cache 说明、best checkpoint、复现实验命令、不可包含的东西。 -
Cloud Run Hygiene
独立 venv、GPU 可见性、不要污染 /home、run 目录命名、checkpoint 阶段备份、/dev/shm cache 生命周期。这类踩坑非常常见。
原文：https://my.feishu.cn/wiki/DpB2ws11TipCmSkSEm3cgAMhnfb?from=from_copylink
最后：不要相信ai，计算过程，仔细观察，代码不清晰即时重构，汇报慢一点。
