上周有个朋友问我，说现在到处都在讲“skills”，尤其是Claude Code、Codex这些工具出来以后，几乎每个AI讨论帖里都有人在晒自己的skills列表。他说自己跟着教程装了几个，但装上之后发现AI助手好像也没什么变化，怀疑自己是不是装了个寂寞。
其实这个感觉我特别理解。2025年的这波“skills”热潮，和AI圈以前那些花里胡哨的概念不太一样，它解决的是一个非常朴素的痛点：通用大模型什么都懂一点，但什么都不精。你想要它输出符合你们团队规范的代码、按照特定格式写文档、或者复现一套固定流程的操作，每次都靠临场写提示词去“说服”它，既累又不稳定。Skills本质上就是给智能体装上“可插拔的职业病”，让它一进入特定场景就自动切换成对应领域的专家模式。这篇文章我想从第一性原理出发，把这些散落的热搜词——Codex skills、Claude Agent skills、superpower skills、前沿开发者都在用的那些workflow——掰开揉碎讲清楚，告诉你这些技能到底是怎么工作的、为什么有效、以及如何从零构建自己的第一个skill。
这篇文章适合这些人看：正在折腾Claude Code或Codex、但对skills机制半懂不懂的开发者；团队里想统一AI编码规范但找不到抓手的技术负责人；以及那些“看过很多skill但依然用不好AI”的内容创作者和效率工具党。我会尽量用大白话，把底层原理、文件结构、开发流程、踩坑记录一次讲透。
1. Skills到底是什么？先把这个概念扒干净
1.1 从“大模型白纸”到“带新人入职手册”
先说一个最核心的认知：很多人以为给AI装skills就像给手机装App，装完就多了一个新功能，随时可以点开用。这个类比其实不那么准确。更贴近的比喻是：你给一个高智商但刚入职的新人发了一本部门《工作手册》。这本手册规定了他遇到什么情况该按什么流程处理、产出物长什么样、有哪些红线不能碰。他平时并不会一直捧着手册看，但一旦接到对应类型的任务，就会先翻开手册，按照手册的路子去干活。
底层机制大致是这样：当你给AI助手配置了一组skills之后，系统会在每次对话或任务开始时，根据用户的请求内容去匹配最合适的skill。一旦匹配命中，这个skill对应的“核心指令文件”（通常叫SKILL.md）就会被注入到AI的上下文窗口里，相当于临时给模型叠了一层角色和流程约束。然后模型就基于这份指令加上它本身的通用能力来执行任务。
所以关键点有两个：第一，skills不是常驻内存的功能模块，而是按需加载的指令包；第二，它的本质是“上下文工程”的标准化封装——把那些分散在长提示词里的最佳实践、流程规范、示例模板，打包成了可复用、可分享、可版本管理的文件。理解了这两点，后面所有的操作逻辑就都能串起来了。
1.2 Skills和MCP、Function Calling有什么仇什么怨
现在AI应用开发的语境里，三个词经常被放在一起说：MCP（Model Context Protocol）、Function Calling、Skills。很多人分不清它们之间的边界，我来做个简单粗暴的划分。
Function Calling是让模型输出一个结构化的调用请求，由外部程序去执行真实函数并返回结果。它适合“让AI使唤工具”，比如查天气、操作数据库、调用API。MCP则是把这个过程标准化了，让不同的AI应用能像USB设备一样即插即用各种外部工具服务。Skills和它们都不冲突，它约束的不是“AI能调用什么工具”，而是“AI应该按照什么规矩来思考和产出”。
打个比方：Function Calling和MCP解决的是“AI的手能伸多远”，Skills解决的是“AI的脑子在特定场景下该按什么套路转”。一个完整的高质量Agent系统，三者往往是配合使用的。Skills定义工作方法论，MCP提供工具执行力，Function Calling是底层的通讯协议。之前网上有个很火的观点说“Skills正在取代MCP”，我觉得这个说法太极端了。更准确的说法是，Skills承接了“工作流程自动化”那一层，而MCP承接了“工具连接”那一层，两者服务的目标根本不一样。
2. 为什么Skills成了2025年智能体开发的核心范式
2.1 三条路线对比：提示词、Agent框架、Skills
在Skills这个范式火起来之前，想让AI助手在特定场景下稳定输出，主流的路子大概有三条：一条是堆系统提示词，把团队规范、输出格式、案例全部塞进system prompt里。好处是直接，坏处是上下文长度有限、修改成本高、多个项目之间无法复用。第二条是用Agent编排框架（比如LangChain、AutoGen、自研的状态机），把流程写死在代码里。好处是可控制性强，坏处是开发量大、不灵活、每次改流程都要发版。第三条就是现在的Skills：把流程和规范写成一个可插拔的文件包，由模型动态加载。
我自己的体会是，Skills最大的优势在于解耦了“流程知识”和“系统实现”。你不需要为了一个“前端代码审查”的场景专门去写一套Agent逻辑，只需写一个描述清晰、步骤明确的skill文件（或者从社区下载一个），扔进目录就能生效。系统层面的加载、匹配、注入机制是通用的，你只要专注于领域知识的整理和沉淀。这其实很像Vim插件生态的成功逻辑：编辑器本身保持轻量，所有个性化的能力都通过插件体系去扩展。Skills就是AI交互层的“Vim插件系统”。
2.2 Skills解决了什么真实痛点：稳定性、复用性、团队一致性
先说稳定性。用过AI写过代码或者文档的人都知道，同一个模型，你今天问它“帮我review一下这段代码”，它给的反馈像资深架构师；明天同样的问题，它的回答可能就像刚学会变量命名的新手。为什么？因为通用模型的注意力分布是概率性的，输出质量波动大。而Skill通过注入固定步骤和检查清单，把输出的“下限”拉高了——哪怕模型状态不太好，它也至少会按手册走完流程。
再说复用性。我个人维护了一套“论文润色”的skill，从一个项目搬到另一个项目，只需要把skills目录拷过去，最多改一下期刊的格式要求细节。以前我得每次重新写一大段“你是一个学术编辑，请按照以下要求修改”的提示词，现在还容易漏条件。现在这些全部固化成了文件，配合版本管理，整个团队的人都能共享同一份“AI使用规范”。如果你的团队里有10个人都用Claude Code，不搞统一skills的话，那基本等于10个人各写各的提示词，产出风格五花八门，根本没法整合。Skills真正让“AI工程规范”这件事变成了一件可以被评审、被迭代、被Code Review的工程产物。
3. 解剖一个Skill：目录结构、SKILL.md和加载机制
3.1 一个典型Skill的文件系统长什么样
拿目前社区里比较主流的实现来说（Claude Code和Codex的skills实现大同小异），一个skill就是一个独立的文件夹，里面至少要有一个SKILL.md作为入口文件。这个文件的头部通常有一段YAML格式的frontmatter，用来声明元信息，尤其是name和description。它们的作用至关重要：description其实相当于这个skill的“简历关键词”，系统在匹配用户请求时，主要就是靠它来判断“要不要加载这个skill”。如果description写得含糊不清，那大概率你的skill永远不会被触发。下面是一个最小可用的结构示例：
my-skill/ ├── SKILL.md # skill的核心指令文件 ├── scripts/ # 可选的辅助脚本（Python/Shell等） ├── references/ # 可选的参考资料（API文档、规范PDF等） └── assets/ # 可选的模板、图片等静态资源SKILL.md内部怎么写没有强制标准，但从实践效果来看，一份好用的SKILL.md通常会包含这几块：角色定义（你在这个场景下是谁）、执行步骤（接到任务后先做什么后做什么）、产出格式（最终交付物的模板）、以及检查清单（交活儿之前逐项确认）。它本质上是一份可被模型阅读理解的结构化SOP（标准作业程序）。
3.2 加载机制与匹配逻辑：为什么你装了Skill却没反应
这里必须专门展开讲一下匹配逻辑。很多人在社区里喊“装了skill没反应”，绝大多数情况就是description没写好。在Claude Code的实现中，系统会在对话开始时根据当前用户的输入，计算与每个skill的description的语义相似度，选出最匹配的那个或那几个，把SKILL.md内容注入上下文。什么最容易导致匹配失败？常见有三类：一是description写得太泛（比如“帮助用户处理代码问题”——这种描述几乎和任何请求都有相关性，反而会被系统当成噪音过滤掉）；二是写得过于具体，术语太特定，实际触发时用户换了个说法就匹配不上；三是description里塞了大量无关关键词想提高“命中率”，结果反而稀释了语义重心。
我个人的经验是，好的description写法是“场景+任务+产出”三要素齐全，并且尽量用动作导向的句式。比如下面这两条，实际效果差别非常大：
- 差：
Help with code about frontend. - 好：
Use when reviewing frontend React code for performance issues, accessibility, and best practices. Output a bug list with file paths and line numbers.
第二条明显更容易被匹配，因为它描述了一个具体任务发生的上下文（review React代码），并明确了输出物（带文件路径和行号的bug列表）。社区里所谓的“superpower skills”之所以感觉好用，很大程度上就是它在description的措辞上反复打磨过，大大提高了命中率和唤醒精准度。
4. 实操：从零开发一个“论文写作辅助”Skill
4.1 慢一点：先定义清楚你想要的Skill边界
纸上谈兵再多，不如动手写一个。这节我拿一个最近在热搜里反复出现的场景来示范——“写论文的skills”。很多人想要AI帮忙写论文，但直接拿通用模型硬写，结果经常是“正确但空洞”，或者“细节丰富但结构混乱”。针对这个问题，与其天天调提示词，不如自己做一个学术写作辅助的skill。
开发的第一步不是写文件，而是想清楚边界。我问自己几个问题：这个skill服务于哪类写作场景？是毕业论文、会议论文还是期刊投稿？它应该帮用户完成什么？是从零起草，还是修改润色，还是检查结构？输出形式是什么？一份修改建议清单，还是一份可以直接提交的草稿？我的定位是做一个“论文结构诊断与学术表达润色”的skill，不负责提供实验数据，也不负责编造参考文献，只专注于结构逻辑、论证衔接和学术语言规范。边界清楚了，后面的SKILL.md才好写。
4.2 目录初始化与SKILL.md骨架
然后我建了一个文件夹叫academic-paper-polish，在里面创建了SKILL.md。骨架如下：
--- name: academic-paper-polish description: Use when user needs help reviewing, structuring, or polishing an academic paper, thesis section, or journal submission. Focuses on logical flow, transition sentences, academic phrasing, and structure diagnosis. Not for generating fake data. --- # Academic Paper Polish ## Role You are an experienced academic editor with deep expertise in scientific writing standards. ## Steps 1. Ask user whether the input is a draft, an outline, or a finished section before editing. 2. Read the text carefully and identify the logical structure. 3. Output a `Structure Diagnosis` table listing strengths and weak points. 4. Then generate a revised version of the text, preserving original meaning, improving academic tone and transitions. 5. End with an `Edit Log` itemizing the main changes you made and why. ## Output Format Requirements - Always use markdown headings. - Use tables for diagnosis. - Never invent citations or references. If the text lacks citations, state that explicitly. ## Checklist - [ ] Did I preserve the author's core argument? - [ ] Are all edits reversible/clear? - [ ] Did I flag unsupported statements instead of silently deleting them?这份文件看着简单，实际上每个字段都有用途。name是唯一标识；description直接决定触发率；“Role”给模型一个稳定的立场；“Steps”把处理流程拆成可执行的动作序列；“Output Format Requirements”锁死输出的结构化程度；“Checklist”让模型在交付前进行一轮自检。整个写下来大约几百行字，但它一个文件能顶好几千字的临时提示词。
4.3 测试与迭代：让Skill真正“通用”起来
写完第一版之后，千万别直接丢进skills目录就完事。你必须跑几个测试用例，而且要用不同的说法去触发。比如我测试时故意用了三种问法：“帮我把这段摘要改得学术一点”“这篇introduction的逻辑有点乱，你看看怎么调”“用学术风格润色以下段落”。如果三个场景都能稳定命中skill并且产出符合预期，那说明这个skill的description和指令设计都过关了。
测试过程中我发现一个很普遍的问题：如果文本长度特别长，Skill给出的诊断表格往往过于笼统，缺少对具体段落的引用。后来我在SKILL.md里补了一条规则：“在诊断表中，弱点的描述必须指向具体段落或句子，引用原文片段，禁止用‘整体逻辑不够清晰’这类套话。”加了这条之后，输出质量立刻上了一个台阶。这就是迭代的意义——Skills本身就是一个持续打磨的活物，不是写完就固定了。
5. 那些“有点东西”的Skill思路：前端、分镜、移动安全、自动化审查
5.1 前端开发Skills：把团队规范固化下来
在所有的skill场景里，前端开发应该是目前社区沉淀最丰富的方向之一。我也折腾了一套自己的前端review skill，核心思路是把团队的设计系统规范、组件库使用约定、性能预算阈值、可访问性检查项全部写进references文件夹，然后在SKILL.md里规定一个标准代码审查流程：先读接口和数据流，再检查组件拆分，再跑一遍性能风险评估，最后输出一个分级的问题列表（P0必须改、P1强烈建议、P2可选优化）。
这样做的好处非常实际。以前让AI review代码，它给的评论往往“正确但无用”，比如“建议提取公共组件”“注意内存泄漏风险”——这些话谁都会说，但缺少可执行性。而当我给skill注入了团队自己的组件库文档之后，AI的review建议就变成了“这个页面用了五处Button组件，建议替换为设计系统的DropdownSelect以保持交互一致性”——具体到可以直接指派给开发改。这才是企业里真正需要的AI代码审查。
5.2 分镜和内容创作Skills：让AI懂“镜头语言”
内容创作的skills我觉得还有巨大潜力没被挖掘。举个我试过的例子：给AI配一个“短视频分镜”skill，它的核心不是让AI写文案，而是让AI学会用专业的镜头语言去拆解和创作。SKILL.md里可以定义景别（远景、全景、中景、近景、特写）、运镜方式（推、拉、摇、移、跟）、转场逻辑（动作衔接、声音先入、空镜过渡），再规定最终输出为表格形式：场次、景别、画面内容、台词/字幕、音效/音乐、时长。
实际体验下来，加了这个skill之后，AI生成的分镜脚本明显从“文案+括弧（镜头拉近）”变成了真正可以拿着去开拍的分镜表。它对视频创作者或广告策划来说价值很大——不需要自己懂太多专业术语，AI已经被“训练”成了半个导演。反过来，如果你想教AI一种新技能，也完全可以按这个模式，把行业黑话、工作流、交付模板写进SKILL.md，它就能像模像样地干活了。
5.3 移动端安全分析与自动化检测思路
这类技能方向比较敏感，但合理使用价值极大。我建议感兴趣的开发者在合法授权的前提下，把Skills用在自己产品的安全性检查上。比如可以构建一个移动端安全基线检测skill：内置常见的敏感权限风险清单、加固绕过手段清单、通用工具链（如静态分析、运行时检测等工具）的调用说明，以及检测报告的模板。核心价值在于把专家的排查经验沉淀成一份可复用的SOP：每次跑产品前，AI都会按固定顺序先梳理应用权限申请是否有越界、再检查本地存储是否暴露敏感信息，最后输出一份标准化的风险评分表。
注意：这类skill绝对不能用来做未经授权的破坏性测试或攻击行为，只能在你自己拥有测试权限的App或已获得明确书面授权的系统中使用。Skill本身是一套方法论，它的作用是让防御方更快发现自己的薄弱点，任何走偏的方向都违背了这套工具的初衷。
5.4 自动化“挖洞”类Skills：为什么我不建议盲目去玩
热搜词里有“自动挖洞skills”，我必须多说一句。这类东西在社区流行得很快，看起来也很有诱惑力——好像装上之后AI就能自动发现系统漏洞。但真正深入看那些所谓的“自动挖洞skill”，你会发现大部分只是把一些安全测试工具的参数和常见漏洞特征写进了SKILL.md，让AI能够按图索骥去调用工具。它并不能凭空产生漏洞挖掘能力，更不能替代人的判断。如果你对Web安全没有基础，直接去跑这类skill，轻则测出一堆误报浪费时间，重则可能对不属于自己的系统做越权测试，踩到法律红线。
我的建议是，如果对安全方向感兴趣，不如自己做一套“漏洞报告整理skill”或者“渗透测试报告生成skill”，专注于把测出来的结果规范化，而不是试图让AI全自动地去做发现和利用。安全这行，责任边界比效率重要得多。
6. 避坑指南：我踩过的五个常见问题
6.1 SKILL.md写得太长，结果上下文被塞爆了
你以为Skills指令越详细，AI表现越好？其实不一定。我一开始做复杂的skill时，恨不得把整个行业知识库都塞进去，结果SKILL.md写完快上万字。用了几次后发现，模型并不能真正“吸收”那么多东西，反而因为指令过于庞杂，忽略了一些本来重点要约束的规则。
后来我养成了一个习惯：SKILL.md只写核心逻辑、步骤和检查点，尽量控制在100行以内。那些手册、长文资料、API细节全部放到references目录，SKILL.md里只写“如果遇到XXX情况，参考references/xxx.md中的第X节”。这其实是在模拟人的工作习惯——你入职手册不会把所有规章制度都印在上面，只告诉新人“有疑问去哪里查”。这样既控制了上下文长度，又保留了知识深度。
6.2 Description写得太完美，匹配反而更加随机
这个是我调试过程中最妖的一个问题。有一次我把某个skill的description写得非常有文学性，用了大量同义词去描述适用场景，结果发现触发变得很不稳定。后来想明白了：当description里的关键词密度太高、覆盖面太广时，模型反而难以判断它的核心适用边界，导致它有时候在很无关的请求上触发了，又在真正该触发的时候没触发。
解决思路很朴素：把description当成一段“任务描述”，用两三句话精准说清楚“什么时候该用、用了要干什么、产出是什么”。一句话能说清楚就绝不用两句话，把最重要的触发场景动词放在开头。这个原则我称之为“description减肥法”，亲测有效。
6.3 工具权限与脚本执行的坑
很多skill会带scripts目录，用来让AI执行一些辅助脚本（比如格式化代码、拉取API数据）。但实际操作中最容易出问题的就是执行环境。比如你的skill里让AI跑一个Python脚本，结果这台机器上根本没装依赖，AI就会卡在报错信息里，然后开始瞎编一个“如果你遇到这个错误，说明环境问题”的补救方案。这其实不是AI的问题，是skill设计时没考虑到执行前置条件。
后来的做法是：在SKILL.md里写清楚每个脚本的运行前置条件、依赖安装命令、以及预期的退出码。更稳妥的做法是让skill优先使用Agent自带的代码执行环境，而不是依赖宿主机环境。在团队里分发带scripts的skill时，最好在README里额外写一首安装脚本或依赖清单，避免同事拉下来之后一脸懵。
6.4 Skill之间的指令冲突
当你同时装了十几个skill之后，新的问题就来了：某两个skill的description有重叠，或者同一个场景下模型同时匹配到了两个skill，它们的步骤和输出格式完全不一样。我踩过的具体案例是“代码重构”和“代码风格检查”两个skill同时被命中，结果AI一边重构一边检查风格，产出格式完全混乱。
缓解手段有几层：第一，开发skill时就要注意技能边界的互斥性，在description里明确写“本skill不适合XXX情况”；第二，在SKILL.md的Role段落里加一句“如果检测到用户请求同时涉及其他专业方向，先主动向用户确认优先级”；第三，如果真的经常冲突，那就合并成一个skill，通过内部条件分支处理不同子场景，别让模型自己去做选择题。
6.5 别迷信社区里的现成Skills，很多只是“提示词换皮”
现在网上和官方市场里有大量Skills下载，但质量参差不齐，很多所谓的“超级技能包”其实就是把一段长的system prompt拆巴拆巴塞进了SKILL.md，根本没有结构化的流程设计和边界控制。用了这种skill，你觉得“好像有用”，但又说不出它比你自己写的提示词强在哪。判断一个skill值不值得用，我一般看三个标准：有没有清晰的步骤拆解？有没有可落地的输出格式？有没有明确的边界和触发条件？三条都占，是好skill；一条都不占，基本等于换皮prompt。
另外要小心一些来路不明的“skill安装包”，尤其是压成压缩包、让你直接覆盖到主目录的那种。Skill本质上是可执行的指令和脚本，被人恶意植入指令很容易翻车，建议尽量只从官方市场或高信任度社区下载，装之前把SKILL.md从头到尾读一遍。
6.6 开发Skills的正确上线姿势总结
最后想给一套自己常用的开发验收流程：新建目录和SKILL.md草稿，用三五条例句测试匹配是否命中；然后跑一轮真实任务，观察输出是否符合预期格式；接着故意制造一些边界情况（不明确的任务、混合任务、超长输入）来测你的skill会不会跑偏；再反向审查一遍文件，把套话删掉，把模糊的指令改成可验证的检查项；最后扔到真实项目里用一到两周，针对暴露出来的问题迭代。一轮走完，你的skill就是真正能打的skill了。
我还想补充一个经验：Skills练得多了之后，你会慢慢形成一种“元能力”——你再看到一个复杂的工作流程时，会下意识地去拆解它的步骤、产出物和触发条件，这在各种AI应用开发中都是通用的能力。用技能去制造技能，这可能就是这个领域最有趣的地方了。
