Andrej Karpathy 最近半年在公开场合反复提一个判断大模型本身的智能已经够用了Agent 真正缺的是可复用的 skills。我第一次听到这个说法是在一场关于编程助手的对谈里当时他拿会聊天的实习生和带过项目的老手做对比说差距不在知识量而在脑子里的那套操作流程。说实话当时我半信半疑。后来我在 Claude Code 和 Codex 上把社区里的 skills 装了一圈又自己动手写了几个才意识到这层东西对日常开发效率的提升是实打实的。这篇文章不打算复述 Karpathy 的每一句话只讲我实际使用和开发 skills 的经验它和 Prompt、MCP 之间的边界在哪里安装命令里的参数到底是什么意思一个标准 SKILL.md 文件应该怎么写以及我在这个过程中踩过的几个坑。适合刚听说 skills 这个词、想搞清楚它是什么的人也适合已经装了不少技能但觉得没发挥出效果的人。1. 从 Karpathy 的讨论说起模型会和会干活隔着一个 skills 层1.1 一句话说清 AI Skills 是什么Skills技能在 AI Agent 语境里是一套给模型看的结构化操作手册。它不是一个能独立运行的脚本也不是模型的权重更新而是一组文本文件——通常以 SKILL.md 为主体——安装到 Claude Code、Codex、OpenCode 这类编程代理的指定目录。当模型收到的任务和技能描述匹配时代理框架会把技能文件作为上下文注入给模型让模型按照手册里写的步骤、检查单、模板去执行。类比一下新员工入职第一天拿到一本《岗位工作手册》手册里写清楚遇到客户投诉先安抚情绪再记录问题超过三类问题升级处理。模型平时靠常识和训练数据干活但有了技能包之后它就多了一本针对具体场景的内部规范行为会稳定很多。代码类技能如此数学建模、专利写作、前端设计类技能也是同一个原理。1.2 Karpathy 为什么反复强调 skillsKarpathy 跟模型打了很多年交道他提到 agent 时经常强调的一点是模型不是不够聪明而是不够职业。聪明来自参数规模职业来自流程约束。一个做过大量代码审查的工程师拿到一个陌生仓库时会有自己固定的动作——先看 README再看目录结构找依赖配置扫 TODO 和 FIXME最后才动笔写结论。这些动作不是每次临时想出来的而是长期练出来的肌肉记忆。Skills 要解决的就是把这种肌肉记忆固化下来再交给模型复用。我自己的体验也印证了这点。在没有 skills 之前我每次让 agent 做代码评审都要在提示词里重复一遍流程要求稍微漏一句它就会默认走简要总结式的输出质量很不稳定。装上合适的技能包之后同样一句话它会自动进入先分析、再逐项检查、最后给报告的状态。这一步之差就是能聊天的模型和能交付的助手的差别。2. 拆开一个 Skill 的包装SKILL.md 里到底装了什么2.1 frontmatter 和正文一个最小可用的技能文件一个标准的 skill 通常是一个目录目录里至少有一个 SKILL.md也可以附带脚本、示例、参考文档。SKILL.md 最前面是 YAML 格式的 frontmatter里面最关键的两个字段是name和description。--- name: codebase-review description: 用于分析一个代码仓库的整体结构、依赖关系与潜在风险生成带完整证据链的代码审查报告。当用户要求分析项目审查代码梳理架构找技术债时使用。 --- # Codebase Review ## 前置条件 1. agent 已能读取目标仓库目录。 2. 确认仓库根路径。 ## 执行步骤 1. 列出根目录阅读 README 与项目说明。 2. 分析依赖清单package.json / pyproject.toml / go.mod 等。 3. 扫描 TODO / FIXME / 安全敏感调用。 4. 按模块输出问题清单每条必须给出文件路径和行号。 ## 输出模板 - 项目概览 - 依赖结构 - 风险清单 - 修改建议description写得好不好直接决定技能会不会被正确触发。触发机制是按描述匹配代理拿到用户请求后会先判断请求和哪个技能的 description 最相关再把对应技能内容注入模型。所以 description 里最好写明什么时候用、什么时候不用而不是写一堆形容词。2.2 Skills 与 Prompt、MCP、插件的边界这里直接给一张对比表把几个容易混淆的概念分开。维度PromptSkillMCP插件本质一段对话文本结构化手册附件外部工具接入协议带运行时的应用扩展生命周期用完即抛可版本化管理、复用常驻服务安装后常驻触发方式用户手动输入系统按描述自动加载Agent 动态调用用户或系统调用主要作用约束模型行为沉淀业务方法/流程让 Agent 读写外部系统扩展宿主应用能力依赖无纯文本几乎零依赖需要服务端实现需要宿主 API边界并不绝对一个 skill 里完全可以写如果遇到需要查询数据库调用名为 postgres 的 MCP 工具。Skills 管怎么想、按什么顺序做MCP 管能碰哪些外部资源。很多时候它们是在同一任务里配合使用的。这也是为什么不少团队把 skill 当成流程层把 MCP 当成连接层。3. 实际安装与调用我从命令行到日志的完整过程3.1 安装命令逐参数拆解社区里最常见的安装方式是使用 skills CLI。以我常用的 superpowers 技能库为例npx skills add superpowers --agent claude-code -g -y这条命令拆开看npx skills add调用 skills 命令行工具从技能仓库下载并安装superpowers技能仓库/技能包的名称可以换成任意 GitHub 上的仓库名--agent claude-code指定要安装到哪个 agent 的配置目录常见取值包括 claude-code、codex、opencode-g表示全局安装而不是只在当前项目安装-y跳过安装过程中的交互确认方便脚本化执行。如果你没走 registry而是从 GitHub 源码安装手动复制也很快git clone https://github.com/example/awesome-skills.git mkdir -p ~/.claude/skills/codebase-review cp -r awesome-skills/codebase-review/* ~/.claude/skills/codebase-review/换成 Codex 就把路径改成~/.codex/skills/。装完之后重启对应的 agent 客户端技能目录里多出来的文件夹就是安装成功的标志。3.2 验证技能是否真的被加载日志与目录双重确认安装不等于生效。我验证技能是否被加载的习惯是打开 agent 的详细日志模式然后故意发一条正好命中该技能 description 的请求。如果日志里出现loaded skill之类的字样说明触发链路完整如果没有任何反应先检查路径再检查 description 措辞。不同 agent 的加载策略有细微差别。Claude Code 对技能命中比较主动描述匹配即可Codex 更倾向在用户明确提到某个能力时才读取技能目录。所以同一个技能在不同 agent 下表现可能不一样这不算 bug是各家实现的取舍。3.3 我实测的四个高频场景从代码审计到专利交底第一个是代码审计。装了一个 code-review 类技能后让它帮我盘一下这个项目的技术债它输出的不是笼统的几条建议而是带文件路径、行号、优先级的分模块报告可以直接贴进工单。第二个是数学建模。数模类 skill 会把流程固定成问题重述—假设说明—模型建立—求解—灵敏度分析—优缺点—排版七步对打比赛的人很省心哪怕你不想全自动把它当检查单用也行。第三个是前端开发。设计类 skill 里通常会写清楚色彩变量、间距规范、组件命名让模型生成的页面不再是千篇一律的 Tailwind 默认样式。第四个是专利交底。专利类 skill 会把技术问题—技术方案—技术效果三段式写进步骤里生成初稿时不会漏掉审查员最看重的逻辑链。4. 从零写一个自己的 Skill把重复任务变成可复用技能包4.1 需求拆解挑那个让你重复到烦的任务写 skill 不需要从我应该做一个技能开始而是从我哪件事每周都在重复做开始。举一个我自己的例子每个月要给一个老项目做依赖安全检查。手工流程是更新依赖清单、比对已知漏洞库、评估影响范围、写修复优先级报告。流程固定、重复度高、输出格式统一天然适合技能化。拆需求时我建议做三件事把手工执行的步骤完整写下来包括踩过的坑标出哪些步骤是即使我也容易忘的检查点明确输入输出输入是仓库路径输出是报告模板。4.2 写 SKILL.md描述要精确步骤要给判断标准写 frontmatter 时name 用短横线命名description 里写清楚什么时候用、什么时候不要用。比如--- name: dep-security-scan description: 对项目依赖做安全扫描与风险评估。仅当用户要求检查依赖漏洞、做安全审计、评估依赖风险时使用不要用于分析业务代码逻辑。 ---正文部分步骤不是越多越好。我个人的经验是每一步都要给判断标准否则模型还是不知道怎么决策。比如如果漏洞版本为高危且出现在生产依赖则建议一周内升级如果只出现在开发依赖可安排下个迭代处理这种判断标准才是技能的灵魂。4.3 本地测试与迭代从三步开始一次只加一条约束写完第一版后用一条最典型的任务做测试观察它有没有命中技能、执行顺序是否符合预期。第一版只写三到五个大步骤跑通后再逐步加约束。一次加太多出问题时你根本不知道是哪条约束导致模型行为变形。测试时也可以直接对着技能目录提问这个目录里包含哪些步骤 如果模型对答如流说明技能内容已经被正确索引。迭代几轮之后把 skill 提交到 Git 仓库方便回滚和分享。5. Skills 落到项目里三个典型坑与我的应对5.1 技能装上了但 agent 不理中文描述与英文 frontmatter 的错位我遇到过最隐蔽的情况SKILL.md 的 frontmatter 里把 description 写成了纯英文而我日常用中文提问。触发匹配是文本相似度匹配中文请求和英文描述之间可能出现匹配不到导致技能等于没装。解决办法是 description 里同时写中文和英文关键词或者至少把常用触发词全部列出来。另一个常见原因是模型/agent 版本太旧对 SKILL.md 的 frontmatter 支持不完善。升级客户端之后问题一般会消失。5.2 技能装太多描述重叠导致加载错技能社区里现有的技能很多比如代码审查类就有十几个仓库在维护。装多了以后两个技能的 description 都命中请求agent 可能加载了错误的那个。我的经验是建立自己的技能清单每个季度清理一次。控制技能数量比收集技能数量重要得多。我见过有人一口气装了 50 多个技能结果 agent 每次都要在大量候选里挑响应变慢输出质量也下降。5.3 过度技能化当流程变成剧本模型就失去了判断力这是我觉得最值得警惕的坑。Skill 步骤写得越细模型自主判断的空间越小。有些技能把每一步的措辞都固定死结果模型输出的东西千篇一律碰上边界情况不知道怎么变通。社区里关于 rethinking skills and prompts 的讨论越来越多甚至有人开始研究下一代模型应该如何处理技能与提示的关系。我的看法是技能应该提供导航和检查单而不是剧本。留出判断空间让模型在必要时可以脱离步骤这才是技能和死板流程的区别。5.4 几条我长期在用的实战建议最后分享几条我自己的经验优先把有明确输出模板的任务技能化这类任务收益最直接skill 目录纳入 Git 管理便于回溯每个技能都配一个最小测试用例跑通后再扩展像漏洞检测、渗透测试这类高风险技能只在有书面授权的测试环境中使用并让技能文件里默认写入授权确认步骤。到现在为止我自己的技能目录里有七八个真正常用的技能数量不算多但个个都是从重复劳动里长出来的。回头再看 Karpathy 反复强调 skills 那番话我的体会是他说的不是某种花哨功能而是 Agent 想要进入真实工作流必须有一层介于模型能力和具体任务之间的沉淀物。如果你也想试别贪大把手里最烦的那件重复事做成第一个技能跑通一次你大概就能理解为什么这条赛道最近这么热了。