达尔文.skill 是花叔（AlchainHust）继女娲之后在 GitHub 开源的又一款 Claude Code Skill，它做的事听起来极朴素——像训练模型一样优化你的 Skill。灵感直接取自 Karpathy 的 autoresearch：定一套评分标准，让 Agent 自主生成改动，跑测试打分，只保留可测量的改进，其余统统 revert。一轮轮爬山之间插入「人在回路」的暂停；一层层棘轮之后，Skill 的分数从此只升不降——这是第一次有人把"进化"装进工具链。
女娲解决的是"Skill 怎么诞生"，达尔文解决的是"Skill 怎么变好"——这是两种互补的造物能力。在它之前，评价一个 Skill 靠的是读起来"规不规范"；达尔文把它换成两条量化轴：结构评分 60 分 + 实测表现 40 分，共 8 个维度、100 分满分；再套一层棘轮机制让改动只能上升；再让独立子 Agent 评分防"自己改自己评"；最后在每个 Skill 之间插"人在回路"的暂停。
它不完美——测试 prompt 的设计本身就是门手艺，分数满分也不代表真实体验一定好，人在回路又让它丧失一部分"全自主"的魔力。但它诚实地承认这些边界，并把 autoresearch 的思想平移到一个全新领域——这是 2026 年最能体现"Skill 即被训练资产"的实战样本，也是一次对"工具也应该会进化"这一命题的系统性回答。
从 autoresearch 到 Skill Optimizer，为什么 Skill 也需要被训练。
028 维度 100 分制：结构 60 + 效果 40，为什么实测权重最高。
03Phase 0 → 0.5 → 1 → 2 → 2.5 → 3 的完整优化循环全景。
04只能向前转的齿轮：keep / revert 二元决策，分数单调递增。
059 种异常 fallback、7 条约束、4 级策略库、3 风格成果卡片。
06autoresearch 映射、独立评分、人在回路的真正价值。
074 种使用场景 + 女娲×达尔文合流 + Skill 进化论下一步。
达尔文.skill 的设计哲学有一个非常尖锐的出发点——"Skill 生态正在爆炸，评价 Skill 的方法却还停在十年前的 linter 阶段"。花叔把 Karpathy 在模型训练里用过的 autoresearch 范式平移到 Skill 领域，本质上是在把 Skill 当做一种可被训练的资产，而不是写完即永恒的文档。理解这一点，是理解整个项目的入口。
Agent Skill 生态正在以惊人速度扩张——Claude Code、Codex、OpenClaw、Trae、CodeBuddy 等工具都已支持 SKILL.md 格式。10 个 Skill 你靠手感维护，60 个 Skill 你就需要一个系统。花叔在 README 里用一句话说清了这个分水岭。
更尖锐的问题是：传统 Skill 审查是纯结构性的——格式对不对、步骤有没有编号、路径能不能访问。但一个格式完美的 Skill，跑出来的效果可能很差。结构合格不等于有用，这就是达尔文要解决的核心错配。
Karpathy 的 autoresearch 做的是——写一个 program.md 定义目标和约束，让 Agent 自主生成和测试代码变更，只保留可测量的改进。达尔文把这个范式完整地搬到了 Skill 优化领域：
| autoresearch | darwin-skill | 映射解释 |
|---|---|---|
program.md | 本 SKILL.md | 定义评估标准和约束规则 |
train.py | 每个待优化的 SKILL.md | 被优化的资产，每次实验只改它 |
val_bpb | 8 维加权总分（满分 100） | 可量化的优化目标 |
git ratchet | keep / revert 机制 | 只保留有改进的 commit |
| test set | test-prompts.json | 验证改进是否真的有效 |
| 全自主运行 | 人在回路 | Skill 的好坏比 loss 更微妙，需人判断 |
六条映射里，前五条几乎是一对一的平移——这是这个项目最惊艳的地方：它没有重新发明论文级的方法，而是把一个被验证过的工作机制精准落到新领域。只有最后一条做了关键改造：引入"人在回路"，因为 Skill 的"好"是一种多维度品味，不像 loss 那样单调可微。
Design Taste 一个好的"新工具"，往往不是发明新机制，而是把已经在别处被证明有效的机制，精准地搬到一个它从未被用过的领域。达尔文.skill 做的就是这件事——把 autoresearch 的棘轮思想从 PyTorch 搬到 Skill 目录。
达尔文.skill 的整个系统，压缩到极致就是五条原则。每一条都对应着一个"Skill 进化系统必须回答"的基本问题：
这五条原则不是随便列的——它们之间有严密的内在逻辑：01 保证归因、02 保证维度完整、03 保证单调、04 保证客观、05 保证品味。少掉任何一条，整个系统都会塌陷——比如没有独立评分，改 + 评在同一个上下文里，自己一定会偏袒自己的改动。
整个达尔文系统的"loss function"就是这张 Rubric——没有它，一切爬山都无从谈起。花叔把它做成 8 维加权、满分 100 的结构：结构 60 分（静态分析可得）+ 效果 40 分（必须实测）。实测单项 25 分——全表最高权重——直接宣告了整个系统的价值观：Skill 写得再漂亮，跑出来效果不好就是零。
这 6 个维度不需要跑 Skill 就能打分，主 Agent 读完 SKILL.md 即可判断。它们对应的是"Skill 作为文档的基本素养"：
| # | 维度 | 权重 | 评分标准 |
|---|---|---|---|
| 1 | Frontmatter 质量 | 8 | name 规范、description 含做什么+何时用+触发词、≤1024 字符 |
| 2 | 工作流清晰度 | 15 | 步骤明确可执行、有序号、每步有明确输入/输出 |
| 3 | 边界条件覆盖 | 10 | 处理异常情况、有 fallback 路径、错误恢复 |
| 4 | 检查点设计 | 7 | 关键决策前有用户确认、防止自主失控 |
| 5 | 指令具体性 | 15 | 不模糊、有具体参数/格式/示例、可直接执行 |
| 6 | 资源整合度 | 5 | references/scripts/assets 引用正确、路径可达 |
注意权重分布——"工作流清晰度"和"指令具体性"各 15 分，并列结构维度最高。这反映了花叔的判断：Skill 最常见的失败模式不是格式问题，而是步骤模糊。"处理图片"这种指令给了跟没给一样。
剩下的 40 分不是算出来的——必须跑。这是达尔文和所有纯结构审查工具的分水岭：
| # | 维度 | 权重 | 评分标准 |
|---|---|---|---|
| 7 | 整体架构 | 15 | 结构层次清晰、不冗余不遗漏、与花叔生态一致 |
| 8 | 实测表现 | 25 | 用测试 prompt 跑一遍，输出质量是否符合 skill 宣称的能力 |
单项 25 分放在"实测表现"上——这是整个 rubric 里最重的一个权重，也是最难打的分。花叔给出了具体的打分流程：
dry_run。
如果把 8 个维度混在一起打一个总分，会失去一个重要信息——这个 Skill 是结构有问题，还是效果有问题。这两种问题对应的改进策略完全不同。
症状：frontmatter 漏触发词、step 无编号、fallback 缺失。
改法：改格式、加编号、补异常分支——改起来快、判断清晰。
哪里查：维度 1–6 的单项分数。
症状：跑出来跟用户意图跑偏、带 skill 比不带还差、输出格式不符合预期。
改法：改 prompt 的措辞、加具体示例、去掉过度约束——需要靠观察输出才能定位。
哪里查：维度 7–8 的分数、测试 prompt 的 baseline 对比。
把这两条轴拆开打分，让达尔文的诊断-改进-验证循环有了精准着力点——它能清晰地告诉你"这个 Skill 短板在结构的哪个维度"或"这个 Skill 短板在效果表现"，而不是笼统地说"这个 Skill 不够好"。
Why it matters "严格大于"这一条，直接排除了"运气型进步"——如果允许四舍五入，系统就会接受大量伪改进。浮点漂移就是敌人，达尔文把小数位和门槛这件事写在边界条件里，显示了作者对机器学习里"分数漂移"的深刻理解。
整个达尔文.skill 的执行流程，压缩成一张图就是下面这个5 个阶段 + 1 个可选分支的流水线：Phase 0 初始化 → Phase 0.5 测试 prompt 设计 → Phase 1 基线评估 → Phase 2 优化循环（可回到 Phase 2.5 探索性重写）→ Phase 3 汇总报告。每个阶段都有明确的输入、输出、与人类确认点。
流程图不是线性的流水线——它有两类节点：单向推进节点（Phase 0 / 0.5 / 1 / 3）和循环节点（Phase 2 主体）。这样的形状决定了整个系统的"可预测性"：
| 阶段 | 核心动作 | 输出 | 是否循环 |
|---|---|---|---|
| Phase 0 | 扫描目标 + 建分支 + 开日志 | git 分支 + results.tsv | 否 |
| Phase 0.5 | 为每个 Skill 设计 2–3 条测试 prompt | 每 skill 的 test-prompts.json | 否 |
| Phase 1 | 双轨评分（结构主 Agent + 效果子 Agent） | 初始分数卡 + 人类暂停点 | 否 |
| Phase 2 | 诊断 → 改 → 重评 → keep/revert × 最多 3 轮 | 每 Skill 的爬山日志 | 是 |
| Phase 2.5 | 结构级重写（跳出 hill-climbing 局部最优） | 重写版 vs 基线对比 | 是（可选） |
| Phase 3 | 汇总 + 生成成果卡片 PNG | 最终报告 + 视觉卡片 | 否 |
整个流程有 3 个显式的 human checkpoint，它们的位置不是随便放的：
Why it matters autoresearch 是完全自主的，因为它的目标是最小化 val_bpb——一个不会骗你的数字。Skill 的"好坏"却不是一个数字能完全表达的：有时候分数上升了，但 Skill 的味道丢了。在这种地方留下人类的暂停点，是系统设计者对"自动化"的一种克制。
棘轮（ratchet）是一种只允许单向旋转的机械结构：顺时针可以转，逆时针会被卡齿挡住。达尔文把这个机械隐喻贴到 Skill 优化上——每一轮实验，要么让分数上升，要么干净地退回起点。不允许缓慢退化。
朴素的梯度下降会接受"分数下降一点点"的变更——因为它假设噪声均匀、最终会收敛。但 Skill 优化不是在连续的 loss surface 上走，而是 LLM 给出的离散评分。评分器有噪声，Skill 改动有副作用。如果允许任何回退，10 轮后你根本说不清它是进步还是变坏。
棘轮是无记忆的保守策略：不相信单次评分能抵消随机性，只相信"新分严格大于旧分"这个二元信号。一旦通过，就锁死新基线；一旦不通过，立即 git revert 擦除。
Phase 2 的 Step 5 是整个系统的守门员。它只有两个分支：
| 条件 | 动作 | 副作用 |
|---|---|---|
| new_score > old_score | KEEP：保留 commit，更新 best_score | results.tsv 记 kept，下一轮基线上升 |
| new_score ≤ old_score | REVERT：git revert HEAD --no-edit |
results.tsv 记 reverted，工作树回到上一基线 |
为什么用严格 > 而不是 ≥？浮点漂移、LLM 采样随机性、子 agent 重评出现 ±1 分都是常态。等号会让一次"运气差"的评分永久固化一个并无改进的改动。严格大于逼着系统只接受"能被 LLM 稳定识别为更好"的变更——哪怕代价是偶尔错过真改进，也不能让伪改进混进来。
README 给了最直观的演示：
Round 2 的 75 分被自动回滚，Round 3 从 78 继续改进。分数曲线是单调非递减的阶梯，没有回踩。
每一轮改动都是一个独立的 commit，结构统一：
Round N: 优化维度X - 说明
变更：[具体改动]
得分变化：XX → YY (diff: [分维度变化])
状态：kept / reverted这带来两个免费收益：
git log --oneline 一眼看到每轮尝试了什么、分数如何变化、最终保留还是丢弃git checkout <round-N> 回到某一轮的 SKILL.md 状态，对比当前版本棘轮不是免费的。它的代价是：
这正是 Phase 2.5 探索式重写存在的理由——它允许系统主动丢掉当前整份 SKILL.md，从候选变体里重新挑基线。棘轮保证单调，探索式重写保证不困死，两者合起来才是完整故事。
达尔文 SKILL.md 有 400+ 行，真正的"产品差距"不在前面的设计哲学，而在后半部分处理各种"万一"的兜底规则。产品级 Skill 和玩具级 Skill 的差别就在这。
SKILL.md 第 288 行开始的「异常处理」小节，列了 9 种必须有明确处理方式的边界情况：
| # | 异常 | 处理 |
|---|---|---|
| 1 | 子 agent 不可用 | 启用 dry_run：主 agent 用启发式代估，明确标注未实测 |
| 2 | SKILL.md > 500 行 | 优先级切到"精简"维度，加压缩权重 |
| 3 | 结构 >80 但效果 <30 | 警示"漂亮但没用"，强制效果优化 |
| 4 | 连续 3 轮回滚 | 触发 Phase 2.5 探索式重写 |
| 5 | test-prompts.json 缺失 | Phase 0.5 现场生成，询问用户确认 |
| 6 | maxRounds 耗尽仍低分 | 诚实报告"当前 Skill 可能不适合优化" |
| 7 | 优化后分数反降 | 全局回滚到基线，出错误报告 |
| 8 | Skill 触发其他 Skill | 跳过此 Skill，标注复合依赖 |
| 9 | results.tsv 冲突 | 备份后重建，保留历史 |
每一条都有对应场景，都是"跑过一遍真实 Skill"才会撞到的坑。把这些写进 SKILL.md 比写一堆漂亮的流程图更体现产品成熟度。
在那堆流程之上，SKILL.md 还给自己设了 7 条必须遵守的约束：
SKILL.md.original），随时可回溯--auto）Phase 2 生成改进方案时不是随机发散，而是按预先定义的策略库挑。每个维度下有几条具体套路，并按优先级排序：
P0-P2 优先从低分维度里挑最高 ROI 的单点改动；P3 只在连续回滚后的 Phase 2.5 才会动用。
Phase 3 结束时，系统会生成一张 HTML 结果卡——对应三套预设主题，用户挑一个喜欢的：
极简国际主义，适合发推文截图
开发者友好，像 CI 报告
仪式感强，适合正式归档
结果卡是"优化有没有发生"的对外凭证。没有卡 = 没发生——这是产品化里最不起眼、但最重要的细节。
如果把达尔文当成"帮我把 Skill 改好"的工具，你会错过它最值得学的部分。它的核心价值不在终态 Skill 有多漂亮，而在每一步改动都有据可查、可回放、可对比。这才是 LLM 产品工程最缺的东西。
Karpathy autoresearch 跑在模型训练这个 loss 可度量、实验可重放的经典 ML 循环上。达尔文把这套循环搬到了 prompt engineering——一个以往被视为"玄学"的领域。两者之所以同构，是因为它们都做了三件事：
缺任何一项，agent 的"自主实验"就会退化成漫无目的的漂移。达尔文的贡献是把这套框架移植到 SKILL.md 这个全新的资产类别，并证明它依然 work。
SKILL.md 是纯自然语言 + 轻结构，没有类型系统约束、没有编译错误、没有运行时依赖地狱。每一轮改动都能瞬间跑起来测评。这让"自主实验 → 测评 → 保留/回滚"循环的时延从小时级降到分钟级，正是 LLM 能把它跑穿的前提。
最朴素的实现是让主 agent 自己改完自己评。问题显而易见：改动者是评委时，评分会向"我刚做的事"倾斜。这是 RLHF 研究里反复观察到的"self-enhancement bias"。
达尔文强制启动独立子 agent做评分，连主对话的上下文都不传——子 agent 只看到 SKILL.md 文本 + rubric。两个方面的收益：
autoresearch 是全自主的，达尔文刻意插入 3 个人类检查点。这不是工程保守，是对"Skill 质量"这件事的尊重：
| 检查点 | 时机 | 检查内容 |
|---|---|---|
| CP1 | Phase 0.5 后 | 测试 prompts 是否真的能覆盖 Skill 用途 |
| CP2 | 每个 Skill 优化完 | diff + 分数变化 + 输出对比，用户确认再继续下一个 |
| CP3 | Phase 3 前 | 最终报告生成前，允许回退某一轮 |
"Skill 的好坏比 loss 更微妙"——达尔文原文里这句话是整个设计的基石。loss 降了就是降了；Skill 分数涨了可能只是文本更冗长、更讨好评委、或者刚好抓到了评委的偏好漏洞。人类的直觉判断在这种时候比数字更可信。
棘轮的代价是会困在局部最优。达尔文的解法不是调整评分函数、也不是放松 keep 条件，而是引入一个完全不同的变异算子——Phase 2.5 探索式重写允许系统丢掉当前整份 SKILL.md，从候选变体里重新起跑。
这和遗传算法里的"大变异率救逃局部最优"一脉相承。棘轮是小步精修（局部搜索），Phase 2.5 是整段改写（全局探索）。两者必须并存——只有小步会困死，只有大步会没头苍蝇。
很多 Skill 优化工具只输出"优化后 SKILL.md"。达尔文还生成一份 results.tsv，记录每一轮的：
这份表格的真正用处不是"给人看"，而是为下一次优化提供冷启动知识。一个跑了 20 轮的 Skill，第 21 轮就可以查 results.tsv，知道哪些方向已经试过了、哪些方向被评分器讨厌。这让 Skill 优化从一次性事件变成有历史的过程。
Agent Skill 生态目前处在"人人都能写 Skill，没人知道自己写得好不好"的阶段。达尔文填的是生态下游的评估/优化位——和上游写 Skill 的工具（比如花叔自己的女娲）形成互补：
Skill 从 0 到 1 的生成器。把人物思维框架快速搭出一份可运行的 SKILL.md。
Skill 从 1 到 N 的进化器。对已有 SKILL.md 持续做可归因改进。
"女娲造 Skill，达尔文让 Skill 进化"——这不是口号，是生态位的准确定位。
达尔文的用法远不止"一键优化"。它更像一条能插在 Skill 生命周期里的流水线——随时可以启动、随时可以归档、随时可以重放。以下是四种被明确支持的使用姿势。
"优化所有 skills"
扫描 ~/.claude/skills/，对每一个 Skill 跑完整的 5 阶段循环。每完成一个就在对话里汇报 diff + 分数变化，让用户点头再进下一个。适合定期维护整个 Skill 库。
"优化 nuwa-skill"
只针对单个 Skill 跑，省掉扫描阶段。适合你刚改完某个 Skill，想验证这次改动是不是真的带来了分数提升。
"评估所有 skills 的质量"
跑 Phase 0/0.5/1，得到结构+效果双重基线分后停下，不进入 Phase 2 优化循环。适合快速体检：知道哪些 Skill 分数低、哪些维度是短板，然后自己决定要不要修。
"看看 xxx-skill 上次优化了什么"
读 results.tsv + git log，把某个 Skill 历次优化的时间线输出给你——每轮动了哪些维度、留下哪些改动、丢弃了哪些尝试。
如果你没有现成的 Skill，先让女娲造出来；造完再交给达尔文优化。这是花叔给的完整链路：
用自然语言描述你想要的 Skill 人格/职责，女娲产出一份完整的 SKILL.md
对刚造出的 SKILL.md 跑几轮棘轮循环，把"能跑"变成"跑得好"
每用一段时间后再跑一次达尔文，让 Skill 跟着 Claude 模型版本一起演进
目前 rubric 是达尔文内置的 8 维，未来可能出现 rubric-*.md 这种可插拔评分器。写 Skill 的人可以选"用 X 作者的评分标准来评我"。
当某类 Skill 足够多（例如 10 个都在做"代码 review"），达尔文可以给出"这一类 Skill 的平均分/百分位/最佳实践案例"。Skill 评估从个体走向群体。
目前 Phase 0.5 需要 LLM 生成测试 prompts 并请人确认。未来可以让用户的真实使用日志反哺回来——用过去 100 次调用的真实 prompt 作为评估集，效果评分和真实使用高度一致。
把达尔文挂成 cron，每月自动跑一次全量优化。Skill 质量像代码质量一样，有"持续集成"而不是"一次交付"。这才是把 Skill 当软件来维护的终局形态。
达尔文真正的野心，是让 Skill engineering 从一门手艺变成一门科学。
它没有声称"我能把你的 Skill 优化到完美"。它声称的是更朴素的事——"我让你的 Skill 只会变好，不会变坏。"
把时间拉长，一个只向前转的棘轮，比任何天才式的一次性优化都更可靠。