压箱底宝藏，很多人低估了这个 skill：Auto Research实战指南

你的 Skill 第一次跑通时，往往最有成就感。

真正的折磨在后面：你想加一条规则、收紧一步流程、修一下边界——改完演示像没问题，旧场景却开始跑偏。要么语气变油、要么中间悄悄偷步、要么多打了几轮工具。

最痛的不是又报错，而是你心里没底：这次到底是变好了，还是换了一种错法？

没有固定的输入集、没有能落地的断言、没有可比较的分数，你根本无从比较这一版和上一版谁更靠谱。写出来不难，持续把它改对却很难——缺一把尺子时，再怎么改都像是同一桌牌局里重复下注。

很多人一听 Auto Research，第一反应还是：不就是自动帮我调 prompt 吗？

如果停在这一层，你就很容易把它用浅。这篇文章要给你的，是一套用来自证「真的变好」的办法：表面看像在改提示词，实际上是在固定目标下替你跑小步实验。

真正值钱的不是自动改写，而是自动验证。没有 evaluator，再怎么迭代也只是凭手感改稿，只是手速变快了而已。

下面先把「你以为它在做什么」和「它真正能帮你省掉什么」摆到一张图里对齐，再往下拆做法。

01-compare

你以为它在做的是：找个模型把提示词润色几遍。它真正做的是：在固定规则下反复试错，用分数告诉你哪一版更站得住。

拿一个代码审查 Skill 做例子。

难的不是先把东西做出来，而是你怎么证明它真的变好了，而不只是看起来更聪明。

这条链路读 PR diff 和上下文，把「提交代码 → 审查意见」收成一条链路：识别改动范围、按文件分类（安全 / 逻辑 / 性能）、对比已有测试覆盖、标记高风险改动、检查是否引入已知反模式、给出具体修复建议。

从提交 PR 到出完整审查意见，平均能压到两分钟。但真正想讲的不是这条链路本身，而是怎么给 Skill 上尺子——先 evals，再 Auto Research。

先 evals，再 Auto Research

第一阶段用的是类似 skill-creator 的 evals：结构化输入配上 expectations。

关键不是回答像不像人，而是工具调用路径和禁止动作能写成断言。比如纯格式改动只做风格检查，别深入逻辑分析；涉及权限的改动必须先查调用链；测试文件的改动可以跳过复杂度审查。这些都能判对错。

第二阶段才上 Auto Research，流程是设 evaluator、跑基线、做小改动、重测、保留收益、回滚退化。思路和公开圈里 Karpathy 聊过的 Auto Research 接近。

如果前面没有硬断言，Auto Research 很容易变成模型在空转脑补「最佳实践」：分上去了，依据却虚。

所以这条路线里顺序很硬：没有固定测试集、没有 mock MCP、没有工具调用硬断言、没有稳定可复现的评测场，就别急着让 AI 替你自动改 Skill。

你也可以把它想成写单元测试的那套脾气：先能稳定复现失败，再谈重构。

Skill 只是换了一层皮，内核还是「输入固定、环境固定、期望固定」，否则自动迭代只是在给随机性打工。

四个部件，按顺序凑

02-workflow

目标函数要写得能算分。 一个可改的加权例子：score = tool_correctness * 0.4 + review_quality * 0.35 + efficiency * 0.25。

工具调不调对、参数和过滤靠不靠谱，归到 tool_correctness；有没有命中真实风险、结论站不站得住、修复建议能不能落地，归到 review_quality；乱不乱刷工具、token 浪不浪费，归到 efficiency。

权重按你的业务改，不必照抄，但「能拆成几项、每项什么意思」要比一个含糊的总分重要得多。

固定测试集别靠「随便问两句」。 用 case 库，每个 case 有输入、mock、expected.json，还有类似 sql-inject-01 这种编号。

预期里写必须出现的 flagged_risk、false positive patterns、工具调用次数上下限。同一版 Skill 多跑几次，结论不会飘；你也能在 CI 里对同一批 case 反复跑，看改动是抬分还是砸盘。

Harness 要稳。 mock MCP、硬断言、能进 CI 就进 CI。

评测场不稳，自动迭代就是在拟合噪声；外部接口一抖，你今天保留下来的「最优版」，明天可能就是过拟合。

分层打分，别把「感觉好多了」当成指标。 拆开几项再加权，比一句话总分可比较得多，也方便你定位是工具用呲了，还是结论飘了，还是单纯变贵了。

三个坑，适合贴检查单上

一是别让模型自己定义什么叫好。 Auto Research 会凭空编一些「最佳处理」，依据靠不住。

做法是标准人手写，从真实失败样本抽，再用一小撮黄金 case 校准：先让人类把「什么叫过关」钉死，再交给自动搜索。

二是顺序断言别写太死。 早期卡调用顺序，模型换了个同样合法的顺序也被判挂。

后来改成多数场景用集合断言，只有真有依赖的步骤才卡顺序；否则你测的是「模型有没有按你想象的剧本走」，不是「任务有没有做对」。

三是高分不等于真好用。 有一版 SKILL.md 通过率 91%，用起来仍别扭。

case 全是单轮，没覆盖多轮追问，「过测」和「用着顺」就错位了。补多轮 case，再加一点「交互流畅度」之类的维度，才把缝补上。

单轮全绿不代表线上对话里用户会舒服。工程师第二句追问「那为什么昨天没报」这种路径，也要进集合里才算数。

哪些情况不适用 Auto Research

也别把 Auto Research 当成万能钥匙。

第一种是不知道自己到底想优化什么。 你如果连"什么叫变好"都只能靠感觉形容，今天觉得这版顺一点，明天又觉得那版更像人，那它就不适合自动跑。它最依赖的不是模型，而是那把尺子。

第二种是环境根本不稳定。 每次评测都直连真实线上接口，数据今天一套、明天一套，外部依赖还时不时抖一下。这种场景跑出来的高分，很多时候只是运气好，不是 Skill 真进步了。

第三种是样本太少。 只有两三个 case，就很容易把系统优化成"只会做这几道题"。看起来通过率很高，换个问法就露馅。

这也是为什么前面会提多轮 case——不是锦上添花，而是防止你把假进步当成真进步。

第四种是问题本身太主观。 像"这篇文章有没有灵气""这个设计够不够高级"这种，天然更适合人工 review，不适合交给一套全自动闭环。缺的不是迭代速度，而是稳定的判断标准。

第五种是单次试错成本太高。 每次实验都要打真实生产系统、会影响用户、或者回滚代价很大，这种就别直接让 Auto Research 上手。先在可复现、可隔离的沙箱里跑，再说自动优化。

一句话总结：Auto Research 适合"能重复、能评分、能回滚"的问题，不适合"说不清、测不稳、代价高"的问题。

第一次上手，最小框架

先用十来个真实翻车样本，把「成功」写到你敢拿去断言的程度，最好落到工具调用和禁止项。

每个样本一个 case：输入、mock、期望文件，能进 CI 就跑。evaluator 先抓最痛的一块，别一上来堆满指标。

基线稳了，再开 Auto Research 做小步迭代，每次都能 diff 分数、能回滚。改动最好小到你能说清「这一版只动了什么」；否则分数变了，你也难查是评测在动还是 Skill 在动。

还有一个容易被忽略的点：评测本身也会误判。

顺序断言太脆、黄金集太窄，都会让「失败」变成噪音。修评测和修 Skill 往往要交替来：先怀疑是不是尺子歪了，再怀疑是不是手抖写坏了提示词。把误判当成流程里正常会出现的一类 bug，你会少很多无谓的通宵。

如果你团队里已经有人在写 Agent，却没人愿意维护 case 库，Auto Research 多半也撑不起来。它吃的是「可重复的失败样本」和「可重复的通过标准」，不是一句「再聪明一点」。

这和模型强弱关系不大，和工作习惯关系很大。

Auto Research 不是银弹。没有 Harness，自动优化也可能只是在放大错误。更值钱的那一半，往往是先能自动验证，再谈自动改写。

你手头如果正好有一个 Skill 想迭代，你会先把「成功」写成自然语言，还是直接写成可断言的工具规则？卡在哪一步了，留言说说。