最近一年我深度依赖AI编程助手干活从日常写代码到做技术方案、分析项目、整理学术资料几乎每天都在和各种Agent工具打交道。用久了你会发现一个明显的分水岭刚上手的人把AI当聊天框敲一句话让它“写个页面”“分析下项目”用得久的人会把AI当成一个可以不断培养的“实习生”给它配工作手册、配专用工具、配操作流程而实现这一整套配置的核心载体就是Skills。Skills这个概念的走红和Claude Code、Codex、OpenCode这些AI编程工具近期的快速发展密切相关。你可能已经刷到过类似的帖子有人晒出“让Claude自动做PPT”的Skills有人分享“把设计稿一键还原成前端页面”的Skills还有人弄出了“自动做数学建模”的Skills。乍一听像是魔法实际上拆开看就是一套有结构的配置包。这篇文章我用自己的实践经历来讲透这件事Skills到底是什么为什么值得你花时间研究以及最关键的——从零到一怎么写一个属于自己的、真正能被AI稳定复用的Skills中间哪些坑我替你踩过了。1. 先搞清楚Skills的本质不是提示词也不是插件1.1 用一个实习生类比理解Skills的运作逻辑我每次给朋友解释Skills的时候都喜欢用带实习生的场景来类比。假设你招了一个基础扎实但没什么行业经验的助理你希望他帮你完成“每周竞品分析”这件事。你会怎么做大概率不是每天重复告诉他“你要去查网站、整理数据、写报告、注意排版”而是会给他一份操作手册查哪些网站、数据指标怎么定义、报告按什么结构写、格式有什么要求再顺手给他几个模板和案例。等他把这套手册吃透了下次你说一句“这周竞品分析照常做”他就能把事情办得漂漂亮亮。Skills之于AI编程助手就是这份操作手册加配套工具。它不只是几句提示词而是一个结构化的能力包里面通常包含描述文件、参考资料、模板、脚本等。AI在执行对应任务时会先加载这个能力包按里面的流程和规范来行动。这和你临时在对话框里敲一大段Prompt有本质区别临时Prompt是一次性的丢失了就不存在了Skills是持久化的一次写好反复调用还能分享给其他人和项目复用。从实现机制上看Skills做的事情就是给模型提供一套“高质量的前置上下文”。模型本身的知识和能力没有被改变但因为它拿到了你精心整理过的流程、标准和工具它的输出质量和稳定性会明显提高。这也是为什么同样用GPT或Claude有的人用得像普通问答有的人能折腾出稳定的自动化工作流核心差异往往就在这里。1.2 Skills、Prompt和MCP工具的正确分工很多人第一次接触Skills时会把它和Prompt、MCP工具混为一谈。我需要把这三者的关系理清楚。Prompt是“一次性的指令”你问什么它答什么。优点是没有学习成本缺点是不稳定、不持久。今天这个说法效果好明天换个场景又不灵了。MCPModel Context Protocol解决的是“AI能调用哪些外部工具”的问题它相当于给AI接上了外部的手和脚。比如通过MCPAI可以去读写本地文件、查询数据库、调用浏览器、操作GitHub。注意MCP本身不告诉AI“你要按什么步骤做这件事”它只是提供能力接口。Skills则介于两者之间它解决的是“AI面对一类任务时应该按什么方法和流程来做”的问题。Skills里面可以写指令、写规范、写判断规则也可以引用脚本、模板等参考文件甚至可以通过MCP工具去操作外部系统。简单说Prompt是你说的一句话MCP是AI的手和脚Skills是AI的岗位说明书。三者可以配合使用但并不相同。从我实际使用来看最适合把三者组合起来的场景是这样的Skills定义任务流程并在步骤中要求AI“如果需要获取实时数据调用MCP的浏览器工具去搜索”Prompt只负责触发任务和补充临时要求。三层各司其职整个工作才会像一个稳定的系统而不是每一次都靠模型临场发挥。2. 动手前先想清楚什么样的任务适合写成Skills2.1 判断任务是否值得做成Skills的三个标准并不是所有任务都值得做成Skills。我见过一些人把自己所有日常需求都封装成Skills结果维护成本比收益还高。根据我自己的经验判断一个任务是否适合写成Skills至少要满足三个标准。第一任务要高频。如果你一个月才做一次的事临时写Prompt就够了没必要投入时间去结构化。反过来那些你每周甚至每天都要处理的事务性工作就非常值得沉淀成Skills。比如我每周要给团队输出项目周报这个流程很固定我就专门做了一个周报Skills从项目信息拉取、进度整理到风险提示、格式渲染全部自动化。第二流程要相对固定。Skills发挥作用的前提是“这件事有稳定的标准做法”。如果每次任务的需求都完全不同、没有通用套路那Skills能提供的帮助就有限。比如“帮我想创业点子”这种事太发散不适合但“帮我做一份竞品功能对比表”就有非常清晰的步骤和产出标准很适合。第三任务需要专业知识和细节经验。这是Skills价值最大的场景。一个前端新人需要琢磨很久的设计稿还原流程对资深前端来说可能就是一套固定的思维习惯先看布局层级、再抽设计变量、然后写结构、最后调交互。把这套经验写进Skills里相当于把老师傅的隐性知识显性化了AI直接继承这份经验输出自然上一个台阶。满足这三个标准的任务做成Skills就是正向收益。如果某个任务只是偶尔做做、流程混乱、又不需要专业积累那还是保持临时Prompt简单处理就好。2.2 先写流程草稿再考虑技术实现很多新手开发Skills最容易犯的错是一上来就写配置文件、设计目录结构结果写了半天发现SKILL.md描述不精准AI根本不认。正确顺序是反过来的先抛开技术用纸笔把“一个专家是怎么办这件事的”完整写下来。拿“图片还原为前端页面”这个Skills来说。我在动手之前先把自己平时做设计稿还原的流程完整复盘了一遍草稿大概是这样的第一步观察整体布局结构判断是上下布局、左右布局还是混合布局第二步确定色彩系统从图中提取主色、辅色、背景色第三步分析字体和间距判断字号层级和间距规律第四步把页面切成模块从顶部导航栏到页脚逐个实现第五步补充响应式适配和交互动效。这五步就是整个Skills的核心逻辑。写好了流程草稿封装只是时间问题。因为AI模型本身已经具备代码生成能力真正稀缺的是这套“专家思路”。Skills本质上是在把专家的思考过程标准化、模块化然后交给模型去执行。所以我建议所有想开发Skills的人第一件事不要安装任何工具先坐下来拿出一张纸把你最擅长的事情一步步写出来。这一步做得越细最后的效果越好。2.3 Skills目录设计与元信息配置的常见约定不同AI工具对Skills的目录规范略有差别但大体结构是共通的。以我大量使用的Claude Code为例一个典型的Skills目录是这样的~/.claude/skills/ design-to-code/ SKILL.md references/ design-tokens.md component-patterns.md scripts/ extract-colors.pySKILL.md是Skills的灵魂里面写清技能名称、适用场景和完整操作流程。references目录放参考资料比如设计变量规范、组件模式示例AI在执行时可以根据需要查阅。scripts目录放辅助脚本比如从图片里提取配色、计算布局参数之类的自动化脚本。这里有个很关键的细节SKILL.md开头通常会有一段YAML格式的元信息包括name、description、keywords等字段。description尤其重要因为AI决定是否调用这个Skills主要就是看你在任务描述里提到的信息和Skills的description是否匹配。很多人的Skills写得很好但AI不调用问题往往就出在description写得太狭隘比如只写了“处理图片”但用户真实需求是“把设计稿还原成页面”匹配度不够自然就不会触发。我一般会在description里尽量多覆盖同义表达和典型场景把前端、UI、设计稿、切图、页面实现这些词都铺进去调用率立刻就有明显变化。3. 一个完整的实战从设计稿到前端页面的Skills是怎么写出来的3.1 先搭框架让AI先看全貌再动手为了让这套东西讲得更具体我拿自己写过的“设计稿还原”Skills当例子完整拆开给你看。先展示一下SKILL.md的大致内容结构开头是元信息和整体说明--- name: design-to-code description: 将UI设计稿图片格式转换成可直接运行的前端页面代码。适用于设计稿还原、切图、前端页面实现、UI转代码等场景。 keywords: 设计稿, UI, 前端, 切图, 页面实现, 还原 --- # Design to Code 将一张或多张UI设计稿图片转换为高质量前端页面。在执行前先检查输入图片是否存在。 ## 工作流程 ### 第1步审视设计稿理解整体布局 先仔细查看设计稿判断页面整体结构。输出一段布局分析包括 - 页面整体是上下、左右还是混合布局 - 包含哪些主要区块区块之间的层级关系 - 桌面端、移动端适配的初步判断看到这里你可能感觉到了SKILL.md不像普通Prompt那样只有一句话要求而是一个带步骤、带输出要求、带判断逻辑的作业指导书。为什么要这样设计因为模型处理复杂任务时如果直接让它“写页面”它很容易跳过分析、直接上手写代码结果页面结构和设计稿差得很远。但如果强制它在代码生成前先输出布局分析和设计规范它就能像真人前端一样先建立全局认知再动手最终还原度会明显提升。3.2 把专业知识写进参考文件光有流程还不够我还发现一个规律设计稿还原类任务最怕AI“自由发挥”。同一个页面不同AI可能给出完全不同的实现方案有的用Flexbox有的用Grid有的盒模型处理得很怪异。为了统一输出质量我倾向于在references目录里放一份“组件规范”文件把页面中常见元素的做法固定下来。比如我会这样写组件模式文档按钮组件基础样式用内边距加大圆角主要按钮用主题色填充次要按钮用描边风格导航栏组件固定顶部、背景半透明白、内容区最大宽度1200px居中卡片组件圆角16px、阴影浅色柔和、图片占位符合设计稿比例。这些看起来都是很基础的CSS常识但对模型来说却是重要的“上下文锚点”能让它把某些默认行为稳定下来不会这一版写成圆角按钮、下一版又切成直角。为什么这么做有用因为模型在生成代码时有很多种“正确”的写法但项目里真正需要的是“一致性”。参考文件的价值不是教模型写代码而是帮它在诸多正确方案里选出一个和你项目风格最匹配的方案。这一步往往是网络上那些“神级Skills”看起来特别聪明的原因之一它不只是能用而是用得对、用得稳。3.3 用脚本接管模型不擅长的计算设计稿还原还有一个非常实际的问题从图片里精确提取颜色值、计算间距、识别字体大小。虽然多模态模型能大概描述图片里的颜色但“这个蓝色到底是#3B82F6还是#3B83F7”这种精度模型做不到。这时候就需要外部脚本来补位。我在skills目录里放了一个Python脚本用来做两件事第一读取设计稿图片用算法提取出现频率最高的十几个颜色并换算成HEX值第二对图片做简单的色块分布分析辅助判断页面的色彩区块布局。SKILL.md里的流程会明确要求AI先运行脚本提取颜色再基于提取结果写CSS变量而不是靠肉眼猜。这个设计思路可以推广到所有Skills开发中凡是模型不擅长、但可以用确定性代码解决的问题都应该交给脚本。模型的价值在于理解和决策脚本的价值在于精确计算两者搭配才能发挥最大效果。我见过有人让AI自己计算复杂公式结果翻车的概率很高这类脏活累活交给代码去完成才是正道。3.4 测试迭代没有哪个Skills一次就完美开发完一个Skills之后最危险的想法是“终于写完了”。我自己的经验是Skills的开发和代码开发一样必须经历多轮验证和迭代。第一版往往存在明显问题可能是AI压根不触发这个Skills也可能是推理过程冗长、输出结构不符合预期还可能是某些特殊情况没考虑到。我的测试方法很简单用三个不同难度的真实任务去压测。第一个任务是最简单的比如还原一个单卡片设计的移动端页面第二个任务复杂度中等加上了导航栏、Hero区和多卡片模块第三个任务是极端场景比如设计稿包含深色模式、异形布局或大量图形装饰。每轮测试后我会记录两个关键指标AI是否稳定调用Skills输出结果是否符合预期质量。有问题就回到SKILL.md里调流程描述、操作顺序或者扩充参考文件、增加判断规则。有一件事我特别想提醒很多人遇到效果不好第一反应是重写整个SKILL.md这通常是最低效的做法。更合理的思路是像调代码一样做小步修改、逐步逼近每次只改一个变量。比如这次只调description扩大触发范围下次只补充一个特例说明再下次修改参考文件里的特定样式。这样你能准确知道是哪个改动起了作用而不是在一次大改之后效果变好了却不知道为什么。4. 高频场景解析前端、项目分析、数学建模、学术研究全覆盖4.1 前端场景不只是设计稿还原还有代码审计与重构网上讨论最多的前端Skills基本都围绕“设计稿还原”但前端场景的想象空间远不止这个。我自己日常更常用的是“前端代码审计Skills”和“组件库规范Skills”。代码审计Skills的核心逻辑是让AI带着一份“问题检查清单”去审代码。清单里包括性能方面有没有重复渲染、不合理的依赖项可维护性方面组件是否足够单一职责、命名是否规范兼容性方面有没有使用过新的API且没有降级处理。这种Skills写起来不难核心就是把有经验的工程师在Code Review时脑子里自动跑的那些规则一条条显式地写出来。效果非常惊人AI能像资深同事一样指出代码里的潜在问题而不是泛泛地夸一句“代码写得很清晰”。对于团队开发者来说我强烈建议做一个“团队组件规范Skills”。把你们团队的设计变量、组件用法、代码风格要求全部整理进去然后让AI在生成代码前先查这个规范再动手。这样一来AI生成的代码会天然贴合团队风格代码审查阶段的返工会少很多。4.2 项目分析场景把模糊需求变成结构化报告另一个我觉得特别实用的是“项目分析Skills”这正是搜索热词里“codex 分析项目的 skills”指向的需求。当一个项目丢给你的时候最怕的就是盲目乱翻代码。一个成熟开发者会按逻辑顺序去了解项目而Skills可以固化这套顺序。我写过一个项目分析Skills核心流程是这样的第一步扫描项目根目录查看package.json、README、配置文件快速判断技术栈第二步梳理目录结构按入口、路由、组件、状态管理、工具函数归类第三步追踪核心数据流搞清楚请求从哪里发出、数据经过哪些处理、最终渲染在哪个组件最后输出一份包含架构图描述、核心模块说明、潜在风险点的分析报告。做这个Skills时我会刻意在流程里加一个要求每分析一个模块都要标注“这个文件负责解决什么问题如果删掉它会发生什么”。这个视角能帮助AI抓住项目的关键路径而不是在细枝末节里打转。项目分析类Skills调试好了之后几乎可以一键完成原先几小时的代码勘探工作。4.3 数学建模与学术研究用Skills固化专家思维从搜索热词里能看到很多人对“数学建模skills”和“academic research skills”非常感兴趣。这类Skills的核心价值是把高水平学者或参赛选手的解题方法论写进去供模型复制。以数学建模为例一条成熟的解题路径包括问题解读、选择合适的模型类型、假设条件设定、模型建立、求解与验证、结果分析与灵敏度测试、论文撰写。这些步骤之间是存在强依赖关系的跳过任何一环都可能导致后面失控。如果把完整的解题流程写进Skills同时把线性回归、时间序列、优化模型、机器学习等算法选型条件整理成决策树放进参考文件模型在面对建模问题时就不再是“随机选择一个模型”而是先分析问题特点再匹配最合适的方法。尤其在校学生做数模竞赛时这个Skills能把大量时间从折腾模型选择中解放出来让人把精力集中在问题定义和论文表达上。学术研究类Skills我同样做了不少。我建了一个文献综述Skills流程固定为确认研究主题与检索词拆解关键概念检索相关文献按主题/方法/结论对文献分类提炼研究脉络与空白点生成综述初稿。每一步都有明确的输出格式比如文献分类表要包含作者、年份、研究方法、核心发现、局限与可拓展方向。模型执行这套流程时产出的综述脉络会比直接让它“写个综述”清晰很多。4.4 场景选择提醒有些方向不要碰热门搜索词里也出现了“渗透测试skills”这类方向。这里我要非常认真地说一句网络安全技术在合规的授权测试和防御研究中有正面价值但具体到渗透测试类的“技能包”很容易触及法律和安全红线。如果你不是在企业授权范围内做安全评估不要盲目开发、下载或使用这类Skills。网络上的所谓“黑客skills包”来源不明、行为不可控轻则是无效占资源重则可能让你惹上不必要的麻烦。这个方向我建议所有读者直接避开不是技术问题是底线问题。5. 常见问题与排查技巧实录5.1 AI就是不调用Skills怎么办我遇到过最多的场景就是Skills已经建好了路径也没问题但AI就是视而不见继续按普通方式回答任务。这个问题排查起来先不要怪模型大多数情况下是Skills本身的“触发条件”设计得不够好。排查顺序我建议是这样的。第一步检查SKILL.md的name和description是否与用户真实语言匹配。比如用户说的是“帮我看看这个页面效果图”而你Skills里只写了“design to code”这个英文名字、description里也只有英文术语那很多情况下AI确实无法建立关联。解决办法是让description覆盖尽可能多的同义表达。第二步检查Skills是否在工具支持范围的路径中。如果你用的工具不读取这个目录或者目录结构不完整AI根本看不到这个Skills当然不会调用。第三步考虑显式引导。在任务的Prompt里直接写“使用design-to-code技能处理”让AI明确感知到该调用哪个技能。这虽然看起来不够“智能”但实际工作里是最有效的兜底方案。5.2 触发了Skills但输出不稳定、效果时好时坏Skills被触发之后效果不稳定的情况也很常见。问题的根源往往在于SKILL.md中的步骤不够明确模型在多个“可行解”之间随机选择结果每次输出都会漂移。解决思路是尽量把抽象要求变成具体的输出约束。与其写“分析页面整体布局”不如写“输出页面布局结构按区块顺序用列表描述每个区块标明功能和视觉特点”与其写“保持代码风格一致”不如在参考文件里给出两三个标准代码片段让模型照着写。再有一个好用的技巧是让AI在正式执行前先输出“执行计划”相当于让它在动手之前先展示自己对流程的理解一旦计划和预期不符你可以及时纠正而不是等它生成了完整代码才发现方向跑偏。5.3 多个Skills之间互相冲突、上下文互相污染当你的Skills数量多起来之后会出现新的问题某些任务同时匹配多个Skills的描述AI不知道选哪个或者把多个Skills的内容全部加载进来导致上下文混乱、指令冲突。这个问题的本质是Skills的职责边界没有划清楚。我的解决方法有两个。第一在description里写清“适用边界”明确排除不适合的场景比如项目分析Skills的描述末尾加一句“本技能用于已有代码项目分析不用于编写新功能模块”这样能减少误触发。第二把有相关性的Skills设计成分层调用关系。比如一个“周报Skills”中可以引用“项目分析Skills”的输出结果两个Skills之间通过中间产物衔接而不是互相竞争同一段上下文。层与层之间职责清晰整个Skills体系才能像软件工程里的模块一样低耦合、高内聚。6. 开发Skills的进阶技巧从够用走向好用6.1 少追求一次到位的“完美”提示词多构建可演进的小系统我见到很多人在开发Skills时特别喜欢一次性写一份非常长的SKILL.md恨不得把所有情况都覆盖到。这种行为带来的结果是文档太长、模型抓不住重点、执行时逻辑混乱。我的观点是优秀的Skills更像一个小系统小步快跑、迭代演进。初始版本只要覆盖核心流程和最低限度的输出规范就行跑通一个端到端流程后再根据失败的案例逐步补充规则。比如前端代码审计Skills第一版只需要“性能、可维护性、兼容性”三个维度的检查清单跑通之后再根据实际项目里的典型问题逐步增加安全检查、依赖大小检查等新维度。每次只增加一到两条规则保证文档始终精练模型执行时的负担也更小。6.2 用子目录和命名让Skills可以被搜索和理解当你积累了几十个Skills之后命名规范和目录组织就变得很重要。我自己的习惯是采用“功能领域-动作”的命名模式design-to-code、project-analysis、weekly-report、literature-review。这样在对话里提到“分析项目”“周报”“文献综述”时模型能大概率精确匹配。另外我习惯在SKILL.md的最前面加一个“When to Use”小节明确说明这个技能适合什么场景、不适合什么场景。这不是为了给人类看而是给模型看的。因为模型在决定是否调用时会综合description和文档开头的内容做判断一行清晰的适用边界能大幅减少错误触发。6.3 社区与官方文档不要重复造轮子最后给个建议开发Skills之前先去看看社区里已经有的成果。GitHub上有不少知名的Skills集合仓库比如有人整理了几十个常用技能包Claude Code和Codex的官方文档里也有详细的编写规范吴恩达团队也发布过专门的Agent Skills教程里面提到了一套很系统的技能包设计方法论。站在这些基础上做二次开发比从零开始要高效得多。借鉴社区资源时我的做法是先用现成的Skills跑一个测试任务观察它哪里好用、哪里不顺手然后只改造需要改进的部分。很多人懒得做这一步拿了一份Skill就无脑用结果发现和自己的工作流不匹配最后得出结论“Skills没用”。实际上问题不在Skills本身而在于没有做适配这步不可省略的工作。最后再分享一个实操心得折腾了这么久的Skills我自己最大的体会是Skills真正的价值不在于“让AI多做一件事”而在于“让AI稳定地做好一件事”。临时Prompt能解决一次性的问题但无法积累今天是这个质量、明天是那个水平Skills则是一种沉淀把零散的实操经验变成可复用、可持续迭代的资产。开发和优化Skills这件事很像早期做前端时沉淀自己的组件库、工具函数库前期投入的时间和精力到了后期会以极高的回报率回到你身上。如果你现在还没碰过Skills我的建议很简单从你日常最高频、最容易标准化的一项工作开始按照我前面说的流程先写专家步骤、再搭目录结构、再做第一版SKILL.md然后拿真实任务去压测迭代。两周之后再回头看你大概率会发现自己已经回不到“裸用Prompt”的状态了。这套东西用起来有一种很强的上瘾感因为它真正跑通了“经验自动化”这条路。