我最近把 Karpathy 那套 Autoresearch 思路搬到了 Claude Skills 的开发流程里效果比我预想的好太多。以前写一个 Skill先得翻半天文档再反复试 prompt 调结构最后还要找一堆场景做回归测试一天能磨出一个就不错了。现在我把研究、生成、测试三个环节全部交给 AI 自己跑同一个 Skill 从想法到能用基本控制在半小时内而且质量一点不比手动写的差。这篇文章就把我的完整做法摊开讲Karpathy 的 autoresearch 方法到底解决了什么问题Claude Skills 的底层机制有哪些坑以及怎么搭一条自动调研、自动生成、自动验证的流水线。适合正在用 Claude Code 的人、想给团队沉淀领域经验的同学以及写了几个 Skill 但总觉得不好用、不聪明的开发者。1. 先搞懂 AutoresearchKarpathy 提倡的这种研究方法到底是什么1.1 从让 AI 查资料到让 AI 完成整轮研究很多人以为 autorearch 就是拿 AI 当搜索框用问一句答一句然后把答案复制进文档。Karpathy 在公开场合聊这个概念时强调的是另一个维度让 AI 像研究员一样自己定义研究问题自己去找资料自己交叉验证自己输出报告然后根据报告质量继续下一轮迭代。这不是一个单次问答而是一个闭环流程。我把它简化成五个阶段目标定义、信息采集、综合归纳、产出沉淀、结果评估。目标定义阶段让 AI 明确我要解决什么问题、产出什么格式的结果信息采集阶段AI 自动访问官方文档、GitHub、技术博客拉取与主题强相关的内容综合归纳阶段把采集到的碎片整理成结构化结论产出沉淀阶段生成一份可以直接用的文档或技能文件最后评估阶段用一组测试用例检查这份产出到底有没有用没用就打回重来。这么说可能有点抽象我用一个生活类比。你让一个实习生做行业调研给他一个主题他不会只搜一次就交差。他会先列大纲分头查资料比对不同来源的说法发现矛盾再深挖最后写成报告还要找人挑错。Autoresearch 就是把这个完整流程自动化了AI 同时扮演实习生、审稿人和项目经理。把它用在 Claude Skills 开发上正好命中了一个痛点Skills 的本质是领域知识而领域知识恰恰依赖大量且新鲜的输入。1.2 为什么这套方法论天然适合 Skills 开发写 Skill 的人通常都会遇到三个问题。第一是知识盲区前端、运维、数据分析、学术写作每个领域的水都很深个人经验再丰富也覆盖不全第二是迭代成本高写完一版 Skill要实测、要改、再实测每改一轮都要消耗不少时间第三是知识保鲜难很多 Skill 里写的最佳实践半年后就过时了但你很难持续跟踪。Autoresearch 恰好能同时解决这三个问题。知识盲区靠自动调研来补AI 一天能读的资料比人一个月读的都多迭代成本靠自动循环来降把生成、测试、反馈写成脚本改一个描述就能自动跑完整轮验证知识保鲜靠定期复盘来维持让 AI 定时基于使用日志重新调研把过时的内容替换掉。我在实际项目中试过之后最大的感受是它把 Skill 开发从手工艺活变成了流水线生产你不用再亲力亲为每一个细节而是把精力花在定义目标和评审结果上。2. Claude Skills 机制你可能踩过的坑和真正该懂的底层规则2.1 Skills 的本质不是插件是压缩后的领域经验先把这个概念理清楚。Claude Skills 不是传统意义上的插件它不包含可执行程序本质上是一个带有结构化格式的 Markdown 知识包。你给它起好名字、写好说明、塞进固定目录Claude Code 就会在遇到匹配任务时自动加载这份操作手册照着里面的规则来干活。为什么说它是压缩后的领域经验因为一份优秀的 SKILL.md 相当于把某个领域的所有关键知识浓缩成几条可执行的指令。比如写一个前端代码审查 Skill你不用把 JavaScript 语法抄一遍而是要把审查时的关注点、常见反模式、推荐的组件拆分原则写清楚。Claude 读到之后就知道在什么场景下按什么顺序做什么判断。目录结构也很简单默认放在~/.claude/skills/下每个 Skill 一个子目录里面必须有SKILL.md。举个例子~/.claude/skills/ └── frontend-review/ └── SKILL.md当 Claude 认为当前任务与 frontend-review 的描述匹配时它会自动读取这个文件的内容然后按里面的指导执行。这个机制的一大好处是知识可以独立于对话历史存在。哪怕是一个全新的会话只要装了这个 SkillClaude 就知道该领域的操作规范不用每次都从头解释。2.2 手写一个最小可用的 Skill从命名到 Frontmatter我来给你看一个能直接跑起来的最小样例。先新建目录和文件然后在SKILL.md里写这些内容--- name: frontend-review description: 用于审查前端代码关注组件拆分、状态管理、性能隐患与可维护性。当用户请求 review 前端代码时使用。 --- # 前端代码审查 ## 审查步骤 1. 先梳理代码的整体结构与组件划分 2. 检查状态管理是否合理避免过度全局化 3. 定位明显的性能隐患例如不必要的重渲染、大依赖打包 4. 给出可执行的修改建议而不是抽象批评 ## 输出格式 - 按 问题 / 影响 / 建议 三列列出审查结果这个文件里有三个关键点。第一是name它是 Skill 的唯一标识第二是description这段描述决定了 Claude 什么时候触发这个 Skill一定要写清楚适用场景和触发条件写得越精确越不容易误触发第三是 Markdown 正文它提供了技能的实际操作内容。这三个部分缺一不可。很多新手卡在description上要么写得太宽泛比如审查代码导致 Claude 在所有编程任务里都想加载它要么写得太窄比如审查 React 组件中的 useState 使用导致该触发时不触发。我的经验是描述里应该包含 2-3 个明确的业务场景词再写清楚在什么情况下使用这样命中率最高。2.3 安装与路径那些容易被卡住的环节Skill 的安装方式有两种。一种是把目录直接放到全局目录~/.claude/skills/所有项目都能用另一种是放在项目目录下的.claude/skills/只对当前项目生效。个人项目建议用全局路径团队协作时建议跟项目一起走方便版本管理。但我得提醒你Windows 用户在这里最常见的报错是claude : 无法将claude项识别为 cmdlet、函数、脚本文件或可运行程序的名称。出现这个基本就是 npm 全局安装目录没进 PATH。解决办法是在系统环境变量里加上 npm 的全局路径具体位置用npm prefix -g查。装完要重启终端然后再执行claude --version验证。还有一个 Windows 特有的坑提示claudes workspace requires the virtual machine platform on windows. enable。这是因为 Claude Code 的部分工作区能力依赖 Windows 虚拟化平台。解决路径是控制面板 → 启用或关闭 Windows 功能 → 勾选虚拟机平台然后重启。如果你用的是 WSL2这一步基本是绕不开的。3. 用 Autoresearch 方法 10 倍改进 Claude Skills一条可复制的流水线3.1 阶段一自动领域调研把别人踩过的坑写进 Skill我写 Skill 的第一步已经不再是自己回忆经验而是让 AI 做一轮深度调研。比如我要写一个前端开发 Skill我会把这段 prompt 丢给 Claude你是一名资深前端架构师。请围绕React 组件设计最佳实践这个主题自动调研 2024-2025 年官方文档、知名开源项目、技术博客中的观点。 要求 1. 列出 10 条值得写进技能文档的结论每条标注来源 2. 从社区讨论中总结出 5 个常见反面模式 3. 输出一份 Markdown 格式的调研报告供后续写入 SKILL.md这一轮跑下来你会得到一份信息密度非常高的报告。然后我再让 Claude 基于报告提炼出操作规则直接生成 SKILL.md 的初稿。这一步的好处是Skill 里的观点不再是我觉得而是有出处的、经过交叉验证的行业共识。对盲区多的领域这件事尤其关键你闭门造车想不出来的坑社区里早就讨论过无数遍了。3.2 阶段二自动生成加自动测试打磨出高质量 Skill拿到初稿只是开始真正值钱的是后面的循环。我会写一个简单的脚本把三个动作串联起来从调研报告生成 Skill 文件、跑一组预置的测试用例、收集失败结果反馈给 AI 修改。下面是这个循环脚本的核心结构我用的 Python你可以换成任何顺手的技术栈import subprocess import json def generate_skill(research_report: str, output_path: str): prompt f基于以下调研报告生成一份 SKILL.md 文件要求结构清晰、指令可执行\n{research_report} # 调用 Claude API 生成 skill 内容 result call_claude_api(prompt) write_file(output_path, result) def run_test_cases(skill_path: str, test_cases: list): passed 0 for case in test_cases: # 让 Claude 在加载 skill 的情况下处理测试输入 response run_claude_with_skill(skill_path, case[input]) ok evaluate(response, case[expected]) if ok: passed 1 return passed / len(test_cases) def iterate(skill_path: str, test_cases: list, max_rounds: int 5): for round_id in range(max_rounds): score run_test_cases(skill_path, test_cases) print(fround {round_id}: {score:.2%}) if score 0.9: break # 将失败用例反馈给 AI 继续改进 feedback collect_failures(skill_path, test_cases) improve_skill_with_feedback(skill_path, feedback)这里的核心思路不是一次写对而是让 AI 知道自己哪里做错了然后去改。第一次生成的 Skill 可能只拿到 60% 的测试通过率但把失败样例喂回去之后第二次就能到 85%第三轮基本稳定在 90% 以上。整个循环不需要人介入质量就这么一点点磨出来了。3.3 阶段三持续反思与版本迭代让 Skill 跟上时代Skill 写完之后不能放着不管领域知识在变工具链在变最佳实践也在变。我的做法是让 Claude Code 每次使用 Skill 后输出一条简短的使用日志记录任务类型、关键决策和遇到的问题。积累一段时间后把日志打包发给 AI让它做一次复盘输出改进建议。这个复盘本质上也是一次小规模的 AutoresearchAI 回顾实际使用的案例对比当前 Skill 的指令和目标效果之间的差距再搜索最新的资料验证有没有更优做法最后输出 SKILL.md 的修改补丁。我大概每两周跑一次这样的复盘每次都能发现几个值得优化的点。比如某个 Skill 里的旧 API 用法被新版替代或者哪个审查步骤在实际应用中太啰嗦这类问题靠人肉感知很难及时发现。4. 实操用 Autoresearch 思路构建一个前端开发 Skills完整示例4.1 需求定位为什么拿前端开发做示范我选前端开发作为这次演示的主题是因为它在热搜里反复出现而且非常能体现 Autoresearch 的价值。前端技术栈碎片化严重React/Vue 生态、打包工具、样式方案、性能指标每个方向都有大量内容需要跟踪。如果手动整理光一个组件设计话题就能写几万字但用自动调研去生成半小时内就能产出一份既能用又好维护的 Skill。下面我会完整演示一个名为frontend-dev的 Skill 从调研到落地到验证的全过程。代码和文件都是可以直接复制跑的你改改描述就能迁移到自己的领域。4.2 第一步让 Claude 自动调研输出 Skill 原料我先执行上一节里的那段调研 prompt。为了让你看到实际效果我调整一下让它更贴近一个完整 Skill 的需求你是一名资深前端开发者。请自动调研当前前端开发的关键主题组件设计、状态管理、性能优化、CSS 方案选型。 输出一份《前端开发全景调研报告》包含 1. 每个主题下 3 条公认的最佳实践 2. 每条最佳实践对应的反面案例 3. 一份适合写入 SKILL.md 的操作指令清单 4. 标注信息时效性说明哪些知识点在 2024 年后有更新跑完之后AI 给我的报告里最值钱的是操作指令清单。比如组件设计部分它总结出每个组件只做一件事props 数量超过 8 个就要考虑拆分避免在 render 中创建新对象导致子组件重渲染状态提升到最近公共父组件。这些指令本身就带可执行性几乎可以直接进 SKILL.md。4.3 第二步生成 SKILL.md 骨架并写入核心指令基于调研报告我让 Claude 生成了一份frontend-dev的 SKILL.md。结构是这样--- name: frontend-dev description: 用于现代前端开发任务包括 React/Vue 组件设计、状态管理、性能优化与代码审查。适合在小程序、中后台应用、前端工程化项目中配置。 --- # 前端开发 ## 核心原则 - 组件单一职责一个组件只做清晰的一件事 - 状态放到最近的公共父级避免无意义的全局 store - 性能优化优先解决渲染次数与依赖体积 ## 组件设计检查清单 - [ ] props 是否超过 8 个 - [ ] 是否在 render 中创建对象或函数字面量 - [ ] 是否存在深层 props 透传 - [ ] 能否拆分子组件 ## 状态管理决策路径 1. 先问这个状态是服务端数据还是 UI 状态 2. UI 状态优先使用局部 state跨组件才考虑 Context 3. 服务端数据用请求库的缓存能力不直接进全局 store ## 代码审查输出格式 | 文件位置 | 问题 | 影响 | 建议 | |---------|------|------|------|这份 SKILL.md 的特点是指令密度高、组织清晰。描述部分明确写清了适用场景正文部分把审查、组件设计、状态管理都拆成了可勾选的清单。为什么要勾选清单因为 Claude 在生成代码时天然倾向于自由发挥而清单能把它约束到逐项排除问题的路径上这正是 Skill 和普通 system prompt 的差别。4.4 第三步编写测试夹具与自动化校验脚本只有 SKILL.md 还不够我得验证它是不是真的好用。我构造了 8 个测试用例覆盖组件拆分、状态管理、性能审查等场景。每个用例包含输入代码和预期结论关键词[ { id: case-01, input: ComponentChild data{obj.item} /Child data{obj.item} //Component, expected: [重复渲染, 缓存, memo] }, { id: case-02, input: function App(){ const [user, setUser] useState(null); return Profile user{user}/ }, expected: [状态提升, props, 合理] } ]然后我用前面那段iterate脚本跑自动评分。第一轮生成出来的 Skill 通过率只有 75%主要问题集中在有的用例它只给出了泛泛建议没有命中期望的关键词。我把失败输出收集起来让 Claude 阅读自己的问题再改第二次就达到了 100% 通过率。说实话这个速度远超我的预期。4.5 第四步接入 Claude Code实测效果测试脚本通过不代表真实场景好用我还得在 Claude Code 里实测。我把这个 Skill 放在全局目录然后在一次真实的代码审查任务里触发了它。实际效果是当我把一段控制台工具的代码提交给它 review 时它自动加载了 Skill 里关于状态管理和性能优化的检查清单给出的建议明显比没有 Skill 时更结构化比如直接指出这个列表组件缺少 memo会导致父组件每次渲染时子组件全部重渲染。实测下来我还发现一个有趣的现象加载 Skill 后Claude 的输出长度反而变短了。因为它不再输出一堆正确的废话而是按清单逐项走最后只留下真正有问题的点。这也是我认为 Skill 最核心的价值它不是让 AI 变得更啰嗦而是让 AI 更精准。4.6 避坑提示没有银弹的 Skill 设计写 Skill 最容易犯的错误是试图覆盖所有场景。一开始我给frontend-dev塞进了 React、Vue、Angular、工程化、可视化、小程序、移动端适配结果就是这个 Skill 看起来无所不包实际使用时哪一条都不深入连触发都变得不稳定。后来我把它拆成frontend-react、frontend-vue、frontend-performance三个独立 Skill效果立刻不一样了。另一个注意点是Skill 正文里尽量减少模糊指令。比如提高代码质量这种话等于没说检查每个 effect 是否缺少清理函数才是有效指令。你在设计 Skill 时一定要想象 Claude 是个执行力很强但不太会举一反三的实习生你的指令越明确它的表现越可靠。5. 进阶玩法当 Skills 开始自举5.1 让 Skill 自己的执行流程里带上 Autoresearch前面说的是用 Autoresearch 开发 Skill进阶一步是让 Skill 在运行中执行 Autoresearch。什么意思比如一个>
Autoresearch驱动Claude Skills开发：自动调研生成测试的完整流水线
我最近把 Karpathy 那套 Autoresearch 思路搬到了 Claude Skills 的开发流程里效果比我预想的好太多。以前写一个 Skill先得翻半天文档再反复试 prompt 调结构最后还要找一堆场景做回归测试一天能磨出一个就不错了。现在我把研究、生成、测试三个环节全部交给 AI 自己跑同一个 Skill 从想法到能用基本控制在半小时内而且质量一点不比手动写的差。这篇文章就把我的完整做法摊开讲Karpathy 的 autoresearch 方法到底解决了什么问题Claude Skills 的底层机制有哪些坑以及怎么搭一条自动调研、自动生成、自动验证的流水线。适合正在用 Claude Code 的人、想给团队沉淀领域经验的同学以及写了几个 Skill 但总觉得不好用、不聪明的开发者。1. 先搞懂 AutoresearchKarpathy 提倡的这种研究方法到底是什么1.1 从让 AI 查资料到让 AI 完成整轮研究很多人以为 autorearch 就是拿 AI 当搜索框用问一句答一句然后把答案复制进文档。Karpathy 在公开场合聊这个概念时强调的是另一个维度让 AI 像研究员一样自己定义研究问题自己去找资料自己交叉验证自己输出报告然后根据报告质量继续下一轮迭代。这不是一个单次问答而是一个闭环流程。我把它简化成五个阶段目标定义、信息采集、综合归纳、产出沉淀、结果评估。目标定义阶段让 AI 明确我要解决什么问题、产出什么格式的结果信息采集阶段AI 自动访问官方文档、GitHub、技术博客拉取与主题强相关的内容综合归纳阶段把采集到的碎片整理成结构化结论产出沉淀阶段生成一份可以直接用的文档或技能文件最后评估阶段用一组测试用例检查这份产出到底有没有用没用就打回重来。这么说可能有点抽象我用一个生活类比。你让一个实习生做行业调研给他一个主题他不会只搜一次就交差。他会先列大纲分头查资料比对不同来源的说法发现矛盾再深挖最后写成报告还要找人挑错。Autoresearch 就是把这个完整流程自动化了AI 同时扮演实习生、审稿人和项目经理。把它用在 Claude Skills 开发上正好命中了一个痛点Skills 的本质是领域知识而领域知识恰恰依赖大量且新鲜的输入。1.2 为什么这套方法论天然适合 Skills 开发写 Skill 的人通常都会遇到三个问题。第一是知识盲区前端、运维、数据分析、学术写作每个领域的水都很深个人经验再丰富也覆盖不全第二是迭代成本高写完一版 Skill要实测、要改、再实测每改一轮都要消耗不少时间第三是知识保鲜难很多 Skill 里写的最佳实践半年后就过时了但你很难持续跟踪。Autoresearch 恰好能同时解决这三个问题。知识盲区靠自动调研来补AI 一天能读的资料比人一个月读的都多迭代成本靠自动循环来降把生成、测试、反馈写成脚本改一个描述就能自动跑完整轮验证知识保鲜靠定期复盘来维持让 AI 定时基于使用日志重新调研把过时的内容替换掉。我在实际项目中试过之后最大的感受是它把 Skill 开发从手工艺活变成了流水线生产你不用再亲力亲为每一个细节而是把精力花在定义目标和评审结果上。2. Claude Skills 机制你可能踩过的坑和真正该懂的底层规则2.1 Skills 的本质不是插件是压缩后的领域经验先把这个概念理清楚。Claude Skills 不是传统意义上的插件它不包含可执行程序本质上是一个带有结构化格式的 Markdown 知识包。你给它起好名字、写好说明、塞进固定目录Claude Code 就会在遇到匹配任务时自动加载这份操作手册照着里面的规则来干活。为什么说它是压缩后的领域经验因为一份优秀的 SKILL.md 相当于把某个领域的所有关键知识浓缩成几条可执行的指令。比如写一个前端代码审查 Skill你不用把 JavaScript 语法抄一遍而是要把审查时的关注点、常见反模式、推荐的组件拆分原则写清楚。Claude 读到之后就知道在什么场景下按什么顺序做什么判断。目录结构也很简单默认放在~/.claude/skills/下每个 Skill 一个子目录里面必须有SKILL.md。举个例子~/.claude/skills/ └── frontend-review/ └── SKILL.md当 Claude 认为当前任务与 frontend-review 的描述匹配时它会自动读取这个文件的内容然后按里面的指导执行。这个机制的一大好处是知识可以独立于对话历史存在。哪怕是一个全新的会话只要装了这个 SkillClaude 就知道该领域的操作规范不用每次都从头解释。2.2 手写一个最小可用的 Skill从命名到 Frontmatter我来给你看一个能直接跑起来的最小样例。先新建目录和文件然后在SKILL.md里写这些内容--- name: frontend-review description: 用于审查前端代码关注组件拆分、状态管理、性能隐患与可维护性。当用户请求 review 前端代码时使用。 --- # 前端代码审查 ## 审查步骤 1. 先梳理代码的整体结构与组件划分 2. 检查状态管理是否合理避免过度全局化 3. 定位明显的性能隐患例如不必要的重渲染、大依赖打包 4. 给出可执行的修改建议而不是抽象批评 ## 输出格式 - 按 问题 / 影响 / 建议 三列列出审查结果这个文件里有三个关键点。第一是name它是 Skill 的唯一标识第二是description这段描述决定了 Claude 什么时候触发这个 Skill一定要写清楚适用场景和触发条件写得越精确越不容易误触发第三是 Markdown 正文它提供了技能的实际操作内容。这三个部分缺一不可。很多新手卡在description上要么写得太宽泛比如审查代码导致 Claude 在所有编程任务里都想加载它要么写得太窄比如审查 React 组件中的 useState 使用导致该触发时不触发。我的经验是描述里应该包含 2-3 个明确的业务场景词再写清楚在什么情况下使用这样命中率最高。2.3 安装与路径那些容易被卡住的环节Skill 的安装方式有两种。一种是把目录直接放到全局目录~/.claude/skills/所有项目都能用另一种是放在项目目录下的.claude/skills/只对当前项目生效。个人项目建议用全局路径团队协作时建议跟项目一起走方便版本管理。但我得提醒你Windows 用户在这里最常见的报错是claude : 无法将claude项识别为 cmdlet、函数、脚本文件或可运行程序的名称。出现这个基本就是 npm 全局安装目录没进 PATH。解决办法是在系统环境变量里加上 npm 的全局路径具体位置用npm prefix -g查。装完要重启终端然后再执行claude --version验证。还有一个 Windows 特有的坑提示claudes workspace requires the virtual machine platform on windows. enable。这是因为 Claude Code 的部分工作区能力依赖 Windows 虚拟化平台。解决路径是控制面板 → 启用或关闭 Windows 功能 → 勾选虚拟机平台然后重启。如果你用的是 WSL2这一步基本是绕不开的。3. 用 Autoresearch 方法 10 倍改进 Claude Skills一条可复制的流水线3.1 阶段一自动领域调研把别人踩过的坑写进 Skill我写 Skill 的第一步已经不再是自己回忆经验而是让 AI 做一轮深度调研。比如我要写一个前端开发 Skill我会把这段 prompt 丢给 Claude你是一名资深前端架构师。请围绕React 组件设计最佳实践这个主题自动调研 2024-2025 年官方文档、知名开源项目、技术博客中的观点。 要求 1. 列出 10 条值得写进技能文档的结论每条标注来源 2. 从社区讨论中总结出 5 个常见反面模式 3. 输出一份 Markdown 格式的调研报告供后续写入 SKILL.md这一轮跑下来你会得到一份信息密度非常高的报告。然后我再让 Claude 基于报告提炼出操作规则直接生成 SKILL.md 的初稿。这一步的好处是Skill 里的观点不再是我觉得而是有出处的、经过交叉验证的行业共识。对盲区多的领域这件事尤其关键你闭门造车想不出来的坑社区里早就讨论过无数遍了。3.2 阶段二自动生成加自动测试打磨出高质量 Skill拿到初稿只是开始真正值钱的是后面的循环。我会写一个简单的脚本把三个动作串联起来从调研报告生成 Skill 文件、跑一组预置的测试用例、收集失败结果反馈给 AI 修改。下面是这个循环脚本的核心结构我用的 Python你可以换成任何顺手的技术栈import subprocess import json def generate_skill(research_report: str, output_path: str): prompt f基于以下调研报告生成一份 SKILL.md 文件要求结构清晰、指令可执行\n{research_report} # 调用 Claude API 生成 skill 内容 result call_claude_api(prompt) write_file(output_path, result) def run_test_cases(skill_path: str, test_cases: list): passed 0 for case in test_cases: # 让 Claude 在加载 skill 的情况下处理测试输入 response run_claude_with_skill(skill_path, case[input]) ok evaluate(response, case[expected]) if ok: passed 1 return passed / len(test_cases) def iterate(skill_path: str, test_cases: list, max_rounds: int 5): for round_id in range(max_rounds): score run_test_cases(skill_path, test_cases) print(fround {round_id}: {score:.2%}) if score 0.9: break # 将失败用例反馈给 AI 继续改进 feedback collect_failures(skill_path, test_cases) improve_skill_with_feedback(skill_path, feedback)这里的核心思路不是一次写对而是让 AI 知道自己哪里做错了然后去改。第一次生成的 Skill 可能只拿到 60% 的测试通过率但把失败样例喂回去之后第二次就能到 85%第三轮基本稳定在 90% 以上。整个循环不需要人介入质量就这么一点点磨出来了。3.3 阶段三持续反思与版本迭代让 Skill 跟上时代Skill 写完之后不能放着不管领域知识在变工具链在变最佳实践也在变。我的做法是让 Claude Code 每次使用 Skill 后输出一条简短的使用日志记录任务类型、关键决策和遇到的问题。积累一段时间后把日志打包发给 AI让它做一次复盘输出改进建议。这个复盘本质上也是一次小规模的 AutoresearchAI 回顾实际使用的案例对比当前 Skill 的指令和目标效果之间的差距再搜索最新的资料验证有没有更优做法最后输出 SKILL.md 的修改补丁。我大概每两周跑一次这样的复盘每次都能发现几个值得优化的点。比如某个 Skill 里的旧 API 用法被新版替代或者哪个审查步骤在实际应用中太啰嗦这类问题靠人肉感知很难及时发现。4. 实操用 Autoresearch 思路构建一个前端开发 Skills完整示例4.1 需求定位为什么拿前端开发做示范我选前端开发作为这次演示的主题是因为它在热搜里反复出现而且非常能体现 Autoresearch 的价值。前端技术栈碎片化严重React/Vue 生态、打包工具、样式方案、性能指标每个方向都有大量内容需要跟踪。如果手动整理光一个组件设计话题就能写几万字但用自动调研去生成半小时内就能产出一份既能用又好维护的 Skill。下面我会完整演示一个名为frontend-dev的 Skill 从调研到落地到验证的全过程。代码和文件都是可以直接复制跑的你改改描述就能迁移到自己的领域。4.2 第一步让 Claude 自动调研输出 Skill 原料我先执行上一节里的那段调研 prompt。为了让你看到实际效果我调整一下让它更贴近一个完整 Skill 的需求你是一名资深前端开发者。请自动调研当前前端开发的关键主题组件设计、状态管理、性能优化、CSS 方案选型。 输出一份《前端开发全景调研报告》包含 1. 每个主题下 3 条公认的最佳实践 2. 每条最佳实践对应的反面案例 3. 一份适合写入 SKILL.md 的操作指令清单 4. 标注信息时效性说明哪些知识点在 2024 年后有更新跑完之后AI 给我的报告里最值钱的是操作指令清单。比如组件设计部分它总结出每个组件只做一件事props 数量超过 8 个就要考虑拆分避免在 render 中创建新对象导致子组件重渲染状态提升到最近公共父组件。这些指令本身就带可执行性几乎可以直接进 SKILL.md。4.3 第二步生成 SKILL.md 骨架并写入核心指令基于调研报告我让 Claude 生成了一份frontend-dev的 SKILL.md。结构是这样--- name: frontend-dev description: 用于现代前端开发任务包括 React/Vue 组件设计、状态管理、性能优化与代码审查。适合在小程序、中后台应用、前端工程化项目中配置。 --- # 前端开发 ## 核心原则 - 组件单一职责一个组件只做清晰的一件事 - 状态放到最近的公共父级避免无意义的全局 store - 性能优化优先解决渲染次数与依赖体积 ## 组件设计检查清单 - [ ] props 是否超过 8 个 - [ ] 是否在 render 中创建对象或函数字面量 - [ ] 是否存在深层 props 透传 - [ ] 能否拆分子组件 ## 状态管理决策路径 1. 先问这个状态是服务端数据还是 UI 状态 2. UI 状态优先使用局部 state跨组件才考虑 Context 3. 服务端数据用请求库的缓存能力不直接进全局 store ## 代码审查输出格式 | 文件位置 | 问题 | 影响 | 建议 | |---------|------|------|------|这份 SKILL.md 的特点是指令密度高、组织清晰。描述部分明确写清了适用场景正文部分把审查、组件设计、状态管理都拆成了可勾选的清单。为什么要勾选清单因为 Claude 在生成代码时天然倾向于自由发挥而清单能把它约束到逐项排除问题的路径上这正是 Skill 和普通 system prompt 的差别。4.4 第三步编写测试夹具与自动化校验脚本只有 SKILL.md 还不够我得验证它是不是真的好用。我构造了 8 个测试用例覆盖组件拆分、状态管理、性能审查等场景。每个用例包含输入代码和预期结论关键词[ { id: case-01, input: ComponentChild data{obj.item} /Child data{obj.item} //Component, expected: [重复渲染, 缓存, memo] }, { id: case-02, input: function App(){ const [user, setUser] useState(null); return Profile user{user}/ }, expected: [状态提升, props, 合理] } ]然后我用前面那段iterate脚本跑自动评分。第一轮生成出来的 Skill 通过率只有 75%主要问题集中在有的用例它只给出了泛泛建议没有命中期望的关键词。我把失败输出收集起来让 Claude 阅读自己的问题再改第二次就达到了 100% 通过率。说实话这个速度远超我的预期。4.5 第四步接入 Claude Code实测效果测试脚本通过不代表真实场景好用我还得在 Claude Code 里实测。我把这个 Skill 放在全局目录然后在一次真实的代码审查任务里触发了它。实际效果是当我把一段控制台工具的代码提交给它 review 时它自动加载了 Skill 里关于状态管理和性能优化的检查清单给出的建议明显比没有 Skill 时更结构化比如直接指出这个列表组件缺少 memo会导致父组件每次渲染时子组件全部重渲染。实测下来我还发现一个有趣的现象加载 Skill 后Claude 的输出长度反而变短了。因为它不再输出一堆正确的废话而是按清单逐项走最后只留下真正有问题的点。这也是我认为 Skill 最核心的价值它不是让 AI 变得更啰嗦而是让 AI 更精准。4.6 避坑提示没有银弹的 Skill 设计写 Skill 最容易犯的错误是试图覆盖所有场景。一开始我给frontend-dev塞进了 React、Vue、Angular、工程化、可视化、小程序、移动端适配结果就是这个 Skill 看起来无所不包实际使用时哪一条都不深入连触发都变得不稳定。后来我把它拆成frontend-react、frontend-vue、frontend-performance三个独立 Skill效果立刻不一样了。另一个注意点是Skill 正文里尽量减少模糊指令。比如提高代码质量这种话等于没说检查每个 effect 是否缺少清理函数才是有效指令。你在设计 Skill 时一定要想象 Claude 是个执行力很强但不太会举一反三的实习生你的指令越明确它的表现越可靠。5. 进阶玩法当 Skills 开始自举5.1 让 Skill 自己的执行流程里带上 Autoresearch前面说的是用 Autoresearch 开发 Skill进阶一步是让 Skill 在运行中执行 Autoresearch。什么意思比如一个>