前端AI Skills实战：从提示词到可复用的技能资产

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、样式怎么支持主题切换、需不需要写单元测试。把这些规范固化成一个 skill，AI 写出来的组件质量会明显高于裸 prompt。

第三个是“前端性能优化扫描”。拿到一个页面，让它按性能清单检查：首屏请求数量、图片是否懒加载、列表是否虚拟滚动、有没有重复渲染、包体积分析等。这个 skill 的价值不在于 AI 真能修好所有问题，而在于它能帮你快速出一份“问题清单 + 优先级”，省掉了人工照 Lighthouse 报告逐条看的时间。

第四个是“Code Review”。把团队的 review 标准写进 skill，AI 帮你先过一遍代码，找出潜在问题。这个特别适合对“前端八股文”里那些常见问题（闭包泄漏、事件监听未销毁、依赖数组写错等）做初筛，人工再聚焦看业务逻辑。

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 Skill

3.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.md

• SKILL.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 目录里的示例代码却用了any，AI 会优先模仿示例。这是一个非常常见的坑，所以每个示例文件在入库前都要严格审查，确保它本身就符合规范。

第三是冲突指令覆盖。如果你这次提问的 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 时最常遇到的几个问题和对应的排查方向：

这张表可以贴到团队知识库里，遇到问题先查表，能省不少沟通成本。如果你在实践中有新的坑，也建议同步补充进去。

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，但你用它的方式变了，产出的质量也变了。