name: darwin-skill description: "Darwin Skill 2.0 (达尔文.skill 2.0): autonomous skill optimizer, v2.0 integrates Microsoft Research SkillLens (arXiv 2605.23899) 9-dim rubric + SkillOpt (arXiv 2605.23904) validation-gated design + human-in-the-loop checkpoints. Evaluates SKILL.md files using a 9-dimension rubric (structure + effectiveness + meta-skill blacklists), runs hill-climbing with git version control, spawns independent judge agents for blind evaluation, validates improvements through test prompts with auto-break on diminishing returns, and generates visual result cards. Use when user mentions "优化skill", "skill评分", "自动优化", "auto optimize", "skill质量检查", "达尔文", "darwin", "帮我改改skill", "skill怎么样", "提升skill质量", "skill review", "skill打分"."

Darwin Skill 2.0

v2.1 · 2026-06-10 — keep/revert 棘轮从「绝对分数 delta」改为「paired 同-judge 比较 + 奇数 N 多数决」（绝对分数 ±8 judge 噪音淹没保守编辑的真实增益、是 false-revert 源；within-judge 比较消除换尺污染）。绝对分数降级为 triage-only。 v2.0 · 2026-05-28 — 吸收 Microsoft Research SkillLens（arXiv 2605.23899）的 9 维评分药方 + SkillOpt（arXiv 2605.23904）的 validation-gated 验证机制 + human in the loop 三层守关。

借鉴 Karpathy autoresearch 的自主实验循环，对 skills 进行持续优化。 核心理念：评估 → 改进 → 实测验证 → 人类确认 → 保留或回滚 → 生成成果卡片 GitHub: https://github.com/alchaincyf/darwin-skill

设计哲学

autoresearch 的精髓：

1. 单一可编辑资产 — 每次只改一个 SKILL.md
2. 双重评估 — 结构评分（静态分析）+ 效果验证（跑测试看输出）
3. 棘轮机制 — 只保留改进，自动回滚退步
4. 独立评分 — 评分用子agent，避免「自己改自己评」的偏差
5. 人在回路 — 每个skill优化完后暂停，用户确认再继续

与纯结构审查的区别：不只看 SKILL.md 写得规不规范，更看改完后实际跑出来的效果是否更好。

评估 Rubric（9维度，总分100）

设计依据：基于 SkillLens 论文（arXiv 2605.23899）实证发现——LLM-as-judge 评估 skill 质量准确率仅 46.4%（接近随机），加入 meta-skill 三维度后提升到 73.8%。本 rubric 强化 dim3 / dim5 评分标准，新增 dim9「反例与黑名单」，权重平衡到 100。目的：让评分对真实质量更敏感，减少 LLM judge 的乐观偏差。

结构维度（59分）— 静态分析

效果维度（35分）— 需要实测

Meta-skill 维度（6分）— 反例与黑名单

评分规则

• 维度1-7、9：每个维度打 1-10 分，乘以权重得到该维度得分
• 维度8（实测表现）：跑2-3个测试prompt，按输出质量打1-10分
• 总分 = Σ(维度分 × 权重) / 10，满分100
• ⚠️ 绝对总分只用于 triage（粗排「哪支最弱、先改谁」），绝不用于 keep/revert。实测：同一份未改文字换个 judge 评，总分可摆 ±8（一支只加了 3 个 🔴 字元的 skill、单评却 −8.5，全是 judge 换尺、非真实退步）。keep/revert 一律走 Phase 2 的 paired 比较。
  • 为什么：LLM judge 给的是抽样、不是测量——分数住在「文字 × 该 judge 当下选的标准」里，不是文字属性。绝对总分 = 用两台未校准磅秤量节食前后，差值大半是磅秤差；paired = 同一台磅秤量前后，误差相减抵销。pairwise preference >> absolute scoring 是 LLM judge 的已知结论（RLHF 用 pairwise 不用绝对分同因）。

Rubric 的实证基础

rubric 设计依据来自 SkillLens 论文（arXiv 2605.23899） + 本机 controlled study：

• SkillLens 发现 LLM-as-judge 准确率仅 46.4%（接近随机），加入 meta-skill 三维度后升到 73.8%
• 本机对 huashu-research 做 4 类 degradation → 5 个独立 judge 盲测一致 V1>V2，Δ 均值 +46.5（5/5 high confidence）

结论：rubric 能识别 gross degradation，但 fine-grained quality difference 仍不可信，重要决策必须人审。

→ 详细论文证据 + 5 judges 完整数据 + HL 实战案例数字见 references/skilllens-evidence.md

关于「实测表现」维度

这是与纯结构评分最大的区别。评分方式：

1. 为每个skill设计2-3个典型用户prompt（不是边缘case，是最常见的使用场景）
2. 用子agent执行：一个带skill跑，一个不带skill跑（baseline）
3. 对比输出质量，从以下角度打分：
   • 输出是否完成了用户意图？
   • 相比不带skill的baseline，质量提升明显吗？
   • 有没有skill引入的负面影响（过度冗余、跑偏、格式奇怪）？

若子 agent 不可用（超时/资源限制），退化为「干跑验证」：读完 skill 后模拟一个典型 prompt 的执行思路，判断流程是否合理；必须在 results.tsv 标注 dry_run。dry_run 比例 > 30% → 评估失效警告（来自本机 controlled study：dim8 实测维度权重 23%，无 full_test 验证时分数不可信）。

Runtime 适配性审查（gate 项，独立于 9 维度评分）

skill 应当能在 Claude Code / Codex / Cursor / OpenClaw / Hermes / Gemini CLI / OpenCode 等 50+ skills-compatible runtime 通用——否则其他 agent 解析时会被「在 Claude Code 里」「Claude Code skill」等措辞误判为「不是给我用的」直接拒装（实例：nuwa-skill 因此被 Marvis agent 拒绝）。

Phase 1 基线评估时强制跑一次红灯扫描

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 2>/dev/null

输出非空 = 红灯命中，但须先读命中行上下文排除假阳性（grep 命令本身/反例引用/讲解该规则的元陈述=假阳性，记 runtime_scan=false_positive 不改；判别表见 references/runtime-neutrality.md）→ 确认是真红灯（指令性用法）才强制把 Phase 2 第一轮定为 P0「runtime drift 修复」（写入 results.tsv 的 note 列 runtime_warn=N）。

例外（允许的「Claude Code 痕迹」）

frontmatter 触发词、花叔生态内部 skill 名引用、明确标注 runtime-specific 章节、commit message——这些正当出现，不算红灯。

→ 红灯/绿灯完整对照表 + 例外清单详细规则 + Phase 1/2/3 各阶段审查时机见 references/runtime-neutrality.md

自主优化循环

Phase 0: 初始化

1. 确认优化范围：
   - 全部skills → 扫描 .claude/skills/*/SKILL.md
   - 指定skills → 用户指定列表
2. 创建 git 分支：auto-optimize/YYYYMMDD-HHMM
3. 初始化 results.tsv（如不存在）
4. 读取现有 results.tsv 了解历史优化记录

Phase 0.5: 测试Prompt设计

在评估之前，为每个skill设计测试prompt。这步很关键——没有测试prompt，「实测表现」维度就打不了分。

for each skill:
  1. 读取 SKILL.md，理解它做什么
  2. 设计2-3个测试prompt，覆盖：
     - 最典型的使用场景（happy path）
     - 一个稍复杂或有歧义的场景
  3. 保存到 skill目录/test-prompts.json：
     [
       {"id": 1, "prompt": "用户会说的话", "expected": "期望输出的简短描述"},
       {"id": 2, "prompt": "...", "expected": "..."}
     ]

展示所有测试prompt给用户，确认后再进入评估。测试prompt的质量决定了优化方向是否正确。

Phase 1: 基线评估（Baseline）— triage 用途

本阶段绝对分数是 triage 排名（决定先改谁），不是 keep/revert 基准。judge 对 gross 差异会一致（「哪支最弱」可信），对 fine-grained delta 不可信（±8 噪音）。keep/revert 在 Phase 2 用 paired 比较。

for each skill in 优化范围:

  # 结构评分（主agent可以做）
  1. 读取 SKILL.md 全文
  2. 按维度1-7逐项打分（附简短理由）

  # 效果评分（用子agent做，独立于主agent）
  3. 对每个测试prompt，spawn子agent：
     - with_skill: 带着SKILL.md执行测试prompt
     - baseline: 不带skill执行同一prompt
  4. 对比两组输出，打维度8的分

  # 汇总
  5. 计算加权总分
  6. 记录到 results.tsv

如果子agent不可用（超时、环境限制），维度8用干跑验证打分，标注 dry_run。不要因为跑不了测试就跳过这个维度——哪怕是模拟推演也比完全不看效果好。

基线评估完成后，展示评分卡：

┌──────────────────────────┬───────┬──────────────┬──────────────┐
│ Skill                    │ Score │ 结构短板      │ 效果短板      │
├──────────────────────────┼───────┼──────────────┼──────────────┤
│ huashu-proofreading      │ 78    │ 边界条件      │ 测试prompt2  │
│ huashu-slides            │ 72    │ 指令具体性    │ baseline持平  │
├──────────────────────────┼───────┼──────────────┼──────────────┤
│ 平均                     │ 75    │              │              │
└──────────────────────────┴───────┴──────────────┴──────────────┘

🔴 CHECKPOINT · 🛑 STOP：暂停等用户确认，再进入优化循环。

Phase 2: 优化循环

用户确认后，按基线分数从低到高排序，先优化最弱的。

for each skill:
  round = 0
  while round < MAX_ROUNDS (默认3):
    round += 1

    # Step 1: 诊断
    找出加权短板最大的维度：weighted_gap = weight × (10 - score) / 10，结构或效果都算
    # /10 与「总分 = Σ(维度分 × 权重) / 10」同标度：weighted_gap 就是该维度还能贡献的总分数
    # 为什么不用「原始分最低」：低权重维度会制造进步幻觉——issue #18 实战中
    # dim9（权重6，gap 5.3）原始分最低被优先修，而 dim8（权重23）加权短板最大（11.5）却 4 轮未动
    # 加权短板相近（差距 ≤ 1.0，同上述标度）时，回退为原始分升序
    # HL-3 警告：dim2/dim3/dim4 是相关簇，修一个时另两个常跟着涨
    # → 不要因为 dim3 短板最大就单独修，要看整簇短板再决定是否同步改

    # Step 2: 提出改进方案
    针对该维度，生成1个具体改进方案：
      - 改什么（具体段落/行）
      - 为什么改（对应rubric哪条）
      - 预期提升多少分

    # Step 3: 执行改进
    编辑 SKILL.md
    git add + commit（message: "optimize {skill}: {改进摘要}"）

    # Step 4: Paired 重新评估（取代绝对重打分——绝对分数 judge 噪音 ±8、淹没保守编辑的 +3~8 真实增益）
    spawn N=3 独立 judge，每个【同一次 call 内】读两版：
      - 改前版：git show HEAD:<skill-path>/SKILL.md（上一个 kept commit）
      - 改后版：working tree 当前 SKILL.md
    照 9 维 rubric 当【比较准则】（不是各打绝对分），回 {better | worse | tie} + margin{clear|slight} + 一句理由。
    关键：同一 judge 在一次 call 内比两版 → 它那把不准的尺对两版【等量作用、在比较时抵销】(within-judge cancellation)，
    这正是 paired 优于绝对的机制。N 取奇数（默认 3；close call 升 5）。

    # Step 5: 共识决策（多数决，取代「新总分 > 旧总分」）
    cur = 投 better 的 judge 数；wor = 投 worse 的；
    if cur >= wor:  # 多数说改后 ≥ 改前（含 tie）
      status = "keep"
      # HL-4 见好就收：连续 2 轮多数 judge 判 margin=slight 或 tie → break 进 Phase 3
    else:           # 多数说 worse —— 这才是真退步（已扣掉换尺噪音）
      status = "revert"
      git revert HEAD（创建新commit回滚，不用 reset --hard）
      记录到 results.tsv（note 记 vote 比数 + 一句 worse 理由）
      break
    # 单评绝对分数出现「负 delta」≠ revert 信号；必须经 paired 多数判 worse 才 revert（否则在丢真实增益）

    # Step 6: 日志
    results.tsv 追加行

  # === 🔴 CHECKPOINT · 每个 skill 优化完后强制人审 ===
  展示该skill的改动摘要：
    - git diff（改前 vs 改后）
    - 分数变化（哪些维度提升/下降）
    - 测试prompt输出对比（如果跑过的话）
  等用户确认 OK 再继续下一个skill。
  如果用户说"不好"，回滚到该skill的优化前版本。

Phase 2.5: 探索性重写（按需触发）

当 hill-climbing 连续2个skill都在 round 1 就 break（涨不动）时，提议一次「探索性重写」：

1. 选一个瓶颈skill
2. git stash 保存当前最优版本
3. 从头重写SKILL.md（不是微调，是重新组织结构和表达方式）
4. 重新评估
5. if 重写版 > stash版: 采用重写版
   else: git stash pop 恢复

这解决了 hill-climbing 的局部最优问题——有时候需要「先拆后建」才能突破瓶颈。 🔴 CHECKPOINT · 🛑 STOP：必须征得用户同意后才执行。

Phase 3: 汇总报告

## 优化报告

### 总览
- 优化skills数：N
- 总实验次数：M
- 保留改进：X（Y%）
- 回滚次数：Z
- 实测验证：A次完整测试 / B次干跑

### 分数变化
┌──────────────────────────┬────────┬────────┬────────┐
│ Skill                    │ Before │ After  │ Δ      │
├──────────────────────────┼────────┼────────┼────────┤
│ huashu-proofreading      │ 78     │ 87     │ +9     │
│ huashu-slides            │ 72     │ 83     │ +11    │
├──────────────────────────┼────────┼────────┼────────┤
│ 平均                     │ 75     │ 85     │ +10    │
└──────────────────────────┴────────┴────────┴────────┘

### 主要改进
1. [skill-A] 补充了边界条件处理，测试输出质量提升明显
2. [skill-B] 重组了workflow结构，baseline对比优势增大

results.tsv 格式

timestamp	commit	skill	old_score	new_score	status	dimension	note	eval_mode
2026-03-31T10:00	baseline	huashu-proofreading	-	78	baseline	-	初始评估	full_test
2026-03-31T10:05	a1b2c3d	huashu-proofreading	78	84	keep	边界条件	补充fallback	full_test
2026-03-31T10:10	b2c3d4e	huashu-proofreading	84	82	revert	指令具体性	过度细化	dry_run

eval_mode 列：paired（同 judge 比改前/改后，keep/revert 权威依据）｜full_test（子agent 跑 prompt）｜dry_run（模拟推演、仅供参考）。 paired 行：new_score 栏记 vote 比数（如 3-0 better），note 记一句裁断理由。例：

2026-06-10T06:30	paired	some-skill	（绝对 87.3→78.8 = judge 噪音）	3-0 better	paired 推翻单评假退步	paired

文件位置：.claude/skills/darwin-skill/results.tsv

实战 high-leverage 操作（精髓速查）

4 条经实战验证（huashu-gpt-image +10.85 / huashu-weread-advisor +14.9 / claude-design +16.5）。详细案例数据见 references/skilllens-evidence.md 的「HL 实战案例」节。

• HL-1（dim4）显性视觉标记是杠杆：加 🔴 CHECKPOINT / 🛑 STOP，靠「必须」措辞不行——LLM 解析时扫描视觉标记。4 行改动撬动 dim4 +3 分
• HL-2（dim3）if-then 三段式 fallback 表：把「症状/解法」两列升级为「触发条件 / 一线修复 / 仍失败兜底」三段式。SkillLens failure-mechanism encoding 维度的落地
• HL-3（Phase 2 诊断）维度相关簇警告：dim2/3/4 是相关簇——修 dim3 时 dim2 常跟着涨。「找最大加权短板维度」时同时看相关簇短板再决定是否同步改
• HL-4（Phase 2 退出）触顶自动 break：连续 2 轮 Δ < 2 分 → break 进 Phase 3。+0.15 是停手信号不是继续信号；硬凑 MAX_ROUNDS=3 引入 over-engineering

优化策略库

按优先级排序，每轮只做最高优先级的一个：

P0: Runtime 适配性问题（gate 项命中 → 必须先修）

• README/SKILL.md 出现红灯措辞（如「在 Claude Code 里」「Claude Code skill」）→ 替换为 runtime-neutral 措辞
• Badge 钉死单一 runtime → 改为 Agent Skills Standard + skills.sh + Multi-Runtime 三个中立 badge
• 安装章节只给一种 runtime 的路径 → 改为「一行命令（auto-detect）+ 手动路径表 + 作为参考资料」三层结构
• 工作流硬编码 runtime-specific 工具且无 fallback → 给出通用替代方案或标注「仅在某 runtime 可用」
• 例外：skill 名明确标注单 runtime（如 xxx-codex）的，可跳过本项

P0: 效果问题（实测发现的）

• 测试输出偏离用户意图 → 检查skill是否有误导性指令
• 带skill比不带还差 → skill可能过度约束，考虑精简
• 输出格式不符合预期 → 补充明确的输出模板

P1: 结构性问题

• Frontmatter缺少触发词 → 补充中英文触发词
• 缺少Phase/Step结构 → 重组为线性流程
• 缺少用户确认检查点 → 在关键决策处插入

P2: 具体性问题

• 步骤模糊（"处理图片"）→ 改为具体操作和参数
• 缺少输入/输出规格 → 补充格式、路径、示例
• 缺少异常处理 → 补充 "如果X失败，则Y"

P3: 可读性问题

• 段落过长 → 拆分+用表格
• 重复描述 → 合并去重
• 缺少速查 → 添加TL;DR或决策树

异常与边界条件

流程假设环境理想，但实操常遇异常。以下预定义 fallback，保证优化过程不会「一跑就卡住」。

原则：异常先告知用户，再按规则处理；绝不静默跳过或静默失败。

darwin 操作反例黑名单（dim9 应用：darwin 自己优化时不要做的事）

来自本机 results.tsv 早期 40 次 0 revert 的教训 + Judge G/H 自指评估暴露的反模式。每条都是真实踩过的坑。

触发场景：每轮 Phase 2 改动前对照本表一次。任一反模式命中 → 改方案重写。

约束规则

1. 不改变skill的核心功能和用途 — 只优化"怎么写"和"怎么执行"，不改"做什么"
2. 不引入新依赖 — 不添加skill原本没有的scripts或references文件
3. 每轮只改一个维度 — 避免多个变更导致无法归因
4. 保持文件大小合理 — 优化后SKILL.md不应超过原始大小的150%
5. 尊重花叔风格 — 中文为主、简洁为上
6. 可回滚 — 所有改动在git分支上，用git revert而非reset --hard
7. 评分独立性 — 效果维度必须用子agent或至少干跑验证，不能在同一上下文里「改完直接评」
8. Runtime 中立性 — skill 必须能在 Claude Code、Codex、Cursor、OpenClaw、Hermes 等任何 skills-compatible runtime 中正常运行。除非 skill 名明确绑定单一 runtime（如 xxx-codex、huashu-slides-codex），任何「在 Claude Code 里」「Claude Code skill」「单一 badge 钉死」「安装命令只给 .claude/skills/ 一种路径」都视为 gate 不通过，须在 P0 优先修复（详见「Runtime 适配性审查」章节）

使用方式

全量优化（推荐首次使用）

用户："优化所有skills"
→ Phase 0-3 完整流程
→ 默认：先基线评估，按分数升序优先优化最低 5-10 个

单个优化

用户："优化 huashu-slides 这个skill"
→ 只对指定skill执行 Phase 0.5-2

仅评估不改

用户："评估所有skills的质量"
→ 只执行 Phase 0.5-1（设计测试prompt + 基线评估），不进入优化循环

查看历史

用户："看看skill优化历史"
→ 读取并展示 results.tsv

设计灵感

"You write the goals and constraints in program.md; let an agent generate and test code deltas indefinitely; keep only what measurably improves the objective." — Karpathy, autoresearch

本skill的对应关系：

• program.md → 本文件（评估rubric和约束规则）
• train.py → 每个SKILL.md
• val_bpb → ⚠️ 此处是 1.0 的概念错误源：autoresearch 的 val_bpb 是确定性 loss（重跑同数），darwin 套到 LLM-judge 分数（随机抽样） 上却沿用「绝对值比大小」棘轮 → 不可重复的数当可重复用。修正：9 维 rubric 当 paired 比较准则、不当绝对 metric
• git ratchet → 保留 paired 多数判「改后 ≥ 改前」的 commit（不是「绝对总分更高」的 commit）
• test set → 每个skill的test-prompts.json

区别：增加了人在回路（autoresearch是全自主的，skill优化需要人的判断力），以及双重评估机制（结构+效果），因为skill的「好坏」比loss数值更微妙。

学术依据 & Credits

• SkillLens（arXiv 2605.23899）：9 维 rubric 的实证来源（LLM 自评 46.4% → 加 meta-skill 三维度后 73.8%）。
• SkillOpt（arXiv 2605.23904）：validation-gated edits 形式化框架。代码 github.com/microsoft/SkillOpt（pip install skillopt）、项目页 microsoft.github.io/SkillOpt。🤝 2026-06-03 微软官方仓库已把 darwin-skill 列入集成名单。
• autoresearch：github.com/karpathy/autoresearch，本 skill 1.0 的原始灵感。

成果卡片生成（Result Card）

每个skill优化完成后（或全量汇总后），自动生成视觉成果卡片，截图保存为PNG。

卡片模板

模板位置：templates/result-card.html

3种风格，每次随机选择一种：

生成流程

1. 复制 templates/result-card.html 到临时工作文件
2. 用 sed/编辑工具 替换占位数据：
   - data-field="skill-name" → 实际skill名
   - data-field="score-before/after/delta" → 实际分数
   - 9个维度的 dim-bar-before/after width → 实际百分比（若模板仍是旧 8 维布局，加一行 dim9 反例黑名单条目）
   - data-field="improvement-1/2/3" → 实际改进摘要
   - data-field="date" → 当前日期
3. 随机选择风格：hash 设为 swiss/terminal/newspaper 之一
4. 用 scripts/screenshot.mjs 截图（2x 高清，只截 .card 元素，自动 open 图片）：
   node .claude/skills/darwin-skill/scripts/screenshot.mjs \
     /abs/path/to/card.html /abs/path/to/output.png
   # 回退方案（脚本失败时）：
   npx playwright screenshot "file:///path/to/card.html#[theme]" \
     output.png --viewport-size=960,1280 --wait-for-timeout=2000
5. 提示用户查看成果卡片 PNG

### 资源文件速查

| 路径 | 用途 |
|---|---|
| `templates/result-card.html` | 3风格主模板（swiss/terminal/newspaper，hash切换） |
| `templates/result-card-dark.html` / `-white.html` | 单一风格替代模板（需要锁定风格时用） |
| `scripts/screenshot.mjs` | 2x 高清截图，只截 .card，自动 open |
| `results.tsv` | 历次优化日志（9列含 eval_mode） |
| `{skill目录}/test-prompts.json` | 每个 skill 的测试 prompt 集（用于维度8实测） |

### 何时生成

- **单skill卡片**：每个skill优化完成后，展示该skill的分数变化
- **总览卡片**：全部优化完成后（Phase 3），展示全局战绩

### 品牌元素

- 顶部：Darwin.skill 品牌标识 + 日期
- 底部：「Train your Skills like you train your models」+ github.com/alchaincyf/darwin-skill

## 版本自检（静默）

本节给 AI agent：每次使用本 skill 前，先做一个不联网的判断——读本 skill 目录（SKILL.md 所在目录）下的 `.last-update-check` 文件（内容为一行日期 YYYY-MM-DD）。文件存在且距今不足 30 天，跳过本节直接干活，不向用户提任何更新相关的话。

到期或文件不存在时，且仅在此时：

1. 本目录不是 git 克隆（无 `.git` 或无 origin）→ 写入今天日期后跳过本节
2. 对比版本：`git -C <本目录> rev-parse HEAD` 与 `git -C <本目录> ls-remote origin HEAD`
3. 无论结果如何，把今天日期写入 `.last-update-check`
4. 两者一致 → 什么都不说；确认落后 → 先完成用户当前任务，结束后附一句「本 skill 有新版本，可用 `git -C <本目录> pull --ff-only` 更新」。是否更新由用户决定，不要主动执行更新

English | 中文

达尔文.skill 2.0

像训练模型一样优化你的 Agent Skills。

受 Andrej Karpathy 的 autoresearch 启发，将自主实验循环从模型训练搬到 Skill 优化领域。一个只能向前转的棘轮。

v2.0 · 更新于 2026-05-28 · 吸收微软研究院 SkillLens 与 SkillOpt 两篇论文做的系统性升级。

npx skills add alchaincyf/darwin-skill

[!NOTE] 🤝 微软研究院把达尔文列进了 SkillOpt 的官方集成名单。 2026-06-03，微软在 SkillOpt 仓库 的更新里写道： 「gbrain, gbrain-evals, and darwin-skill have all integrated SkillOpt.」 我们吸收了它的 validation-gated 框架，它把达尔文写进了自己的集成名单。这是一次双向的致意。👉 去 SkillOpt 仓库看看

What's New in 2.0

2.0 不是缝缝补补，是系统性吸收微软研究院 2026-05-22 两篇论文后的结构性升级。五个变化：

1. 评分标准 8 维 → 9 维（吸收 SkillLens 实证的 73.8% rubric 药方）

• 原「错误处理」维度升级为 失败模式编码 (Failure Mechanism Encoding)：不只是「告诉 agent 别犯错」，而是把已知失败路径显式编码进 skill
• 原「明确性」维度升级为 可执行具体性 (Actionable Specificity)：明文禁止「建议/可以考虑/根据情况/灵活把握/视情况而定」等模糊词
• 新增第九维 高风险行动黑名单 (High-Risk Action Blacklist)：rm/git reset --hard/force push 等破坏性操作必须在 skill 中显式列禁

2. 验证机制对齐 SkillOpt 的 validation-gated 设计

• 多评委独立审查：每轮启动 2 个独立评委
• 评委不复用：下一轮启动全新评委，避免锚定效应
• 早停机制：单轮涨幅 < 1 分自动停手，避免凑分堆冗余
• 干跑模式控制：干跑比例 > 30% 自动告警

3. Human in the Loop 三层守关（达尔文区别于 SkillOpt 全自动设计的核心）

• Phase 1 基线评估：自动 + 人工审报告，决定改什么
• Phase 2 单维度优化：🔴 CHECKPOINT 强制暂停，等用户确认
• Phase 2.5 测试提示词跑（可选）
• Phase 3 回归测试：🛑 STOP 涨幅低于阈值强制停手

4. 反例黑名单 8 条（明文禁止的反模式）

1. 同一个 AI 又改又评（SkillLens 实证：LLM 自评准确率仅 46.4%）
2. 用 git reset --hard 当回滚手段（应用 git revert）
3. 为凑分而堆冗余
4. 跳过测试提示词直接评分
5. 一轮内改多个维度
6. 干跑比例 > 30%
7. 静默跳过异常
8. 忽视维度相关簇

5. 实测验证数据

• huashu-gpt-image skill：80.8 → 91.5 → 91.65（+10.85，6 个独立评委共识）
• darwin-skill 自评：86.05 → 92.05 → 92.7

核心循环

为什么做这个

Agent Skill 生态在快速扩张。Claude Code、Codex、OpenClaw、Trae、CodeBuddy 等工具都支持 SKILL.md 格式。当你有 10 个 Skills 时可以手动维护；当你有 60+ 个 Skills 时，你需要一个系统。

传统的 Skill 审查是纯结构性的：检查格式对不对、步骤有没有编号、路径能不能访问。但一个格式完美的 Skill，跑出来的效果可能很差。

达尔文.skill 同时评估结构质量和实际效果，然后只保留真正有改进的修改。

从 autoresearch 到 Skill Optimizer

这个项目直接受 Karpathy autoresearch 启发。autoresearch 的做法是：写一个 program.md 定义目标和约束，让 agent 自主生成和测试代码变更，只保留可测量的改进。

我们把同样的思路搬到了 Skill 优化：

五条核心原则

9 维度评估体系

总分 100。结构维度靠静态分析，效果维度必须实测。v2.0 新增三个维度直接来自 SkillLens 论文的实证 rubric。

新增的三个维度（SkillLens 73.8% rubric 药方）：

实测表现权重最高。Skill 写得再漂亮，跑出来效果不好就是零。

优化循环：5 个阶段

系统在每个阶段内自主运行，但在阶段之间暂停等待人类确认。

Phase 2 的核心逻辑（v2.0 强化）：

1. 找出加权短板最大的维度（weighted_gap = weight × (10 − score) / 10，避免低权重维度制造进步幻觉）
2. 针对该维度生成 1 个具体改进方案（一轮只改一个维度，反例黑名单第 5 条）
3. 编辑 SKILL.md，git commit
4. 启动 2 个独立子 agent 重新评分（下一轮换全新评委，避免锚定）
5. 新分高于旧分 → 保留；否则 → git revert（禁用 git reset --hard，反例黑名单第 2 条）
6. 单轮涨幅 < 1 分 → 自动早停（避免凑分堆冗余）
7. 🔴 CHECKPOINT 暂停，展示 diff + 分数变化，等用户确认

棘轮机制

分数只能上升。每一轮要么改进 Skill，要么干净地回滚。不会随时间积累局部退化。

轮次 2 的 75 分低于当前最优的 78 分，被自动回滚。有效基线始终锁定在 78，后续改进从 78 继续。

快速开始

npx skills add alchaincyf/darwin-skill

安装后在任何支持 Skill 的 Agent 工具中说「优化所有skills」或「优化某个skill」就行。

无法访问 GitHub 的朋友，可以直接下载 zip 包：darwin-skill.zip，解压后把 SKILL.md 放到 ~/.claude/skills/darwin-skill/ 目录即可。

安全提示：

• 在 git 仓库里跑优化，并先把你本地对 skill 的改动 commit 或 stash，这样 darwin.skill 才能干净地保留或回滚实验改动。
• 进入下一轮优化前先审查 checkpoint 的 diff，尤其当 skill 涉及 shell 命令、git 操作、凭证、本地文件或发布流程时。

设计灵感

这个项目的设计直接受 Andrej Karpathy 的 autoresearch 启发。

核心机制完全相同：只保留可测量的改进，其余全部回滚。

v2.0 在此基础上吸收了微软研究院 2026-05-22 发布的两篇论文：SkillLens 提供了实证验证的 rubric 设计，SkillOpt 提供了 validation-gated edits 的形式化框架。

References & Credits

v2.0 的设计直接基于以下学术工作。强烈推荐 skill 生态的研究者和工程师阅读：

SkillLens

Microsoft Research. From Raw Experience to Skill Consumption: A Systematic Study of Model-Generated Agent Skills. arXiv:2605.23899, 2026.

• 论文：https://arxiv.org/abs/2605.23899
• 贡献：实证验证的 73.8% rubric 药方。达尔文.skill v2.0 的三个新维度（Failure Mechanism Encoding / Actionable Specificity / High-Risk Action Blacklist）直接来自该论文。同时也是「同一个 AI 又改又评」反模式的实证来源——LLM 自评准确率仅 46.4%。

SkillOpt

Microsoft Research. SkillOpt: Executive Strategy for Self-Evolving Agent Skills. arXiv:2605.23904, 2026.

• 🔗 代码仓库：github.com/microsoft/SkillOpt（pip install skillopt，v0.1.0 已上 PyPI）
• 项目页：https://microsoft.github.io/SkillOpt/
• 论文：https://arxiv.org/abs/2605.23904
• 贡献：validation-gated edits 的形式化框架。把 skill 当作 frozen 模型的「外部可训练状态」，每次编辑都必须通过独立验证才能保留。达尔文.skill v2.0 的多评委独立审查、评委不复用、早停机制、干跑比例控制都对齐了该框架。
• 🤝 双向印证：2026-06-03，SkillOpt 官方仓库把 darwin-skill 写进了集成名单，原文是 "gbrain, gbrain-evals, and darwin-skill have all integrated SkillOpt." 它给我们框架，我们给它实战验证。

autoresearch

Andrej Karpathy. autoresearch. GitHub repository, 2026.

• 代码：https://github.com/karpathy/autoresearch
• 贡献：达尔文.skill 1.0 的原始灵感来源。核心机制（program.md / train.py / val_bpb / git ratchet / test set）的映射逻辑完全继承自 autoresearch。

达尔文 vs SkillOpt 的关键区别：SkillOpt 是全自主系统，达尔文.skill 强调 human-in-the-loop——Skill 的好坏比 validation loss 更微妙，关键阶段（基线评估、单维度优化、回归测试）强制暂停，让人来做最终判断。

关于作者

许可证

MIT

女娲 造 Skill。 达尔文 让 Skill 进化。 只保留改进，时间就站在你这边。

MIT License © 花叔 Huashu