---
title: "Skill 写完只是一半：用 autoresearch 自动优化 Claude Skill"
author: deletexiumu
pubDatetime: 2026-03-26T02:00:00+08:00
featured: false
draft: false
tags:
  - Claude Code
  - AI Agent
  - 教程
description: "Karpathy 的 autoresearch 方法搬到 Claude Skill 优化上：定义 checklist、一键启动、自动迭代。附三步安装指南、Checklist 设计原则和开发者场景示例。"
---

Ole Lehmann 用 autoresearch 跑自己的落地页文案 Skill，质量 checklist 通过率从 56% 提升到 92%——4 轮自动改动，启动后零人工干预。

这个方法来自 Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 负责人、"vibe coding" 提出者）。他最初用 autoresearch 自动优化 ML 训练脚本，Ole 把同样的思路搬到了 Claude Skill 的 prompt 优化上。起因是他发现自己的 Skill 有大量时间在静默失败。

他跑了自己的落地页 Skill 多次，发现输出里反复出现弱 CTA（"Learn More"）和空泛标题（"Transform Your Business"）。超过一半的输出没通过质量检查，但日常使用时他根本没注意到——因为偶尔出一次好结果就觉得"还行"。

![autoresearch 核心循环流程图](/blog/autoresearch-skill-optimization/01-autoresearch-loop.jpg)

---

## 三步跑通 autoresearch

### Step 1：安装 autoresearch Skill

```bash
git clone https://github.com/olelehmann100kMRR/autoresearch-skill
# 将整个 Skill 目录内容放入 ~/.claude/skills/autoresearch/
mkdir -p ~/.claude/skills/autoresearch
cp autoresearch-skill/SKILL.md ~/.claude/skills/autoresearch/SKILL.md
# 如果仓库包含 eval-guide.md 或 references/ 等配套文件，一并复制
cp autoresearch-skill/eval-guide.md ~/.claude/skills/autoresearch/ 2>/dev/null || true
```

验证安装成功：在 Claude Code 中输入 `/skills`，确认列表中出现 autoresearch。这个 Skill 也支持在 Cowork（Claude Code 的多 agent 协作模式）中使用。

### Step 2：准备三件事

| 准备项 | 说明 | 示例 |
|--------|------|------|
| 目标 Skill 路径 | 要优化的 Skill 文件 | `~/.claude/skills/code-review/SKILL.md` |
| 测试输入（3-5 个） | 多样化、覆盖边界 | 见下方"如何设计测试输入" |
| 二元评估标准（3-6 个） | 是/否问题，定义"什么叫好" | 见下方"Checklist 设计" |

测试输入的要点是**多样化**。如果你优化的是代码审查 Skill，不要 5 个输入都是 Python Web 代码——应该包含不同语言、不同复杂度、有安全问题的和没有安全问题的。边界情况决定了优化后的 Skill 是否真的变好了，还是只在特定场景下变好了。

**运行参数表**：

| 参数 | 默认值 | 说明 | 调整建议 |
|------|--------|------|---------|
| 每轮运行次数 | 5 | 每个改动测试几次取分 | 输出不稳定的 Skill 建议 8-10 |
| 运行间隔 | 2 min | 两轮实验之间的间隔 | API 限流时加长 |
| 预算上限 | 无 | 最多跑多少轮 | 建议首次设 10 轮试水 |
| 停止条件 | 连续 3 次 ≥95% | 自动停止阈值 | 要求不高可降到 85% |

### Step 3：一句话启动

```
run autoresearch on my code-review skill
```

Agent 接管后的流程完全自动：

1. 跑基线测试，拿到当前通过率
2. 分析 checklist 中失败率最高的项
3. 对 SKILL.md 做**一处**改动
4. 用全部测试输入重新跑，计算新通过率
5. 通过率上升 → 保留改动；下降 → 撤销，换个方向
6. 循环，直到连续 3 次 ≥95% 或达到预算上限

启动后浏览器会弹出 `dashboard.html`，实时展示分数趋势、每个 checklist 问题的通过率、改动日志。每 10 秒自动刷新。你可以盯着看，也可以走开。

**产出文件清单**：

| 文件 | 内容 | 价值 |
|------|------|------|
| 改进后的 SKILL.md | 优化后的 prompt | 直接使用 |
| SKILL.md.baseline | 原始备份 | 随时回滚 |
| results.json | dashboard 数据源 | dashboard.html 读取此文件渲染图表 |
| results.tsv | 每轮分数日志 | 追踪优化曲线 |
| changelog.md | 每次改动的内容、原因、效果 | **最有价值——模型升级时的迁移文档** |
| dashboard.html | 可视化面板 | 过程监控 |

---

## Checklist 设计——autoresearch 的灵魂

autoresearch 能跑多有效，完全取决于你的 checklist 写得怎么样。这是整个流程中唯一需要你投入思考的环节。

### 为什么用二元评估（是/否）而不是打分（1-10）

打分制的噪音太大。同一个输出，不同时刻用 LLM 打分可能差 2-3 分。二元评估像阅卷老师手里的标准答案——100 份卷子打下来，结果一致。

![二元评估 vs 量表打分对比](/blog/autoresearch-skill-optimization/02-binary-vs-scale.jpg)

### 设计原则

- **3-6 个问题**。太多会导致 Skill 为过 checklist 而写——就像学生背答案不理解原理。
- **每个问题测一个独立维度**，不重叠。如果两个问题经常同时通过或同时失败，合并成一个。
- **Agent 会引导你**。启动 autoresearch 后，agent 会问你"什么样的输出算好"，帮你把模糊感觉变成具体的是/否问题。你不需要提前把 checklist 想得很完美。

### 三问测试

每个 checklist 问题定稿前问自己：

1. **两个不同的 agent 打分，结果会一样吗？** 不一样说明问题太主观，需要更具体。
2. **Skill 能不能不真正改善就通过？** 能就说明问题太松了。
3. **这个问题检查的是用户真正在乎的东西吗？** 不是就删掉——多余的 checklist 项只会给优化过程引入噪音。

### 四个常见错误

1. **太多评估（>6 个）**：输出会被 gaming，Skill 为了通过检查变得面面俱到但每项都浅
2. **太死板（任意约束）**：比如"必须恰好 3 个段落"——这类人为约束会让结果生硬
3. **评估重叠**：无法定位是哪个维度出了问题，优化方向模糊
4. **不可衡量**：形同虚设，agent 打分随机

### 示例 A：Ole 的落地页文案 Skill（英文营销场景，作为参照）

- "标题是否包含具体数字或可量化结果？"（抓住 "Grow Your Business" 这类空泛标题）
- "是否避免了 revolutionary、synergy 等零信息量词汇？"
- "CTA 是否用了具体动词短语？"（抓住 "Learn More"、"Click Here" 这类弱 CTA）
- "第一句是否点出了具体痛苦场景？"（抓住 "In today's fast-paced world..." 这类万能开头）
- "总字数是否在 150 字以内？"（抓住注水）

### 示例 B：代码审查 Skill（中文开发者场景）

把同样的思路迁移到开发者日常场景。如果你有一个代码审查 Skill，经常给出"建议优化此函数"这种废话审查，checklist 可以这样设计：

- "是否指出了至少一个具体的代码行号或函数名？"——抓住泛泛而谈的审查
- "每个问题是否附带了修改建议而非只说'建议优化'？"——抓住只提问题不给方案的审查
- "是否检查了安全风险（SQL 注入、XSS、硬编码密钥）？"——抓住只看代码风格不看安全的审查
- "输出是否控制在 500 字以内？"——抓住注水审查

4 个问题，每个检查一个独立维度：定位精度、方案完整度、安全覆盖、简洁度。

### 示例 C：需求澄清 / PRD 改写 Skill（产品场景）

- "是否将每个模糊需求转化为可验收的具体条件？"
- "是否指出了需求中的矛盾或遗漏？"
- "输出是否保留了原始需求的业务目标而非替换成技术方案？"

---

## Ole 的优化过程拆解

以下基于 Ole 公开的结果描述，提炼出三类有效的改动模式。

### 模式 1：加入明确规则（修复高频失败点）

改动内容：加入"标题必须包含具体数字或结果，永远不要用 'Transform Your Business' 这类模糊承诺"。

逻辑：checklist 数据显示"标题含数字"这项失败率最高，agent 直接加了一条明确规则。

**可迁移的做法**：跑完基线后看哪个 checklist 问题失败率最高，针对它加一条明确规则。

### 模式 2：加入禁用词 / 反面例子

改动内容：加入禁用词列表——"NEVER use: revolutionary, cutting-edge, synergy, next-level, game-changing, leverage, unlock, transform."

逻辑：光说"避免废话"太模糊，具体列出禁词才能让模型有明确边界。

**可迁移的做法**：如果你的 Skill 反复犯某类错误，把错误模式列成黑名单写进 prompt。

### 模式 3：加入高质量示例（few-shot）

改动内容：加入一段好的落地页文案示例，标注了痛点开头和 CTA 的写法。

逻辑：与其描述"好的输出应该怎样"，不如直接展示一个好的输出让模型看到。

**可迁移的做法**：给 Skill 加 2-3 个你手动写过的好输出作为示例。

### 被撤销的改动

Agent 尝试过更严格的字数限制，但撤销了——因为文案变薄、CTA 质量反而下降。

这正是 autoresearch 的价值所在：它能自动发现"看起来像改进但整体变差"的改动。人工优化时，你改了一处觉得"这下好了"，但很难注意到其他维度悄悄退化。autoresearch 每次改动后都重新跑全部 checklist，退化无处藏。

**changelog 的长期价值**：当更强的模型发布时，把 changelog 喂给新模型，它能从上一轮的经验继续优化，而不是从零开始试错。

![56%→92% 优化过程可视化](/blog/autoresearch-skill-optimization/03-optimization-progress.jpg)

---

## 它为什么有效——Evaluator-Optimizer 模式的落地

读到这里你已经知道怎么用了。现在补一下原理，帮你判断什么时候该用、什么时候不该用。

### Karpathy 原版 autoresearch

Karpathy 的设计目标是让 AI agent 自主优化 ML 训练脚本。核心约束很简单：

- **单文件范围**：agent 只能改 `train.py`，数据准备代码锁死不动
- **单指标**：`val_bpb`（验证集每字节比特数），越低越好
- **固定时间预算**：每轮训练限时 5 分钟，保证实验之间可比
- **设计哲学**：限制 agent 能改的范围，让改动 diff 可审查

预期吞吐量：每小时约 12 次实验，跑一夜能做 ~100 轮。

### 从 ML 到 Prompt 的映射

Ole 做的事情是把这套框架平移到 prompt 优化上：

| Karpathy 原版 | Ole 改编版 |
|---------------|-----------|
| `train.py`（训练脚本） | `SKILL.md`（prompt） |
| 跑 5 分钟训练 | 跑一次 Skill |
| `val_bpb`（验证损失） | checklist 通过率 |
| git diff 审查改动 | `changelog.md` 记录 |
| 一夜 ~100 轮 | 通常 4-10 轮收敛 |

映射关系非常干净。"单文件"约束在 Skill 场景下天然成立（就是一个 SKILL.md）。

"单指标"从连续值（val_bpb）变成了二元打分的聚合通过率（0-100%），但优化方向一样：让数字往好的方向走。

### 与 Evaluator-Optimizer 模式的关系

autoresearch 本质上是 Evaluator-Optimizer 模式的一个即插即用实现：

- **Evaluator**：checklist 打分机制——对每个输出做是/否判断
- **Optimizer**：agent 分析失败项，修改 SKILL.md
- **循环**：自动重复，直到收敛

可以把它理解为 prompt 的局部搜索优化。它不是梯度下降（没有连续的损失函数可求导），更像是 hill climbing：每次走一小步，走对了就继续，走错了就退回来。

如果你读过[关于 Evaluator-Optimizer 模式的那篇文章](/posts/ai-agent-evaluator-optimizer/)，autoresearch 就是那个模式从理论到工具的具体落地。

---

## 更多候选场景

### 已有验证的场景

- **落地页文案 Skill**：56% → 92%，4 轮（Ole 实测）
- **网站性能优化脚本**：1100ms → 67ms，67 轮（社区转述，未追溯到一手来源，仅供参考）

### 开发者场景（候选，待验证）

autoresearch 适用于任何"能定义二元评估标准"的 Skill。除了上文 Checklist 设计一节已展开的代码审查 Skill（示例 B）和 PRD 改写 Skill（示例 C），还有几个开发者场景值得尝试：

**提交信息生成 Skill**：
- 是否遵循 Conventional Commits 格式？
- 是否包含变更范围（scope）？
- subject 是否控制在 72 字符内？

**单元测试生成 Skill**：
- 生成的测试是否覆盖了至少一个边界条件？
- 是否避免了 mock 泛滥？
- 测试名称是否描述了预期行为？

通用规则：能定义稳定的二元评估标准 → 就值得尝试 autoresearch。

---

## 适用场景与局限

**适合用的场景**：

- Skill 输出质量不稳定（有时好有时差）
- 能定义清晰的"好/坏"标准（3-6 个是/否问题）
- 反复使用的 prompt（优化的投入回报成正比）

**别折腾的场景**：

- 一次性使用的 prompt——投入回报不成正比
- 输出质量高度主观、难以二元判断——比如"写一首诗"，好坏见仁见智，checklist 无法捕捉审美
- Skill 本身逻辑有根本性问题——autoresearch 是调参，不是重写。食谱有问题不是换调料能解决的
- 用同一个模型既生成又评估——在单会话中通常由同一个模型完成生成和评估（这是经验判断，非官方文档明确说明）。如果你发现分数很快到 95% 但实际输出没那么好，可能是 evaluator 偏差导致分数虚高。可以考虑用不同模型做 evaluator，或者人工抽检几轮结果校准

---

## 写 Skill 只完成了一半

写 Skill 只完成了 50%。验证它在多大比例的情况下真正有效，然后系统性地优化，这才是另一半。

这个系列里，[Skill 工具链实战](/posts/claude-code-skill-toolchain/)教你怎么写 Skill，[Skill 设计手册](/posts/claude-code-skill-design-guide/)教你怎么设计 Skill，这篇教你让 Skill 自己变好。三篇串起来是一个完整的 Skill 生命周期：创建 → 设计规范 → 持续优化。

如果你想试一下，不需要一步到位。选一个你最头疼的 Skill，写 3 个 checklist 问题，跑一次 autoresearch 看看基线分数。光是看到基线分数这一步，就已经比"感觉还行"强了。

---

*来源：[Ole Lehmann 原帖](https://x.com/itsolelehmann/status/2033919415771713715)*

*来源：[Karpathy autoresearch GitHub](https://github.com/karpathy/autoresearch)*

*来源：[Ole autoresearch-skill GitHub](https://github.com/olelehmann100kMRR/autoresearch-skill)*

---

## 相关阅读

- [从需求到自动化：Claude Code Skill 工具链完整实战](/posts/claude-code-skill-toolchain/) — Skill 生命周期第一步：怎么从零写一个能用的 Skill
- [Skill 设计手册：Anthropic 内部数百个 Skill 的经验总结](/posts/claude-code-skill-design-guide/) — Skill 设计规范，autoresearch 优化的前提是 Skill 本身结构合理
- [AI Agent 模式解析：从"做完"到"做好"](/posts/ai-agent-evaluator-optimizer/) — autoresearch 背后的理论基础——Evaluator-Optimizer 模式