Autoresearch：让 AI 自己跑实验

一个 630 行的奇迹

2026 年 3 月，Andrej Karpathy 在 GitHub 上扔了一个仓库，名字就叫 autoresearch。630 行 Python 代码，一个 README，一张训练曲线图。

这个思路后来被 uditgoenka 做成了通用技能包，不再限于 ML 训练，可以在 OpenCode 上以 /autoresearch 命令使用。后面的操作部分就是基于这个通用版本。

核心思想

可验证可量化的过程就可以循环改进。

这是 autoresearch 的全部前提。拆开来看：

可量化。 必须有一个数字能说明"变好了"还是"变差了"。测试覆盖率、响应时间、构建体积、val_bpb——什么数字都行，但不能没有。

可验证。 必须可以快速、稳定地测出这个数字。如果一次验证要跑很久，循环就没有意义。

循环。 改一个东西 → 测一下 → 好了就留、差了就退——重复。不是手动重复，是让 AI 自动重复，一晚上跑 100 次。

LOOP:
  1. Review 当前状态和历史
  2. 做一个改动 → git commit
  3. 跑验证
  4. 变好了 → 保留。变差了 → git revert。
  5. 记录结果
  6. 重复

这就是全部。没有复杂的架构，没有玄学的理论。能测就能改，能改就能自动改。

为什么有效

单次改动很小，但 100 次全自动的累积是复合增长。每次保留的改进都是下一步改进的基础。每次失败的尝试都留在 git 历史里，告诉 AI"这个试过了不行"。

人做不到一晚上跑 100 次实验。AI 可以。这不是 AI 更聪明，是 AI 更有耐心。

什么时候不适合

需要可量化的指标——"代码更好读了"这种目标跑不了。需要快的验证——一次验证超过 10 分钟就不太适合。需要 git——自动回滚全靠 git revert。不适合探索性问题——目标明确了再让它跑。

在 OpenCode 上使用

假设你的测试覆盖率是 72%，想提升到 90%：

/autoresearch
Goal: Increase test coverage from 72% to 90%
Scope: src/**/*.ts
Metric: coverage %
Verify: npm test -- --coverage | grep "All files"
Direction: higher

Agent 会读取 scope 内文件 → 跑 baseline → 开始循环。每 5 次打印一次进度。你不需要守着。

命令

/autoresearch — 主命令。需要 Goal、Scope、Metric、Verify、Direction 五个参数。可选加 Guard（保底命令）和 Iterations: N（限制次数）。

/autoresearch_plan — 交互式向导，帮你把模糊目标转换成可执行的配置。

/autoresearch_status — 查看当前进度。

Guard 机制：

/autoresearch
Goal: Reduce API response time
Verify: npm run bench:api | grep "p95"
Guard: npm test

Verify 测指标有没有改善。Guard 测其他功能有没有坏。指标改善但 Guard 失败了，Agent 换一种方式重做。

实用建议

开始之前确保工作区是干净的。 git status 应该是干净的，不然 git revert 会冲突。

指标选稳定的。 选方差小的指标，或者每次跑 3 次取中位数。否则好的改动可能被随机波动冤枉成坏的。

先跑一次验证确认命令没问题。 如果 verify 命令本身就写错了，整个循环都在浪费时间。

Guard 比 Verify 更重要。 指标优化可以慢慢来，但 Guard 失败了说明现有功能被破坏了。

设 Iterations 上限。 还不熟悉的项目先设 Iterations: 20，跑完看效果再决定要不要继续。

循环过程中不要手动改文件。 你改了，agent 也改了，git revert 的时候你的改动可能被一起退掉。