提到“skills”很多人第一反应是“技能”但在最近的AI开发圈里这个词已经变成了一套非常具体的东西——它可以是Codex里的一段指令包也可以是Claude Agent里的一个能力插件甚至是一整套“拿来就能用”的工作流。我最早接触“skills”这个概念是在折腾前端开发自动化的时候发现光靠一段Prompt根本压不住复杂的项目结构后来看到有人把“让AI处理某项任务”的方法封装成可复用的技能包才意识到这玩意儿才是Agent真正好用起来的关键。这篇文不聊虚的我想把我这段时间摸爬滚打总结出来的东西讲清楚skills到底是什么、怎么选、怎么自己写一个、怎么测试调试以及各种坑。不管你是前端、后端、安全研究还是单纯想用AI写论文、做分析的都能找到可以“抄作业”的部分。1. 先理解skills到底是什么——从一杯咖啡的“配方”说起1.1 一个生活化的类比你可以把skills想象成一杯拿铁的制作流程咖啡豆、牛奶、糖浆、温度、比例这些是材料而“拿铁做法”就是把材料变成成品的那套步骤和配方。没有配方你和咖啡师面对同样一堆材料做出来的东西天差地别。AI模型就是这个咖啡师它本身知道怎么“做咖啡”但你如果不说清楚“要什么口味、用什么豆、水温多少、奶泡打到什么程度”它就只能凭感觉发挥。Skills的本质就是一套结构化的“配方”。它把某一类任务的执行方法固化成文件、脚本、说明文档和示例让AI在遇到相关任务时能自动加载、按步骤执行、输出符合预期的结果。它不是模型本身也不是一个独立的程序它是“模型 上下文 工具 工作流”的组合包。在OpenAI Codex、Claude Agent、各式开源Agent框架里skills通常表现为一个目录里面包含SKILL.md说明文件还有辅助脚本、模板、参考文档等。当Agent发现当前任务和某个skill匹配时就会按照这个skill定义的流程去处理。1.2 为什么这个时代突然开始狂提“skills”因为纯Prompt对话的短板太明显了。你可以让AI“帮我写一个带搜索功能的前端页面”它能给你代码但如果让它“按照团队规范、技术栈、目录结构、接口风格来完成这个页面并自动跑测试”一次对话根本写不清楚而且每次都要重复描述。Skills就是把这种“描述”沉淀下来。一次写清楚之后所有项目都能复用。一个人写好了团队其他人也能直接引入。GitHub上有大量别人整理的skills包有前端的、后端的、写论文的、做数据分析的这就是热词里“skills推荐”“skills大全”出现的原因——大家在互相共享和交换“配方”。1.3 一个最小可用的skills到底包含什么我拆解过几个比较流行的skills包发现它们几乎没有例外地包含这几部分入口文件通常叫SKILL.md用Markdown写告诉AI这个技能是干什么的、适用什么场景、需要哪些输入、输出什么格式、遵循什么步骤。参考资源比如代码片段、配置模板、常见问题列表、示例输出。这些内容不需要每次对话都塞进上下文而是在需要时按需读取。可执行脚本或工具比如一个处理文件名的Python脚本、一个调用API的Shell命令。Agent可以调用它们来执行实际操作而不是只能“嘴上说说”。护栏规则明确指出什么不能做、什么必须验证、什么情况下要停下来问用户。所以你会发现skills不只是一个“更长的Prompt”它是把“知识”和“执行”绑在一起的综合体。这也是为什么很多人说“Skills让AI从聊天助手变成了干活的员工”。2. 围绕“skills”怎么选、怎么用——热门方向与落地场景2.1 前端开发skills最常见的入门场景热词里“前端开发skills”排得很靠前确实前端是skills最能发挥价值的地方。因为前端项目通常有固定的工程化流程初始化项目、安装依赖、搭建目录、写组件、做类型定义、跑构建、修报错。这套流程如果每次都用一句“帮我做”开头AI产出的东西往往风格各异、甚至跑不起来。我试过把一套“前端页面生成skill”引入Codex里面定义了标准目录结构src/components、src/pages、src/utils规定了必用TypeScript、组件命名用PascalCase、样式使用Tailwind并禁止全局CSS还要求生成后必须执行pnpm build验证。效果非常直接同一个任务使用skill前生成的代码质量参差不齐使用skill后基本一次通过构建而且风格和团队手写代码的差异很小。选择前端skills时我会重点看几个维度是否和你的技术栈匹配React/Vue/小程序等。是否包含工程化校验步骤比如lint、build、test。是否明确了目录结构和命名规范。是否附带了可运行的示例。GitHub上搜索“codex skills”或者“claude skills”能找到一大堆但很多质量一般。我建议优先看高星仓库、最近还在维护的并且下载后先看SKILL.md的内容别直接跑。2.2 写论文、写文档、做研究的skills知识工作者也能用“codex写论文的skills”“workbuddy skills 写论文”这些热词也说明了大量需求。写学术类内容最大的问题是引文、格式、逻辑结构AI容易一本正经地胡编。好的论文写作skill会强制要求分步执行先梳理论文题目和摘要再生成大纲然后逐节撰写每一步都必须基于用户给出的资料不能凭空编造引用。我在实际使用中总结出这类skills需要具备的硬性条件有“事实核查”步骤标记出哪些陈述需要用户确认。有引用格式模板比如GB/T 7714或APA。有段落长度与语言风格控制。能输出可编辑的Markdown或LaTeX文件。有些做法学、社会学研究的朋友也在用这类skills做文献综述和初稿但记住AI生成的论文一定要自己改别直接提交。skill能管住流程但管不住内容的责任。2.3 安全研究方向安卓脱壳skills的前置与边界热词里有“安卓脱壳skills”“自动挖洞skills”这两个词比较敏感但作为技术分享还是可以说清楚的。在移动安全研究、合规的渗透测试、个人App自研调试中应用加固与脱壳对抗是一个真实存在的技术领域。所谓的“脱壳skill”其实就是把这个过程的方法论、工具链和步骤固化成Agent可执行的流程比如检测加固类型、查找脱壳点、dump内存、修复导出表、去重等。我自己并不建议初学者一上来就搞脱壳。原因很简单环境非常容易翻车各种厂商的加固方案差异很大同一个skill在不同系统版本上表现极不稳定。如果你真的在做合规的安全研究我的建议是把脱壳skill当成“辅助工作手册”让它指导Agent帮你准备环境、执行命令行工具、整理脱壳结果而不是完全自动一条龙。至于“自动挖洞skills”很多开源项目里都有比如把子域名枚举、端口扫描、目录爆破、常见漏洞检测整合进一个skill。我只强调一点先确认授权再谈技术。没有授权的扫描是违法的不管你的skill写得多漂亮。2.4 Agent Skills测试与工具链“agent skills测试”这个热词也提醒我们skills不是写完就能用是需要测试的。现在主流的方式有两种一种是在官方市场里直接安装和试跑另一种是在本地用sandbox环境跑一套自动测试用例。我常用的测试工具链是一个docker容器里面装上Codex CLI或Claude Agent SDK再挂载skills目录用一组标准任务来验证输出是否命中预期。例如测试“代码审查skill”就给它一个故意写了bug的仓库看能不能定位到问题测试“生成单元测试skill”就给它一个带私有方法的类看生成的测试能不能覆盖。如果你不想自己搭环境很多开源项目也提供了基于pytest的测试套件直接把skills包拉下来运行make test就行。3. 手把手开发一个自己的skills——从零到可复用3.1 第一步确定边界和场景我刚开始写skills时犯的最大错误就是想“一步到位”写一个包罗万象的skill结果AI根本不知道该执行哪一步。后来学乖了一个skill只解决一个问题。比如你先做一个“给React组件生成storybook stories”的skill不要想着同时覆盖“生成组件写测试写文档”。边界越清晰SKILL.md里面描述的场景匹配就越准确AI误用其他skill的概率也越低。确定场景时可以回答这几个问题这个skill主要给谁用前端同事、数据分析师还是自己需要Agent做什么写代码、跑脚本、整理文档在什么情况下应该触发它比如“用户说我要给Button加story”。什么情况下不应该触发它比如涉及后端接口联调时就别掺和。3.2 第二步设计目录结构和核心文件我的习惯是每个skill一个文件夹文件夹里至少包含my-skill/ SKILL.md references/ template.txt example-output.md scripts/ run.py tests/ test_case_1.txtSKILL.md是灵魂。我自己写的时候会用这样一套骨架--- name: my-skill description: 这个skill用于xxx场景当用户提出xxx请求时使用 --- # 任务目标 一句话说明这个skill要达成什么目标。 # 输入要求 需要用户提供什么信息缺少时应该怎么询问。 # 执行步骤 1. 步骤一... 2. 步骤二... 3. 步骤三... # 输出格式 说明最终交付物的格式比如Markdown、JSON、代码仓库结构。 # 注意事项 - 不要做什么 - 在什么情况下停止并请求帮助description字段非常重要。在Codex或Claude Agent中系统就是靠它来匹配任务和skill的。描述得太笼统会导致误触发描述得太具体会导致该触发时不触发。我推荐写成“当用户需要做X且环境包含Y时使用此skill完成Z”。3.3 第三步让skill“说人话”——把执行步骤写细很多社区里的skill写得像论文提纲AI看完还是不知道具体怎么做。真正的skill执行步骤应当像操作手册一样包含命令、参数、检查项和兜底方案。拿“前端代码审查skill”举例我在SKILL.md里会写先读取package.json识别项目框架和包管理器。如果使用了pnpm用pnpm install安装依赖如果lock文件是npm生成的不要强行用pnpm。执行eslint .和tsc --noEmit把报错信息按严重程度分类。审查组件目录时重点看props类型、事件命名、样式是否“泄露”到全局。审查完成后输出一个分类清单阻塞问题、建议修改、可忽略。这里面的关键是“如果…就…”逻辑。AI模型的执行能力很强但它需要决策依据。你给它明确的分支条件它就能像一个老员工一样自己判断而不至于每次卡住都问你要下一步。3.4 第四步把参考模板和脚本放进去如果你的skill涉及重复性的输出格式一定要放模板。比如“生成周报skill”模板就是周报的markdown结构再比如“生成API接口文档skill”模板里就包含请求路径、参数表、响应示例。脚本的作用是让Agent能做更“重”的操作。我写过一个小脚本用来从JSON文件里批量提取字段并生成元组列表省得AI自己解析字符串时出错。脚本通常都用Python因为跨平台、依赖少、容易调试。在SKILL.md里要写明“如果需要运行scripts/run.py请使用python3并传入参数--input xxx”。写脚本时记得容错做个try except把异常信息返回给Agent这样就算脚本崩了AI也能根据错误信息来调整调用方式而不是呆在那里。3.5 第五步自测与迭代写完skill先别急着发布。我会先在命令行里做一个手工测试codex exec --skills my-skill 帮我根据这个模板生成一个Button组件看看输出是否符合预期。然后换一种说法“现在要给Card组件加story文件”测试触发匹配是否准确。最后再给一个完全不相关的任务“今天天气怎么样”确保它不会误触发。迭代时要特别关注SKILL.md里的描述和步骤。AI不听话通常不是它笨而是你的spec有歧义。把“尽快”改成“在10分钟内”把“检查一下”改成“运行git status并确认没有未提交的变更”效果会立刻变好。4. 测试、调试与常见坑——实操经验实录4.1 为什么skill会不生效遇到最多的情况是skill已经放进目录了但Agent就像没看见一样。原因大概率是描述匹配失败。Codex或Claude Agent采用语义匹配如果你的description里用的词和用户提问差太远就触发不了。比如你写的是“生成SVG图标”别人问“给这个按钮加个箭头”匹配不上很正常。解决方式把描述写得更有“召回率”把同义词、场景词都放进去但别堆砌。比如“生成或修改前端图标包括SVG、iconfont、组件内联图标适用于按钮、状态指示、加载动画等场景”这个描述就能覆盖不少变体。还有可能是skill目录结构不对。有些框架要求SKILL.md必须放在某个固定位置或者要求每个skill有唯一的name元数据。如果放错层级系统在扫描时根本找不到。4.2 调试技巧让AI把自己的“思考过程”说出来我调试skill的时候会在开头加一句“请先说明你选择了哪个skill以及原因”然后再执行任务。这样如果选错了我能第一时间看出匹配问题。比如它选了“数据库设计skill”来处理“帮我写个接口”这种请求说明描述里的边界不清晰需要收紧。还可以为每个执行步骤设置“日志点”让AI在完成每步后输出一句话的总结。虽然会稍微消耗一些token但对定位问题非常有帮助。正式使用的时候再让AI只输出最终结果。4.3 常见的坑与避坑清单下面这份清单是我踩过之后整理出来的不一定全但遇到频率很高坑表现解决方案描述过于宽泛什么任务都触发或什么都不触发在description中增加“当用户提到…”“不适用…”步骤里缺少分支AI反复询问用户同一类问题把“如果X做Y”写清楚依赖全局工具换台机器就报错在SKILL.md中声明所需依赖并在scripts里加检测模板过于固定业务稍有不同就输出垃圾模板里多写变量占位和“可选”标记脚本路径写错找不到文件使用相对路径并附上示例命令忽略错误处理脚本报错导致后续全崩脚本返回结构化错误如{error: ...}没有测试用例迭代后行为漂移每次修改都跑同一组测试场景4.4 多做“对抗”测试在安全研究类skill上我额外会做对抗测试故意给出一段包含恶意执行逻辑的代码看看skill是否会引导Agent去执行。如果skill没有护栏它会老老实实地把命令写入自动化流程这是一个非常危险的信号。做自动化挖洞或脱壳研究的同学特别注意skill里面至少要有两条硬性护栏默认禁止对非授权目标执行扫描、默认禁止上传任何敏感数据到第三方服务。4.5 性能与上下文控制很多人抱怨“skills让AI变蠢了”是因为所有参考资料被一股脑塞进上下文占用了大量token。实际上按需加载才是正解。现代Agent框架里SKILL.md本身是一份“目录”AI读取它之后再根据步骤打开具体文件。你不需要把所有内容都写进SKILL.md。比如一个“数据分析skill”SKILL.md里只要写“用户提供数据集后先读取scripts/analyze.py按其中定义的5个步骤处理数据”。这样上下文占用少AI的注意力也更集中。4.6 如何在团队里工程化使用skills到这一步我强烈建议在团队仓库中单独建一个skills/目录并用git做版本管理。每个人都能提交自己的新技能但合并之前至少要过一遍review重点看SKILL.md里的安全边界和命令是否可靠。我团队现在的方式是主要维护一套“前端基础skills包”包含页面生成、代码审查、单测生成、组件库文档生成四个skill。新人入职只需要在Agent配置里指向这个目录立刻就能获得“团队级的AI协作能力”不用再反复解释项目规范。还可以给skills加上版本号在SKILL.md的metadata里写version: 1.2.0这样当行为变化时团队可以追踪是谁改的、改了什么。配合自动化测试流水线每次push后跑set指定的样例就能防止一个改动把其他业务场景搞坏。我个人在实际操作中的体会是不要把skills当成“一次搞完的工程”它更像一个不断生长的知识库。最开始可能只有一个“代码审查”用着用着就会觉得“要是它能顺便检查性能问题就好了”于是迭代出第二个版本又用一阵子发现移动端和PC端规范不一样于是又拆出两个独立skill。这种生长过程才是skills最有价值的地方——它把人和AI之间那些说不清的默契一步步固化成团队可以持续积累的资产。最后再分享一个小技巧找一个你每天都在做的重复性任务把它写成一个skill哪怕一开始只有几百字的步骤也足够了。用一周时间持续修正你会明显感受到AI的产出从“能跑”变成“靠谱”。Skills的门槛并不高关键是开始动手的那一刻别想着一口气做完美先让它替你干一次活再说。