最近Andrej Karpathy在多个场合反复强调一个观点大模型应用正在从“写提示词”走向“写Skills”。他甚至在社交账号上直接放话说自己在用Superpower Skills这个项目来管理日常工作流理由是“提示词是一次性的Skills是可积累的资产”。这可能是今年AI工程领域最值得关注的一个转向也是我在实际用Claude Code、Codex这类工具时感受最明显的一次变化。这篇文章就围绕“andrej-karpathy-skills”这个话题聊聊Skills到底是什么、为什么Karpathy这么看重它以及普通人怎么自己上手开发、安装、组合一套能真正提高效率的Skills体系。如果你现在还在靠一条条越来越长的prompt去反复指挥AI干活那你大概率会觉得“每次都要重新解释一遍上下文”这件事非常烦人。Skills恰恰就是要解决这个问题把一次调用AI的完整能力固化成文件、可复用、可分享、可迭代。这篇文章适合所有正在用Claude Code、Codex、OpenCode或任何Agent类工具的开发者也适合刚接触AI编程但已经受够了重复劳动的人。读完你能带走一套从零开发、调试、发布、组合Skills的完整方法论。1. Karpathy为什么喊话“写Skills”先搞清楚他在反对什么1.1 从Prompt到Skills到底是一次升级还是一次推翻先说结论Karpathy并不是在否定Prompt本身他否定的是“Prompt至上”这种思路。过去两年大家普遍把大模型的能力发挥归结为“提示词写得好不好”。于是各种花式Prompt模板满天飞什么角色扮演、思维链、few-shot示例都往一条消息里塞。但这个模式有一个天然瓶颈——它没有记忆、没有版本、没有模块边界。你今天调好的提示词明天换个项目、换个Agent可能就完全失效你只能再花半小时重新写。Karpathy说的Skills本质上是在提示词之上加了一层工程外壳。一个大模型任务被拆解成“任务描述 工作流步骤 辅助脚本 参考资料”统一放进一个带元数据的文件夹里。这个文件夹就是一个Skill。它可以被任意一个支持Skills协议的Agent加载加载之后Agent就知道“在什么场景下调用这个技能、按什么顺序执行、用哪些外部脚本辅助”。听起来复杂其实就是把“你每次都在消息框里重复交代的那一大段话”变成了一个规范化的、可以被程序扫描的文件包。1.2 Karpathy自己的实践他是怎么把Skills用进工作流的Karpathy公开提到的实践很有趣。他把Skills用在了三件很具体的事情上第一是代码重构他给Claude Code配了一个“代码审查”Skill每次跑完重构都会自动按规范检查一遍第二是论文阅读他有一个“论文精读”Skill输入PDF路径后会自动按“摘要—方法—实验—局限”四个模块输出结构化笔记第三是博客写作他把自己过往的文章风格浓缩进一个Skill让AI按这个风格完成初稿他在此基础上修改。这三件事的共同特点是它们都是高频率、可标准化、有明确质量要求的任务。Karpathy的潜台词是——如果你只有一个每天用一次的固定工作流那写Prompt就够了但如果你有二十个这样的工作流没有一个工程师能忍受每次重新敲一遍。他还反复提一个观点大模型时代真正的杠杆不是“能在对话里把事情说清楚”而是“能把事情说清楚一次然后以后都不用再说了”。2. Skills到底是什么拆解一个Skill的骨架和运行逻辑2.1 SKILL.md是核心但整个目录才是Skill很多人第一次接触Skills时都有一个误解觉得SKILL.md就是一个更长的Prompt。但这是一个很贵的误解——如果你只是把一个两万字的提示词扔进一个文件夹它并不会因为换了个后缀就变成一个更好的Skill。真正的Skills是一个模块化单元它至少由三个层次的组件构成描述层、指令层、执行层。描述层就是YAML格式头部那几行元数据告诉Agent这个技能什么时候触发、触发时该做什么指令层是SKILL.md正文展开描述任务目标、执行原则、输入输出要求执行层是scripts/目录下的脚本、references/目录下的参考资料给Agent提供“手和眼睛”。我见过一个做得很漂亮的“数据结构可视化”Skill它的目录长这样SKILL.md定义“根据需求生成HTML结构图”scripts/generate_svg.py负责把JSON数据渲染成SVG图references/color_palette.md和examples/目录提供配色规范和成品样例。Agent在处理请求时先读SKILL.md确认流程中间调用Python脚本完成计算最后参考色彩系统输出结果。这个Skill跑起来效果远不是一条“帮我生成一个图”的提示词能比的因为脚本保证了输出的结构正确性参考文件保证了视觉风格统一。2.2 Skill的运行机制Agent是怎么“读”一个Skill的弄清运行机制非常重要因为这决定了你写Skill的方式。当一个Agent被要求解决一个问题时它会先扫描当前Workspace里有没有匹配的Skills列表。匹配依据是SKILL.md头部YAML里的description字段——你没看错就是靠一句话描述做匹配。一旦命中Agent并不会一次性把整个SKILL.md读进上下文它通常是先读头部和部分指令然后边执行边动态加载scripts和references里的具体文件。这个机制带来的实际影响有两个。第一description字段写得好不好直接决定你的Skill会不会被正确触发。写得太宽泛无关任务也会触发白白浪费上下文和推理时间写得太狭窄该触发的不触发Skill等于不存在。第二因为Agent是惰性加载子文件的所以你在SKILL.md正文里应该写“做什么、按什么顺序做、从哪里获取辅助信息”而不是把所有细节全部塞进正文。真正参与计算的文件应该在references和scripts里这样上下文占用最小执行效率最高。2.3 为什么说“Skills是代码不是提示词”Karpathy在介绍他的Skills框架时有一个很核心的说法你写的不应该是一段话而应该是一个程序。这句话值得展开一下。一个提示词哪怕写得再详细本质上还是一个静态文本。它没有条件分支、没有错误处理、没有可验证的输入输出。但一个Skill有——SKILL.md可以有“如果输入不完整先运行scripts/check_input.py检查参数”这样的指令scripts目录里的Python脚本可以做正则校验、可以抛异常、可以格式化数据references里的示例文件可以被脚本读取作为对比基准。这些都是程序行为不是文本行为。我自己的理解是把Skills当代码写意味着你要做三件对提示词来说很反常的事。第一你要设计接口——SKILL_NAME、DESCRIPTION、输入参数是什么这就是你的API签名第二你考虑边界条件——如果输入为空怎么办如果脚本执行报错怎么办第三你做版本管理——Skill的每一次改动都会被记录、可回滚可以和别人协作修改。做到这三点Skills才真正成为“资产”而不是一个换了名字的提示词。3. 动手开发一个自己的Skill从0到1完整实操3.1 Steps创建第一个可用的Code Review Skill要理解Skills的威力最快的方式是自己动手打包一个。我们拿最日常的“代码审查”场景来做示范。先确定目标我需要一个能在Claude Code里被执行、能对当前改动文件进行静态审查、按规范输出问题清单的Skill。整个开发过程分四步。第一步建目录结构。在Claude Code的Skills目录下新建文件夹名字用全小写连字符格式就叫code-review-helper。目录里放SKILL.md、scripts/review_logic.py、references/review_checklist.md。第二步写YAML头部。这一步是让Agent认识你的Skill我给的模板是--- name: code-review-helper description: 使用当用户要求审查代码、检查代码质量、发现潜在bug时使用本技能。基于项目上下文和最佳实践输出结构化审查报告。 ---第三步写SKILL.md正文。这里不要铺开写一堆大道理而是明确任务边界和执行流程。我建议这么写先声明目标检查指定文件的正确性、可读性、安全性再定义输入要审查的文件路径不传则默认为当前git diff然后规定输出格式问题等级、问题描述、修改建议、相关代码行号最后要求Agent执行完后主动运行scripts/review_logic.py来生成统计报告。第四步写辅助脚本。这个脚本不必复杂关键是让Agent调用后能产出标准化的中间结果。这里放一个极简示例功能是统计文件行数和TODO注释数量#!/usr/bin/env python3 Quick static stats for code review. import sys from pathlib import Path def main(file_path: str) - None: target Path(file_path) if not target.exists(): print(json.dumps({error: f{file_path} not found})) sys.exit(1) lines target.read_text(encodingutf-8, errorsignore).splitlines() todo_count sum(1 for line in lines if TODO in line or FIXME in line) print(json.dumps({file: str(target), lines: len(lines), todos: todo_count})) if __name__ __main__: main(sys.argv[1])这里有个关键细节一定要给脚本写清晰的输入输出约定让Agent知道“运行这个脚本能得到什么”否则Agent经常不知道要不要调用它。3.2 Karpathy式开发心法三个在他视频里反复出现的检查标准写了好几个Skill之后我再回头看Karpathy关于开发Skills的观点发现他其实在传达三个很具体的检查标准。第一个叫“可被理解”——如果你的SKILL.md让另一个工程师或另一个模型的Agent读一遍就能准确复现你的意图那才算合格如果你的Skill只有你自己能运行那就只是私货。第二个叫“可被触发”——描述字段要写清使用场景并给出典型用户说法比如“审查一下这段代码”“帮我看看这个函数有没有问题”这样Agent在真实对话中更容易命中。第三个叫“可被调试”——Skill会出错所以你必须给脚本设计清晰的错误信息让Agent知道出了什么错、该怎么继续。我自己开发时还体会到一条额外的经验初始版本的Skill不要贪大。你可以只覆盖一个非常窄的流程哪怕只是“把一段文本转换成JSON格式并写入文件”这种小事先让它在真实项目中跑通一遍。跑通之后你再逐步加references、加异常分支。这比一开始就试图做一个全能的超级Skill靠谱得多因为后者往往调试成本高到你根本不想再用第二次。3.3 调试Skill的独家方法让Agent“说出来”比让它“做出来”更有效调试Skills最大的难点在于你看不到Agent内部是怎么理解你的Skill的。面对这个问题我的方法是把“输出markdown格式的过程报告”写进SKILL.md的指令里。比如在审查Skill里我会要求Agent先输出一段说明——它打算调用哪些脚本、按什么顺序执行、为什么这样执行然后再输出真正的审查结果。这个技巧的原理是它强迫Agent暴露它的执行路径一旦结果不对你能立刻判断问题是出在“Agent没理解指令”还是“脚本本身有bug”。如果是前者你修改SKILL.md的措辞如果是后者你只需要修脚本跟常规调试完全一样。我实测下来这种“过程可观测”的设计能把Skills调试时间缩短一半以上。另外一个小技巧是在Skill里加一个dry-run模式当用户请求带有“dry run”字眼时Agent只打印执行计划而不真正执行外部脚本这样每次改动SKILL.md后你都可以快速验证逻辑是否正确而不用真的跑一遍全流程。4. 主流平台的Skills生态对比Claude Code、Codex、OpenCode怎么选4.1 三足鼎立的格局一句话说清每个平台的脾气既然Karpathy把它当成了重点话题整个生态的响应速度也很快。到目前Claude Code的Agent Skills、OpenAI的Codex Skills、以及开源的OpenCode Skills基本把Skills协议推成了业界事实标准。它们在核心思路上都是一致的——以SKILL.md为中心配一套可被Agent加载的文件结构——但在交互方式和使用体验上有明显差异。我画了一个简单的对比表给自己和团队选型时用平台安装方式触发机制适合场景备注Claude Code手工放目录或npx自动安装自动匹配description日常开发、文档生成、代码审查生态最成熟参考资料最多Codexnpx skills add自动匹配GitHub项目分析、代码库问答与GitHub集成最紧密OpenCodegit clone或npx自动匹配自托管、自定义扩展性最强可完全自控需要注意这些平台都在快速迭代接口可能随时变化。你选型时不用追求“最好”而应该问自己一个问题我的核心使用场景在哪个工具里频率最高比如你主力IDE里跑的是Claude Code那就优先用Claude Code的Skills格式你更多是在命令行里处理GitHub仓库Codex就更有优势。4.2 用npx命令拉取别人的Skill一条命令背后的门道找现成Skills最方便的方式之一就是使用npx在v2的时候这类命令的通用格式是npx skills add some-user/some-skill-repo --agent claude-code -g -y这条命令背后的逻辑是npx会去GitHub上拉取指定仓库识别仓库里的SKILL.md结构然后自动安装到当前Agent的Skills目录下。实际使用中我建议你把skill仓库先本地读一遍再安装因为目前Skills的规范虽然趋同但不同作者对不同Agent的适配程度差别很大。有的Skill虽然打上了“claude-code”标签实际跑起来可能还是为别的平台写的需要你手动微调。还有一点要注意如果你拉取的Skill来自陌生账号建议先检查目录里有没有可疑脚本。这不是极端谨慎而是基本的供应链安全意识——因为SKILL.md里的描述会被Agent自动执行等于在运行第三方代码。我自己的习惯是新下载的Skill一律先放到隔离目录里用一次无害任务测试正常之后再放进正式的全局目录。4.3 从“单点Skill”到“Skill全家桶”组合就是新的生产力单个Skill只是提高了某个环节的效率但Skills真正让我震撼的是它可以互相组合。比如我有一个“前端开发”Skill本身只负责生成React组件代码还有一个“UIUXProMax”Skill专门负责给组件加上设计系统规范再有一个“结构图”Skill负责生成架构图。这三个Skill可以被串成一个完整的开发闭环我先让Agent用“前端开发”Skill生成组件接着用“UIUXProMax”Skill补充样式规范最后用“结构图”Skill生成组件的依赖关系图。每一条指令背后都是整套成套的专业Know-how在起作用而不是一个孤立的大模型在“自由发挥”。这种组合思维我认为才是Karpathy谈论Skills时最想强调的东西。单个Agent的能力边界有限但当你有一个Skill库时Agent的行为边界可以被你自定义。你不再受限于模型本身的通用能力而是可以赋予它你想要的任何专业能力并且这些专业能力还能被不断升级、分享、迭代。5. 常见问题与排查技巧实录我踩过的坑你尽量别踩5.1 典型问题速查表实战中不可能一遍跑通这里是我反复踩过之后的最常见问题清单现象根因解决方案Skill从未被触发description写得太窄或太宽重写description加入典型用户用语示例Skill被错误触发description用词有歧义缩小触发条件增加否定条件如“不处理部署类问题”Agent不调用scripts缺少调用指令或脚本输出不规范在SKILL.md中明确“必须运行scripts/xxx.py”定义输出格式SKILL.md太长把所有细节都写进了正文把细节移到references/正文只写流程脚本报错被忽略错误信息不友好脚本输出带错误码和修改建议升级后行为异常旧版本缓存清理Agent缓存确认新SKILL.md已加载5.2 排查思路观察路径、确认加载、分析上下文如果遇到问题我会按三步来排查。第一步观察路径让Agent输出它的执行计划和每一步调用的文件通过它的话判断问题出在哪个环节。第二步确认加载手动查看Agent的调试日志或直接打开Skill目录看看SKILL.md是否被正确读取、YAML头是否解析成功。很多时候只是格式问题——比如description缩进不对Agent会直接忽略这个Skill。第三步分析上下文看Agent最终有没有从references里读取参考文件如果读了是只读了一部分还是全部读取这能反映你的SKILL.md对加载范围的描述是否清晰。这种排查方法效率很高的原因是它不从“模型不行”这个角度去找原因而是把Skill当成普通程序来调试。程序不工作当然是先看程序的哪一段出了问题而不是抱怨“运行环境”不好。有了这个思维你处理Skills问题的速度会快很多。5.3 关于开发、维护、组合Skill的效率心得维护Skill库同样需要设计。我认为业界在从“提示词工程”转向“技能工程”时需要养成三个习惯。第一每个Skill都要写README说明它解决什么问题、在什么Agent上测试过、有哪些已知限制。第二Skill要版本化管理。推荐把整目录放进Git这样每次改动都留痕出问题可以直接切回上一个版本。第三拆分配置。把常用的规则、偏好比如代码风格、文档格式抽成一个共享的references目录供多个Skill引用。这样当你修改一条规则时只需改一处而不是要把每个Skill都翻出来手动改一遍。我自己在维护Skill库的过程中越来越觉得它就是一支“私人增强团队”每个Skill都相当于一个标准作业程序确保同样的事情每次都被同样高质量地完成。这种稳定性和可复现性恰恰是大模型原生应用里最缺的也是Skills价值最大的地方。6. 不只是工具更是一种工程思维从Karpathy个人力推到各大模型平台纷纷跟进再到社区里涌现出的海量Skill下载命令整个趋势非常明确大模型的使用方式正在从“对话式即兴发挥”走向“工程化资产沉淀”。Karpathy在展示他的Skills流程时说的一句话让我印象很深“我不在乎模型有多聪明我在乎的是我的25个Skills每个都能百分百稳定地执行它们的任务。”这句话才是真正点醒我的地方——一个聪明但随机的AI助手远不如一个中等能力但稳定可靠的技能系统有价值。我自己现在的工作流已经完全建立在Skills体系上了。上周我做的三项工作一个用“前端开发”Skill快速搭建的新页面一个用“代码审查”Skill过了三遍把关的PR一篇用“博客写作”Skill生成初稿再改了一下午的文章。每一件事都是单靠大模型对话也能完成的但结果稳定性和时间成本完全不在一个量级。共性的差异是对话是忘的Skills是长的对话是零散的Skills是体系的。如果你已经在用Agent工具处理日常任务我很建议从明天开始尝试为一个高频重复的工作流写一个简单的Skill不用复杂能跑通就是胜利。