把“感觉还行”变成可迭代的分数：AutoResearch 思路如何用在 Skill、工作流和开发任务上

Karpathy 的 autoresearch 给了一个很朴素的范式：不要让 AI 只是写一段答案，而是让它在一个可测环境里反复试。改代码，跑实验，看指标；指标变好就保留，变差就回滚。这个项目在 README 里把范围压得很窄：agent 只改 train.py，prepare.py 不动；每轮训练固定 5 分钟；评价指标是 val_bpb，越低越好。它不靠“看起来不错”，而靠一个数字决定这轮修改要不要留下。

两篇微信公众号文章讨论的是同一件事的两种迁移。第一篇《我把 Karpathy 的 AutoResearch 搬到了软件开发领域，效果炸了》把它移到通用软件开发：从 GitHub Issue 出发，agent 实现、测试、多 agent 审核，分数达标后自动 PR 和合并。文章给出的评分结构是 5 个维度：正确性 35%、测试 25%、代码质量 20%、安全 10%、性能 10%，总分达到 9.0/10 才算通过。第二篇《我用 Karpathy 的 autoresearch 思路优化了一个 Skill，可测性从 8.6 拉到满分 10》把它移到 Skill 优化：只允许 agent 修改 SKILL.md，不允许改 benchmark、eval 和 rubric；每轮之后跑评估，分数涨了 keep，没涨或下降 discard。文章中的实验结果是 testability 从 8.6 到 10.0，coverage 从 98% 到 100%，11 轮里 5 轮保留、4 轮丢弃。

这套方法真正有价值的地方，不是“让 AI 自己干活”这么简单。更准确地说，它把工作从写 prompt，变成了设计一个会自我筛选的工作系统。

为什么单纯写 prompt 不够

写 prompt 当然有用。好的 prompt 能减少很多低级错误，也能把风格、边界、输出格式讲清楚。但 prompt 有一个硬伤：它很难告诉你，这次输出到底比上一次好了多少。

比如你写了一个“用户故事生成 Skill”。你可以在 prompt 里写：“验收标准要具体、可测试、不要模糊。”这句话方向没错，但 agent 生成的 then 字段到底能不能直接变成自动化断言？“系统正常处理，库存恢复”算不算具体？人一看就知道不行，但机器如果没有评估规则，就只能继续凭语感。

第二篇文章里那个例子很说明问题。优化前的 then 是：

系统正常处理，库存恢复

优化后变成：

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

后者可以直接写成 assert order.status == "已取消" 和 assert product_a.stock == 52。这就是“可测性”从形容词变成判断题的过程。

这是不是能让 Skill 自进化？能，但前提很苛刻

我认为答案是：可以，而且方向是对的。但它不是魔法。它能不能跑起来，取决于你能不能把“好”拆成稳定的评价信号。

Karpathy 原始项目里，val_bpb 是一个天然指标。软件开发没有这么单纯，所以第一篇文章采用多维评分。Skill 更容易被 agent “刷分”，所以第二篇文章把可修改文件和评估文件分开，禁止 agent 改评分规则。这个设计非常关键。否则它不是在进化 Skill，而是在修改考试答案。

如果要把这种方法用于自己的工作流，我会先问四个问题：

• 被优化的对象是什么？是 SKILL.md、某个功能分支、一个 App 原型，还是一套研究流程？
• 哪些文件绝对不能被改？比如测试集、rubric、benchmark、CI 配置、生产数据。
• 什么叫“变好”？能不能拆成 3 到 6 个稳定指标？
• 分数变好之后，是自动保留、人工确认，还是只生成候选补丁？

这四个问题回答不清楚，就不要急着做全自动。先做半自动。

怎么把看似无法打分的东西数值化

很多工作看起来不能量化，其实是因为我们一上来就想打一个“大分”。比如“文章写得好不好”“Skill 是否稳定”“App 是否完成”。这些都太大。更好的办法是把它拆成一组小的、可判断的 Yes/No eval。

1. 先把主观词翻译成可观察信号

“可测试”不要直接打 1 到 10。先问：每条 then 是否能在不依赖人类主观判断的情况下写成 assert？能就是 1，不能就是 0。

“覆盖完整”也不要凭感觉。把原始需求拆成需求点，然后计算：已被故事承接的需求点 / 原始需求点总数。

“代码质量”可以拆成更硬的信号：测试是否通过，lint 是否通过，是否新增 TODO，占位实现是否存在，是否修改了禁止目录，关键路径是否有回归测试。

2. 指标不要太多

第二篇文章提到一个坑：一开始设 5 个指标，agent 会去刷不重要的冷门指标；砍到 3 个指标后，方向反而清楚。这个经验很实用。指标越多，优化目标越容易变浑。对多数 Skill 或工作流来说，3 到 6 个指标足够。

3. 用最低分保护短板

如果一个 Skill 生成 20 条验收标准，其中 19 条很好，1 条完全不可测，那么平均分会掩盖问题。第二篇文章把 testability 设计成“所有 then 的最低分”，这个思路值得借鉴。对高风险任务，短板比平均值更重要。

4. 区分硬门槛和软评分

有些东西不该加权，而应该一票否决。比如：

• 测试失败，一票否决。
• 改了 forbidden paths，一票否决。
• 文章里出现未引用的关键事实，一票否决。
• App 不能启动，一票否决。

剩下的再打分。否则一个严重错误可能被几个漂亮指标平均掉。

三个可以落地的例子

例子一：优化一个 Skill

假设你有一个“竞品分析 Skill”。不要只写“请生成高质量竞品分析”。可以把优化系统设计成这样：

• 可改文件：SKILL.md。
• 不可改文件：eval/、benchmark/、rubric.yaml。
• 评估样本：5 个历史任务，包括 App 竞品分析、AI 产品分析、定价页分析、用户评论分析、广告素材分析。
• 硬门槛：不能虚构数据；引用的数据必须能追溯到源文件或 API 输出。
• 指标：事实准确率、覆盖率、可执行建议占比、引用完整率。

事实准确率可以这样算：抽取文章中的数据性陈述，逐条检查是否在来源中出现。覆盖率可以这样算：rubric 要求的模块中有多少被完整回答。可执行建议占比可以定义为：建议是否包含对象、动作、预期效果和验证方式。这样一来，“分析质量”就不再只是主观评价。

例子二：开发一个功能

第一篇文章中的软件开发版本已经给了框架：Issue 输入，多 agent 实现和审核，测试通过后按正确性、测试、代码质量、安全、性能加权评分。这个方法比较适合中等复杂度、边界清楚的 Issue，比如“给 Job 增加 timeout、max retries、agent selection”。文章记录的案例中，相关 Issue 约 10 分钟、3 轮迭代达到 9.0/10。

但如果任务是“重构整个架构”或“重新设计产品定位”，就不该直接全自动合并。可以改成：agent 生成方案和补丁，评估系统跑测试和静态检查，最后由人决定是否合并。

例子三：重新创建一个 App 原型

如果目标是“重建一个小 App”，可以把任务拆成一组可评估切片：

• 启动：App 能在目标设备或模拟器启动。
• 核心流程：用户能完成注册、创建内容、发布、查看结果。
• UI 对齐：关键页面截图与设计稿的结构差异低于阈值，或者由视觉评审 agent 给出结构评分。
• 数据真实性：不能使用 mock 数据冒充真实接口，除非任务明确允许。
• 回归：已有功能的 smoke test 仍然通过。

这里最重要的是不要把“好看”直接交给 LLM 打分。可以让视觉 agent 参与，但它的判断最好也拆成更具体的项：导航是否存在、按钮是否可点击、文案是否一致、截图预览是否显示、空状态是否可见。

它对减少幻觉有没有帮助？有，但不是因为模型突然更聪明

这种方法能减少幻觉，靠的是外部约束，不是靠模型自觉。

当 agent 说“测试通过”，系统真的跑测试。当 agent 写“覆盖率 100%”，系统真的算覆盖率。当 agent 改了 forbidden path，脚本直接拦。每一轮的输出都要接受环境反馈、rubric 反馈或另一个 agent 的审核反馈。幻觉不能只靠提醒解决，必须让它撞上硬边界。

这也是它比单纯 prompt 更稳定的原因。prompt 是一次性的意图表达；autoresearch 式工作流是一个循环系统。它会记录分数，会丢弃退步，会把上一轮失败反馈带到下一轮。长期看，后者更像工程，前者更像聊天。

优势

• 输出更稳定。因为每轮都要经过同一套 eval，而不是每次重新凭感觉判断。
• 进化过程可追溯。keep/discard 记录会告诉你哪些方向真的有效，哪些只是看起来合理。
• 对 Skill 特别有用。Skill 本质上就是 agent 的操作规程，最适合用真实任务反复压测。
• 能把人的经验沉淀成系统。人不需要每次提醒“不要写模糊验收标准”，而是把它写成 eval。
• 多 agent 审核能减少单模型盲区。第一篇文章用 Codex、Claude、OpenCode 轮转审核，就是这个思路。

缺点和风险

• eval 设计很难。指标差，系统会优化错方向。
• 容易被刷分。如果 agent 能改测试、改 rubric、改 benchmark，结果会失真。
• 成本不低。多轮 agent、测试、审核都会消耗时间和 token。
• 不适合所有任务。开放式研究、审美判断、战略判断，很难完全自动化。
• 分数可能制造假安全感。9.0/10 不等于没有 bug，只代表它通过了当前这套评估。

我会怎么用在实际工作里

如果现在要把它用起来，我不会一开始就做“全自动自进化”。我会先选一个高频、边界清楚、失败成本低的 Skill。比如文章改写 Skill、需求拆分 Skill、代码审查 Skill。先固定 10 到 20 个历史样本，写 3 个核心 eval，跑 10 轮。每轮只允许改 SKILL.md，不允许改评估集。分数上升就保留，下降就丢弃。最后看两件事：分数是不是稳定上升；人工抽检是不是也觉得变好。

如果这一步成立，再往开发任务扩展。开发任务要更谨慎，因为代码的副作用更大。可以先从非核心模块、低风险 Issue、测试覆盖较好的项目开始。自动 PR 可以，自动合并要慢一点打开。

我个人也更认可这种方向。它比“写一个更长的 prompt”更接近真正的工作系统。prompt 当然还需要，但 prompt 只是规则的一部分。更重要的是 eval、日志、回滚、权限边界和反馈循环。把这些东西搭起来之后，AI 才不是每次从零开始聊天，而是在一条被验证过的路径上改进。

所以，这是不是未来减少 AI 幻觉、提高结果稳定性的一条路？我觉得是。但它不会替代人的判断。它更像是把人的判断前置成规则，把人的复盘沉淀成 eval，把人的反复提醒变成自动门禁。对个人工作流、团队 Skill、长期开发任务来说，这已经足够有价值。

参考来源

• 《我把 Karpathy 的 AutoResearch 搬到了软件开发领域，效果炸了》，百度Geek说。
• 《我用 Karpathy 的 autoresearch 思路优化了一个 Skill，可测性从 8.6 拉到满分 10》，敏捷绩效-AI变革领导力。
• karpathy/autoresearch README：项目说明了单文件修改、5 分钟固定预算、val_bpb 指标和 program.md 的角色。
• smallnest/autoresearch README：项目说明了 GitHub Issue、本地 Issue、百度 iCafe 模式，以及 Claude、Codex、OpenCode 轮转审核和默认评分门槛。