1. 为什么“AI Skills”突然成了前端圈的热词1.1 AI Skills 到底是什么先别急着记概念我想请你回想一个场景你在 Cursor 或者 Codebuddy 里让 AI 帮你写一个 Vue3 组件结果它写出来的东西“能用”但 props 命名一团糟、样式全是内联、没有任何注释、事件名和你的项目规范完全对不上。你一边改一边骂最后发现改的时间比自己写还长。这就是没有“技能”约束的 AI 协作——它只是个聪明的实习生你问什么它答什么但不懂你团队的规矩。AI Skills 解决的就是这个问题。你可以把它理解成一套给 AI 用的“岗位说明书 操作手册 质检标准”。它不是一句提示词而是一整套结构化的技能定义里面写清楚这个 AI 在什么场景下扮演什么角色、应该按什么顺序干活、输出必须满足哪些规范、哪些红线绝对不能碰。所以你会发现AI Skills 火了不是因为它是个新工具而是因为它把“AI 能不能帮我干活”推进到了“AI 能不能按我的标准干活”。前者靠模型能力后者靠技能编排而前端开发恰恰是技能编排收益最明显的领域之一。1.2 前端开发为什么尤其适合用 AI Skills我带过不少团队也面试过很多人前端面试题里这两年也明显开始问 AI 协作相关的问题我自己的判断是前端是 AI 辅助开发落地效果最好、也最应该尽早引入 Skills 的方向。原因有三个。第一前端的技术栈碎片化严重。React、Vue、Angular、小程序、Taro、Next.js、Nuxt……每个框架都有自己的约定组件库有各自的规范甚至同一家公司不同项目的目录结构都可能不一样。这种“环境依赖强”的特性恰好是通用 AI 最不擅长的地方——你让它随机发挥它就只能平均发挥。而 Skills 可以把团队沉淀的项目规范、目录约定、组件写法固化下来让 AI 输出稳定贴合团队标准。第二前端的重复劳动密度极高。表单页、列表页、详情页、弹窗、表格、筛选区、分页器……做业务的前端同学一天到晚都在写这些而且每家的写法还略有不同。以前我们靠复制粘贴老代码改一改现在完全可以把“从需求到组件完成”的全流程交给 AI Skill 去跑人只做审阅和兜底。第三前端是天然“视觉反馈”驱动的领域。AI 写后端代码你未必一眼看出好坏但前端的产出直接呈现在页面上好不好看、间距对不对、交互顺不顺手肉眼可见。这种“可验证性”意味着 Skills 里定义的规范能很快被检验、被修正形成正反馈循环。1.3 它和普通提示词Prompt的本质区别很多人问我不就是写个 prompt 吗干嘛要搞 skills 这么重的概念我打个比方。普通 prompt 是你在咖啡厅临时跟一个外包工程师口头交代需求说完了人家理解了就去干活而 AI Skills 是你把一份《团队前端开发规范手册》加上一份《常见组件 Demo 集》加上一份《Code Review 检查清单》都塞给这个工程师让他开工前先读完干完活再用清单自检。区别在哪里一是个性化prompt 是“一次性”的skills 是可沉淀、可迭代的二是上下文长度prompt 来不及写完的规范细节skills 可以写得很详细三是复用性团队里十个人可以让同一个 AI 用同一套 skill而不是各自开口头 prompt四是版本化skill 可以放进 git 仓库管理改了哪个字段、优化了哪条规则一清二楚。所以我更愿意把 AI Skills 看成“可执行的知识资产”而不是“更长的提示词”。这也是为什么 OpenAI 提出 Agent Skills 这个概念之后前端圈跟进得特别快——大家很快意识到这玩意儿就是给团队工作流量身定做的。2. 前端场景下AI Skills 的设计思路与拆解2.1 一个前端 Skill 应该包含哪些模块我见过不少团队写出来的 skill 特别“虚”一上来就是“你是一个资深前端工程师请写出高质量的代码”然后就没有然后了。这种 skill 基本等于没写AI 输出还是看它心情。一个真正能落地的前端 skill至少要包含六个模块角色定义、工作流、输出规范、质检清单、示例片段、红线约定。我逐个说。角色定义不是简单的“你是前端专家”而是要加上约束条件比如“你是某公司中后台前端团队的高级开发者熟悉团队内部的 Vue3 TypeScript Vite 技术栈写代码遵循团队规范优先考虑可读性与可维护性”。约束越具体AI 输出越收敛。工作流是很多新手会忽略的部分。你要告诉 AI 先做什么后做什么比如“第一步先分析需求列出组件 props 和事件第二步确认是否需要拆分子组件第三步编写模板结构第四步写样式第五步自查”。没有工作流AI 可能一上来就猛写代码写到一半发现结构不对浪费大量 token。输出规范要细。细到什么程度props 命名用 camelCase 还是 PascalCase样式单位用 px 还是 rem颜色是直接用变量还是允许内联函数需不需要写 JSDoc 注释组件文件需不需要附带 index.ts 导出——这些都要写清楚。越细AI 产出的代码越像你们团队自己人写的。质检清单是给 AI 自检用的也是给开发者 review 用的。比如“检查是否有遗留的 console.log”、“检查是否有未使用的 import”、“检查表单校验逻辑是否覆盖所有必填项”。这个模块特别适合把你们团队 Code Review 时经常提的意见沉淀进去。示例片段就是 few-shot。给 AI 一到两个你们团队认可的优秀组件示例它模仿起来会非常快比任何文字描述都管用。注意示例一定要选真正符合规范的代码别拿网上抄来的、质量一般的代码当模板。红线约定是安全兜底比如“不允许直接修改 node_modules 下的文件”、“不允许在组件中直接写死业务接口地址”、“不允许使用 any 类型”、“样式不允许使用 !important特殊情况除外”。这些红线能帮你挡住最常见的 AI 翻车。2.2 从高频痛点反推 Skill 设计设计 skill 最忌讳“大而全”一上来就要做一个覆盖所有前端场景的超级 skill结果每个场景都没写透AI 也不知道按哪个指令执行。我建议反过来做把团队每周重复三次以上的工作列出来选最痛的几个先做。前端这边我见过的几个高频场景非常值得优先沉淀成 skill。第一个是“中后台 CRUD 页面生成”。这类页面结构高度相似搜索区 表格区 分页 新增/编辑弹窗 删除确认。如果一个团队用的是 Element Plus 或 Ant Design完全可以把这套页面骨架写成一个 skill让 AI 根据后端接口文档直接生成页面能省至少一小时。第二个是“组件封装”。很多团队有内部组件库封装组件的规范比较复杂比如 props 要不要支持 v-model、样式怎么支持主题切换、需不需要写单元测试。把这些规范固化成一个 skillAI 写出来的组件质量会明显高于裸 prompt。第三个是“前端性能优化扫描”。拿到一个页面让它按性能清单检查首屏请求数量、图片是否懒加载、列表是否虚拟滚动、有没有重复渲染、包体积分析等。这个 skill 的价值不在于 AI 真能修好所有问题而在于它能帮你快速出一份“问题清单 优先级”省掉了人工照 Lighthouse 报告逐条看的时间。第四个是“Code Review”。把团队的 review 标准写进 skillAI 帮你先过一遍代码找出潜在问题。这个特别适合对“前端八股文”里那些常见问题闭包泄漏、事件监听未销毁、依赖数组写错等做初筛人工再聚焦看业务逻辑。2.3 命名、版本管理与复用方式Skill 写好了怎么管理我的建议是把技能文件当作代码资产来管理严格遵守“一套技能、一个目录、一个版本”的原则。命名上我推荐用“领域-场景-语言/框架”三段式比如vue3-admin-crud、react-component-library、web-perf-audit。这种命名方式在团队多人共享时很有用看到名字就知道这个 skill 是干嘛的、用在什么技术栈上。目录结构我习惯这样组织以 Codebuddy 这类工具为例skills/my-app/下面是 SKILL.md 说明文件里面是frontmatter元信息 正文规则同目录下可以放examples/放示例代码references/放团队的编码规范和接口文档片段。版本管理方面我强烈建议把 skills 目录放进 git 仓库单独管理每次修改提交时写清楚 changelog。一个 skill 通常在试用两周后会经历一次大改比如你发现 AI 输出里样式问题很多就补上样式规范发现它组件拆分不合理就在工作流里加强“第二步”。复用方式分为个人级、项目级和团队级。个人级就是把 skills 放在你本机的 AI 工具配置目录里自己用项目级是把 skills 放进项目仓库的.ai/skills目录跟着代码走团队级是建一个独立的 skills 仓库所有成员共用一份通过 git 拉取同步。三种方式不冲突可以混合使用我的经验是先用个人级跑通再逐步推广到团队级。3. 手把手写一个可复用的前端 AI Skill3.1 技能定位与目录结构设计下面我用一个真实案例完整演示写一个叫vue3-ts-component-builder的 skill作用是让 AI 按照团队规范生成一个 Vue3 TypeScript 的通用组件。先定好技能目录结构vue3-ts-component-builder/ ├── SKILL.md ├── examples/ │ ├── good-base-table.example.vue │ └── good-input-with-label.example.vue ├── references/ │ ├── team-vue-coding-standards.md │ └── common-props-api.md └── checklist.mdSKILL.md是技能的核心文件定义角色、工作流、输出规范。examples/放团队认可的示例组件AI 会模仿它们的风格。references/放团队编码规范和常用 API 约定。checklist.md是自检清单AI 输出完代码后逐项检查。这个结构不复杂但信息密度很高。很多团队只写 SKILL.md 不写 examples效果会差很多因为 AI 对“抽象规范”的理解远不如对“具体代码”的模仿来得准确。3.2 Skill 文件的核心骨架与关键字段写法SKILL.md我个人习惯用 Markdown YAML frontmatter 的格式既方便 AI 解析也方便人阅读。核心内容如下--- name: vue3-ts-component-builder description: 根据需求生成符合团队规范的 Vue3 TypeScript 组件 version: 1.2.0 author: fe-team tags: [vue3, typescript, component] --- # 角色 你是公司中后台前端团队的高级前端工程师技术栈是 Vue3 TypeScript Vite Element Plus。 你的任务是根据用户描述生成可直接用于业务代码的组件。 # 工作流 1. 分析需求列出组件的 props、emits、slots 和对外暴露的方法。 2. 判断是否需要拆分子组件如果组件过于复杂先在思路中说明拆分方案。 3. 编写模板结构优先使用语义化标签避免无意义的 div 嵌套。 4. 编写 TypeScript 逻辑props 使用 defineProps 泛型定义事件使用 defineEmits。 5. 编写 scoped 样式使用 CSS 变量禁止硬编码颜色值。 6. 对照 checklist.md 自查修正不符合规范的地方。 7. 输出完整组件代码并附上用法示例。 # 输出规范 - 所有 props 必须有类型声明和默认值可选项写在 withDefaults 中。 - 事件命名使用 kebab-case回调函数参数必须声明类型。 - 组件内不允许出现 any 类型如遇未知类型使用 unknown 并在使用时收窄。 - 样式优先使用组件库自带的间距和颜色变量禁止 !important。 - 组件根节点类名以 x- 开头子节点用 __ 连接如 x-table__header。 - 必须导出组件名供全局注册使用。 # 示例参考 见 examples/ 目录中的两个示例文件输出风格需与示例保持一致。这里面的关键在于“工作流”和“输出规范”写得非常具体。比如事件命名 kebab-case、类名以x-开头这些约定就是直接从团队代码里提炼出来的AI 看到这样的规则生成的组件几乎不需要大改。checklist.md内容如下# 组件自检清单 - [ ] props 是否都声明了类型和默认值 - [ ] emits 是否都写了事件名和参数类型 - [ ] 是否有遗留的 console.log、debugger - [ ] 是否有未使用的 import - [ ] 样式是否有硬编码颜色 - [ ] 是否处理了组件卸载时的事件监听清理 - [ ] 是否考虑了无障碍按钮 aria-label、输入框 label这些检查项看着简单但正好是 AI 最容易出错、也是团队 review 时最常揪出来的点。3.3 在 Codebuddy、Cursor 和 OpenAI 系工具中的继承方式写好了 skill怎么装进工具里用我实测下来目前主流 AI 编程工具有几种不同的接管方式说下我的经验。在 Codebuddy 里通常是放在项目的.codebuddy/skills目录下或者在用户全局配置目录下建skills文件夹每个 skill 一个子目录工具会自动识别 SKILL.md 并作为可调用技能。在 Cursor 里对应的机制是.cursor/rules。它有全局规则和项目规则你可以把 SKILL.md 里的内容拆成多条规则文件也可以直接放一个component-builder.mdc文件在文件头部用 frontmatter 指定 globs匹配哪些文件生效和 description。Cursor 会在合适的场景自动拉起规则。OpenAI 系的 Agent Skills 则是把 skills 放在~/.agents/skills目录下每个技能同样是一个子目录加 SKILL.md。这个设计的好处是跨项目复用你换台电脑拷走这个目录就带走了所有技能。如果你用的是其他基于 Agent 的工具基本思路一致先找到 skills 或 rules 的存放目录然后把你的技能目录放进去重启工具让配置生效。注意有的工具对 frontmatter 的字段名有要求比如name是必须的description会被用来做语义匹配所以 description 一定要写得能让人一眼看懂“这个技能干什么的、什么时候触发”。“继承”这个问题是很多人问我的OpenAI 怎么继承 skills我的做法是把已有的 skill 当作文档来组合。比如你团队里已经有一个“Vue3 编码规范”文档不要复制粘贴而是在 SKILL.md 的 references 里用相对路径引用它。这样规范文档更新了skill 跟着生效不用二次维护。同理团队已有的eslintrc配置、代码格式化配置都可以在 references 里引用项目内的实体文件让 AI 读。3.4 实际效果对比用 Skill 和不用 Skill 的差别我在一次团队内部演示时做了个对比让同样的 AI 引擎分别用裸 prompt 和用上面的 skill 写同一个组件一个带搜索和分页的用户列表页面。裸 prompt 的输出结果是能用但 review 时全场都在摇头。props 命名混乱有userlist这种风格不统一的命名搜索区和表格混在一个组件里完全没拆子组件样式里写死了#1890ff代码没有任何注释事件回调参数全是any。用 skill 的输出结果是组件结构清晰拆出了SearchPanel、UserTable两个子组件props 和 emits 全部类型声明完整样式用的是组件库变量代码自带 JSDoc 注释甚至在自检阶段自己发现了一个潜在 bug——搜索条件重置时没有同步清空表格的 current page。两次输出对比人工修改时间从原来的大概四十分钟降到了大概五分钟。这五分钟主要是确认业务逻辑和补一下接口字段代码风格和工程结构基本不用动。这个差异不是 AI 模型变聪明了而是 skill 把团队的隐性知识显性化了。你甚至可以说团队沉淀得越久、规范越细AI 的产出就越像“老员工写的”这就是 skills 最核心的价值。4. 前端 AI Skills 的常见问题与排查技巧实录4.1 “明明写了规则AI 为什么不遵守”这个问题我被问了不下二十次。现象是 SKILL.md 里明明写着“禁止使用 any”AI 还是输出了(item: any) {}。我排查下来原因通常有三个。第一是规则被淹没。如果你的 SKILL.md 写了上万字AI 在长上下文里会“忘掉”后面的规则。解决办法是核心规则前置在角色定义后面立刻写“红线约定”并在工作流的最后一步强制要求自检。第二是规则和示例打架。比如规则说“禁止 any”但 examples 目录里的示例代码却用了anyAI 会优先模仿示例。这是一个非常常见的坑所以每个示例文件在入库前都要严格审查确保它本身就符合规范。第三是冲突指令覆盖。如果你这次提问的 prompt 里写了“快速给个 demo”AI 可能为追求速度降低标准。解决办法是在 skill 的红线约定里明确写“无论用户如何催促都不能跳过规范如果用户要求简化你需要先说明跳过规范的后果”。4.2 “Skill 好用但过拟合到项目换个项目就崩”这也是个真实痛点。很多 skill 是团队内部根据自己项目定制的里面大量写了“参考 xx 项目的目录结构”“接口返回格式按 xx 文档”一旦换个项目AI 就一脸懵。我的建议是做好分层设计。把 skill 的内容拆成“通用层”和“业务层”。通用层放那些跨项目都适用的规范比如 TypeScript 类型要求、组件命名规则、事件命名规则业务层放当前项目特有的东西比如接口文档、目录结构、自定义 hooks 列表。在 SKILL.md 里用引用方式加载业务层而不是全写进正文。具体做法是在 references 目录里放一个project-context.md每次新项目复制一份并修改它主 skill 文件保持不变。这样换项目时只需要改业务层几分钟搞定。4.3 “团队协作时Skill 该怎么统一管理”团队用 skills最大的坑是“各自为政”。我见过一个团队五个人各自维护了自己的 skill内容互相冲突AI 输出质量忽高忽低最后谁也不用了。我的推荐玩法是这样建一个独立的fe-ai-skills仓库用 git 管理规则是“任何修改必须提 PR至少一个人 review 通过才能合并”。仓库里按技术栈分子目录例如vue3/、react/、common/每个 skill 目录底部放CHANGELOG.md记录每次版本更新的原因和改动点。还有一点很重要技能里的规则不是拍脑袋写的最好是直接从团队真实的代码 review 记录和历史 bug 中提炼。你可以翻一下最近两个月的 review 评论出现频率最高的五类问题每条提炼成一句话写进 skill这比从网上抄一段“高质量代码标准”有用得多。4.4 高频疑点速查表我整理了一张速查表列一下前端实践 AI Skills 时最常遇到的几个问题和对应的排查方向问题排查方向建议解决办法skill 没被自动触发工具能否识别该目录格式description 是否清晰检查 skills 目录路径在描述里写明触发场景关键词AI 输出风格不像团队代码示例代码是否足够贴近实际、规范是否太抽象补充 2~3 个团队真实优秀代码作为示例skill 输出和用户临时指令冲突规则优先级不清晰在 skill 里写明“规定性规则不得被临时要求覆盖”组件通用性差、和项目耦合过深业务层和通用层没有分离拆分通用层和业务层业务层单独引用新成员不知道有哪些 skill缺乏索引文档仓库顶部放一个 README列出所有技能及适用场景修改 skill 后没生效工具缓存了旧配置重启工具或手动清除 skills 缓存目录这张表可以贴到团队知识库里遇到问题先查表能省不少沟通成本。如果你在实践中有新的坑也建议同步补充进去。4.5 一个被低估的入口把 skills 用到“前端面试”和“新手上路”最后再说一个很多人没注意到的玩法。AI Skills 不光能写业务代码还能帮你搞前端学习和面试准备。我身边有同事把自己整理的前端面试题库写成了一个fe-interview-prepskill里面包含按难度分级的题目、每个题目的考察点、最佳回答框架和常见错误。准备面试时让 AI 扮演面试官随机提问答完根据 skill 里定义的评价标准打分。实测下来这种方式比死记硬背“前端八股文”有效得多因为 AI 会根据你的回答追问细节模拟真实面试节奏。类似的新人入职后让他先跑一遍团队 skill 里的project-scanner把所有不认识的目录、依赖、脚本命令都问 AI 一遍两三天就能上手看代码不用追着老同事问了。5. 我的几点实践心得说点掏心窝的话。我在实际使用中最大的体会是AI Skills 不是一个“装了就能飞”的插件而是一套“你越懂自己团队它越好用”的体系。它本质上做的事情是把前端工程师脑子里那些“只可意会不可言传”的规范变成 AI 可执行的指令。你团队的积累越深、文档越全、review 越严格写出来的 skill 越锋利。第二点心得是别一上来就追求完美。我第一次写 skill 花了三个多小时写得很长很全结果 AI 输出时因为上下文太长规则执行反而更差。后来我改成“最小可用”的思路先只写角色 五条红线 一个示例跑通流程后每周再迭代一小部分。三个月下来这个 skill 已经变成了团队离不开的工具。想一口吃成胖子大概率会失望。第三点也是我想提醒你的skill 里的每条规则务必来自真实的团队经验。有一次我把网上看到的“高质量组件规范”整段贴进去结果 AI 生成的组件连我们自己的变量命名习惯都改了折腾半天才回滚。从那以后我坚决不用“拿来主义”的规则每一条都要在团队的真实 code review 里找到出处。如果你正准备入手 AI Skills我建议你从今天开始做一件事挑一个你重复度最高的前端场景比如列表页开发或者组件封装把团队规范整理成一个最简单的 skill试跑一次。你会很快发现AI 还是那个 AI但你用它的方式变了产出的质量也变了。