Karpathy最近反复在公开场合和社交媒体上强调一个判断提示词工程正在过时我们正处在一个技能skills的时代。翻看社区讨论时你会发现andrej-karpathy-skills已经不只是一个推特热度词而是成了一套正在被快速标准化的技术实践——从Claude Code的skills目录到Codex的skills包再到社区里铺天盖地的superpower skills、opencode skills、各种npx一键安装的技能仓库都在往这个方向靠。吴恩达也在跟进agent skills的相关教程海外圈子里甚至已经开始讨论GPT-6/Astra时代如何重新思考skills和prompts的关系。我一开始听到这套说法本能地觉得又是营销话术。但在自己的项目里把几个技能包接入Claude Code和Codex跑了一段时间之后确实感受到工作方式在变。这篇文章不打算重复Karpathy说过的话而是从一个实际使用者、开发者的角度把技能包到底是什么、为什么要这么做、怎么做、怎么调试整个链路拆开讲清楚。无论你是写代码的、写文案的还是做数据分析的看完应该都能直接上手。1. 为什么一个技能包能打败十条精心设计的提示词——Karpathy Skills理念拆解1.1 从临时指令到肌肉记忆先想一个问题同样一项任务比如给这个项目做一次代码审查用提示词让AI做和用一个训练好的技能包让AI做区别到底在哪用一条即时提示词相当于每次跟AI说你要当资深工程师按照这些维度去检查代码……提示词写的再详细本质上也只是一个瞬时指令。指令执行完就没了下次再来一个项目你还得重新描述一遍。而且每次措辞稍微不一样AI的输出风格和侧重点就会漂移。今天它按安全优先来审查明天可能就变成风格优先了。技能包做的恰恰是把怎么完成一类任务这套方法论固化下来。Karpathy提过一个形象的说法给LLM写技能包就像把知识从对话里搬出来放到一个模块化的文件系统里。LLM本身可以看成一个操作系统对话是短期记忆文件是磁盘存储而技能包更像是系统里的函数库或者算子库——平时不用占用资源任务来的时候按名调用。用生活化的例子解释提示词像是每次做菜前临时翻菜谱动作生疏、还容易漏步骤技能包则是老厨师的操作卡油温多少、下料顺序、出锅判断标准都写得清清楚楚。AI执行的时候不是大概知道方向而是每一步都有人把关。我自己实际测试过同样一个数据清洗任务。用提示词驱动模型第一遍会漏掉异常值处理而用技能包驱动SKILL.md里规定了读取数据—检查缺失值—检查分布—处理异常—输出报告的强制流程每一步都有检查点输出质量稳定得多。这就是技能包的第一个价值用流程换取稳定。1.2 确定性、规范性与可复用Karpathy把这种东西叫做superpower skills核心其实就是三个词确定性、规范性、可复用。确定性是指AI的输出不再是随机的自由发挥而是被技能包里的规范约束。很多技能包里不只是文字说明还有scripts目录放着可以执行的脚本。机械性工作统计行数、扫描文件、匹配正则直接交给脚本完成判断性工作哪里逻辑有问题、哪里风险高交给模型完成。脚本输出的是固定格式文本模型基于这些文本再推理出错概率大幅下降。规范性是指SKILL.md规定了输出长什么样。比如一个报告类技能包会规定必须包含摘要、详细发现、修缮建议、风险等级这几个区块。AI生成的报告大部分情况下都能符合框架要求不用你再花十分钟整理格式。可复用是指技能包跟项目无关。它装在一个目录里从一个项目复制到另一个项目从Claude Code切到Codex甚至从代码任务换成文案任务都能用同一套技能。这种搬运能力是普通提示词做不到的——你总不能在每次对话开头都贴2000字的few-shot example吧。这三点叠加起来才让技能包真正变成superpower。所以你在深入研究skills harness的时候会发现社区讨论的高频词汇已经变成workflowcheckpointartifact核心思路也都是围绕这三个特性做文章。2. 技能包、提示词、插件与MCP的边界选错工具等于白做2.1 四类工具的分工这两年AI圈子的概念爆炸prompt、skill、plugin、MCP、agent混淆得一塌糊涂。我经常看到有人费劲做了一个MCP server结果发现他要解决的根本是流程问题一个skill就能搞定。先上表格把四类东西分清楚。工具形态解决的核心问题类比典型例子Prompt一次性告诉模型现在要做什么当面吩咐一件事临时任务指令Skill把一类任务怎么做固化下来标准操作卡SKILL.md scripts/referencesMCP / Tool让模型能调用外部数据和操作外部系统给模型装上手和眼睛GitHub API、数据库查询Agent / Harness让模型能自动决策、编排多个步骤给模型配一个指挥官Claude Code、Codex、Agent SDK核心区别用一句话概括MCP解决的是模型够不到外部资源的问题skill解决的是模型不知道如何系统化地完成一项复杂任务的问题。Karpathy本人也被反复问到skills和MCP的关系。他的回应大概意思是说两者解决的是不同层次的问题完全可以配合使用。真实项目里的配合方式是技能包负责规划流程MCP负责执行具体动作。比如一个发布管理技能包SKILL.md规划了检查测试—构建产物—更新版本号—发布—通知的流程其中更新GitHub Release这一步可能要借助MCP去调用GitHub API。流程归流程工具归工具不要混为一谈。2.2 什么时候不该用技能包不是所有任务都适合技能包。我自己踩过几个坑总结出以下几类情况应该放弃技能包一次性任务。比如帮我把这段文字翻译成英文一条提示词就够了。做成技能包纯粹浪费上下文。强实时性任务。需要立刻读取最新数据、查询实时状态的应该直接用工具或者MCP而不是靠skill里贴死的参考文档。上下文极度敏感的任务。有些场景上下文窗口已经很紧再注入一个3000字的SKILL.md反而让模型抓不住重点。技能包本质上是用上下文长度换确定性不适合轻量级高频任务。判断标准就一条如果这个任务你一周只做一次用提示词如果一个团队/一个流程里反复出现且输出需要稳定格式才值得把它固化成技能包。从另一个角度说提示词时代的很多土办法也没有必要留在技能包时代了。比如在系统提示词里塞一堆few-shot示例、靠反复强调你必须扮演资深专家来引导输出——这些东西完全可以下沉到技能包的references目录里按需加载而不是每条对话都背着跑。3. 从零开发一个可用的技能包目录结构、SKILL.md规范与工程细节3.1 最小目录结构与frontmatter一个最朴素的技能包其实就是一个文件夹。以社区普遍认可的规范为例最小结构长这样code-review/ ├── SKILL.md # 技能包主文件核心中的核心 ├── scripts/ # 可执行脚本可选 │ ├── collect_context.sh │ └── complexity_check.py └── references/ # 参考资料按需加载可选 ├── security_checklist.md └── best_practices.mdSKILL.md是技能包的大脑。它的头部是YAML格式的frontmatter用来给agent建立索引。常见字段如下--- name: code-review description: 对目标代码库执行系统性审查识别逻辑缺陷、安全隐患、性能瓶颈和可维护性问题。当用户要求检查代码审查PRreview code时使用。不适用于代码生成或调试。 version: 1.0.0 tags: [code, quality, security] metadata: author: your-name license: MIT require_scripts: true ---frontmatter里面最重要也最容易被忽视的就是description。后面讲触发机制时你会看到agent不是每次都会把所有技能包全文加载进来而是先扫描每个技能包的description判断任务匹配度。description写得模糊技能包就永远不会被唤醒。3.2 一个代码审查技能包的完整示例下面是我在实际项目里用过的code-review技能包主体内容你可以直接抄。--- name: code-review description: 对指定代码目录或Git提交执行系统性审查并生成结构化报告。用户提到检查代码审查PRreview这个项目分析代码质量时使用。简单代码提问不要用此技能。 version: 1.0.0 tags: [code, review, security] metadata: require_scripts: true --- # 代码审查技能 ## 任务概述 对目标代码执行多维度审查输出结构化审查报告。审查范围包括 1. 逻辑正确性边界条件、错误处理 2. 安全性注入、越权、敏感信息泄露 3. 性能算法复杂度、N1查询、资源释放 4. 可维护性命名、复杂度、重复代码 ## 执行流程 1. 使用 scripts/collect_context.sh 收集项目结构与文件清单 2. 对目标目录运行 scripts/complexity_check.py获取圈复杂度报告 3. 按逻辑 → 安全 → 性能 → 可维护性顺序逐项审查优先处理高风险项 4. 生成最终报告报告必须包含摘要、问题清单按严重程度排序、修改建议、复测指令 ## 输出格式 输出Markdown格式报告问题项使用如下结构 ### [S1] 漏洞描述 - 路径src/auth/login.py:42 - 风险等级高 - 问题说明xxx - 修复建议xxx ## 注意事项 - 不修改任何代码文件 - 如果目录超过200个文件先用collect_context.sh生成清单再定位重点目录 - 所有结论必须引用具体代码位置禁止泛泛而谈技能包的正文部分就是把Karpathy那套给模型立规矩的哲学落实下来规定流程、规定输出格式、规定边界条件。你会发现AI在这里不是被要求发挥创意而是被要求照章办事——这正是技能包逻辑和提示词逻辑最大的不同。3.3 内容创作类技能包怎么设计技术圈聊skills动不动就是代码生成、代码审查好像技能包只能用在程序员身上。其实内容创作才是最需要技能包的场景之一。我在做公众号和博客的过程中就把公众号文章写作做成了一个技能包效果相当好。它的目录结构大概是这样的wechat-article/ ├── SKILL.md ├── standards/ │ ├── style_guide.md # 文风规范短句、口语化、禁用AI味套话 │ ├── heading_rules.md # 标题层级规范 │ └── forbidden_words.md # 禁用词汇清单 ├── scripts/ │ ├── word_count.py │ └── title_generator.py └── templates/ ├── outline_template.md └── article_template.md这个技能包的SKILL.md核心不是让它写一篇好文章而是让它按照工序拆解任务选题分析制大纲、大纲逐节扩写、初稿生成后做自检字数、段落长度、禁用词、可读性、最后给三个备选标题。整个过程中标准文件里存的是授权过的写作规范脚本处理字数统计这种机械动作。实际体验下来最大的感受是以前让AI直接写稿需要我在提示词里反复强调不要用随着…的发展不要AI腔段落别太长每次都是同一套话。技能包把所有这些规范一次性固化调用的人只需要说一句用文章写作技能给这个话题写一篇2000字的稿子产出质量自动就稳定在一个水平线上。4. 技能包到底怎么跑起来的加载时机、上下文拼接与变量插值机制4.1 Agent如何发现和加载技能包很多人第一次用技能包会以为它跟插件一样始终常驻其实不是。主流agentClaude Code、Codex、Cursor等对技能包的加载都有两段式策略启动时扫描目录读取所有技能包的frontmatter主要是name和description建立索引。对话中根据用户请求匹配description中的触发条件把命中的技能包全文注入上下文。这个机制非常关键。一方面它保证了上下文窗口不被几十个技能包轰掉另一方面也意味着description写得不好技能包就永远只是躺在硬盘上的文件夹。为了验证这个机制我在Claude Code里同时装了十几个技能包然后仔细看会话的日志。你会发现不相关的技能包连个影子都没有而当我提到检查一下这个项目的代码质量时系统自动就把code-review的SKILL.md插进来了。整个过程不用手动指定。4.2 上下文消耗与变量插值技能包注入是要消耗上下文的。所以社区对SKILL.md篇幅共识是主体控制在1000到3000字之间把详细资料丢到references里按需加载。一个5000字的SKILL.md每次调用都相当于让模型背着巨大的负担去执行任务效果反而会变差。变量插值是另一个实用机制。SKILL.md和scripts里的路径、参数可以通过模板语法来抽象比如## 执行流程 1. 使用 scripts/collect_context.sh --path {{target_path}} 收集上下文 2. 使用 scripts/complexity_check.py {{target_path}} 检查复杂度调用的时候agent会自动把{{target_path}}替换成用户指定的实际目录。同一个技能包今天可以审查/home/user/projectA明天可以审查/home/user/projectB完全通用。这就是Karpathy强调的技能包跟项目无关的工程基础。至于技能包执行链基本上是一个循环读SKILL.md确定步骤、运行脚本拿到中间结果、基于中间结果继续推理、下一步是否需要再跑一个脚本。整个链路里脚本提供事实数据模型负责判断决策各干各的活互不越界。这套skills harness的思路其实已经超出了传统prompt工程范畴更像是在给模型搭一套确定性的执行框架。社区里讨论GPT-6/Astra时代的skills设计时也基本沿着这个方向在走更大的模型虽然能力更强但依然需要一个外部框架来约束、校验和稳定输出。5. 技能包管理与生态接入从npx skills到社区热门仓库5.1 安装与导入现在往自己的agent里装技能包已经很简单了。社区里最常用的方式是用skills CLI一条npx命令搞定。我挑一个有代表性的命令拆解一下npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这条命令做的事情是从GitHub拉取sandai-org/vidmuse-skills这个仓库里的技能包安装到Claude Code的配置目录-g表示全局安装对所有项目生效-y跳过交互式确认。如果想安装到当前项目目录去掉-g即可。除了npx skills手动克隆也可以mkdir -p ~/.claude/skills git clone https://github.com/xxx/skills.git ~/.claude/skills/Claude Code识别~/.claude/skills和项目根目录下的.claude/skills两个位置。Codex的位置类似一般在~/.codex/skills。我在实际配置中还发现不同的agent对技能包的支持程度不一样。Claude Code 2.x版本已经原生支持skills目录Codex的skills机制也逐步完善一些IDE插件则是通过读取相同目录结构来识别的。所以你在网上看到一个技能包发布第一件事是确认它是给哪个agent用的再决定安装方式。5.2 配置与验证技能包装完不生效是新手最常见的问题。我的排查顺序基本固定目录位置确认技能包装到了agent实际扫描的路径下。Claude Code扫描~/.claude/skills和.claude/skillsCodex扫描~/.codex/skills装错地方等于没装。frontmatter完整性SKILL.md必须带YAML frontmatter且name和description不能为空。个别实现连frontmatter的缩进都敏感。同名冲突如果装了两个同名技能包agent可能加载到错误的那个。装之前检查已有技能包的name字段。脚本权限scripts目录里的shell脚本必须有可执行权限否则agent调用时会直接报错。记得chmod x scripts/*.sh。agent版本太老版本的agent可能不支持某些新技能包字段升级到最新版一般能解决。验证是否加载成功除了交叉检查日志还可以做一个最简单的动作在对话里明确说使用xxx技能执行xxx看输出是否包含该技能包定义的结构化内容。如果技能包被触发了输出格式会跟普通对话明显不同。5.3 社区生态里值得关注的技能包过去一年GitHub上冒出一批高质量技能包仓库。除了Karpathy本人开源的那套仓库还有几个我实测比较好用的superpower skills社区热度最高的技能包合集覆盖编程、写作、思考框架、项目管理等多种能力。作者将其定义为workspace-level技能包安装后能明显改变agent日常对话的执行方式。安装这个本身就是很好的学习入口——去读它的SKILL.md你能看到一群顶尖的prompt工程师是怎么设计技能结构的。codex skills专门为Codex环境设计的技能包集合里面多数是编码辅助类技能。opencode skills跟着opencode项目走的技能包比较适合开源项目协作场景。vidmuse-skills视频/多媒体创作方向npx安装那个例子就是这个仓库。我不建议一上来就装一整套技能包。装太多description之间互相干扰agent反而更容易犯糊涂。先挑三五个跟日常工作最相关的技能包用熟了再扩展。说到开发自己的skills这个过程其实不神秘。任何一个技能包都是从今天这个任务我重复做第三遍了这个念头开始的。我在实际开发中形成了这样一套流程先手动跑一遍完整任务记录每一步的动作、输入、输出。拆出哪些步骤是机械性的写脚本哪些步骤是靠判断力的留给模型。写成SKILL.md重点是流程步骤和输出格式。在agent里测试一两轮根据失败的地方调整描述和步骤。沉淀references把整理过的规范、样例放进去。这套流程帮我把经验真正变成资产。团队里反复有人问这个怎么写那个怎么改的问题与其一遍遍回答不如直接把方法整理成技能包谁需要就调用。6. 快跑通、慢迭代我开发和使用技能包的几点体会最后说几个实际操作层面的体会算不上什么大道理但都是真金白银换来的经验。第一技能包的灵魂是SKILL.md里的流程说明脚本只是脚手架。我见过很多人做技能包花大量时间写复杂的脚本SKILL.md却寥寥数语。跑起来的结果往往是脚本输出了一堆数据模型不知道怎么用。顺序应该是先设计流程再决定哪一步需要脚本辅助。第二一个技能包只解决一类问题。技能包最忌讳做成瑞士军刀。你把用例边界画得越清楚description写得越具体agent正确触发它的概率就越高。比如code-review就是代码审查wechat-article就是公众号写作project-analysis就是项目结构分析。一旦一个技能包的description覆盖了三种毫不相关的任务它基本就不会被正确触发了。第三description要往当用户提到什么时使用的方向写。这是我在反复调试中发现的规律。同样的技能包description从执行代码审查改成当用户要求检查代码、审查PR、review代码质量时使用触发率提升了将近一倍。原因很简单agent匹配的是你这句话里有没有和用户意图重合的语义。第四先写最简版跑通再往里面堆references。我第一次做公众号文章技能包就试图把过去一年的写作经验全部塞进去结果SKILL.md臃肿到7000字模型调用时反而无所适从。后来我把正文压到2000字左右把详细规范拆到references按需加载效果立刻好了。第五调试技能包的关键是看日志。Claude Code和Codex的调试模式下你能看到agent每一步加载了哪些文件、执行了什么命令。90%的技能包不生效问题追一遍日志就能定位。就算你不会看完整日志至少留意它有没有执行scripts目录里的脚本——如果脚本没跑说明它压根没有完整加载你的技能包。最后一个我特别想分享的小技巧把团队里反复出现的人工过程固化成技能包比写十份文档有用。我把自己日常做项目分析、写周报、审查代码的那套流程逐步沉淀成了十几个技能包。现在每次接到新需求不是从空白对话开始反复调教模型而是喊一个技能包的名字让模型按照成熟流程办事。这种感觉就像把老员工的肌肉记忆复制到了每个新项目里——虽然还做不到完全替代人的判断但至少那些重复性的、机械性的工作已经基本从我手里交付出去了。如果你也正在重新思考skills和prompts的关系我的建议很简单不要停留在概念层面挑一个你手头最烦人的重复性任务花一个晚上把它做成第一个技能包。跑通了你对整个事情的感知会完全不一样。