我用 Karpathy 的 autoresearch 思路优化了一个 Skill，可测性从 8.6 拉到满分 10

📝

Karpathy 前不久开源了 autoresearch——让 AI agent 自主迭代优化大模型训练。

原文链接：https://mp.weixin.qq.com/s/qeeKYgODP0Y2RkWTa8pG6Q

Karpathy 前不久开源了 autoresearch——让 AI agent 自主迭代优化大模型训练。

Karpathy 前不久开源了 autoresearch——让 AI agent 自主迭代优化大模型训练。

我看完后想到一个问题：这套方法能不能用来优化 AI Skill？

于是拿自己写的 story-builder（一个把需求转成标准用户故事的 Skill）做了实验。结论是：

• 可测性（testability）：8.6 → 10.0（满分）
• 覆盖率（coverage）：98% → 100%
• 评级：A → A（满分 A）
• 迭代轮次：11 轮，其中 4 轮被丢弃、5 轮被保留

这篇文章讲的不是 autoresearch 本身，而是我怎么把它的核心方法论迁移到 Skill 优化上，以及过程中踩了哪些坑。

一、为什么 Skill 需要”可测试”？

先说背景。story-builder 是我自己做的一个 Skill，功能是：

把任意格式的需求输入（PRD、会议纪要、口头描述、单条需求），转化为指定粒度的结构化用户故事。

它支持三种粒度：

• epic — 多 Sprint，一个完整用户目标，含实体分析和需求追溯
• feature — 单 Sprint，用户目标的一个关键功能切片
• story — Sprint 内，满足停止条件的最小可交付垂直切片

输出遵循 Mike Cohn 格式 + Gherkin 验收标准。关键设计是：所有输出的 then 字段强制执行可测性规则，确保验收标准可以直接转化为自动化断言。

这个 Skill 用了一段时间，体感”还行”，但有几个问题：

1. 有时候 then 写得不够具体，无法直接变成测试断言
1. 模糊需求输入时，故事覆盖率偶尔缺漏
1. 不同粒度之间的边界判断不总是准确

“还行”是一个很危险的状态——你不知道它什么时候会翻车，也不知道翻车是因为什么。

比如 then 字段写了”系统响应快速，用户可以看到结果”——这句话你怎么写自动化断言？写不出来。

这正是 autoresearch 思路要解决的问题：把”感觉还行”拆成可自动判断的 Yes/No。

二、我怎么定义”好”：6 条 Then 可测性规则

在用 autoresearch 方法之前，我先得定义”什么是好的输出”。这一步最难，也最关键。

我把 story-builder 的核心质量目标拆成了 6 条可检查的规则：

规则 1：每个 then 必须包含至少 2 种不同类型的信号
信号类型包括：具体数字、UI 文案（用「」括起）、可量化约束、明确状态转换、时间约束。只有 1 种不算通过。

规则 2：禁止模糊词
正常、正确、合理、友好、流畅、快速、及时——全部禁止，包括出现在「」引号内的 UI 文案中。

规则 3：禁止模糊一致性表述
与预期一致、结果不改变、保持不变——单独使用时无法写断言，必须列出具体字段的期望值。

规则 4：Exception 场景必须双断言
每个 then 同时包含”观察到 Y（正向）”和”X 不发生（负向）”。

规则 5：「无事发生」场景必须给具体计数
“不增加”→ “记录总数保持为 N 条，不增加”。

规则 6：NFR 场景必须引用具体阈值
“接口响应时间达标”→ “P99 响应时间 ≤ 500ms，100 QPS 内所有请求均返回结果”。

这 6 条规则，每条都是 Yes/No——通过就是通过，不通过就是不通过。

有了这组规则，我再来搭 autoresearch 的迭代框架。

三、照搬 autoresearch 的三个关键设计

autoresearch 有三条核心设计原则。我把它们迁移到 Skill 优化场景：

原则 1：单文件修改

autoresearch 里 agent 只能改 train.py，其他文件不可动。

我的做法是把权限分层：

• 可修改：SKILL.md（Skill 本体，agent 迭代优化的唯一对象）
• 不可修改：benchmark/、eval/、rubric.yaml（评估基准、测试用例、评分规则）

和 autoresearch 的 train.py（可改）vs prepare.py（禁改）完全一致。

这很关键——如果 agent 能同时改 Skill 和改评分规则，它会”刷分”而不是”变好”。就像考试时既答卷又改答案。

原则 2：固定评估指标

autoresearch 用 val_bpb 作为唯一指标。我定了三个：

• testability（可测性，0-10）：逐个检查每个 then 字段能否直接写 assert。取所有 then 的最低分——短板决定质量。10 分 = 每个 then 可直接写断言；7 分 = 大部分可测、个别缺值；4 分 = 部分模糊。
• coverage（覆盖率，0-100%）：回溯原始需求，逐条核对是否有故事承接。已覆盖需求点 / 原始需求总点数 × 100。
• grade（综合评级）：A = 可测性 ≥ 8 且覆盖率 ≥ 90%；B = ≥ 6 且 ≥ 80%；C/D 依次递减。

三个指标都有明确的计算规则，不靠”感觉”。前面定义的 6 条 then 规则，就是 testability 评分的具体评判标准。

原则 3：Keep / Discard 二元决策

每轮迭代后，跑评估。分数涨了，keep；跌了或没涨，discard。

不搞”涨了一点点算不算进步”的模糊判断。二元的。

三、11 轮迭代，真实过程

起点（Baseline）

指标

分数

testability

8.6

coverage

98%

grade

看起来不差，但 testability 8.6 意味着大约 14% 的验收标准无法直接变成测试断言。对于一个核心 Skill，这不够。

迭代记录

轮次

主要改动

结果

决策

iter 3

强化 then 字段的具体性约束

testability ↑

✅ Keep

iter 4

增加”类型多样性”强制规则

testability ↓

❌ Discard

iter 5

对模糊需求增加量化解析

评分波动大

❌ Discard

iter 6

修复 iter5 问题但均分未达基准

未达标

❌ Discard

iter 7

回退到 iter3 基础，只改输出格式约束

coverage ↑

✅ Keep

iter 8

补充边界 case 处理

testability ↑

✅ Keep

iter 9

精简冗余规则

无变化

❌ Discard

iter 10

强化 Gherkin Given/When/Then 模板

testability ↑

✅ Keep

iter 11

微调措辞精度

达到满分

✅ Keep

终点

指标

分数

testability
10.0
coverage
100%
grade
A

四、3 个最重要的教训

教训 1：连续 Discard 不是失败，是在缩小搜索空间

iter 4-6 连续三轮 discard，过程挺挫败的。但事后看，这三轮帮我排除了三个”看起来合理但实际没用”的方向：

• “类型多样性过于严格” → 强制多样性反而让 agent 生成不自然的故事
• “模糊需求量化解析” → 对模糊输入强行量化，评分反而不稳定
• “修复补丁” → 在错误方向上打补丁，不如回退

回退到上一个 keep 点，换方向，比在错误路径上死磕有效得多。

教训 2：Eval 指标不能太多

一开始我设了 5 个指标。跑到 iter 3 就发现，agent 开始”刷冷门指标”——某个不重要的指标拉满了，核心指标反而退步。

砍到 3 个指标后，优化方向立刻清晰了。

这和 autoresearch 原文说的一样：超过 6 个 eval 就开始”钻空子”，3-6 个最佳。

教训 3：可测性是一个递归问题

“验收标准可测”听起来简单，但实操时会发现：怎么定义”可测”本身就是一个模糊概念。

我最终把”可测”拆成了一条 Yes/No 规则：

这条 then 字段，能否在不依赖人类主观判断的情况下，写成一个自动化断言（assert）？

能 = 通过。不能 = 不通过。

没有”基本可以””差不多能”。二元的。

五、一个具体的反例→正例

给你看一个真实的迭代改进，感受一下”可测性”到底意味着什么：

迭代前（testability 8.6 时的 then）：

系统正常处理，库存恢复

迭代后（testability 10 时的 then）：

订单状态变为「已取消」，商品 A 库存恢复为 52（原 50 + 回补 2）

前者你无法写 assert。后者可以直接写：

1 2	`assert order.status == "已取消" assert product_a.stock == 52`

这就是从 8.6 到 10 的区别——每一条 then 都能变成代码。

六、这套方法的适用范围

autoresearch 原本用于训练大模型。但核心逻辑是通用的：

只要你能定义评分规则，就能让 agent 自主迭代优化。

除了 Skill 优化，我正在把同样的思路用在：

• 内容生产 Skill：开头第一句是否提到了具体的时间/地点/感官细节？输出是否在 800-1500 字之间？
• OKR 拆解 Skill：KR 是否包含具体数字？是否有明确截止日期？是否可以用”完成/未完成”判断？
• 代码生成 Skill：输出能否零报错运行？是否有 TODO 占位？所有函数名是否具有描述性？

注意这些 eval 全都是 Yes/No 二元题——不是量表，不是感觉，不是”打个分”。

这也是 autoresearch 原文的核心洞见：量表会叠加波动，二元 eval 才能给你稳定可靠的信号。

七、给管理者的行动建议

如果你的团队正在用 AI Agent / Skill：

1. 选一个高频使用的 Skill，给它定义 3 个 Yes/No eval
2. 跑 10 轮迭代，记录每轮的 keep/discard 和原因
3. 保留 changelog——这份进化记录比最终版 Skill 本身更有价值

未来模型升级、Skill 迁移平台，你不用从零开始。手里有一份被验证过的进化路径。

这才是 agent 时代真正稀缺的东西：不是”一个好 Skill”，而是”一条通往好 Skill 的路”。

我整理了一份可直接落地的： 《组织 AI 编排层自检清单（管理者版）》（含诊断项 + 优先级建议 + 首周行动表）。

想要就回复关键词：Harness****

或直接加我微信：oscaryang，留下你的信息，也许我能发你这个 skills

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。