把 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。