花叔把 Karpathy 的 autoresearch 改造成给 Skill 演化的棘轮

上篇文章我拆了 Karpathy 的 autoresearch，它让 Agent 通宵自主做 LLM 研究，核心是「改代码，跑实验，涨了留 commit，跌了 reset」。其实吧，我提到这套思路可以迁移，有个项目直接把它搬走了。

这个项目叫 darwin-skill，中文叫「达尔文.skill」，作者是花叔。5159 个 star，556 个 fork，4 个贡献者。它做的一件事，把 autoresearch 的自主实验循环，从「优化模型」挪到「优化你的 Skill 文件」。

Skill 这东西现在是 AI Agent 生态的硬通货。Claude Code，Codex，Cursor，OpenClaw 都吃 SKILL.md 格式。你有 10 个 Skill 还能手动维护，有 60 个的时候，你需要一个系统帮你判断哪个该改，怎么改，改完是不是真变好了。

darwin-skill 就是这个系统。说真的，它干的事不复杂，但把 autoresearch 那套思路搬对了地方。

从 autoresearch 到 Skill Optimizer，映射关系

花叔在 README 里直接列了一张对照表，把 autoresearch 的每个概念翻译到 Skill 语境。

autoresearch 的 program.md 定义研究目标，对应 darwin 的 SKILL.md，也就是它自己这份规则文件。autoresearch 的 train.py 是被优化的资产，对应每个待优化的 SKILL.md。val_bpb 这个模型指标，对应 darwin 的 9 维加权总分，满分 100。git ratchet 那套 keep/revert 机制，对应完全相同的 git 版本控制。test set 对应 test-prompts.json，验证改进是否真的有效。

唯一的根本区别在最后一条。autoresearch 是「全自主运行」，darwin-skill 是「人在回路」。坦白讲，花叔的理由很实在，Skill 的好坏比 validation loss 微妙，需要人的判断。

这个映射不是生搬硬套。autoresearch 优化的是一个数值目标（val_bpb 越低越好），darwin 优化的是「这个 Skill 跑出来的效果好不好」，后者天然更主观，所以必须加入人类检查点。

9 维评分体系，分数不是唯一标准

darwin 的评估 rubric 有 9 个维度，总分 100。结构维度 59 分靠静态分析，效果维度 35 分要实测，还有 6 分给 meta-skill 维度。

我读 SKILL.md 里那张权重表时注意到几个细节。「失败模式编码」占 12 分，它的评分标准是必须显式写出「如果 X 失败 → Y」的分支，只写正向流程不写失败分支直接扣 3 分以上。「可执行具体性」占 18 分权重最高，明文禁止「建议」「可以考虑」「根据情况」「灵活把握」这类软化措辞，出现 3 处以上就扣分。新增的「反例与黑名单」占 6 分，要求 Skill 必须有「不要做什么」的清单。

这三个维度不是花叔拍脑袋想出来的。我一直觉得这点值得多说一句，它们来自微软研究院 2026 年 5 月那篇 SkillLens 论文（arXiv 2605.23899），论文里管这叫 73.8% rubric 药方。意思是，加了这三个维度，LLM 当评委判断 Skill 好坏的准确率能从 46.4% 提到 73.8%。它们来自微软研究院 2026 年 5 月那篇 SkillLens 论文（arXiv 2605.23899），论文里管这叫 73.8% rubric 药方。意思是，加了这三个维度，LLM 当评委判断 Skill 好坏的准确率能从 46.4% 提到 73.8%。

这里有个数字值得停下来想。46.4% 是什么概念，比扔硬币（50%）还差。给一个 LLM 两份 Skill 让它选哪份更好，它的准确率还不如随机猜。这就是 darwin 后面那套复杂机制的根源。

为什么绝对分数不可信

darwin v2.1 有个看起来很反直觉的设计，它明确说绝对总分「绝不用于 keep/revert」。你想想看，一个评估系统居然不信任自己的分数，这挺怪的。

SKILL.md 里写了实测数据，同一份没改的文字换个 judge 评，总分能摆动 ±8。有支只加了 3 个 🔴 字符的 Skill，单评结果反而 −8.5，全是 judge 换尺造成的，不是真实退步。

花叔用了个很准的比喻。绝对总分是用两台没校准过的磅秤量节食前后，差值大半是磅秤本身的差异。paired 比较是同一台磅秤量前后，误差相减能抵消。所以 keep/revert 一律走「paired 同 judge 比较」，而不是看绝对分涨跌。

v2.1 把 keep/revert 从「绝对分数 delta」改成「paired 同 judge 比较 + 奇数 N 多数决」。这是被 false-revert 源逼出来的改进。原来按绝对分判断，保守编辑的真实增益被 ±8 的 judge 噪音淹没了，导致很多真正有改进的版本被误回滚。

darwin 给绝对总分留的唯一位置是 triage，也就是粗排「哪支最弱，先改谁」，不碰「这个改进留不留」这种关键决策。这个区分很关键，它承认了 LLM judge 的能力边界，又没放弃它的排序价值。

五阶段循环，三层人工关卡

darwin 的优化循环分 5 个阶段，每个阶段内自主运行，阶段之间暂停等人确认。

Phase 0 是初始化，确认优化范围，建 git 分支 auto-optimize/YYYYMMDD-HHMM，初始化 results.tsv。

Phase 1 是基线评估，扫描所有 SKILL.md，跑一遍 runtime 中立性 gate（这个后面讲），用 9 维 rubric 打基线分。

Phase 2 是核心的单维度优化。它的逻辑是先找加权短板最大的维度，公式 weighted_gap = weight × (10 − score) / 10，这个加权很重要，避免低权重维度制造进步幻觉。然后针对那个维度生成一个改进方案，一轮只改一个维度。改完 git commit，启动 2 个独立子 agent 重新评分，下一轮换全新评委避免锚定效应。新分高于旧分就留，否则 git revert。单轮涨幅低于 1 分自动早停。最后 🔴 CHECKPOINT 暂停，展示 diff 和分数变化，等用户确认。

Phase 2.5 是可选的测试提示词跑，用 test-prompts.json 里准备好的典型场景验证。

Phase 3 是回归测试，🛑 STOP 标记，涨幅低于阈值强制停手，最后生成可视化结果卡片。

三层人工关卡分别卡在基线评估后，每个 Skill 单维度优化后，以及回归测试时。这个设计直接对应了前面那个数字，LLM judge 准确率 73.8% 意味着每 4 次决策仍错 1 次，重要决策必须人审。

棘轮机制和它的反例黑名单

「棘轮」是 darwin 的核心隐喻。分数只能上升，每一轮要么改进 Skill，要么干净回滚，不会随时间积累局部退化。说实话，这个隐喻选得很准，棘轮就是那种只能往一个方向转的齿轮。

这个机制完全继承自 autoresearch 的 git ratchet。但 darwin 有一条 autoresearch 没有的「反例黑名单」，8 条明令禁止的反模式。

这几条值得挑出来说。第一条，同一个 AI 又改又评，对应 SkillLens 那个 46.4% 的实证数据。第二条，用 git reset --hard 当回滚手段，必须用 git revert。第三条，为凑分堆冗余。第四条，跳过测试提示词直接评分。第五条，一轮内改多个维度。第六条，干跑比例超过 30%。第七条，静默跳过异常。第八条，忽视维度相关簇。

「干跑比例」这个词需要解释。darwin 的效果维度（权重 23 分）理想情况是跑真实测试，但子 agent 不可用时会退化为「干跑验证」，也就是读完 Skill 后模拟一个典型 prompt 的执行思路判断流程合不合理。SKILL.md 里明确写了，干跑比例超过 30% 触发评估失效警告。这是个很诚实的自我设限，承认「没跑实测的分数不可信」。

Runtime 中立性这道暗门

darwin 有个独立于 9 维评分的 gate，叫 Runtime 适配性审查，藏在 references/runtime-neutrality.md 里。这个维度很容易被忽略，但说真的，它解决一个很实际的问题。

它解决一个很实际的问题。一个 Skill 如果在 README 或 SKILL.md 里写「在 Claude Code 里使用」或「Claude Code skill」，其他 runtime（比如 Marvis agent）解析时会误判「这不是给我用的」直接拒装。README 里举了个真实案例，nuwa-skill 就因为这种措辞被 Marvis 拒绝。

Phase 1 基线评估时会强制跑一次红灯扫描，用一条 grep 命令扫这些钉死措辞。

grep -nE "(在 Claude Code|Claude Code skill|Claude Code 用户|Cursor only|Codex 中|^\[!\[Claude Code|~/\.claude/skills/[a-z]|/plugin install\b)" SKILL.md README.md

输出非空就是红灯命中，强制把 Phase 2 第一轮优化定为 P0「runtime drift 修复」。绿灯措辞的替换建议也很具体，「在 Claude Code 里」改成「在你的 agent 里」，「Claude Code skill」改成「Agent Skill」。

这个 gate 的存在说明花叔对 Skill 分发有自己的判断，一个被单一 runtime 绑定的 Skill，分发力会大打折扣。这个维度很多 Skill 作者根本意识不到。

微软论文，双向致意还是单方背书

darwin v2.0 的卖点之一是「吸收微软研究院 SkillLens 和 SkillOpt 两篇论文」。坦白讲，这种和学界论文的绑定关系值得审一下。README 里还放了 SkillOpt 官方仓库把 darwin-skill 写进集成名单的截图，2026 年 6 月 3 日的更新，原文是「gbrain, gbrain-evals, and darwin-skill have all integrated SkillOpt」。

这段关系值得审一下。darwin 吸收了 SkillOpt 的 validation-gated 框架，多评委独立审查，评委不复用，早停机制，干跑比例控制，都对齐了该框架。SkillOpt 也把 darwin 列进了集成名单。看起来是双向致意。

但要注意 darwin 和 SkillOpt 的根本区别。SkillOpt 是全自主系统，darwin 强调 human-in-the-loop。darwin 的差异化卖点恰恰是「我不像 SkillOpt 那样全自动，我在关键阶段强制暂停让人审」。这个定位很清晰，不是蹭微软热度，而是在微软框架上做了一层「反全自动」的设计选择。

darwin 自己的实测数据，huashu-gpt-image skill 从 80.8 涨到 91.65，darwin-skill 自评从 86.05 涨到 92.7。样本量不大，4 个贡献者 bus factor 很低。但这些数字花叔自己也没拿来当硬广，更多是「证明这套流程跑得通」。

棘轮模式的迁移价值

autoresearch 和 darwin-skill 连起来看，能提炼出一个我管它叫「Git Ratchet Pattern」的东西。

它的三要素是这样。第一，单一可编辑资产，autoresearch 是 train.py，darwin 是单个 SKILL.md，把搜索空间收窄到一个文件让变量可控。第二，不可动的真值仲裁，autoresearch 是 evaluate_bpb，darwin 是 9 维 rubric 加 paired judge，谁当裁判这件事不能让执行者自己说了算。第三，git 当状态机，改进留 commit，退步 reset 或 revert，永不积累退化。

这个模式比「让 AI 自主优化」这个模糊口号有用得多。它告诉你哪些是必须人控的（真值仲裁，检查点），哪些可以交给循环（改资产，跑测试）。

darwin 相对 autoresearch 的进化，在于它发现「评估主观任务时，绝对分数不可信，必须用 paired 比较 + 人在回路」。这个教训不只是 Skill 优化用得上，任何用 LLM judge 做质量评估的场景都该记住。LLM 给的分是抽样不是测量，别拿它当刻度尺。

想把 Skill 生态理顺的人，darwin 值得装一个。但记住它的诚实边界，干跑超过 30% 不可信，单评摆动 ±8，4 个人维护。它给你的是一套「带着刹车」的优化流程，不是一个能甩手不管的自动驾驶。