原帖：[skill 创作] 实验类skill，-定义你到达终点的方式，纯靠踩坑得到的skill（机器学习类）
作者： CC3
一句话结论
这是一个领域判断很强、风险意识很好的实验树 Skill，但当前更像一份完整操作手册，而不是稳定的可触发路由层；它需要先修复版本与语义化结构问题，再收缩主文档、统一模板和验证闭环。
复杂度判断
复杂度：复杂 Skill。
判断依据：
- 它覆盖实验分支管理、最终门槛、指标可信度、数据泄漏、缓存谱系、代码入口、运行环境、部署导出和视觉诊断等多个高风险维度。
- 它包含主流程、图像模型 sprint 分支、ML 数据/指标 guard、模板生成脚本和 reference 分层。
- 它的正确性不只取决于文字说明，还取决于模板、脚本、验证入口和真实实验记录的一致性。
主要优点
- 目标边界清楚：
SKILL.md开头明确说明它用于“实验树”而不是直线任务，典型场景覆盖模型训练、论文实验、benchmark 驱动工作和防止局部调参循环。 - 风险意识很强：正文明确要求 final gate、gap to target、benchmark 不进入训练、GT 不能成为推理输入、metric bug 后重跑 baseline 和 candidate。
- Verdict 词表可执行：
promoted、pending final gate、invalid due metric等结论词能减少“看起来不错”这类不可验证判断。 - Companion files 方向正确：
experiment-tree-format.md承担模板，image-model-auto-sprint.md承担图像模型 sprint 细节，ml-code-data-metric-guard.md承担 ML 高风险守卫。 - 已有轻量脚本入口：
scripts/new_branch.py能快速向 ledger 追加分支模板，说明这个 Skill 已开始从纯文档走向可执行辅助。
主要问题
P0：frontmatter 缺少 version，会让版本管理受到影响
建议：补齐 version，并同步增加正文头部版本信息与文末版本历史，至少从 1.0.0 或当前实际版本开始。
P0：主文档没有采用语义化工作流标记，执行者能读懂内容，但机器和后续维护者很难稳定巡检“触发边界、执行步骤、验证点、失败回流”。对复杂 Skill 来说，这会影响主路由稳定性。
P1：主 SKILL.md 过厚，已经承担了 reference 和模板职责
证据：主文档约 511 行，包含 14 条硬规则、完整分支模板、失败标签、图像模型 sprint 细则和主 workflow。与此同时，references/experiment-tree-format.md 与 references/image-model-auto-sprint.md 已经保存了相同类型的模板和图像 sprint 规则。
影响：主文档仍然好用，但渐进加载优势不足。后续任何模板字段或 sprint 规则变化，都可能出现主文档和 reference 两处重复维护。
建议：主文档保留触发边界、核心不变量、workflow 和 reference 读取时机；长模板、缺陷分类、guard 明细全部下沉到 references。
P1：reference 入口不完整
证据：主文档只显式提示图像/视频 auto-sprint 时读取 references/image-model-auto-sprint.md，但没有明确说明什么时候读取 references/experiment-tree-format.md 和 references/ml-code-data-metric-guard.md。
影响：执行时可能跳过 canonical 模板或 ML 数据/指标守卫，导致 companion files 变成“存在但不一定被加载”的资源。
建议：在主 workflow 对应步骤补充读取规则：
- 创建或修复 ledger 模板时读取
references/experiment-tree-format.md - 涉及模型训练、benchmark、缓存、指标、部署时读取
references/ml-code-data-metric-guard.md - 涉及图像/视频模型自动 sprint 时读取
references/image-model-auto-sprint.md
P1：脚本模板与 canonical branch template 不一致
证据：SKILL.md 和 references/experiment-tree-format.md 的分支模板包含 Verification trail 字段，但 scripts/new_branch.py 生成的模板没有该字段。
影响：脚本生成的 ledger 会漏掉本 Skill 很强调的“Force Verification, Not Trust”证据链。实际使用时，越依赖脚本，越可能生成不完整分支记录。
建议：把分支模板抽成单一来源，或至少让脚本模板与 references/experiment-tree-format.md 完全一致。优先补齐：
Verification trailclaimfile/linecommand/checkexpected evidenceinvalidating evidence
P1：缺少目标 Skill 自身的工程硬校验
证据：目标目录没有 scripts/validate_skill.py，现有 scripts/new_branch.py 也没有测试或 fixture 来保证生成模板和 reference 模板一致。
影响：即使修复 frontmatter，模板漂移、链接漂移和字段缺失仍只能靠人工发现。
建议：新增轻量硬校验，至少检查：
SKILL.mdfrontmatter 含name、description、version- 主文档包含语义化 workflow 和版本历史
- reference 链接均存在
scripts/new_branch.py生成字段覆盖 canonical branch template
P2：触发边界有正向示例，但缺少非触发场景
证据：What This Skill Is For 提供了典型适用场景，但没有明确说明什么情况不应触发，例如简单单次 bugfix、无需实验分支的小任务、纯文档整理、没有指标/证据要求的一次性修改。
影响：容易把普通任务也升级成实验树流程，增加用户和执行者的负担。
建议：增加 Non-trigger cases，明确轻量任务不需要进入实验树。
工作流重构建议
建议把主文档重构为“薄路由层 + 三份 reference + 一个脚本入口”的结构：
SKILL.md：只保留触发/非触发边界、核心规则摘要、主 workflow、reference 读取时机、验证入口和版本历史。references/experiment-tree-format.md：作为 ledger 和 branch template 的唯一权威来源。references/ml-code-data-metric-guard.md：保存 ML 数据、指标、缓存、运行环境和部署导出风险检查。references/image-model-auto-sprint.md：保存图像/视频模型 sprint 的缺陷分类、候选队列和升级规则。scripts/new_branch.py：只负责生成与 canonical template 一致的分支记录。scripts/validate_skill.py：负责检查结构、链接和模板一致性。
优化建议
优先级建议如下：
- 先修
version和版本历史，让基础校验通过。 - 再把主 workflow 改成语义化标记，确保复杂 Skill 有可巡检的执行路径。
- 收缩主文档，把完整模板和图像 sprint 细则下沉。
- 补齐 reference 读取时机，避免 companion files 成为孤立资源。
- 对齐
new_branch.py输出模板和 canonical branch template。 - 增加轻量验证脚本和 fixture，防止后续模板漂移。
总评
这个 Skill 的底层判断很好，尤其适合防止 AI 在实验项目里陷入“小修小补但不接近最终目标”的循环。它的问题不在领域能力，而在发布结构：当前主文档把太多规则、模板和分支细节压在一起，且缺少版本与语义化验证基础。
我的建议是：不要推倒重写，先做一次结构瘦身和验证补强。修完 version、语义化 workflow、reference 入口和脚本模板一致性后，它会从“好用的长手册”变成“可维护、可验证、可持续迭代的实验管理 Skill”。