我发现一个很有意思的现象最近AI圈的热词正在从提示词快速切换到skills。我最初看到这个单词的时候第一时间想到的是GitHub上那种教人用Git的交互式课程后来翻了一圈社区里的讨论才发现完全不是一回事——现在的skills指的是给AI智能体Agent安装的外部技能包是一整套能直接被AI调用的能力模块。一句话概括Skills就是把你的最佳工作流打包成一份AI能看懂的岗位说明书外加配套工具集。装上它之后你不再需要每次对话都从零教AI该怎么做事。这个方向现在非常火从Claude Agent Skills到Codex的skills再到社区里各种定制化技能包几乎每个用AI做深度工作的人都在讨论。这篇文章我会从原理、开发现状、实操流程和避坑经验几个维度把它说透适合正在用AI写代码、写论文、做自动化处理的读者也适合想把团队经验沉淀成可复用资产的开发者。1. 先说清楚Skills到底是什么1.1 从一个实际使用场景看区别先讲一个我自己的真实体感。以前我用AI写一篇需要规范参考文献格式的论文初稿提示词要写一大段你是一个学术写作助手请按照GB/T 7714格式整理引用注意检查术语一致性输出前要自查逻辑链……这些话我几乎每隔几天就要重新打一遍而且换个话题聊天之后AI就把这些约定全忘光了。装上一个论文润色Skill之后情况完全变了。我只需要把素材丢给AI说一句用论文润色技能处理一下它就自动进入固定流程拆分任务、梳理结构、逐段润色、核对引用格式、统一术语最后按预置模板输出。整个过程不再依赖我每次重复描述需求。这个变化的本质在于模型自身的参数是固定的它不会凭空知道你的团队规范、你的论文格式要求、你的代码审查清单。Skills把这些外部知识固化成一个自包含的模块——里面有指令文件、参考资料、还可能有一些辅助脚本。模型在需要时会主动加载这个模块按照里面的SOP去执行。打个比方。提示词相当于你每回给临时工发一条短信交代今天干什么插件相当于给AI外接了一套手脚能调用API、操作外部系统而Skills更像是你递给AI一份完整的工作手册里面写清了岗位职责、操作流程、注意事项甚至还有配套工具。它不依赖额外的服务端API核心是知识流程的封装。1.2 Skills和提示词、插件、工作流的边界很多人容易把这几样东西混为一谈我梳理了一个简单的对照表维度提示词Prompt插件/工具Plugin/ToolSkills技能包持久性会话级聊完就丢系统级常驻可用项目级或用户级按需加载依赖无需要API、鉴权、服务端通常为本地文件和脚本修改成本低随时改高涉及代码发布中改Markdown和脚本即可典型用途单次任务引导接外部数据、执行操作固化专业流程、领域知识运行机制模型直接理解模型调用外部函数模型读取指令并照章执行从这张表能看出来Skills在架构位置上介于提示词和插件之间它没有插件那种强大的外部系统操作能力但比提示词更稳定、更结构化、更可复用。一个Skill包往往包含一个主指令文件比如SKILL.md后面可以挂参考资料目录和脚本目录。模型在执行任务时先理解主指令需要时再去读参考资料、运行脚本。这个设计解决了一个核心痛点模型上下文窗口是有限的。你不可能把公司全部开发规范、论文格式标准、安全检测清单一次性塞进每次对话里。技能包相当于把那些低频但必须的知识放到了外置硬盘模型用到时再读取不会挤占宝贵的上下文空间。2. 为什么Skills会突然流行起来2.1 Agent开发从调提示词走向配技能我观察到一个趋势AI应用开发的重心正在从写提示词转向配置技能。背后有个很实际的原因——单个模型的能力边界已经趋同了大家用的都是差不多的基座模型真正拉开差距的是你让模型按照什么流程干活、参考什么知识库、调用什么工具。这就像招聘新员工入职时大脑都差不多差别在于你给他什么岗位培训、什么操作手册、什么工具权限。Skills就是这个入职培训包。团队里一位资深工程师的代码审查经验可以通过一个Skill被复制到每个AI辅助的代码审查场景里一个资深编辑的排版规范可以变成一个内容Skill供全组复用。从技术层面拆解这背后还有一层系统1/系统2的隐喻。模型的即时反应是大模型天生的系统1快但容易漂移而技能包里的SOP、检查清单、输出模板是外置的系统2慢但稳定。两者的结合让AI既保留灵活性又有严格的流程约束。这种模式对个人开发者尤其友好。你不必去训练微调模型也不用搭复杂的Agent框架只需要写清楚一份Markdown格式的指令文件、整理好参考资料就能拥有一个专属AI技能。社区里大量skills开发skills大全的讨论热度本质上就是因为这个创作门槛极低。2.2 主流平台到底是怎么做的现在市面上能看到的Skills形态大致分三类我分开说。第一类是Claude的Agent Skills。Anthropic在2024年底推出的这套方案核心思路就是项目即技能——在项目目录下按约定放置技能文件夹每个技能文件夹里包含一个SKILL.md主文件。SKILL.md使用Markdown格式前面有一段YAML frontmatter记录技能名称和描述正文部分就是完整的执行指令。官方推荐把skills目录放在工作区的.claude/skills或者项目根目录下模型会在对话中根据当前任务语义自动判断是否需要加载某个技能。第二类是Codex这类编码智能体的skills。OpenAI的Codex在生态里也有相关的技能概念社区里涌现了大量针对前端开发、代码审查、自动化测试的skills封装。这些技能包的特点是更贴近命令行工作流经常结合AGENTS.md这类项目级说明文件一起使用。示例和规范建议直接参考OpenAI官方文档因为社区格式演进很快网上很多二手教程容易过时。第三类是GitHub Skills。注意这个最容易被名字唬住——它其实是GitHub官方的交互式学习课程教人类开发者学习Git、Actions、Copilot之类的功能跟AI技能包完全不是一个东西。很多人搜skills搜到这里就一头雾水我在这里明确帮大家排个雷。平台技能形态适合人群加载方式Claude Agent SkillsSKILL.md 资源 脚本内容创作、文档、通用Agent工作区内自动语义匹配Codex skills项目级说明 技能目录编码、自动化任务命令行/项目启动时注入GitHub Skills交互式课程人类学习者手动学习与AI无关2.3 当前比较热门的Skills方向社区里涌现的Skills基本集中在几个方向。开发类占了大头前端开发skills生成符合项目规范的组件、自动补样式、代码审查skills按团队的检查清单逐项核对、自动化测试skills根据功能描述生成用例矩阵。内容创作类紧随其后论文写作skills管理引用格式、规范学术表达、分镜脚本skills把小说片段拆成分镜表、长文档结构skills自动生成目录和衔接逻辑。安全研究领域也有一批实用技能。比如合规授权下的App安全评估skills、漏洞挖掘辅助skills这类技能会把常见检测项固化成流程清单减少漏测。要额外说一句安全类技能必须严格遵守授权边界只用于自己拥有或已获得明确授权的系统与程序这是底线问题。一个很明显的规律是业务越专业、流程越固定、知识越密集Skills的价值就越大。反过来那些一句话就能说清楚的通用任务比如帮我写一封邮件根本没必要做Skill。3. 自己动手写一个Skills3.1 最小可用结构长什么样网上有人在问skills应该怎么开发其实从零上手并不难。一个最小可用的技能包目录结构大致是这样skills/ └── paper-polish/ ├── SKILL.md ├── resources/ │ └── citation-styles.md └── scripts/ └── check_reference_format.py核心文件就是SKILL.md这个文件决定了AI能不能正确识别和调用你的技能。我强烈建议使用带frontmatter的写法开头一段YAML元数据后面是正文指令。命名上注意技能名用小写连字符描述写清楚什么时候该用这两个字段直接影响模型的选择路径。这里解释一下为什么description那么重要。智能体在选择技能时通常靠当前用户请求的语义和技能描述做匹配。如果你的描述写得模棱两可比如用于处理文档那模型几乎什么场景都会往这个技能上靠反而干扰判断。反过来如果你写当用户上传学术论文并要求润色、调整结构或规范参考文献时使用触发率就会高很多。描述字段就是你给技能写的广告词要足够具体、能体现明确的触发条件。3.2 一个论文润色Skill的完整示例拿我自己维护的论文润色技能举例。SKILL.md的内容大致长这样--- name: paper-polish description: 当用户需要对学术论文、技术报告、学位论文进行语言润色、结构优化、参考文献格式规范时使用。支持中英文。 --- # 论文润色技能 你是资深学术编辑你的任务是帮助用户把论文改到可投稿或可提交的水平。 ## 处理流程 请严格按以下四步执行 1. **结构诊断**先通读全文输出当前论文的结构清单标记逻辑断裂、章节失衡、论点重复的位置。 2. **逐段润色**按章节逐段修改。保持原意优化语法、用词、句式消除口语化表达。除非用户明确要求否则不改变专业术语。 3. **参考文献检查**根据 resources/citation-styles.md 中的规则核对引用格式标出缺失项和格式错误。 4. **输出结果**先输出修改说明列表再输出完整的润色后全文。 ## 输出格式 每次输出必须包含两个部分 - 修改摘要用无序列表列出10条以内最关键的修改及原因 - 润色全文从标题开始完整输出保持原有章节编号 ## 注意事项 - 不要引入原文不存在的观点和数据 - 数学公式、代码、表格内容原样保留 - 如果原文有逻辑漏洞在修改说明中直接指出不得擅自补写论点这个技能里我刻意设计了几个细节。第一处理流程用编号写出模型执行时就不会乱序。第二输出格式强制分成修改摘要润色全文两部分方便快速核对。第三注意事项里加了一条引用resources文件的指令这样长的格式规范不会占用主指令的篇幅模型需要核对具体引用规则时才读取那个文件——这就用上了前面说的外置知识思路。s.check_reference_format.py这个脚本我实际用下来不多但放在那有个好处以后可以扩展成批量检查引用格式的自动化脚本让技能不再局限于纯文本处理。一个Skill完全可以混合纯指令工作流和代码辅助执行两种模式。3.3 调试与迭代技巧写完一个Skill并不算完真正的功夫在调试上。我调试一个新技能的基本套路是这样的先用一段短文本测试触发——观察模型有没有在对话中主动加载这个技能。如果用户说了润色但它没走技能流程多半是description里的触发词没覆盖到。这时候我会把实际用户话术里的关键词提取出来塞进description里。比如发现用户经常说帮我改改这段话、润一下色我就把这些口头表达也补充进触发说明。接下来测输出稳定性。我会准备5-10个同一类任务的样本连续跑两遍对比输出结果。重点看两个指标一是输出格式是否保持一致二是流程步骤有没有踩漏。如果模型经常跳步我会在指令里加强约束比如只有完成了第一步才能进入第二步这种硬性顺序描述实测比请按顺序执行有效得多。最后一步是控制Token开销。很多新手容易把指令文件写得巨长恨不得把所有情况都写进去。我的经验是主指令控制在500行以内那些查表类、规范类的长内容放进resources目录让模型按需读取。这样既保证技能逻辑完整又不会把上下文占满。我一直强调一个优秀的Skill应该是结构化程度高、外部知识可扩展、输出格式硬约束三者的平衡。结构化高是为了稳定外部可扩展是为了强大输出格式约束是为了方便下游处理。4. 怎么把Skills用起来4.1 去哪里找到现成的Skills社区里搜skills大全skills下载平台的人很多这里我把靠谱的途径盘点一下。最直接的渠道是官方市场。Claude的Agent Skills有官方市场入口里面有团队维护的精选技能质量有保障安装最省心。不过要注意不同平台的技能市场入口和安装方式不一样建议以官方文档为准少信那些转发帖里的过期教程。第二大渠道是GitHub。直接在GitHub上搜skills、agent-skills、awesome-skills这类关键词能找到大量社区合集仓库。但GitHub仓库质量参差不齐我判断一个技能包是否值得下载主要看几个维度项目最近有没有维护记录看commit时间、README里有没有使用示例、SKILL.md内容是否结构清晰、有没有配套的测试样例。我踩过很多次坑下载过那种只有空壳目录、连SKILL.md都是复制粘贴的技能包浪费时间。还有一个容易忽略的渠道是团队内部沉淀。如果你所在组织用了AI编程助手或企业版Agent完全可以把自己验证过的技能包提交到团队共享目录。对个人来说这比下载任何公开技能都更能解决实际问题因为它是为你自己的场景量身定制的。不管从哪个渠道获取我建议安装前先做两步检查打开SKILL.md看一眼指令质量以及确认技能的脚本目录里没有明显可疑的代码。安全习惯要养成尤其是要执行本地脚本的技能包。4.2 安装与引入的多种姿势安装Skills其实不复杂但不同平台的姿势差异很大这里说一条通用的保守路径。第一步确认技能目录格式。下载或写好的技能包先确认它是不是一个包含SKILL.md或对应格式主文件的文件夹。很多从GitHub下载的压缩包解压后会多一层嵌套目录必须把内层技能目录单独提出来。第二步放到正确的读取位置。以Claude Agent Skills为例官方支持把技能目录放在工作区的skills/或.claude/skills/下具体以你所用客户端的文档说明为准。放错目录最典型的表现是你明明把技能放进了项目但对话里模型完全不感知它的存在。第三步用一条测试指令验证是否加载。比如装完论文润色技能直接说请用paper-polish技能处理下面这段话。如果模型回复中体现了技能里的流程说明安装成功否则回第一步排查。有个小技巧技能包的版本管理走Git最省心。我自己会给每个技能单独建仓库主分支保持稳定版本改动能通过commit记录追溯。试过才知道技能迭代多了之后没有版本管理会很痛苦——你根本记不清上次把输出格式改成什么样了。4.3 效果评估与调优的参数化方法技能装好以后怎么知道它好不好用我建议不要靠感觉而是量化评估。我平时的做法是准备一个任务样本集每次迭代后用同一批样本重测记录几个关键指标评估维度说明测试方法触发成功率模型是否在正确场景自动加载技能用10条真实用户话术测试统计调起比例步骤完整度固定流程的每一步是否都执行检查输出是否包含所有必备章节格式正确率输出是否符合预置模板用脚本或人工校验关键格式字段单次Token消耗每个任务平均消耗多少上下文在会话详情里查看Token用量处理耗时从提问到产出完整结果的时长秒表计时或看接口耗时日志调优的优先级也有讲究。先保触发再保质量最后优化成本。触发都失败后面无从谈起质量稳定了再考虑怎么缩短指令、精简参考资料来降低Token消耗。这个顺序我建议刚接触Skills的人严格遵守因为你会逐渐发现很多质量问题的根源其实是触发阶段就没走对流程。5. 常见问题和避坑指南5.1 技能没被触发的三类原因这是遇到最多的问题而且新手的排查方向经常搞反。技能没被触发十有八九是description的问题而不是模型不听话。第一类原因是description写得太宽泛。我之前把一个技能描述写成用于处理文档后果是用户发什么内容模型都想往这里靠反而扰乱了正常对话。正确的做法是精简描述让每个技能只覆盖一类高度相似的任务。第二类原因是触发词覆盖不全。用户实际话术和你的描述用语差太远模型压根没往那个方向联想。这时候要把用户习惯的口语表达补充进description比如帮我改一下润色整理一下都是触发场景的常见说法。第三类原因是技能目录下有多个技能互相干扰。如果某个任务对应好几个技能描述都沾边模型可能会随机选择表现就是时灵时不灵。排查的时候建议新开一个会话单独放那个技能用最直白的话术测试。排除掉其他技能的干扰再看是不是依然不触发。我拿这个方法帮朋友定位过很多次问题几乎都能马上找到原因。5.2 输出质量不稳定的深层解法很多人在技能开发里遇到的另一个瓶颈是技能偶尔能跑出完美结果但大多数时候输出质量飘忽不定。这个问题的根源不是模型状态差而是给模型留的选择空间太大了。我做过一个对比实验同一个技能指令里写请高质量地完成润色和请严格按以下四步输出修改摘要10条、润色全文、保留原有章节编号后者的输出稳定性明显高出不少。模型在模糊指令下会调用它自己的默认偏好而这个默认偏好很难每次都符合你的预期。要解决质量漂移最有效的两招一是用硬性输出格式约束最终结果比如规定输出必须包含哪几个部分每个部分的顺序、标题都不能变二是给一个高质量示例。把一份你手工修改过的范本放进resources目录让模型执行前先参考这个one-shot样例比你在指令里反复强调注意术语注意逻辑强得多。我自己在多个技能里都试过加了示例之后输出质量的方差明显收窄了。5.3 安全与合规是不可逾越的底线最后这部分必须认真提醒尤其是使用安全研究类技能比如热词里提到的安卓应用检测skills、自动化安全评估skills的时候。安全类技能本身是白帽工作流的高效载体但任何技能的使用场景都必须在授权范围内。只对自己的应用程序做安全评估、只检测自己拥有或已获书面授权的目标这是行业铁律。把这类技能用在未经授权的系统上不管动机如何都越过了合规红线这一点没有任何讨论空间。另外要留意通用安全问题。技能包里的脚本是会在本地执行的所以你从网上下载任何含scripts/目录的技能前都要先检查代码内容别指望AI筛选过了就绝对安全。不要在SKILL.md或者配套文件里写死API密钥、内部地址、客户数据。我见过有人顺手把组织内部规范做成公开技能结果敏感信息全跟着发布到GitHub上了这个坑踩一次就够难受的。技能包是可以被传播的资产发布前先把自己人的隐私摘干净。最后聊点我的个人体会玩Skills这段时间我最大的感受是这个方向真正改变了人和AI协作的方式。以前我总在琢磨怎么写出一段完美的提示词现在我把精力花在怎么把一次性的工作流变成可复用的技能资产。Skills本质上就是把你脑子里的最佳实践文档化让AI跟着你走过的路再走一遍。如果你也想上手我的建议很直接不要一开始就想着做一个全功能超级技能从手头最高频的小任务开始。比如先把你的周报格式化技能做出来把一个会议的纪要模板技能做出来跑通之后再扩展。等你积累了三五个稳定好用的技能你会突然发现那些以前最耗精力的重复性工作基本上都能甩给AI去做了。这个投入产出比相当划算。