说实话我大概是半个多月前才真正把“Skills”这个词当回事。起因是工具里多了一个“技能”面板我顺手点开发现里面躺着一堆还不太认识的模块有用来做会议纪要的有做幻灯片排版的还有处理PDF的。起初我以为这只是又一次产品更新里的鸡肋功能直到我在一次输出正式报告时它没有直接生成答案而是默默调起了一个技能然后给我交回了一份流程完整的分页文档。那个瞬间挺震的AI从一个“什么都懂一点”的聊天对象变成了一個带着自己专属工具包的执行器。这篇文章就是想把“Agent Skills”这件事拆开聊透。它到底是什么、底层结构长什么样、怎么自己写一个、现成的又上哪儿找、最后怎么接进Claude或Codex这类主流工具里。如果你和我一样属于“天天在用AI但总觉得差一口气”的人这篇应该能帮你把那口气补上。尤其是当你搜到“skills开发”“skills推荐”却不知道怎么落地的时候下面的内容基本就是按你需要的顺序写的。1. 一个现象和一种生态先搞清楚你在和哪种Skills打交道1.1 为什么“skills”这个普通词一夜之间变成热搜你去看看近期的搜索热词会发现“skills”几乎被搜烂了skills推荐、skills下载平台、skills大全、agent skills测试、人工智能skills、codex skills……一个如此普通的英文单词突然变成技术热词背后的信号只有一个从某个时间点开始AI产品不再满足于“你问我答”而是开始往“你吩咐我调用专业能力”的方向演化。这个变化体感上很直接。以前我要AI做一份PPT需要把要求讲得非常细主题、颜色、大纲、每页放什么甚至还要贴参考案例。现在只要一句“用制作幻灯片的skill把这份提纲做成演示文稿”它自动去读技能说明、跑脚本、产出结果。原本写在对话里的“怎么做”被放进了那个不可见的技能包里。于是所有人的搜索习惯都变了开始搜“有哪些skills”“怎么引入这些技能”——因为大家都感觉到没有这些东西等于同一个AI别人用出八十分自己还在六十分挣扎。1.2 最容易混淆的三种Skills市面上叫Skills的东西我现在随手一列就有三类而且互相之间经常被搜到一起。类型代表本质典型用法官方Agent SkillsAnthropic Claude的Agent Skills可复用的技能文件夹包含说明、脚本、参考材料文档处理、数据分析、代码生成编程助手SkillsOpenAI Codex内置SkillsCLI里可直接启用的专项能力模块论文写作辅助、代码库分析、自动化任务社区增强型SkillsSuperpowers等第三方包一次性导入多个技能的“全家桶”综合增强Claude等工具的默认能力另外还有一个单独的存在GitHub Skills。它不是给模型用的技能包而是GitHub官方做的交互式学习课程教你怎么用GitHub托管、协作、整理仓库。搜索的时候很容易混在一起你搜“github skills”实际是课程平台你搜“skills下载平台”出来的才是我们这里讨论的技能市场。1.3 为什么Agent Skills突然值得所有人学我的判断是模型能力的天花板短期内很难再出现那种“突飞猛进式”的提升但是技能体系可以让人人都把模型用出“另一个层次”。没有Skill的AI你每次都要把同样的话重新教一遍有了Skill的AI等于把多次磨合后的最佳流程固化了下来。对一个团队来说这就是把某个老手脑子的操作SOP沉淀成文件对个人来说这就是把自己的最佳提示词、最佳脚本、最佳案例打包成一件随身武器。所以现在去学它不是赶时髦而是补上一块从“会用AI”到“会用AI干活”之间的关键拼图。2. Skills的工作原理一个文件夹如何变成一项能力2.1 最小技能包的标准骨架你如果打开一个典型的Skill目录会发现它根本没多复杂甚至可以说有点朴素。最小可用的结构大概长这样skills/ my_skill/ SKILL.md scripts/ something.py assets/ template.xlsx references/ guide.md examples/ demo_input.txt demo_output.csv这里面真正的核心是三个部分SKILL.md给模型看的说明书。所有“什么时候用、怎么用、输出什么格式”都写在这里。scripts给模型调用的脚本。这是一个Skill真正开始有含金量的地方。examples示例输入和示例输出。作用是让模型知道“标准答案长什么样”。很多人一开始会高估结构低估说明实际上SKILL.md决定了模型想不想用它而scripts决定了它用得好不好。两者缺一不可。2.2 SKILL.md里的三层设计描述、正文和示例SKILL.md通常带一个YAML格式的文件头最关键的字段就是description。别小看这段描述它的价值不在于给人类看而在于让模型判断“当前这个任务是不是该触发我”。这就是决定你的Skill是无人问津还是次次被调用的第一道关卡。举个例子同样是处理会议纪要差的description是description: 处理会议记录。好的description是description: 将口语化的会议原始记录清洗成结构化的行动项清单。当用户提到“会议记录”“纪要”“下一步安排”“待办事项”“负责人”等场景时使用。输出为表格形式。区别非常明显前者没有任何触发线索模型很可能觉得“我直接回答就行”后者直接把适用场景、关键词、输出格式全交代清楚了。正文部分则要教会模型执行的步骤顺序。建议写出明确编号先读输入、再调脚本、最后把脚本结果整理给用户。模型很擅长模仿这种流程你给它的流程越清晰它的输出就越稳定。最后的示例模块也不是可有可无的它相当于说明书后面附了一个“标准答案册”让模型在不确定的时候有一个模仿的锚点。2.3 脚本是Skill和普通提示词真正拉开差距的地方我见过很多人把Skill理解成“高级提示词”这话对了一半。单纯把一段提示词写进SKILL.md确实也能算一个轻量Skill但如果你想让一件事稳定、可靠、可重复脚本才是关键。打个比方提示词相当于你口述让一个人做饭能做成什么样全看这位师傅今天心情和水平而脚本相当于你给他一条流水线材料进去标准品出来。大模型的语言生成是有随机性的但一段经得起测试的Python脚本没有随机性。它能处理编码、能算数、能解析文件、能读写磁盘这些事情让模型靠“语言想象”来完成水平极不稳定。所以一个合格的Skill尤其是偏工程类的Skill一定尽可能地让脚本承担确定性工作让模型只负责解读需求、整理结果和解释输出。3. 手把手开发把“会议纪要转行动项”做成一个Skill3.1 先判断一个任务适不适合做成Skill不是所有任务都适合。判断标准有三个高频这件事你经常干一周至少一次才值得封装。有固定套路流程基本不变输入输出相对标准。需要一致输出同样一份输入最好每次产出的格式和颗粒度都一样。反过来太开放的任务比如“帮我写一份开题报告的思路”“帮我想一个营销策略”就不适合做成技能。越开放模型自由发挥的空间越大技能反而成了束缚。另外任务如果是一次性的也不建议做别为了一个临时任务维护一个长期包袱。3.2 落地目录结构并编写SKILL.md我现在以“会议纪要转行动项”为例带你完整走一遍。第一步建立目录mkdir -p skills/meeting_actions/scripts mkdir -p skills/meeting_actions/examples然后写SKILL.md--- name: meeting_actions description: 将口语化的会议原始记录整理成结构化的行动项清单CSV格式。当用户提供会议记录、纪要、通话摘要并提到“下一步”“行动项”“负责人”“待办”“整理成表格”等场景时使用。 --- # 会议纪要转行动项 1. 通读用户提供的会议原始记录。 2. 调用执行脚本 scripts/extract_actions.py将原始文本作为输入。 3. 脚本会输出符合标准的 CSV 行动项。 4. 你最终向用户展示的表格必须与脚本输出一致不得自行增删行。 5. 如果脚本执行失败不要假装成功将错误信息原样反馈。 ## 注意事项 - 负责人在原文中可能缺失缺失时请标注“待确认”。 - 日期可能是模糊说法如“下周”不要强行转换保留原文。这一段写下来模型就知道我是谁、我该干什么、我该怎么干活、干不了怎么办。3.3 编写一个足够简单的解析脚本写脚本的时候我强烈建议从最不依赖外部库的版本开始。#!/usr/bin/env python3 # -*- coding: utf-8 -*- 从会议原始记录中提取疑似行动项的文本行并输出CSV。 import sys import csv import re import io def extract_actions(text): actions [] for line in text.splitlines(): if re.search(r(下一步|行动项|负责人|todo|action|待办|跟进), line, re.I): actions.append(line.strip()) return actions def main(): raw sys.stdin.read() actions extract_actions(raw) output io.StringIO() writer csv.writer(output) writer.writerow([序号, 行动项, 原始上下文]) for idx, action in enumerate(actions, start1): writer.writerow([idx, action, action[:80]]) print(output.getvalue()) if __name__ __main__: main()你看这个脚本不需要装任何第三方包读标准输入、输出CSV。这种设计的好处是移植性好你在Claude里能用在Codex里也能用换一个环境也不至于因为缺少依赖直接罢工。3.4 用示例驱动调试写完SKILL.md和脚本一定要补一组示例文件比如examples/demo_input.md就是一段伪造但真实的会议记录里面有人名、有模糊时间、有经费数字examples/demo_output.csv是标准输出示例。之后调试时你就用这组例子反复跑查看模型是否主动触发了这个skill检查脚本是否正常读取输入并输出CSV检查模型最后是否把CSV原样呈现给用户而不是自己重新“美化”了一遍导致丢行。我个人踩过的坑是脚本输出得非常漂亮但模型觉得“我也可以回答得更好”于是擅自改了输出。解决办法就是像我在SKILL.md里写的那样加一句“输出必须与脚本结果一致”。这句话能省掉你后面大量的对账成本。4. 去哪里找现成Skills四个渠道和一套筛选逻辑4.1 四个靠谱的来源渠道现在很多人在搜“skills下载平台有哪些”“skills下载”但实际去看看就会明白根本没有一个像手机应用商店那样集大成的地方。真正活跃的资源主要还是分布在四个位置官方仓库与文档Anthropic官方的Agent Skills开源仓库里面有一套公开、带文档的技能。OpenAI的Codex也自带了一批内置skills可以通过CLI直接查看和启用。GitHub社区搜“awesome claude skills”能发现大量技能收集列表再搜具体的“skill名称”能找到各种个人维护的技能包。GitHub其实是事实上的技能大市场。第三方框架自带的增强包Superpowers这类项目本质上就是一个人维护的“技能全家桶”一次导入就能拥有几十个增强型技能适合不愿意一个个挑的人。垂直技术社区一些安全研究、分镜创作、论文写作的专门社区也会分享针对特定行业的Skills质量往往比大杂烩更高。4.2 拿到一个Skill后先检查这三处再决定要不要用Skill的本质是脚本和说明文件的组合而脚本本质上是会在你机器上执行的程序。下载任何别人写的Skill第一反应都应该像收到一个开源程序一样去审一遍而不是直接双击运行。我用的是三个固定检查点先看SKILL.md里的描述是否聚焦一个动辄说“可以完成一切任务”的Skill基本是垃圾真正好用的技能描述往往收得很窄。再看脚本有没有危险操作比如是否有网络请求、是否有删除或覆盖文件的行为、是否要执行任意shell命令。凡是需要常驻执行、伪装系统工具或者请求不必要权限的直接弃用。最后看维护活跃度最近一年有没有更新、有没有issue反馈、示例文件是否完整。一个长期没人打理的Skill很可能跟不上模型版本迭代。4.3 当前最热门的几类实用方向根据大家最近的搜索热情我梳理一下目前真正活跃的几个方向论文写作类最典型的就是“codex写论文的skills”和“workbuddy skills 写论文”。这类Skill通常能拆解论文各章节、自动整理参考文献格式、按照固定结构生成摘要。前端开发类前端开发skills负责组件生成、布局调整、无障碍优化能把成品代码稳定地输出到指定目录。分镜创作类分镜skills下载需求很大自带镜头语言规则和分镜表格式适用于短视频脚本和动画分镜。安全分析类包括安卓脱壳skills、自动挖洞skills主要服务授权渗透测试和软件安全研究场景。这类技能门槛高使用时更要注意审查脚本行为。数据分析与办公类从Excel清洗到PPT生成是新手最容易上手的入门方向。5. 接入主流工具三个我常用的实践路径5.1 在Claude里激活并使用SkillClaude对个人用户主流做法是把技能文件夹放到用户级技能目录下比如~/.claude/skills/下再把下载或自制的Skill包整个放进去。之后打开对话在系统提示或设置面板里能看到已加载的技能列表。实际使用时不需要你输入“调用哪个技能”只要你的请求命中了description里的场景模型就会自己去翻技能包。有一个小技巧是如果你发现模型没有自动触发技能可以在对话里直接点名比如“使用meeting_actions这个技能来处理下面这段纪要”。手动触发永远是一个兜底方案。5.2 在Codex CLI里使用SkillsCodex用户可以在会话中通过斜杠命令查看当前环境里的skills例如输入/skills会列出可选项然后执行codex skills add把指定的技能加入当前项目。更稳妥的做法是把技能文件放进项目目录下的.codex/skills里这样每次在这个项目里工作时都会自动加载。按照我的经验Codex和Claude对同一份Skill文件的兼容性并不完全一致。主要是某些脚本的依赖差异。如果你要做好跨工具复用核心思路就一句话技能包里的脚本尽量只依赖系统自带的标准库不要绑特定平台。5.3 在IDE和编辑器里把Skill变成工作流的一部分用IntelliJ IDEA这类IDE的人搜索“idea使用skills”其实是想知道自己平时写代码的集成环境怎么和技能打通。目前比较顺滑的做法是把技能文件夹作为一个普通目录随项目维护然后在Agent插件的配置中指定技能目录路径。这样做的好处是技能可以和代码一起进版本管理团队里每个人的Agent都能共享同一套能力。对于分镜、写作这类非编码任务也可以用类似思路把技能放在文档项目根目录让AI在生成内容时自动携带项目专属风格要求。6. 实战避坑为什么同一个Skill有时灵有时不灵6.1 模型死活不调用Skill问题出在描述上排查顺序大概是这样。先确认技能目录有没有被正确扫描到再确认description有没有给出足够强的触发线索最后确认你是不是在一个不支持技能的环境里运行。大多数情况下最后的根源都是描述太模糊模型看了一眼觉得“我自己就能搞定”然后就没然后了。我的对策是在description里明确写出可观察的触发词再加上“必须使用本技能不适用时再直接作答”这种偏向强制的语气。注意别把所有场景都写进去写多了反而会让模型触发得过于频繁造成误用。6.2 脚本能跑结果却不对八成是路径或编码脚本明明在本地测试没问题到了Agent环境就出毛病最常见的原因就是相对路径不对、依赖未安装、中文编码错误。有些Agent执行脚本时的工作目录不一定是技能文件夹写死相对路径就会扑空。对策是凡是涉及外部文件脚本里要么用绝对路径要么通过环境变量拿到技能根目录再拼接路径。中文环境的坑也很多。陈词滥调都要再叮嘱一次sys.stdin读入时用-*- coding: utf-8 -*-声明输出CSV时统一用utf-8-sig编码否则Excel打开就是乱码。别觉得自己熟悉就不踩我几乎每个和文件打交道的技能都在这上面栽过一回。6.3 模型“跳过脚本直接给答案”必须强制绑定脚本输出正常情况下模型会在完成后把结果整理得漂漂亮亮但当你严格依赖脚本时它的“自作聪明”反而是坏事。你发现它没跑脚本、直接冒出一堆自己生成的行动项说明SKILL.md里的权威级别不够。解决方式我前面也提了在正文里写“你的输出必须与脚本输出一致不得自行生成新内容”。同时还可以增加一个强制校验步骤比如要求模型先在回复里粘贴一段“以下内容来自脚本输出”把“转述”变成“引用”。6.4 多技能互相掐架命名和解谜都要隔离当你的技能目录膨胀到几十个以后一个新问题会出现模型面对多个看起来都能做的技能时容易选错。比如“生成PPT”和“生成会议文档”如果description里都写了“处理会议材料”模型就会随机挑一个。对策是给每个技能划分清晰的场景边界命名也要有区分度。比如一个叫slide_builder一个叫meeting_actions不要都叫“会议处理”。同时在description里加入明确的“不适用场景”比如“本技能只处理素材整理不负责演示文稿排版”。这种负向描述能极大减少误调用。我在实际项目里最后养成的习惯是每个技能包除了SKILL.md、scripts之外我还固定放一个demo.md里面保存一组示例输入和标准输出。每次换新环境、新模型我第一件事就是跑一遍demo一旦发现“同样的包在不同工具里行为不一致”就能马上定位是描述问题、脚本问题还是环境问题。这个笨办法帮我省了大量在群里问“为什么别人能用我不能用”的糟心事。Skills目前还处在一个快速演进的阶段今天这版结构也许明天就会被官方更新替代但它背后的设计哲学短期内不会变把一次性的对话沉淀成可复用的能力把每个人的私人经验变成团队能共享的标准化资产。你在自己动手写第一个技能的时候踩的那些坑后面都会变成你判断一个外部Skill靠不靠谱的眼力。希望这篇拆解能帮你把那个“新世界”的路口找对。