把 Karpathy 的 autoresearch 用在自己的 Claude Skills 上，我是从一次失败的 skill 迭代开始的。那时候我攒了一套还不错的 Claude Code 技能包，自我感觉良好，结果一换场景就原形毕露：换个前端框架、换类目命名习惯、甚至换个输出语言，整个 skill 就像没被读过一样，生成的东西全凭临时发挥。后来我琢磨了一下，问题不在于哪个 skill 文件写得不好，而在于我根本不知道怎么系统化地改进它们。直到我重新翻出 Karpathy 经常提的 autoresearch 思路，把他那套「让模型自己发现、自己验证、自己沉淀」的方法迁移到 Skills 的迭代上，才真正感受到什么叫效率上的数量级变化。
这篇文章不聊虚的。我会从 autoresearch 的核心逻辑讲起，讲清楚为什么它天然适配 Claude Skills 的开发与改进，然后给你一套可以直接照搬的四个阶段实操流程，再用一个前端开发技能的真实改造案例，把每一步的参数、文件、验证方法都摊开来说。适合已经在用 Claude Code、手头有几个自己写的 Skills、却总觉得迭代效率不高的开发者，也适合准备用 Claude 升级自己工作流的工程师。如果你是第一次接触 Skills，建议先看第三节的基本盘说明，再回头读前面的方法论。
1. Autoresearch 不是工具，而是一套让模型自己卷自己的方法
1.1 Karpathy 的 autoresearch 到底在说什么
Karpathy 在很多场合都表达过一个观点：AI 的下一步不是「会回答问题」，而是「会主动做研究」。所谓 autoresearch，说白了就是让 AI 对一个目标问题自动完成全套研究工作：定义问题、搜集资料、设计实验、跑通验证、输出可复用的结论。它跟普通「让 Claude 多搜几次网页再回答」有本质区别，因为 autoresearch 要求模型自己控制整个研究闭环，而不是被动地在你的追问下挤牙膏。
我在实际用下来，觉得它的核心可以拆成四条：第一，目标不只是「答案」而是「经过验证的结论」；第二，模型必须自己调用工具去获取信息和证据，而不是只靠参数记忆；第三，要有明确的评估环节，让模型自己判断结果好不好；第四，最终结论要被沉淀下来，变成下一次可以复用的资产。这四条放在科研圈一点都不新鲜，但放在 AI 应用里，尤其是用来改进一套 Claude Skills，杀伤力很大。
我常用一个比较生活化的类比来理解这套方法：普通用法像一对一辅导，你问一句 AI 答一句，正确率取决于老师的水平；autoresearch 像让学生自己去做毕业设计，从选题、查文献、做实验到写论文全包，老师只负责最后答辩时把关。后者训练出来的是能力，前者得到的只是一次性答案。应用到 Skills 改进上，就是让 Claude 不只是「按你的指令改一个 prompt」，而是让它自己设计一套实验，去验证「什么样的 skill 结构更稳定」，最后把验证过的模式写回代码库。
1.2 为什么它能直接套用到 Skills 改进上
很多人在改 skill 时有个惯性：经验驱动。打开 SKILL.md，凭感觉改几个词，跑一次觉得还行了，提交，结束。这种方法不是完全没用，但你根本不知道是哪个改动起了作用，也不知道换个场景会不会崩。久了以后，skill 改得越多，内部矛盾越多，最后变成一坨谁都不敢动的代码。
autoresearch 最值钱的地方，恰恰是帮你把「经验感」变成「实验记录」。一个 Claude Skill 本质上就是一个包含指令、示例、工作流的文本资产，它的所有行为都可以通过固定输入来复现测试。这意味着你可以像做 A/B 实验一样，把描述换一版、把步骤调个序、把自检清单加上，然后跑同一批测试用例，对比输出质量。这就是 autoresearch 的天然试验场。
而且 Claude Skills 的改进有一个独特优势：Claude 本身既是研究对象，也是研究工具。你可以让旧版 skill 生成一批输出当基线，再让新版 skill 在同一批输入上运行，最后让 Claude 自己当裁判，按你预先定义的维度打分。整个过程形成了闭环，你只负责制定规则和审核结论。我第一次跑通这个闭环时，最大的感受是：以前改 skill 像开盲盒，现在改 skill 像照着测试报告重构产品，每一处修改都有据可查。
2. 先弄清楚你到底在改什么：Claude Skills 的基本盘
2.1 Skill 的本质是「可复用的工程资产」
在开始用 autoresearch 之前，先把底层的概念对齐一下。Claude Skills，尤其在 Claude Code 的语境里，是一套结构化的指令包。最常见的形态是一个目录，里面有一个 SKILL.md 作为主文件，YAML frontmatter 里声明 name 和 description，正文里写执行步骤、规范、示例和自检清单。你还可以把参考文档、模板、脚本、测试用例都塞进同一个目录，让这个 skill 变成一个相对完整的「工作台」。
它的本质跟写函数很像：有输入（description 决定了什么时候被触发）、有处理逻辑（正文步骤）、有输出（生成内容或执行动作）、有边界（不做哪些事）。把 Skill 当成纯 prompt 文本是个常见的误解，实际上它更像一套微型工程规范，质量和鲁棒性要靠结构来保证。我见过不少人写 skill 就是几百字「你是专家，请按要求输出」，这种当然也能跑，但换一个稍微复杂些的上下文就露馅。
这里要提一下当前生态里比较流行的做法，像 community 里广受好评的 superpower skills、nature skills、codex skills 这些公开项目，它们的共同点就是：结构化程度极高，触发条件写得很具体，步骤拆得清楚，而且每个 skill 基本都配有自检逻辑。如果你在改进自己的 Skills 前没研究过这些开源范例，那你等于是在没有对标物的情况下闭门造车。
2.2 从「会写 Skill」到「会改 Skill」的差距在哪
写一个新 skill 其实不难，难的是改好一个 skill。为什么？因为写的时候你是一张白纸，想怎么写都行，没有历史包袱；但改的时候，你必须兼容已经跑通的场景，不能捡了芝麻丢了西瓜。我在给团队做 code review 时，最常见的回归事故都是这样发生的：为了提升某个方向的输出质量，改动了入口 description，结果原本应该由另一个 skill 处理的场景被这个 skill 抢走了；或者为了省 token，删掉了某个错误处理分支，结果边界输入直接把流程带崩。
会改 skill 的人，脑子里通常有三个清单。第一是触发清单：什么场景应该归我管，什么场景绝对不能碰。第二是质量清单：什么样的输出算合格，用哪些维度去评审。第三是回归清单：过去有哪几个用例是必须保持通过的。这三个清单不是一次写死的，而是要在持续迭代中不断更新。
而 autoresearch 的妙处在于，它逼你先建模再动手。你如果只是说「帮我把这个 skill 改得更好」，Claude 是无从下手的，因为「更好」不可量化。但你如果说「请在保持现有回归用例全部通过的前提下，让输出通过 eslint 检查的比例从 60% 提升到 90%」，这个任务就变成可研究、可验证、可迭代的工程问题了。
3. 用 Autoresearch 流程把 Skills 改进变成流水线
3.1 第一步：把改进目标变成可度量的研究问题
这是整个流程里最容易被跳过的，也是最重要的。你必须在动手改任何 prompt 之前，先把「更好」翻译成「可测量的指标」。我自己常用五个维度来拆目标：触发准确率、生成合规率、回归稳定性、人工修正量、执行耗时。不需要五个维度同时下指标，一次只聚焦一个主指标，最多加两个辅助指标，再多就容易让评估过程失焦。
举个例子，如果你觉得某个 skill 生成的前端组件经常被 lint 报错，那主指标就可以定为「一轮生成后通过 eslint --fix 加 tsc 编译检查的比例」。辅助指标可以是「无需人工修改即可通过验证的用例占比」。一旦指标定了，下一步就是准备测试集。测试集不需要大，但要覆盖典型场景和边界场景，典型的 10 到 15 个用例就足够发现问题。
这一步完全可以让 Claude 参与进来。我会在 Claude Code 里给它一个任务：「请根据当前 SKILL.md 的能力范围，设计 12 个覆盖典型输入、边界输入、异常输入的测试场景，每个场景给出明确的输入内容与预期输出约束。」这本身就是一个小型 autoresearch 任务，它产出的测试集就是你后面所有实验的标尺。记住，测试集是全流程的地基，测试集质量差，后面的实验全部失去意义。
3.2 第二步：让 Claude 先做「文献综述」
很多人改 skill 是直接改，我建议你先让 Claude 做一轮「文献综述」。什么意思？就是让它自己去检索现有公开的最佳实践、相似场景的优秀 skill、官方文档里的新特性，然后输出一份研究报告，列出当前这个技能包有哪些可借鉴的改进方向。这一步不是走形式，而是为了把你个人的经验盲区补上。单靠你自己的认知去改 skill，天花板就是你自己的水平；让 Claude 去调研社区里的公开项目，等于把行业里最新的实践也拉进了迭代循环。
实际操作时，我会给 Claude 开放联网搜索或者要求它阅读本地已有的开源项目，比如 agent skills 相关的一线社区仓库。这轮研究的产出不是让你照搬，而是给你一张「候选改进点清单」。比如社区里大量优秀的 skills 都会在结尾放 self-check 清单，或者把触发条件写成「只有当用户明确要求 X 且未提供 Y 时才触发」，这些模式都有自己的适用环境。
我在一次针对前端开发 skills 的文献综述里，Claude 给出了三个我当时完全没想到的改进方向：一是把 lint 自检作为生成流程的最后一步，而不是留给用户；二是在 description 中明确排除「只给代码片段不要解释」的触发情况，避免被误触发；三是为组件生成附带 README 片段，说明 props 和用法。这三个方向后来全部被验证有效。文献综述的价值不在于它给你答案，而在于它帮你把「搜索范围」和「思考边界」同时放大。
3.3 第三步：批量实验与回归对比
有了测试集和研究报告，就可以正式进入实验阶段了。这步是 autoresearch 和普通改 prompt 的分水岭：普通改法只跑一两个例子感受一下；autoresearch 则要求你一次设计多组对照实验，然后把结果量化对比。我通常会做至少三组对照：基线版（当前版本）、方案 A（只改描述）、方案 B（描述加自检流程，或者不同版本的结构调整）。每一组实验都在同一批测试集上跑，记录每个用例的输出状态。
评估环节最关键：谁来打分？我的做法是让 Claude 自己扮演评审者，按预设维度对每份输出打分。打分标准在实验前就写好，避免评估过程的随意性。比如对前端组件生成任务，我会定义以下维度：与需求匹配度、代码可编译性、样式完整性、可访问性、安全性。每个维度 1 到 5 分，然后取平均分作为该版本的整体得分。为了减少偶然性，实验时尽量关掉非必要的可变因素，比如固定模型温度、关闭随机采样、保证在同一份上下文里运行。
这一轮跑完，你会拿到一张很直观的对比表。哪个方案在哪个维度上领先、哪个用例让哪个版本翻车，一目了然。我强烈建议把每一次实验记录保存下来，不要只保留最终结论。因为后面追加改进时，你经常会需要回看之前的实验细节，判断某个新问题到底是这次改动引入的，还是一直存在只是没暴露。
3.4 第四步：把结论沉淀回 SKILL.md
实验验证过的结论，最终要写回 skill 本身。这一步要讲究「写入粒度」：不是把实验中的长段对话记录塞进 SKILL.md，而是把有效的模式提炼成简洁的指令。比如你发现「生成组件后必须自检查一遍 props 类型是否完整」有效，那就在 SKILL.md 的末尾加一条自检清单项，而不是写一整段解释。Skill 里的每一句话都是有成本的，会占用上下文窗口，也会影响触发判断，保持高信息密度是长期维护的关键。
沉淀时我也会同步更新 skill 目录里的变更日志或测试记录。我的习惯是给每个重要的 skill 维护一份 test.md，里面记录测试集、各版本得分和已知问题。这样下次要优化时，直接翻开 test.md 就能快速回到上下文，不用重新回忆上一次实验到底跑了个啥。你甚至可以把这个 test.md 本身交给 Claude 去读，让它基于历史实验记录提出下一轮优化方向，这就真正把 autoresearch 的循环转起来了。
4. 实操复盘：一个前端开发 Skill 的 10 倍改进全过程
4.1 原始 Skill 的问题诊断
说个真实发生过的案例。我之前有一个前端开发的 skill，作用是在 Claude Code 里根据产品描述生成 React 组件和对应页面。刚写出来时挺能打的，但随着项目复杂化，问题开始暴露：生成代码经常出现样式漏写、组件拆得过大、甚至把不该有的 mock 数据打进生产代码。最让我头疼的是，这些问题不是每次都出现，而是间歇性出现，所以连排查都费劲。
我最初的想法是加一长串「不要犯错」的禁令，什么「不要漏掉样式」「不要写死数据」「组件不要超过 200 行」。结果可想而知：禁令越多，模型越是在输出时畏手畏脚，生成的组件反而结构更乱。这就是我开头提到的「失败迭代」。后来我停下来，用 autoresearch 的方法做了一次完整复盘。
诊断阶段我用固定测试集跑了一遍基线版，统计出三类主要问题：样式缺失占 45%，组件结构不合理占 30%，硬编码数据占 25%。这个分布直接改变了我的改进策略——如果我当初凭感觉改，大概率会去优化占 25% 的硬编码问题，但真正的大头其实是样式缺失。数据告诉我，需要加强的不是「道德约束」，而是「输出后的自检流程」。
4.2 改版后的核心变化
我把新版 skill 的重心从「事前禁令」转移到「事后自检」。新版流程分三步：先按需求生成完整的组件代码，然后进入独立的自检阶段，逐个检查样式、可访问性和数据来源；最后输出一份简短的 self-review 说明，声明每个检查项是通过还是未覆盖。这个设计是文献综述阶段的成果：与其在指令里反复说「不要漏」，不如把漏的可能性直接变成流程中的显式步骤。
触发描述也有变化。旧版描述是「生成符合要求的前端组件」，太宽泛，经常被无关请求误触发；新版明确写了「当用户描述了一个 UI 组件或页面的视觉结构与交互需求时」触发，同时加上「如果用户仅询问代码写法而非生成完整组件，不要触发」的排除条件。这一个小改动，让这个 skill 的误触发率从大约 30% 降到了 5% 左右，是我完全没想到的额外收益。
我还做了一件很细节的事：把测试用例直接写进 skill 目录。新版 skill 里附带了一个由 12 个场景组成的测试说明文件，Claude 在输出前会参考相近的测试场景约束。这一步看起来不起眼，但效果很明显，因为它让模型在生成时有了「参照系」，而不是凭空发挥。很多公开的优秀 skill（比如 nature skills 这类被大家反复讨论的集合）都会带上几个 few-shot 示例，我在这次改造里体会到了为什么它们都这么做。
4.3 实测数据与收益
改造完成后，我在同样 12 个测试集上跑了对比实验。先说结果：基线版的 lint 检查通过率是 58%，改版后提升到 92%；样式完整性的主观评分从平均 2.8 升到 4.5；需要人工修正的组件数量从 7 个降到 2 个。如果综合「一次通过率」「人工修正时间」「误触发次数」这三个维度，整体效率确实有将近十倍的差距，尤其是人工修正环节，从每个任务平均花 15 分钟降到 3 分钟以内。
这次实验也给了我一个很重要的经验：10 倍改进往往不是靠一个「惊为天人」的新提示词，而是靠把流程拆细、在每个环节降低损耗。旧版 skill 最大的问题不是模型能力不够，而是它没有自查的机会。你让模型一口气生成完就交付，和一个多跑一步自检再交付，输出质量当然天差地别。Claude 很吃「有机会自我修正」这一套，所以设计 skill 时一定要给模型留出纠正自己的路径。
顺带一提，这个案例不代表其他 skill 也要照搬自检流程。如果你在做的是论文润色、数据分析或者命令行操作类 skill，对应的自检项完全不同。但方法论是通用的：先量化问题和目标，再设计实验验证，最后把有效的机制沉淀为流程。
5. 踩坑清单与排查技巧
5.1 常见问题速查表
在实际动手的过程中，我整理了一些常见问题，按表格列出来供你对照排查。
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| Skill 在应该触发时不触发 | description 写得太泛或用了错误的关键词 | 检查触发描述是否包含明确的动词和宾语，补充排除条件 |
| Skill 频繁被无关请求误触发 | description 缺少边界描述 | 增加「什么时候不要触发」的排除语句 |
| 同一输入每次输出差异巨大 | 未固定随机性，或 skill 指令过于轻量 | 增加结构化的输出格式约束，必要时在流程中增加自检 |
| 改版后老场景全崩 | 缺少回归测试集 | 建立一个固定测试集，每次改动后都要回归一遍 |
| 加了大量禁令后效果反而变差 | 模型被过度约束，失去主动性 | 把注意力从「禁止什么」转移到「流程怎么做」 |
| Skill 在 Claude Code 里无法加载 | 安装配置问题，常见于不同平台的安装方式不一致 | 检查 claude code 安装路径、Workspace 环境配置（如 Windows 平台虚拟机启动项）、VSCode 插件配置及终端对 claude 命令的识别 |
表里最后一条要多说两句。最近很多人在 VSCode 里或 Windows 环境配 Claude Code 时遇到加载问题，报错五花八门，有几个非常典型，比如无法识别 claude 命令、native binary 未安装、workspace 需要开启 Windows 虚拟机平台等。这类问题基本不是 skill 文件本身造成的，而是环境。对应做法是依次确认安装命令是否完整执行、系统环境变量是否生效、工作区配置是否被正确加载。与其花时间怀疑 skill 写得有问题，不如先确认环境和命令链路是通的。
5.2 几个我到后期才想明白的避坑心得
第一，不要一上来就追求「全面优化」，先建基线。这是我反复强调的：任何改进必须有一个可量化的起点。没有基线，你根本不知道改的是对还是错。就算测试集只有三五个用例也没关系，有基线比没基线强十倍。
第二，改造时把「文件粒度」拉开，不要把所有内容塞进一个 SKILL.md。我在维护复杂 skills 时，会把步骤拆成子文档，比如 reference.md、checklist.md、examples.md，在 SKILL.md 里用导航的方式引用。这样改一个模块不会影响其他模块，回归排查也更方便。大部分开源顶级 skills 都有类似结构，这不是洁癖，是工程效率。
第三，每次实验记录要包含失败版本。很多人只保存「最终版本」，把中间实验的 prompt 全删了。真到了以后想对比某种写法的优缺点时，你会发现自己什么证据都没有。现在我给每个 skill 目录配一个 experiments/ 文件夹，把每次实验的 main prompt、测试集和评分都存下来。短期看是多了几个文件，长期看这是一座可挖的金矿。
第四，关于常见的「批量生成不了高质量输出」问题，不要急着认定是模型不行。先看 skill 有没有给它足够的上下文和修正机会。如果连 self-check 环节都没有，输出质量不稳定是必然的，跟模型能力有多大关系就说不清楚了。
6. 我个人的一点体会
做完这一整套改造后，我最大的收获不是某个 skill 变强了，而是我形成了一种看待 AI 提示工程的思维方式：任何可重复的任务，都配得上一套可重复的改进流程。以前我把 skill 当作文档来写，现在我把 skill 当作产品来迭代。产品的迭代靠数据、实验、回归，skill 的迭代同样应该如此。
我其实试过把同样的方法用在其他类型的 skills 上，比如论文润色、数据分析报告生成，效果都很显著。这个过程验证了 Karpathy 那个观点的普适性：让 AI 自己研究问题、自己评估方案，这套循环不仅适用于训练模型，也适用于任何依赖模型能力的工程资产。你不需要一次性做到完美，只要能跑通「定义问题、搜集方案、批量实验、沉淀结论」这个循环，你的 skills 就会进入一个持续自我改进的上升轨道。
最后再分享一个小技巧：当你在一个 skill 上跑完三轮 autoresearch 迭代后，强烈建议把整个实验过程和历史版本作为上下文，交给 Claude 去分析它自己的改进轨迹。它会从一个更客观的视角总结出哪些类型的改动对你这个场景最有效。这个信息，往往是你在繁琐的实验记录中最难自己提炼出来的部分。后续扩展也很简单，你可以把这套方法应用到团队协作里，把测试集和基线标准沉淀为公共资产，让每个成员都能在同一个标尺下改进自己的 skills。
