最近被问得最多的一个词不是大模型不是微调而是 Skills。不管是用 Codex 写代码还是折腾各种 AI Agent你会发现所有工具都在往同一个方向收敛把“会聊天”的模型变成“会干活”的员工。我最早对这三个字母是不以为然的——不就是把提示词整理进一个 Markdown 文件嘛有什么好说的直到自己把一个反复手写的流程固化成 Skill然后看着同一套流程在不同任务里稳定复现我才意识到问题没那么简单。这一篇是“HOW - AI Skills 入门”系列的第一篇主要讲清楚三件事Skills 到底是什么、为什么这个时间点它突然成了 AI 编程和 AI Agent 领域的核心玩法以及普通人怎么用上别人做好的 Skills。适合的人群很明确已经在用 AI 编程工具但总觉得输出不稳定的开发者想把自己的测试、前端、建站等经验沉淀成可复用资产的技术人还有对 Agent 生态感兴趣但还没找到下手点的产品经理和爱好者。先把概念掰开揉碎后面的系列再讲具体开发和调优。1. AI Skills 到底是什么给智能体的“作业指导书”1.1 不是提示词也不是插件SKILL.md 才是灵魂很多人第一次接触 Skills 的时候第一反应是“这不就是一个更长的提示词吗”。这个理解方向是对的但差得很远。提示词是“你告诉 AI 怎么做这件事”Skill 是“你给 AI 一套完整的工作框架包括步骤、规范、参考示例、验证方法甚至配套脚本”。同样是让 AI 做代码审查提示词像是你口头交代一句“帮我看看这段代码有没有问题”Skill 则像你甩过去一本《代码审查操作手册》里面写清楚了先看什么、后看什么、什么情况必须报错、什么情况只需提示、最终输出格式是什么。一个 Skill 的灵魂是它的主文件通常叫 SKILL.md。这个文件不是简单的命令列表而是把“一个有经验的人是怎么完成这项工作的”拆解成 AI 能逐步执行的工作流。写 SKILL.md 的人本质上是在做知识工程把隐性的经验显性化把口语化的“你看着办”变成可执行的“先做 A再做 B遇到 C 情况走 D 分支”。1.2 一个 Skill 的标准结构声明、流程、参考、验证我自己用得比较顺的 Skill内部结构通常包含四块内容。第一块是声明区说明这个 Skill 是干什么的、在什么场景下启用、输入是什么、输出是什么。第二块是流程区把任务拆成三到七个步骤每一步给出明确的执行指令比如“步骤 1收集项目文件列表排除 node_modules 和 dist 目录”“步骤 2按依赖、配置、业务代码的顺序进行审查”。第三块是参考区放示例输入输出、常见问题的处理方式、需要遵守的规范清单。第四块是验证区告诉 AI 怎么自查比如“检查输出是否包含严重程度分级”“确认每条问题都关联了文件路径和行号”。这个结构不是拍脑袋定的。我见过很多写得很空的 SKILL.md通篇都是“请你认真分析”“请你全面考虑”——这种话说一百遍也没用模型根本不知道“认真”长什么样。只有把工作流拆到可执行、可检查、可验证的粒度Skill 才能真正稳定发挥。你可以把 SKILL.md 理解成一张给新员工的入职培训表上面不会写“你要努力工作”而是写清楚“每天早上先看工单系统按 P0/P1/P2 分级处理P0 需要在 15 分钟内响应”。1.3 Skills 与 Prompt、Plugin、Agent 的边界在哪这三者的边界经常被搞混我用一个简单的类比讲清楚。Prompt 是“一句话需求”你告诉 AI 你想要什么怎么做取决于模型的心情。Plugin 是“外挂工具”你给 AI 装上一个新的能力比如搜索网页、操作文件但具体怎么组合这些能力仍然靠临场发挥。Skill 则是“作业手册”它定义了完成一类任务的标准动作序列同时还可以调用 Plugin 的能力来完成具体步骤。Agent 则是“拿着手册去执行的人”它负责理解任务、调用合适的 Skill、决定什么时候用什么。所以你可以这样理解Prompt 是需求Plugin 是工具Skill 是方法Agent 是执行者。没有 Skill 的 Agent 就像没有 SOP 的新员工能力很强但动作变形有了 Skill 的 Agent才真正像一个干了三年的老手拿到任务就知道第一步干什么、第二步干什么、做到什么程度算完。这也是为什么现在各大平台都在疯狂推 Skills因为只有 Skill 才能让大模型从“演示级可用”走向“生产级可用”。2. 为什么这个时间点 Skills 突然火了agent 从“演示”走向“干活”2.1 从 Codex Skills 到 Nature Skills大厂和社区在押注同一个方向如果你最近关注 AI 编程圈会发现几件很有意思的事。一方面Codex 这类编程助手开始把 Skills 作为核心能力来推社区里很快冒出了一堆 codex 好用的 skills 推荐帖另一方面围绕 Claude 的官方市场也出现了大量被称作 nature skills 或 cola skills 的第三方技能包下载量还很可观。连 DeepSeek 那边也公开了 AI 智能体训练的新方法方向上都在强调让模型学会调用工具、遵循工作流而不是单纯地生成文本。这些信号放在一起看答案就很清楚了整个行业都在往“可编程的智能体”方向收敛。此前的大模型产品大家拼的是“谁更会聊天”后来拼的是“谁的工具调用更稳”现在拼的是“谁能把复杂任务稳定地做完”。而 Skills 恰好就是那个把“复杂任务怎么做”固化下来的载体。它让经验可以被复制、被分发、被复用——这比任何单次对话优化都更有价值因为它解决问题的粒度从“一次对话”提升到了“一类任务”。2.2 没有 Skills 的 agent 是“无头苍蝇”有了 Skills 才是“老员工”我说一个自己反复踩过的场景。早期我用 AI 做前端项目检查的时候每次都要在对话框里重新交代一遍先看 package.json 里的依赖有没有版本冲突再检查组件目录结构是否规范然后扫一遍有没有硬编码的业务配置……每次都得打一大段字而且模型发挥极不稳定今天记得看这个明天就忘了。后来我把这套流程写成了一个前端开发 skill每次只需要说一句“用项目体检 skill 检查一下当前仓库”它自己就知道先干什么、后干什么、按什么格式输出报告。这个体验差距比模型本身升级带来的差距还要大。这不是个例。社区里流行的 superpower skills、常用 skills 合集本质上都是在做同一件事把“某类专家的工作习惯”复制给 AI。一个前端开发 skill 里存的是前端架构师审查代码时的心法和清单一个测试开发 skill 里存的是资深测试工程师设计用例时的思路和边界条件。这些技能包的价值恰恰在于它们沉淀的是“人怎么做这件事”的方法论而不是“模型背下来的知识”。2.3 什么场景最适合做 Skill判断标准不是所有需求都适合做成 Skill。我实践下来适合做 Skill 的需求有四个特征。第一流程稳定完成这类任务的步骤基本固定不会每次都不一样。第二频率高你或你的团队会反复遇到这类任务值得把经验固化下来。第三专业知识密集任务需要特定领域的检查清单或规范光靠模型常识容易漏。第四输出明确任务的产出物有相对固定的格式标准。反过来低频的一次性需求、主观性极强的创意任务、边界模糊的开放式问题都不适合做 Skill。举个例子“帮我写一句朋友圈文案”就不适合因为主观性太强没有标准动作可拆“帮我给这个项目做一轮完整的依赖安全审计”就适合因为流程固定、有检查清单、输出格式明确。“AI 漫剧”这种内容生产类需求反而是很好的 Skill 场景——分镜脚本怎么写、画面描述用什么格式、配音文本怎么断句整套流程可以固化成技能包让 AI 按流水线方式批量产出。判断一个需求能不能做成 Skill你就问自己一句话如果招一个实习生来做这件事你能不能写出一份让他照着做就不会出错的 S.O.P.能就适合。3. 想直接用现成的推荐从哪几个方向开始3.1 高频高价值的 Skills 方向前端、测试、建站、内容生产很多朋友上来就问“skills 大全在哪里”好像收集了一堆技能包就等于会用了。我的建议是别贪多先按自己最常干的事情挑三五个高质量的装好。目前在社区里最活跃、也是我自己用过觉得最能提升效率的几个方向我列一下。编程类里前端开发 skill 非常成熟能做项目体检、代码规范检查、组件拆解建议测试开发 skill 也很能打能根据需求自动生成测试用例、边界条件列表、冒烟测试脚本。效率工具类里AI 建站 skill 能把“从零搭一个落地页”的流程标准化包含技术选型、页面结构、SEO 基础配置。内容生产类里跟 AI 图片生成原理结合的绘图技能包以及 AI 漫剧类的分镜脚本技能包都是社区里下载量很高的品类。我个人最推荐的切入点是“前端开发 skills”和“ai 测试开发”这两类。原因有二一是这两类任务的评判标准相对客观模型做得好不好一眼就能看出来适合用来体验 Skill 和普通提示词的差距二是这两类技能包的生态最丰富能找到大量高质量的现成品做参考。至于“常用 skills 有哪些”这种问题我建议你去各平台的技能市场看下载量和最近更新时间下载量是可以刷的但最近更新时间骗不了人——一个三个月没更新的技能包大概率已经不兼容当前主流模型。3.2 怎么找优质的 Skills渠道与筛选方法找 Skill 的渠道主要有三类。第一类是官方市场或平台内置的技能库比如 Codex 的 skills 官方市场、Claude 的技能市场这里的技能包经过基本审核质量相对有保障。第二类是 GitHub 等代码托管平台直接搜“awesome skills”“superpower skills”“nature skills”这些关键词能找到大量合集仓库。第三类是社区和博客很多人会把自用的 skills 开源出来附带详细的使用文档这类往往最接地气因为作者是真实用户文档里会写清楚踩过的坑。筛选技能包我有一套固定动作。先看 SKILL.md 的完成度如果一个技能包连主文件都没有或者主文件里全是“请仔细分析”“请全面考虑”这种空话直接放弃。然后看配套示例好的技能包一定会带示例输入和示例输出这能让你快速判断它的输出风格是否符合你的预期。最后看维护频率代码托管平台的提交记录、市场里的更新日期都是好指标。我一般装新 Skill 之前还会看一下它的依赖项——有的技能包依赖特定脚本或第三方 API本地没装好环境的话用起来会到处报错。3.3 安装与启用的通用流程以 codex 和 idea 环境为例不同平台的 Skill 安装方式略有差异但核心逻辑是一样的把技能包放到指定目录让 AI 工具能够在需要时检索到它。以 Codex 为例你通常需要把技能包解压到 skills 目录下然后在对话里用“用 xxx skill 帮我做 yyy”的方式唤起。IDE 类工具更简单比如 idea 里使用 skills 通常通过插件市场安装装完重启 IDE 就能在 AI 助手的技能列表里看到。这里有一个非常重要的经验安装不等于启用。很多 Skill 定义了触发条件不是你说“用一下”它就一定用。写法上建议直接点名要用的技能包而不是含糊地说“帮我检查项目”。实测下来显式唤起命中的概率远高于隐式触发。第一次用新技能包的时候建议先跑一个最小任务验证它能正常工作再放到真实项目里用。我曾跳过这一步直接拿一个刚装好的测试开发 skill 去跑线上项目结果输出了十几个假阳性问题排查了半天才发现是技能包里的检查清单和项目技术栈不匹配。4. 手把手开发第一个 Skill从想法到能稳定交付4.1 先拆工作流再写文件一个“前端项目体检”的例子开发 Skill 最忌讳一上来就写 SKILL.md。正确的顺序是先把你做这件事的完整流程拆出来画成一张步骤图再翻译成给 AI 的指令。我拿自己做的“前端项目体检”技能包举例。这个 Skill 的目标是给一个前端项目做一轮结构化检查输出带严重程度分级的报告。我拆出来的工作流是这样的第一步扫描项目结构定位 package.json、配置文件、源代码目录第二步检查依赖安全性和版本一致性第三步检查目录规范和组件拆分情况第四步扫描硬编码业务配置和敏感信息第五步汇总问题并按 P0/P1/P2 分级输出 Markdown 报告。拆完流程你会发现每个步骤背后都有大量的专业知识要去补充。比如依赖检查不是简单地跑一下 npm audit还要看 lock 文件是否一致、依赖版本是否过老、同一依赖是否重复安装。这些知识哪里来从你的日常工作经验里来也可以参考社区里同类型技能包的做法但不能直接抄——不同团队的项目规范差别很大通用技能包往往停留在“建议级”你要做的是把它变成“可执行级”。4.2 SKILL.md 写作要点指令要可执行流程要闭环写 SKILL.md 的时候我给自己立了三条规矩。第一条每条指令都要让 AI 能直接行动不要出现“思考一下”“综合考量”这种不可执行的动词尽量用“读取”“扫描”“比较”“列出”“输出”这类动作词。第二条流程要有分支处理AI 在真实任务里会遇到各种异常情况比如项目里没有测试目录、依赖安装不完整你得在 SKILL.md 里提前写清楚遇到这些情况怎么办。第三条输出格式必须锁定包括标题层级、列表风格、严重程度怎么标注、结论写在什么位置格式锁定得越死输出越稳定。三段式的 SKILL.md 写作模板我用了很久。开头是 YAML 风格的前置信息写清楚技能名称、适用场景、输入要求、输出格式。中间是主流程按步骤编号列出每个步骤里写清楚做什么、怎么做、做到什么程度算完成。最后是参考和自查清单包含示例输出、常见问题的兜底方案、以及要求 AI 在交付前完成的自我检查项。这套模板本质上是在模仿工程里的代码规范文档只有把“必须做什么”和“不能怎么做”都写清楚执行者才不会跑偏。4.3 配套脚本与参考文件把“经验”沉淀成“资产”一个好的 Skill 不能只有 SKILL.md还需要配套的脚本和参考文件。脚本的作用是替 AI 完成那些“它不擅长”或“它做起来容易出错”的确定性操作比如扫描文件结构、解析 package.json、比对版本号。参考文件的作用则是给 AI 提供专业知识的“外挂记忆”比如一个常见依赖安全问题的速查表、一套团队代码规范摘要、一份历史典型问题的复盘清单。这样你在 SKILL.md 里就只需要写“按参考文件 xxx 中的清单逐项检查”模型会自动去读取并执行。这一步也是最容易被新手忽略的但恰恰是让 Skill 从“玩具”变“工具”的关键。我的前端体检 skill 里加了一个硬编码配置扫描脚本专门匹配常见业务配置模式和可疑的密钥赋值语句效果比纯靠模型肉眼扫稳定得多测试用例生成 skill 里则放了一份边界条件速查表覆盖了空值、超长文本、并发请求、权限不足等高频场景。可以说SKILL.md 是骨架脚本是肌肉参考文件是大脑里存着的经验。三者齐了才算是一个真正能稳定交付的 Skill。4.4 测试与迭代我的实测节奏和调参心得技能包开发不是写完就完事的我一般会拿三个不同规模的项目去测。第一个是小项目测试基本路径能否走通第二个是中大型项目观察 AI 在处理大量文件时会不会丢失上下文第三个是有特殊技术栈的项目看技能包遇到预设之外的场景能不能合理地降级处理。每轮测试我会重点记录三类问题步骤缺失、指令歧义、输出格式漂移。步骤缺失说明 SKILL.md 的工作流拆得不够细指令歧义说明某个动作词还带会让 AI 误解的空间输出格式漂移则说明你对格式的约束还不够硬。迭代的时候我倾向于“一次只改一个变量”。如果一次改了三处措辞结果变好了你根本不知道该归功于哪一处结果变差了你也不知道是谁拖了后腿。另一个心得是不要追求一步到位Skill 是越用越准的因为你会不断遇到新的边界情况这些都是迭代的素材。我那个前端体检 skill从第一版到稳定版改过十几次每次都是因为真实项目里碰到了新场景比如 monorepo 结构、微前端子应用、小程序工程然后我把这些场景的支持方式逐个补进 SKILL.md 里。这才是技能包开发的真实节奏——它不是写出来的是喂出来的。5. 实操中常见的坑和我现在的用法5.1 Skill 越来越臃肿职责单一原则新手开发 Skill 很容易犯一个毛病什么都想往里塞。今天加一个依赖检查明天加一个目录规范后天再塞一个性能分析最后整个 SKILL.md 膨胀到几千行模型每次执行光读完主文件就花掉大量上下文输出的稳定性反而直线下降。我现在的原则是一个 Skill 只解决一类任务职责越单一效果越稳。如果一个技能包开始覆盖多个不相关的检查项我会把它拆分成多个 Skill再用一个“总调度 Skill”去按需调用。拆分之后还有个额外好处可复用性大幅提升。比如我把“毒瘤配置检测”从“前端项目体检”里拆成独立 Skill 之后它不仅能用于体检还能用于每次合并请求的增量检查。社区里那些评分特别高的技能包你去拆解它的设计几乎都是小步聚焦、单点打透的思路。这也解释了为什么那些号称“万能合集”的技能包往往评价两极分化——放的东西越多单个任务上的表现就越平庸。5.2 上下文爆炸与 Prompt 冲突如何管控Skill 用多了之后会遇到另一个问题上下文不够用。尤其是你同时加载多个技能包的时候每个技能包都要占一段上下文来理解AI 的核心推理空间被挤压输出质量自然下降。我的做法是不做任务不加载让技能包变成“按需启用的工具”而不是“常驻内存的程序”。在大多数主流工具里模型都会先判断当前任务是否需要用到某个 Skill如果你发现它在该用的时候不用就用显式唤起的说方式来点名。Prompt 冲突是更隐蔽的坑。当你同时启用了多个技能包它们之间可能对同一件事给出不同的指令比如一个要求输出中文报告另一个的模板里全是英文标题AI 就会开始纠结听谁的。我的解决方案是建立优先级规则在每次任务的初始提示里清楚写明“以技能包 A 的要求为准技能包 B 仅作为参考”并且尽量让技能包的输出格式统一遵循同一套全局规范。这类冲突问题在“多 AI 协作”的场景里尤其明显——不同的 Skill 由不同的人开发风格和约束条件千差万别你必须在编排层做好规范和仲裁。5.3 多 AI 协作时的 Skill 复用问题最近“多 AI 协作”这个话题很热我也试过让多个智能体各带一个 Skill 一起完成一个复杂项目一个负责需求分析一个负责代码生成一个负责测试验证。理想很丰满现实很骨感。最大的问题在于每个智能体都只看到自己那个 Skill 的输出它无法理解上游的上下文。比如测试智能体拿到一份代码生成智能体的产物但它不知道原始需求是什么就会把没问题的代码判断成缺陷。后来我调整了策略每个 Skill 的输入输出都要求包含一段“关键上下文摘要”让下游智能体能快速对齐信息。另外一个很实用的经验是Skill 的输出格式最好设计成机器可读的结构。不需要多复杂只要保证各个智能体之间传递的数据能被程序化地解析就行。比如测试用例生成 Skill我让它最终输出一份 JSON 格式的测试概要同时附带一份人类可读的 Markdown 报告。这样下游的代码生成智能体可以直接读 JSON 来指导修复人类也可以直接看报告来了解整体状况。说白了Skill 的价值不仅在“单个 AI 干得更稳”更在于“多个 AI 之间能配合起来”但后者需要你在设计阶段就为跨系统协作留好接口。5.4 边界意识不是所有内容都适合做成 Skill最后说一个我越来越在意的问题边界。Skills 的本质是把“做事的方法”固化并分发这意味着它能让某些能力被大规模复用也能被滥用。我见过有人把绕过审核、钻平台漏洞之类的操作也做成技能包在私下流传这类东西不仅用起来风险极大而且技术上注定不长久——平台很快会识别并封堵更严重的是可能惹上合规问题。我的态度是涉及隐私数据、未授权访问、擦边内容或灰产思路的需求一律不要碰这不是保守这是基本的职业底线。合规边界之外还有一个使用边界也值得提醒Skill 是辅助不是替代。它帮你把重复劳动标准化但不能替代你对业务本身的理解。我见过朋友把一个代码审查 Skill 的输出直接发进项目群里结果里面好几条误报瞬间社死。Skill 输出再专业最终签字负责的仍然是你自己。所以我现在的要求是凡是 Skill 生成的报告我都会先花五分钟快速过一遍重点结论再决定是否对外使用。这五分钟不是浪费是给你的专业判断力留位置。这篇文章写到这里正好把我从“Skill 是什么”到“怎么用起来”的完整路径交代了一遍。开发自己的第一个 Skill 是一个分水岭——在那之前你只是一个使用者在那之后你才有资格说自己在用 AI 提炼经验。如果这篇对你有用下一篇我会把“如何设计一套完整的工作流”和“如何让 Skill 输出符合你的团队规范”展开来写那些才是真正拉开差距的地方。