上周有个朋友问我说现在到处都在讲“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应用开发的语境里三个词经常被放在一起说MCPModel 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. 实操从零开发一个“论文写作辅助”Skill4.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 authors 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应用开发中都是通用的能力。用技能去制造技能这可能就是这个领域最有趣的地方了。