前阵子团队接了个官网改版的需求设计稿给过来三张图色板、字重、间距的细节特别多。放在以前这种“图片还原成页面”的活儿我得手动量尺寸、取色、写样式大半天才能出个雏形。这次我在编辑器里给 AI 挂了一个专门的 design-to-code skill让它先分析设计规范再按模块输出结构四十分钟不到页面骨架就出来了而且色值和字号基本没跑偏。说实话第一次跑通的时候我自己也愣了一下。过去半年“skills”这个关键词在 AI 编程圈子里的热度蹭蹭往上走Claude Code、Codex、Cursor 这些主流工具几乎同时跟进类似能力社区里也冒出了大量开源 skills从学术研究辅助、数学建模到前端开发、PPT 生成覆盖面非常广。身边朋友问得最多的三个问题是skills 到底是什么它和普通提示词有什么区别我该怎么写出一个真正好用的 skill这篇文章我会用实际项目的视角把这些事一次讲清楚。不管你是刚开始接触 AI 编程助手的新手还是已经在用 Claude Code、Codex、Cursor 做日常开发的老手只要你想让自己的 AI 从“能聊天”变成“会干活”这篇内容应该都能给你一些可落地的参考。1. 一个“技能文件夹”引发的连锁反应Skills 是什么、为什么突然火起来1.1 从“会聊天的助手”到“有手艺的学徒”回想一下我们是怎么带新人的。通常不是丢一本厚厚的手册让他自己看而是给一份 SOP先做什么、再做什么、遇到什么情况怎么处理、哪些事情千万别碰。新人照着走很快就能上手。AI 编程助手以前的最大问题就在这里——每开一次新对话它都像一个忘性极大的新人同样的事情你说一遍它做一遍换个项目、换个会话又得重新调教。Skills 要解决的恰好就是这件事。它把“做某件事的完整方法”固化成文件AI 在遇到对应场景时自动按这套方法执行。我第一次意识到这个差别是在连续做了两周设计稿还原之后。之前每次都要跟 AI 重复一遍“先提取设计规范、再列组件清单、然后生成代码”烦到不行。后来我把这套流程写进一个 SKILL.md再丢设计稿过去AI 自己就知道该按什么顺序来甚至还会主动输出规范 JSON 让我确认。1.2 Skills 的本质可复用、可版本化的“行为包”从技术形态上看一个 skill 的最小单元就是一个目录加一个 Markdown 文件。目录里可以放说明、脚本、模板Markdown 文件告诉 AI“什么时候用我、用我的时候按什么步骤走、输出什么格式”。这个载体本身没什么黑魔法更像是给 AI 准备的“工作手册 工具箱”复合体。但它的核心价值在于三个特性可复用、可版本化、可分享。一次做得很好的项目经验沉淀成 skill 之后下一个项目直接复用团队里其他人 clone 下来也能获得同样的能力放进 GitHub就是一份面向全世界的交付物。这和传统意义上“写提示词”有本质区别——一段提示词是对话里的临时产物而一个 skill 是经过设计、测试、维护的长期资产。1.3 为什么各大工具和社区都在押注 SkillsClaude Code 把这类能力叫做 Agent Skills官方给了一套基于 SKILL.md 的规范Codex 和 Cursor 也陆续推出了自己的类似设计社区里像宝玉baoyu的开源 skills 集合、mattpocock 的 skills 项目还有一大堆“superpower skills”风格的合集都在拼命往这个方向堆料。吴恩达也专门做过 agent skills 相关的分享把“针对特定任务给 AI 装配专项能力”这个概念推到了更多人面前。我个人的判断是这波热度背后其实是 AI 编程路线的一个共识转移大家都在从“追求模型聊天能力”转向“追求模型在真实工作流中的稳定交付”。聊天再强一次任务要反复纠正十次那也只是个玩具Skills 恰好就是“稳定交付”的基础设施之一。它不是某个工具的专属功能而是整个生态逐渐收敛出来的通用抽象。2. 拆开一个 Skill 的骨架SKILL.md、目录结构与依赖声明2.1 最小目录结构先看一个能跑通的最简结构my-skill/ ├── SKILL.md └── scripts/ └── helper.pySKILL.md 是入口AI 会通过它了解这个 skill 的用途、步骤和输出格式。scripts 目录是可选的支持脚本当任务需要计算、文件解析、调用接口时用得上。再复杂一点的还可以有 assets/ 放模板文件、references/ 放参考资料。但我个人的经验是保持简单是王道。大多数场景一个 SKILL.md 加一两个脚本就够了目录层级越深AI 找文件、读文件的开销越大反而容易出错。2.2 frontmatter 里那两个关键字段填错一个就白搭SKILL.md 的开头是 YAML 格式的 frontmatter最核心的就是 name 和 description--- name: design-to-code description: 当用户上传设计稿图片、Figma 截图或手绘草图并希望生成前端代码时使用。 ---name 是唯一标识一般用短横线命名法。description 是触发条件也是最大的坑。很多人把它当功能介绍来写比如“将图片转换为代码”结果 AI 在用户说“把这个图做成页面”的时候反而不触发。正确的写法是描述“什么场景下、用户说了什么、出现什么信号时应该调用这个 skill”——把触发条件写在 description 里而不是把功能堆在里面。字段作用填写建议name技能的唯一标识短横线命名如 design-to-codedescription决定 AI 何时加载写触发条件和用户信号别写功能介绍不同工具对 frontmatter 的支持略有差异有的还支持 metadata、allowed-tools 等扩展字段但 name 和 description 是通用底线先把这两个填对再考虑其他。2.3 正文把“经验”翻译成“可执行步骤”frontmatter 下面是正文这是 skill 真正干活的地方。我总结了一套比较稳的结构目标、步骤、输出格式、约束、示例。目标告诉 AI 这个 skill 要达成什么步骤给三到五个明确动作每个动作一句话说清楚输出格式保证结果形态稳定约束写清楚什么不能做示例给一个简化版的输入输出对照。这种结构之所以有效是因为 AI 对“结构化指令”的遵循率明显高于“自由描述”。你让它“好好处理这个图片”它不知道什么叫好好但你告诉它“第一步提取色板第二步输出 JSON第三步生成代码”它就能稳定地执行。整套指令本质上是在模拟一个老师傅带徒弟时的口述要点只是把口述变成了白纸黑字的文档。2.4 脚本与依赖当纯文字不够用的时候有些 skill 光靠提示词没法完成。举个例子一个做网页资料收集的 skillAI 本身没法“打开网页”你需要给它一个 fetch 脚本一个做数据分析的 skill可能要让 AI 调用 Python 来算回归。这种时候就需要把脚本放在 scripts/ 目录并在 SKILL.md 里明确写明“当需要抓取网页时运行 scripts/fetch_page.py 并读取输出”。这里的坑在于脚本的输出一定要结构化。最好是 JSON或者条理清晰的 Markdown否则 AI 解析起来费劲后面流程就走不稳。另一个坑是脚本自身要健壮AI 不会像人一样帮你处理“参数传错了”这种问题脚本得自己兜住异常比如网络超时重试、非法输入返回错误提示否则流程会突然断掉。3. 从零开发一个自己的 Skill以“设计稿还原前端页面”为例3.1 场景选择小而专是 Skill 的生存法则不是所有任务都适合做成 skill。我选场景有三个标准高频出现、步骤明确、结果可验证。设计稿还原完全符合——高频是因为前端开发几乎天天碰步骤明确是因为“提取规范、列组件、生成代码”是可以固化的结果可验证是因为页面出来之后一眼就能看出像不像。反过来像“帮我看看这段代码有没有问题”这种任务就不适合做成 skill因为它太宽泛每次失败的原因都不一样没法用固定步骤去约束。想做 skill 的朋友我建议先从自己工作中重复次数最多的那个场景下手哪怕小一点都无所谓。一个小而精的 skill比一个什么都想管、什么都管不好的 skill 有用得多。3.2 编写 SKILL.md从设计规范到代码生成的完整链路我当时创建的 skill 长这样。你也可以直接拿这个例子做模板替换成自己的工作流--- name: design-to-code description: 用户上传设计图片、Figma 截图或手绘草图并希望生成前端页面/组件时使用。 --- # 设计稿还原前端页面 ## 第一步解读设计意图 先看图判断是整页、模块还是组件识别整体布局方式。 ## 第二步提取设计规范 输出 JSON包含 { colors: {}, typography: {}, spacing: {}, borderRadius: 0, shadows: {} } 从图片中实际提取不要臆造。 ## 第三步确认疑问 如果图片里某处看不清楚列出问题不要猜测。 ## 第四步编码实现 - 使用 HTML Tailwind - 语义化标签 - 移动端优先断点适配 - hover 态、焦点态尽量合理补齐 ## 第五步自检与说明 对照原图检查偏差输出实现说明。注意我在步骤里用了“不要臆造”“不要猜测”这类负面约束。这非常关键。模型生成本身带有很强的“补全倾向”你不约束它它就会自己脑补色值和间距。加了负面约束之后输出质量会明显上一个台阶。3.3 测试闭环跑通一次之后先别急着高兴写完 SKILL.md 只是开始。把它放到工具对应的 skills 目录下让 AI 重新加载后拿真实设计稿测三轮观察三件事一是 description 是否被正确触发。我第一次写的时候description 用的是英文“design to code”测试时用中文对话结果 AI 完全没有加载这个 skill。把 description 改成中英双语后命中率立刻上来了。这可能跟工具底层的匹配算法有关但结论是一致的description 的语言和用户实际对话语言最好保持一致。二是步骤是否完整走完。AI 有时会在生成代码阶段忘记前面提取的规范解决办法是让它在第二步就把 JSON“钉”在对话里后续每生成一个模块都对照这个 JSON。把关键信息显式放在上下文里比依靠 AI 的长期记忆靠谱得多。三是输出是否符合预期格式。如果 AI 每次输出的页面结构都不一样说明 SKILL.md 里的输出格式约束还不够具体。这时候就得把示例写得更详细甚至在正文里写清楚“图片用占位符并标注尺寸”。3.4 发布与分享让一个 Skill 跨项目复用测试稳定之后我会把项目里通用的部分提炼成独立仓库。命名用短横线小写README 里写清楚适用场景、安装路径和示例。团队协作时用 git 管理这些 skills成员 clone 下来放到本地统一目录就能用这比在聊天记录里翻找提示词靠谱多了。版本管理也很实用。每次改进 skill 之后打个 tag比如 v1.1.0项目里固定引用某个版本就不会出现“昨天还好好的今天怎么不行了”的玄学问题。我自己的习惯是每个 skill 一个仓库或者至少一个独立的子目录方便单独做版本演进和文档维护。4. Skills 与 MCP 组合拳让“会做事”变成“能做成事”4.1 Skill 负责方法MCP 负责通路如果只把 Skills 当成一个“高级提示词包”那就浪费了。真正好用的场景是 Skills 和 MCP 配合起来。Skill 解决“知道怎么做”MCP 解决“能做到”——比如做网页资料调研AI 哪怕方法论再清晰没有联网搜索和网页抓取的能力也没法把资料拿到手。MCP 就是给 AI 接上外部工具的通道搜索、读网页、调数据库、操作文件、发请求都能通过 MCP server 暴露给 AI。这两者的关系有点像“工具箱”和“操作手册”MCP 提供工具Skills 告诉 AI 怎么用手里的工具完成一件完整的事。只装 MCP 不给方法AI 拿到一堆工具不知道组合只写 Skill 不接 MCP方法再完善也拿不到外部信息。4.2 在 SKILL.md 里声明 MCP 工具的两种方式一种是在正文里直接写明工具名称让 AI 按需调用。比如--- name: web-researcher description: 用户需要收集最新网络资料、对比多个来源、生成调研摘要时使用。 --- # 调研助手 ## 行为准则 - 当需要实时信息时调用 search_web 查询关键词。 - 读取具体网页时调用 fetch_url 获取页面内容。 - 某个页面访问失败时换一个来源继续不得编造内容。 - 所有信息整理为结构化 Markdown 报告包含标题、来源链接、关键结论。另一种是在 skill 的配置里声明依赖的 MCP server具体字段不同工具不太一样但本质都是“让 AI 在加载这个 skill 时自动知道可用哪些外部工具”。我一般两种结合着用配置里声明依赖正文里再把工具的使用规则写清楚特别是“什么时候用、什么时候不用”。4.3 实测效果与几个绕不开的坑我用这个方法做过一次竞品行情调研一个 web-researcher skill配合搜索和抓取类 MCP 工具让 AI 搜索多个关键词、抓取竞品页面、汇总成对比表格。整体体验很顺但有几个坑值得拿出来说。工具返回内容过长会把上下文撑爆。第一次让它搜索十个关键词每个关键词返回五十条结果AI 还没开始整理上下文就满了。后来我在 skill 里加了限制“每条搜索结果只保留标题、来源、发布时间不保存完整摘要”问题立刻缓解。另一个坑是不同 MCP 工具的返回结构不统一skill 里不要硬编码工具名而是让 AI“根据已加载的 MCP 工具列表灵活选择”这样换一套 MCP 环境也能跑。还要特别强调一点凡是涉及安全评估、数据采集类的 skill使用前必须确保自己拥有明确的授权。技术能力归能力使用边界归使用边界这个底线不能碰也完全没必要碰。5. 踩坑实录Skills、Rules、插件、子Agent的边界到底在哪5.1 症状一Skill 加载了AI 却不照着做这是最让人抓狂的问题。加载是加载了但 AI 做出的东西完全没按 SKILL.md 里的步骤走。我排查过几次原因通常有三种description 触发条件写得模棱两可AI 拿不准这个 skill 是不是适用于当前任务SKILL.md 正文指令本身模糊比如“请认真处理”这种话AI 不知道怎么执行还有一种情况是用户当前指令和 skill 步骤冲突AI 优先听了用户的。排查方法很简单直接在对话里问 AI“你当前加载了哪些 skill”或者在工具界面查看已加载列表。确认加载了之后再让它逐条复述 SKILL.md 里的步骤看看它的理解和实际内容有没有偏差。绝大多数时候问题都出在指令写得不够具体而不是 AI 故意不听话。5.2 症状二Rules 和 Skills 打架听谁的Rules 是常驻上下文的全局约束Skills 是按需加载的专项流程两个同时在场的时候冲突在所难免。比如项目 Rules 里写了“所有页面必须用 Vue 实现”但设计稿还原 skill 的示例代码全是 HTML TailwindAI 到底听谁的实测下来的行为是AI 会优先遵守 Rules因为它在每一轮对话中都存在权重天然更高。这不是 bug反而是一个可以依赖的机制。我的处理原则是把项目级硬性规范放 Rules把“做某件事的流程”放 Skills。Skills 里不要再写和 Rules 冲突的硬性规定而是写“遵循项目现有技术栈和代码规范”。这样两层机制各管一摊互不干扰。5.3 症状三装了一堆 SkillsAI 反而变笨了还有一个高频问题看到推荐就装装了几十个 skill结果 AI 反应变慢、输出质量下降。原因很简单skill 被触发时会向上下文注入内容装得越多、触发越频繁上下文被占用的比例就越高真正留给任务本身的注意力自然变少。这个问题的解法很朴素按项目维护 skills而不是搞一个全局大杂烩。做前端项目就只挂前端相关的 skill做数学建模就只挂建模相关的 skill。不同的工具有不同的配置方式但思路一样——让当前项目能用到的 skill 保持在 3~5 个之内质量远大于数量。5.4 我用下来的边界判断标准机制加载方式适用场景典型例子Rules常驻上下文全局/项目硬约束代码风格、提交规范、安全红线Skills按需触发特定任务的执行流程设计稿还原、调研、数学建模MCP按需调用外部数据/工具操作搜索、数据库、API 调用插件/子 Agent按需调度复杂自动化工作流自动化测试流水线、多步骤 Agent这几类机制不是互斥的是配合关系。Rules 划定边界Skills 提供方法MCP 接入工具插件和子 Agent 负责更复杂的编排。没有哪一个能包打天下把一个机制用到极致不如把四个机制组合起来形成一条完整链路。6. 从使用者到创作者Skills 开发与选用中的几点心得6.1 让 Skill 质量明显提升的五个撰写技巧我踩过不少坑之后总结出五个比较实用的技巧一是 description 写触发条件不写功能介绍。用“当用户…时”“如果…就…”的句式命中率会高很多。二是步骤控制在五个以内每步指令一句话。太长的步骤会让 AI 在生成长代码时丢掉前面的环节步骤短一点每一步完成度都会更高。三是输出格式一定要给最好给出模板。哪怕是“输出 JSON 格式包含 name、price、description 三个字段”也比只说“整理一下”强出十倍。四是加负面约束。告诉 AI“不要臆造数据”“不要漏掉移动端”“不要修改原有代码”比只说“认真做”管用得多。五是给一个最小的示例。示例不用完整但要能体现输入输出对照让 AI 知道终点长什么样。6.2 哪些场景值得做哪些场景别碰就目前的生态来看值得做成 skill 的场景有几个共同点重复性高、流程相对固定、有明显验收标准。前端设计稿还原、PPT 生成、数学建模、学术研究资料整理、测试用例生成、网页资料收集这些都很适合。社区里也有大量现成实现可以直接参考。不太适合做的是三分钟就能说完的一次性临时任务还有那种过于宽泛的目标比如“帮我做产品经理”。另外涉及大量外部不可控资源、需求天天变的任务也不适合固化——你今天写的步骤下周可能就完全失效了维护成本远远超过收益。6.3 最后一点忠告Skill 也要管好供应链安全现在网上的“skills 推荐”帖子已经非常多了但我要提醒一句不要盲目把别人做的 skill 全部装进自己的环境。Skill 本质上是一段会操控 AI 行为的指令来源不明的 skill 有可能包含不安全的内容比如诱导 AI 读取敏感文件、执行危险命令、把对话内容外传。这和我们平时装开源依赖时的“供应链安全”意识是同一个道理。我自己的做法是只安装可信来源的 skill装之前一定打开 SKILL.md 完整读一遍确认每一步都是自己能理解的。版本更新之后也 diff 一下改动内容再决定要不要升级。安全底线靠自觉等出了问题再补救代价就大了。最后再分享一个小技巧用 git 管理你的 skills 文件夹。每次修改 SKILL.md提交信息里写清楚改了哪个触发词、哪个步骤、效果如何。坚持一个月你会看到自己的 skill 是怎么一步步变好的——这种积累的复利比追任何一个新工具的更新都值。