---
id: daily-darwin-skill
name: "darwin-skill"
url: https://skills.yangsir.net/skill/daily-darwin-skill
author: alchaincyf
domain: ai-skill-platform-ecosystem
tags: ["ai-agents", "workflow-automation", "prompt-engineering"]
install_count: 4600
rating: 4.40 (19 reviews)
github: https://github.com/alchaincyf/darwin-skill
---

# darwin-skill

> 借鉴 Karpathy autoresearch 模式对 Skill 进行持续优化，通过结构评分和效果验证双重评估，自动保留改进并回退退步，每次优化后等待用户确认

**Stats**: 4,600 installs · 4.4/5 (19 reviews)

## Before / After 对比

### Skill 迭代优化

**Before**:

凭感觉修改 Skill 提示词，缺乏量化评估，改进效果依赖主观判断，优化周期长达数周，且容易引入退步而难以发现

**After**:

自动化评估循环生成量化评分，对比基线指标，自动保留有效改进并回退负面变化，每次优化都有明确的性能数据支撑

| Metric | Before | After | Change |
|---|---|---|---|
| 优化周期 | 14天 | 2天 | -86% |

## Readme

# darwin-skill

# 达尔文.skill

借鉴 Karpathy autoresearch 的自主实验循环，对 skills 进行持续优化。
核心理念：**评估 → 改进 → 实测验证 → 人类确认 → 保留或回滚**

## 设计哲学

autoresearch 的精髓：

- **单一可编辑资产** — 每次只改一个 SKILL.md

- **双重评估** — 结构评分（静态分析）+ 效果验证（跑测试看输出）

- **棘轮机制** — 只保留改进，自动回滚退步

- **独立评分** — 评分用子agent，避免「自己改自己评」的偏差

- **人在回路** — 每个skill优化完后暂停，用户确认再继续

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

## 评估 Rubric（8维度，总分100）

### 结构维度（60分）— 静态分析

#
维度
权重
评分标准

1
**Frontmatter质量**
8
name规范、description包含做什么+何时用+触发词、≤1024字符

2
**工作流清晰度**
15
步骤明确可执行、有序号、每步有明确输入/输出

3
**边界条件覆盖**
10
处理异常情况、有fallback路径、错误恢复

4
**检查点设计**
7
关键决策前有用户确认、防止自主失控

5
**指令具体性**
15
不模糊、有具体参数/格式/示例、可直接执行

6
**资源整合度**
5
references/scripts/assets引用正确、路径可达

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

#
维度
权重
评分标准

7
**整体架构**
15
结构层次清晰、不冗余不遗漏、与花叔生态一致

8
**实测表现**
25
用测试prompt跑一遍，输出质量是否符合skill宣称的能力

### 评分规则

- 维度1-7：每个维度打 1-10 分，乘以权重得到该维度得分

- 维度8（实测表现）：跑2-3个测试prompt，按输出质量打1-10分

- **总分 = Σ(维度分 × 权重) / 10**，满分100

- 改进后总分必须 **严格高于** 改进前才保留

### 关于「实测表现」维度

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

- 为每个skill设计2-3个**典型用户prompt**（不是边缘case，是最常见的使用场景）

- 用子agent执行：一个带skill跑，一个不带skill跑（baseline）

- 对比输出质量，从以下角度打分：

输出是否完成了用户意图？

- 相比不带skill的baseline，质量提升明显吗？

- 有没有skill引入的负面影响（过度冗余、跑偏、格式奇怪）？

如果无法跑子agent（时间/资源限制），可以退化为「干跑验证」：读完skill后模拟一个典型prompt的执行思路，判断流程是否合理。但要在results.tsv中标注 `dry_run`。

## 自主优化循环

### 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）

```
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    │              │              │
└──────────────────────────┴───────┴──────────────┴──────────────┘

```

**暂停等用户确认，再进入优化循环。**

### Phase 2: 优化循环

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

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

    # Step 1: 诊断
    找出得分最低的维度（结构或效果都算）

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

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

    # Step 4: 重新评估
    - 结构维度：主agent重新打分
    - 效果维度：spawn独立子agent重跑测试prompt（关键！不能自己评自己）

    # Step 5: 决策
    if 新总分 > 旧总分:
      status = "keep"，更新旧总分
    else:
      status = "revert"
      git revert HEAD（创建新commit回滚，不用reset --hard）
      记录失败尝试到 results.tsv
      break  # 该skill到瓶颈，跳到下一个

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

  # === 每个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 的局部最优问题——有时候需要「先拆后建」才能突破瓶颈。
**必须征得用户同意后才执行。**

### 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` 列：`full_test`（跑了子agent测试）或 `dry_run`（模拟推演）。
文件位置：`.claude/skills/auto-optimize-results.tsv`

## 优化策略库

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

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

- 测试输出偏离用户意图 → 检查skill是否有误导性指令

- 带skill比不带还差 → skill可能过度约束，考虑精简

- 输出格式不符合预期 → 补充明确的输出模板

### P1: 结构性问题

- Frontmatter缺少触发词 → 补充中英文触发词

- 缺少Phase/Step结构 → 重组为线性流程

- 缺少用户确认检查点 → 在关键决策处插入

### P2: 具体性问题

- 步骤模糊（"处理图片"）→ 改为具体操作和参数

- 缺少输入/输出规格 → 补充格式、路径、示例

- 缺少异常处理 → 补充 "如果X失败，则Y"

### P3: 可读性问题

- 段落过长 → 拆分+用表格

- 重复描述 → 合并去重

- 缺少速查 → 添加TL;DR或决策树

## 约束规则

- **不改变skill的核心功能和用途** — 只优化"怎么写"和"怎么执行"，不改"做什么"

- **不引入新依赖** — 不添加skill原本没有的scripts或references文件

- **每轮只改一个维度** — 避免多个变更导致无法归因

- **保持文件大小合理** — 优化后SKILL.md不应超过原始大小的150%

- **尊重花叔风格** — 中文为主、简洁为上

- **可回滚** — 所有改动在git分支上，用git revert而非reset --hard

- **评分独立性** — 效果维度必须用子agent或至少干跑验证，不能在同一上下文里「改完直接评」

## 使用方式

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

```
用户："优化所有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** → 8维加权总分（含实测表现）

- **git ratchet** → 只保留有改进的commit

- **test set** → 每个skill的test-prompts.json

区别：增加了人在回路（autoresearch是全自主的，skill优化需要人的判断力），以及双重评估机制（结构+效果），因为skill的「好坏」比loss数值更微妙。
Weekly Installs740Repository[alchaincyf/darwin-skill](https://github.com/alchaincyf/darwin-skill)GitHub Stars481First Seen1 day agoSecurity Audits[Gen Agent Trust HubPass](/alchaincyf/darwin-skill/darwin-skill/security/agent-trust-hub)[SocketPass](/alchaincyf/darwin-skill/darwin-skill/security/socket)[SnykPass](/alchaincyf/darwin-skill/darwin-skill/security/snyk)Installed oncodex716opencode715gemini-cli711cursor711github-copilot710cline710

---
*Source: https://skills.yangsir.net/skill/daily-darwin-skill*
*Markdown mirror: https://skills.yangsir.net/api/skill/daily-darwin-skill/markdown*