🎁 送你一套超好用超实用的 FE AI-Coding Skills

在 AI 辅助编程日益普及的今天，你是否也遇到过这些痛点：把需求全丢给 AI，结果它不仅胡乱引入依赖，还破坏了你精心设计的 Vue3 响应式状态树，更别提让它遵循你团队专属的 CSS 规范和目录结构了。如果让它修个 Bug，经常是"按下葫芦浮起瓢"。

问题的本质在于：普通的 AI 缺乏工程化的上下文与约束边界。

今天，送你一套专为 Vue3 + TypeScript + <script setup lang="ts"> 深度定制的 前端工程 AI Skills 集合 ！这不仅仅是一些 Prompt 的堆砌，而是一套将 "软件工程方法论"注入 AI 大脑 的完整工作流协议。它能让 AI 从"野生实习生"蜕变为"架构级资深研发"。

---

🌟 核心理念：从"魔法黑盒"到"工业流水线"

这套 Skills 彻底抛弃了"一句话生成整个系统"的幻想，转而采用 "任务分解 + 契约化交接 + 人工把控" 的务实模式。

!WARNING

🚫 行业大忌：直接将整块需求或设计稿甩给 AI 让它"一键实现" 很多人的习惯是丢张图过去说"照着做一个"。但问题是，这个时候 10 个 AI 模型会有 10 种截然不同的理解方式。在缺乏明确工程约束和领域上下文的情况下，它产出的代码资产极有可能充斥着幻觉、错误的数据流以及不符合团队规范的写法，最后人工排雷和修改的成本往往比自己重头手写还要高！

为什么我们需要任务分解？

• AI 更适合微观操作：在单一职责的功能点上，AI 能给出极其精准的类型定义和逻辑实现。
• 便于人工审核纠偏：小改动容易 review，每个功能点后都能调整方向，避免最后大规模返工。
• 设立质量拦截网：通过拆分为小步骤，可以在每一步之间设立关卡（如架构审查、安全检查、性能预算），保证高质量交付。

---

📦 武器库：10 大 FE AI-Coding Skills 总览

这套 Skill 集合包含 10 个核心能力，每个 skill 都包含明确的使用场景、触发关键词和固定工作流，用来让 AI Agent 在需求实现、架构设计、代码审查、缺陷修复、重构、安全、性能和代码风格任务中稳定执行。

需要特别说明的是：Skill 不是"全自动魔法开关"，而是触发条件 + 工作流 + 边界约束。真正执行时只读取当前任务命中的专项 skill，不机械跑完整套流程，也不替代人的需求确认、代码审查和业务判断。

Skill	适合场景	核心产出
fe-requirement-comprehension	截图、原型或零散说明拆解为待确认前端需求文档	.ai-docs 需求文档、资源目录和参照图
fe-ai-coding	已确认需求文档或简单明确需求的编码实现；代码必须符合适用 fe-* 规范	可运行代码、类型、交互和交付说明
fe-architecture	设计页面/组件/hook/API/service/store/model 的职责和数据流	架构方案、分层边界、状态建模和可维护性约束
fe-codereview	分支对比、本地 diff、commit 区间或存量代码审查	AI Code Review 结论、分类表格和落盘报告
fe-mr-codereview	GitLab 前端 MR 串行审查、增量审查、评论发布	MR 评论、问题统计、修复确认和队列汇总
fe-bugfix	复现并修复 UI、交互、接口、状态、权限、样式、构建或测试缺陷	根因定位、最小修复、交付说明
fe-refactor	大组件拆分、重复逻辑抽取、旧写法迁移、技术债治理	渐进重构、行为保护、交付说明
fe-security	XSS、动态 URL、上传下载、token、权限、敏感信息等安全任务	安全边界、防护实现、风险说明
fe-performance	加载慢、交互卡顿、大列表、包体积、重复请求、内存泄漏等性能任务	性能瓶颈定位、优化实现和风险说明
fe-codestyle	目录命名、SFC 分区、模板属性顺序、CSS Module/BEM、API/BO/Param/mock 命名	符合团队规范的代码组织和风格

---

🔄 协作顺序与闭环协议

复杂非结构化需求先使用 fe-requirement-comprehension 产出并确认文档；已可实现的需求再由 fe-ai-coding 作为编码总入口串联：

fe-requirement-comprehension(按需) -> fe-ai-coding -> fe-architecture -> fe-codestyle -> fe-security / fe-performance -> fe-refactor / fe-bugfix -> fe-codereview

• 复杂、截图为主或信息分散的输入先由 fe-requirement-comprehension 生成待确认需求文档，并归档原图、裁剪或标注功能点参照图。
• 已确认需求文档或简单明确需求再由 fe-ai-coding 作为编码总编排入口，读取项目上下文、调度专项 skill，并确保代码符合命中的 fe-* 规范。
• 需要拆模块、定层级或判断状态归属时，由 fe-architecture 决定职责边界、数据流和状态归属。
• 需要落地命名、目录、SFC、样式和类型风格时，由 fe-codestyle 对齐团队写法。
• 涉及 HTML、URL、权限、token、文件、日志时加入 fe-security。
• 涉及大列表、请求、缓存、懒加载、内存和包体积时加入 fe-performance。
• 结构变差或重复明显时使用 fe-refactor 做小步改造。
• 发现真实缺陷时使用 fe-bugfix 复现、定位和最小修复。
• 高风险或跨层改动再用 fe-codereview 审查本次 diff 并落盘报告。
• GitLab MR 合并前使用 fe-mr-codereview 串行审查待审前端 MR 并发布评论。

这套 skills 的闭环不是"依次调用所有 skill"，而是让每一阶段都有清晰输入、输出和质量边界。

主闭环工作流

需求/问题
  -> fe-requirement-comprehension(复杂非结构化需求先产出并确认文档)
  -> fe-ai-coding / fe-bugfix / fe-refactor / fe-performance / fe-security
  -> fe-architecture 定边界
  -> fe-codestyle 定写法
  -> 编码或审查
  -> 按需验证
  -> 高风险时 fe-codereview / fe-mr-codereview 审查落盘或 MR 评论
  -> 按阻塞问题回流修复，非阻塞问题记录风险
  -> 交付

交接契约

每一阶段都有清晰输入、输出和质量边界：

交接	必须带上的信息
需求理解到实现	已确认需求文档路径、资源目录、原图/参照图、功能清单、接口/组件候选和待确认项处理结论
需求到架构	验收点、页面入口、接口契约、权限、状态、复用候选和不确定项
架构到实现	文件落点、层级职责、数据流、状态归属、是否需要 service/store/hook
架构到风格	要新增/调整的目录、文件、组件、API、service、model、枚举和 hook
实现到安全	输入源、危险 sink、权限、token/session、资源 ID、文件、日志和对象合并
实现到性能	用户关键路径、数据规模、请求数量、渲染成本、缓存和生命周期副作用
实现到审查	diff 范围、关键取舍、残余风险和需要重点复核的调用链
审查到返工	【强制/建议/可选/新发现/存疑】分类、位置、问题、风险、建议和回流 skill
MR 审查到修复	上次审查 commit、增量 diff、历史问题修复确认和本次问题统计

质量边界

• 需求：每条需求或缺陷都有实现、修复、推断说明或未覆盖原因；截图类需求的原始图片完整归档，功能点参照图来自原图裁剪或标注。
• 架构：职责边界、数据流、状态归属和复用/抽取取舍明确。
• 风格：目录、命名、SFC、样式、类型和网络请求写法符合项目约定。
• Mock 数据：用户明确要求 mock 数据时，承载 mock 数据的变量或常量以 mock 开头，并在定义上方标记 // TODO: MOCK 数据需处理。
• 参数注释：新增函数、修改函数签名或新增/变更函数参数时，每个参数都有对应注释；BO/Param 转换或构造函数还要说明转换来源、目标和参数业务含义。
• 安全：不可信输入进入危险 sink 前有校验、清洗、转义、allowlist 或拒绝策略。
• 性能：关键路径有预算或瓶颈判断；缓存、取消、懒加载、虚拟化不破坏正确性。
• 按需验证：只有用户明确要求、存在失败信号、改动触及公共契约/高风险路径，或需要确认关键行为时，才运行最小相关命令或手工路径；不默认每次编码后执行格式化、lint、typecheck、test 或 build。
• 审查：高风险或跨层改动才使用 fe-codereview；默认只审查不改代码，只把置信度足够高的真实问题纳入结论，阻塞当前需求的问题必须返工。
• MR 审查：只审查 fe- 前缀的前端项目 MR；已审查且无新提交的 MR 跳过；不落盘本地报告。

返工路径

审查问题	回流 skill
安全漏洞、权限、敏感信息、XSS、动态 URL	fe-security
正确性缺陷、线上回归、测试失败、构建失败	fe-bugfix
分层边界、职责归属、状态模型、数据流问题	fe-architecture
大组件、重复逻辑、可维护性退化	fe-refactor
加载、渲染、请求、缓存、内存和包体积问题	fe-performance
命名、目录、SFC、样式、API/BO/Param 风格问题	fe-codestyle

---

🛠️ 各专项 Skill 详细解析

1. fe-ai-coding：前端需求实现总入口

定位：前端需求实现的总编排入口，前提是输入已经足够支撑编码。负责：

• 判断输入是否可直接进入实现，并对简单需求做轻量验收点收敛。
• 读取项目上下文，识别落点、相似实现和约束。
• 判断需要调用哪些 fe-* 专项 skill，并串联它们的输出。
• 在当前需求范围内完成符合适用 fe-* 规范的实现、检查和交付说明。

本 Skill 不生成需求文档、不归档设计资源、不填写模板章节；复杂非结构化需求应先交给 fe-requirement-comprehension。进入编码后，所有搜索、设计、实现、重构、验证和审查都只服务当前需求本身，不做额外、顺手或扩大范围的改动。

使用场景：

• 用户给出已确认模板化需求文档，希望直接完成前端实现。
• 用户给出简单明确的小需求，希望直接完成前端实现；此时只整理临时验收清单。
• 用户给出已拆解清楚的原型/截图说明，希望完成页面或组件实现。
• 用户要求新增或修改页面、组件、弹窗、表格、表单、交互流程、状态管理或接口联调。
• 用户描述未实现接口的入参、出参和落点，希望补齐 API、Param、BO、Service、Hook 或页面接入。
• 用户希望复用现有能力，或在当前需求范围内做必要的轻量抽取。

如果用户只要求生成需求文档，直接使用 fe-requirement-comprehension。如果用户只要求代码审查，直接使用 fe-codereview；如果只要求修 bug，直接使用 fe-bugfix。

触发关键词：

AI Coding、AI 编码、自动写代码、自动完成前端需求、帮我实现这个需求、按需求文档开发、根据原型开发、原型还原、新增页面、开发组件、接口联调、前端实现。

固定工作流：

1. 输入分流 ：确认输入是已确认需求文档、简单明确需求，还是应交给 fe-requirement-comprehension 的非结构化需求。
2. 实现收敛：基于需求文档或简单需求整理验收点、页面入口、接口契约、状态、权限和必须确认的问题。
3. 项目侦察：读取项目结构、相邻实现、可用脚本和工作区状态，判断复用机会。
4. 专项调度 ：按职责关系选择必要的 fe-* skill，得到落点、风格、安全、性能或重构约束；命中职责场景时必须读取对应 skill。
5. 编码落地 ：只围绕当前需求实现；新增或修改代码必须遵循适用 fe-* skill 的权威规则。
6. 按需验证：只有用户明确要求、存在失败信号、改动触及公共契约/高风险路径，或需要确认关键用户路径时，才运行最小相关命令或手工路径。
7. 审查收尾 ：高风险或跨层改动才使用 fe-codereview 审查本次需求相关 diff，只处理阻塞当前需求的问题。
8. 交付说明：说明实现范围、关键文件、复用/抽取取舍、检查结果、业务假设和残余风险。

2. fe-requirement-comprehension：前端需求拆解

定位：负责把设计稿截图、原型图、UI 走查图或零散说明拆解为可确认的前端需求文档。它只做需求理解、资源归档和文档落盘，不修改业务源码，不进入编码、验证或审查闭环。

需要标准化需求输入时，优先使用本 Skill 生成标准需求文档：文档使用 fe-requirement-comprehension/references/template.md 结构，保存到 .ai-docs/<需求名称>/<需求名称>.md，引用资源统一保存到 .ai-docs/<需求名称>/resources/。

截图类输入还有一个很关键的交付约束：用户提供的原始图片必须完整归档；功能详细说明中引用的参照图应来自原图裁剪，或在原图裁剪副本上做轻量框线、编号、箭头等标注，不用 AI 生成的相似页面或示意图替代真实设计稿。

使用场景：

• 用户给出一张或多张设计稿、原型图、UI 截图，希望拆成功能需求。
• 用户要求"根据截图生成需求文档""拆解功能点""提炼验收点""整理前端需求说明"。
• 用户给出复杂、信息分散或多状态的需求，后续可能需要开发，但当前缺少可确认的实现依据。
• 用户希望先得到一份结构统一、可审阅、可交给 fe-ai-coding 实现的标准需求文档。
• 需要结合仓库已有页面、组件、接口、模型和团队规范，把截图信息补成可交给 fe-ai-coding 的需求说明。

如果用户已经提供完整模板化需求文档并明确要求开发，或需求简单明确到无需文档即可安全实现，应使用 fe-ai-coding。

触发关键词：

需求理解、需求拆解、截图拆需求、设计稿拆解、原型图拆解、功能点分解、生成需求文档、fe-requirement-comprehension。

固定工作流：

1. 确认输入：整理用户提供的截图、链接、补充说明和期望的需求名称。
2. 读取模板 ：打开本 Skill 的 references/template.md，以其为唯一文档骨架。
3. 归档资源 ：创建 .ai-docs/<需求名称>/resources/，保存文档会引用的截图、图标和补充资源。
4. 识别截图：逐张分析页面结构、信息层级、交互入口、状态差异和多图流程关系。
5. 裁剪/标注参照图：根据功能点从原始图片中裁剪对应区域；需要说明时只在原图或裁剪副本上做轻量标注。
6. 侦察项目：读取与截图业务相关的现有代码，确认落点、复用组件、接口、模型、样式和命名约定。
7. 按需引用规则 ：读取必要的 fe-* skill，把架构、风格、安全、性能或复用约束转化为文档描述和待确认项。
8. 生成文档：按模板填写全部章节；不确定内容明确标注，不保留占位符；模板中要求保留原文的章节不要自行扩写。
9. 自检落盘：确认文档路径、资源相对路径、模板章节顺序、占位符清理、参照图引用和不确定项标注无误。
10. 交付说明：告知文档保存路径、资源目录、主要拆出的功能点、已裁剪或标注的参照图、使用的项目证据和仍需确认的问题。

3. fe-architecture：架构与边界设计

定位 ：负责把前端需求转化为职责清晰、类型契约明确、可维护、可扩展的前端架构方案和代码结构，适用于技术栈为 Vue3 + TypeScript + <script setup lang="ts"> 语法糖的前端项目。默认先尊重现有仓库实践；当项目缺少明确约定时，采用本 Skill 的分层架构、SOLID 原则和设计模式。

使用场景：

• 用户要求在技术栈为 Vue3 + TypeScript + <script setup lang="ts"> 语法糖的前端项目中设计页面、模块、组件、hook、API、service、store 或 model 的职责边界。
• 需求实现、重构或审查中需要判断代码应该放在哪一层、谁依赖谁、状态归谁。
• 项目出现大组件、请求散落、状态混乱、重复模型、分层不清或扩展困难。
• 需要应用 SOLID、策略/适配器/门面/工厂等模式，但要避免过度设计。

触发关键词：

前端架构、架构设计、模块拆分、分层架构、SOLID、设计模式、组件职责、容器展示分离、API 边界、Service 边界、Store 边界、Hook 边界、Model 边界、数据流设计、状态建模、请求状态、错误兜底、可维护性提升。

固定工作流：

1. 理解业务边界：确认页面入口、用户流程、数据来源、权限、错误态、空态和扩展预期。
2. 读取现有架构：查看目录、路由、store、请求封装、相邻 feature、公共组件和可用脚本。
3. 拆分职责：决定 page、component、hook、api、service、model、store、utils/constants 的归属。
4. 设计数据流 ：明确 route/props/form -> Param -> API/Service -> BO -> hook/store -> component 的转换和错误处理。
5. 套用原则：用 SOLID 和必要设计模式检查扩展点、依赖方向、接口粒度和组件契约。
6. 落地协作 ：涉及具体命名和 SFC 风格时交给 fe-codestyle，涉及安全/性能时分别套用对应 skill。
7. 按需验证：涉及实现且满足验证触发条件时，选择最小相关命令或关键 UI 路径。

4. fe-codereview：代码审查

定位 ：技术栈为 Vue3 + TypeScript + <script setup lang="ts"> 语法糖的前端代码审查入口，负责：

• 冻结审查范围：分支/commit diff、本地改动或存量 scope。
• 收集证据：diff、调用链、关键上下文和必要工具结果。
• 调度专项 skill：按风险读取对应 fe-* skill 的权威规则。
• 归类输出：把确认问题映射为固定分类，并落盘审查报告。

本 Skill 不承载架构、安全、性能、风格、重构或 bugfix 细则；对应规则以专项 skill 为准。默认只发现和报告问题，不主动修改代码；components.d.ts、字体、SVG 等自动生成或非代码逻辑资源默认不纳入审查结论。

使用场景：

• 分支对比 / commit 区间 ：审查 base...head、两个分支、两个提交或指定路径差异。
• 本地改动审查：审查 staged、unstaged 或当前工作区全部未提交改动。
• 存量代码审查：审查已有模块、目录、页面、组件或整个前端项目。
• 合并前风险扫描：上线、重构、性能优化、安全改造或大型 feature 交付前做风险扫描。

触发关键词：

code review、代码审查、review 一下、帮我看代码、审查本地改动、审查 staged、审查 unstaged、审查 diff、分支对比、commit 区间审查、存量代码审查、风险扫描。

固定工作流：

1. 冻结范围：判断审查模式，记录 base/head、staged/unstaged 或存量 scope。
2. 收集证据：读取 diff、文件列表、关键上下文、调用链和可用工具结果。
3. 风险分流：识别高风险路径，并选择需要调度的专项 skill。
4. 递进审查：按底层逻辑、Vue/TypeScript 框架特性、数据流转、架构、安全、性能、正确性、类型契约、可维护性和风格检查；发现规则未覆盖但真实存在的问题，记录为【新发现】。
5. 问题定级：把握度超过 80% 的真实问题按 P0-P3 内部定级，并映射到【强制/建议/可选/新发现/存疑】分类；P3 控制噪声，只输出代表性问题。
6. 报告落盘 ：保存到 .ai-review/YYYYMMDDHHMMSS.md；没有问题也写清覆盖范围和残余风险。
7. 最终收敛：对用户只摘要总体结论、问题统计、报告路径和工具结果。

5. fe-mr-codereview：GitLab MR 审查

定位：GitLab MR 审查入口，只负责 MR 维度的流程编排：

• 查询未关闭 MR，并过滤项目名以 fe- 开头的前端项目。
• 串行处理 MR 队列。
• 判断是否已有 AI 审查且无新提交。
• 准备完整 diff 和增量 diff 证据。
• 调用 fe-codereview 的审查标准生成 AI Code Review 结论。
• 将结论评论到 GitLab MR，并汇总处理结果。

具体代码审查规则、问题分级、输出分类和报告结构以 fe-codereview 为准。本 Skill 不落盘 .ai-review 报告。它依赖可访问 GitLab 的环境变量和本地可审查代码：至少需要 GITLAB_URL、GITLAB_TOKEN，以及能拿到目标分支和源分支 diff 的仓库环境。

使用场景：

• 用户要求审查 GitLab 上某个未关闭的前端 MR。
• 用户要求查询并审查待审前端 MR；查到后直接串行审查，不等待用户选择。
• 用户给出 GitLab 项目路径和 MR 编号，要求完成前端代码审查并把结论评论到 MR。
• 用户要求对 GitLab MR 发布 AI Code Review 评论。

触发关键词：

GitLab MR 审查、前端 MR 审查、MR code review、审查 GitLab MR、评论 MR、发布 MR 审查结论。

固定工作流：

1. 查询 MR ：查询未关闭 MR，只保留项目名以 fe- 开头的前端项目；用户指定项目或 MR 时也必须校验此前缀。
2. 生成串行队列：多个 MR 按查询结果顺序逐个处理，禁止并发审查多个 MR。
3. 判断是否需要审查：读取当前源分支 head commit 和最近一次 AI 审查评论元信息。
4. 准备证据：收集目标分支到源分支的完整 diff；增量审查时额外收集上次审查 commit 到当前 head 的 diff。
5. 确认历史问题：增量审查必须对上次问题逐条判断已修复、未修复、部分修复、已失效或无法确认。
6. 调用 fe-codereview ：明确当前处于 MR 场景，按 fe-codereview 当前规则审查 MR 代码，不落盘报告。
7. 发布评论：将审查结论评论到 GitLab MR。
8. 队列汇总：汇总已审查、跳过、失败、评论链接、总体结论和问题统计。

6. fe-bugfix：缺陷修复

定位：指导 AI Agent 用可复现、低风险的方式修复 Vue 项目缺陷。默认先理解现有项目结构、Vue 版本、组件组织、编码风格和业务边界，再做最小必要修改；不要把 bugfix 扩大成无关重构，更不要修复一个 bug 又新增两个回归。

使用场景：

• 用户要求修复 UI 异常、交互失效、数据显示错误、表单提交失败或样式回归。
• 用户提供报错日志、失败测试、构建/typecheck/lint 输出，希望定位并修复。
• 线上环境、特定权限、特定浏览器、特定数据条件下出现回归或偶发问题。
• Vue 响应式状态、路由参数、权限判断、请求竞态、缓存或组件卸载导致行为错乱。

触发关键词：

bugfix、fix bug、修 bug、修复缺陷、缺陷定位、报错修复、错误日志、测试失败、构建失败、lint 失败、typecheck 失败、复现问题、定位根因、回归修复、线上问题、偶发问题、UI 异常、交互失效、状态错乱、接口数据异常、权限问题、样式回归。

固定工作流：

1. 确认现象：收集实际结果、期望结果、复现条件、失败日志和影响范围。
2. 建立复现：运行最小失败命令或手工路径。
3. 追踪根因：沿输入、状态、副作用、输出链路定位第一错误点。
4. 评估影响面：识别公共组件、store、service、router、样式、权限和类型契约风险。
5. 最小修复：只改与根因直接相关的代码和类型。
6. 按需验证：修复命令失败时运行对应最小命令；UI/交互缺陷优先复查原路径。
7. 防止回归：修公共契约或高风险链路时重点检查主要调用方。
8. 交付复盘：说明根因、修复点、验证情况和残余风险。

7. fe-refactor：渐进式安全重构

定位 ：指导 AI Agent 在技术栈为 Vue3 + TypeScript + <script setup lang="ts"> 语法糖的前端项目中完成高质量前端重构：先保护现有行为，再分步骤改善结构、类型、可读性和复用性。重构应让代码更容易理解、修改和扩展，但不借重构之名改业务语义。

使用场景：

• 用户要求拆分大 SFC、大组件、复杂模板、复杂 watch/computed 或混乱响应式状态。
• 存在重复代码、重复表单逻辑、重复请求逻辑、重复权限判断，需要抽组件、hook、service 或 util。
• 需要从 Options API、mixins、事件总线、旧请求写法迁移到基于 Vue3 + TypeScript + <script setup lang="ts"> 语法糖技术栈的更清晰实现。
• 代码审查、需求实现或 bugfix 后需要改善可维护性，但不能改变现有业务行为。

触发关键词：

前端重构、refactor、重构代码、技术债治理、可维护性提升、组件拆分、大组件、大 SFC、复杂模板、复杂状态、抽公共组件、抽 composable、抽 hook、抽 service、抽 util、消除重复代码、整理请求逻辑、整理表单逻辑、整理权限逻辑、Options API 迁移、mixins 迁移、旧写法迁移、类型收窄。

固定工作流：

1. 锁定目标：明确重构目的和成功标准。
2. 保护行为：梳理输入输出、接口、权限、状态、缓存和埋点。
3. 评估风险：区分局部整理、抽取、公共契约调整和高风险重构。
4. 小步计划：先类型保护，再移动代码。
5. 实施抽取：按架构职责和代码风格落地。
6. 防止语义漂移：不顺手改业务、不放宽类型、不删除校验。
7. 按需验证：公共契约、高风险重构或已有失败信号才运行相关命令；普通局部整理可用手工路径或说明未运行。

8. fe-security：代码安全

定位 ：指导 AI Agent 在技术栈为 Vue3 + TypeScript + <script setup lang="ts"> 语法糖的前端项目中把安全要求落实到可交付代码：识别输入边界、约束危险 sink、避免敏感信息泄漏、守住权限与租户边界，并为关键风险补上类型和运行时校验。

使用场景：

• 用户要求实现或审查富文本、markdown、v-html、动态 URL、外链、iframe、上传下载或跨窗口通信。
• 功能涉及登录态、token、权限、租户、资源 ID、路由守卫、按钮权限或关键写操作。
• 代码中出现日志敏感信息、浏览器持久化、对象合并、第三方回调、依赖脚本或 CSP/CORS/CSRF 配合问题。
• bugfix、重构、性能优化中可能削弱鉴权、输入校验、错误处理或数据完整性。

触发关键词：

前端安全、安全审查、安全修复、XSS、v-html、innerHTML、富文本、markdown、动态 URL、开放跳转、iframe、postMessage、window.open、下载链接、上传下载、文件名、CSV 注入、对象 URL、token、session、权限、租户、资源 ID、路由守卫、按钮权限、敏感信息、日志泄露、localStorage、原型污染、Object.assign、merge、CSP、CORS、CSRF、安全 Header、第三方脚本、依赖风险。

固定工作流：

1. 盘点输入源：列出用户输入、route/query、后端返回、localStorage、第三方回调、文件和环境配置。
2. 盘点危险 sink：检查 HTML、URL、脚本、样式、下载文件名、日志、请求、对象合并和浏览器 API。
3. 建信任边界：明确可信与不可信数据。
4. 选择防护模式：优先使用 sanitizer、allowlist、safeUrl、safeMerge、权限守卫和统一封装。
5. 最小安全改动：把防护放在合适层级，不弱化后端最终鉴权。
6. 确认风险：必要时用最小路径确认 XSS、URL、权限、文件、竞态、日志和错误分支。
7. 交付边界：说明仍需后端、网关、CSP、CORS 或运维配合的部分。

9. fe-performance：性能优化

定位 ：指导 AI Agent 在技术栈为 Vue3 + TypeScript + <script setup lang="ts"> 语法糖的前端项目中写出默认性能良好的代码：先识别瓶颈，再选择低风险优化；让加载、渲染、交互、网络、资源、内存和构建产物都有清晰性能边界。

使用场景：

• 用户反馈页面加载慢、首屏慢、交互卡顿、滚动掉帧、搜索筛选响应慢。
• 列表、表格、树、图表、富文本、导入导出或大弹窗存在渲染量和资源风险。
• 需求实现或重构涉及缓存、请求去重/取消、防抖节流、虚拟滚动、路由懒加载或异步组件。
• 构建产物、依赖体积、图片字体资源、重复请求或内存泄漏需要分析和优化。

触发关键词：

前端性能、性能优化、页面加载慢、首屏慢、交互卡顿、掉帧、大列表、大表格、虚拟滚动、分页、懒渲染、包体积、bundle、依赖体积、路由懒加载、异步组件、重复请求、请求去重、缓存策略、防抖、节流、AbortController、watch 滥用、computed 副作用、内存泄漏、事件监听清理。

固定工作流：

1. 确定用户路径：明确慢在哪里、影响谁、数据规模和期望指标。
2. 建立基线：收集加载、渲染、交互、请求、内存或 bundle 证据。
3. 定位瓶颈：按资源、响应式、DOM、网络、长任务和生命周期排查。
4. 选择策略：匹配分页、虚拟化、懒加载、缓存、取消、去重、稳定 props 等手段。
5. 架构落点：把优化放到合适的 component、hook、service、store、router 或 build config。
6. 保持正确性：覆盖失败、取消、权限变化和数据一致性。
7. 交付说明：说明优化取舍、预期影响和风险。

10. fe-codestyle：代码风格与命名规范

定位 ：fe-codestyle 只处理技术栈为 Vue3 + TypeScript + <script setup lang="ts"> 语法糖的团队代码风格与命名约定：目录、文件名、SFC 分区、模板写法、SCSS/BEM、类型命名、API 命名、mock 数据命名、枚举/多语言和网络请求类型约束。

不要在这里重复定义架构设计、SOLID、设计模式、模块职责边界或大型重构策略；这些问题交给 fe-architecture。

使用场景：

• 用户要求统一目录、文件名、组件名、API/BO/Param、枚举和多语言配置命名。
• 新增或调整 Vue SFC，需要遵守 #region 分区、模板属性顺序、CSS Module 和 BEM 写法。
• 代码审查或需求实现中发现风格不一致、类型命名松散、请求类型不明确。

触发关键词：

codestyle、代码风格、团队规范、命名规范、目录规范、SFC 分区、#region、模板属性顺序、CSS Module、BEM、BO 命名、Param 命名、API 命名、Service 命名、mock 数据、枚举命名、多语言配置、网络请求类型、Vue 代码规范。

固定工作流：

1. 读取近邻约定：先看同目录、同模块和公共模板，确认项目真实风格。
2. 分清边界 ：只处理风格、命名和组织方式；架构职责先交给 fe-architecture 决定。
3. 统一命名：按目录、文件、组件、BO、Param、API、Service、mock 数据、枚举和 hook 逐层对齐。
4. 整理 SFC ：保留 #region 分区，模板保持声明式，复杂逻辑移出模板。
5. 约束样式 ：使用 CSS Module 与 BEM，控制 :global、z-index、长文本和局部覆盖影响。
6. 类型化请求 ：检查 API 入参和返回值是否显式类型化，避免 any 和重复匿名对象。
7. 按需验证：只有存在风格/类型失败信号、用户要求，或改动触及公共类型/导入/网络契约时，才运行最小相关 lint/typecheck 或局部检查；不要把格式化作为默认收尾动作。

容易被忽略的细节 ：新增或变更接口、BO、Param、DTO/API 类型、数据转换函数和带参数函数时，要补充能说明业务含义的注释；网络请求入参和返回值必须显式类型化，不能用 any 或重复匿名对象把契约藏起来。

---

🚀 典型工作流实战：从"原型图"到"平稳发版"的颠覆式体验

让我们通过一段"多 AI 机器接力"的实况，看看这套标准流水线是如何运转的：

🎯 场景：产品经理扔来几张高保真设计图，要求做一套"带有鉴权和大量交互联动的数据分析看板"

1. 【理解输入，拒绝挖坑】 你调用 /skill fe-requirement-comprehension 并扔进截图。AI 分析后，在 .ai-docs/ 落盘了一份严谨的《看板需求规范》，完整归档原图，并按功能点裁剪参照图；同时高亮标注："设计图上的多角色鉴权缺失了后端 API 契约，需先找后端确认"。
2. 【架构把控，规划蓝图】 契约补齐后，召唤核心的 /skill fe-ai-coding。因为看板逻辑复杂，fe-ai-coding 命中并读取 fe-architecture，将"图表渲染"和"数据请求"拆到不同职责层，并规划好了数据流 Param -> Service -> BO -> View。
3. 【注入规范，代码洁癖】 代码生成中，fe-codestyle 对齐团队写法：用户明确要求 mock 时，新增 mock 数据使用 mock 前缀和 TODO 注释；接口、BO、Param 和转换函数补齐业务含义注释；样式保持在 CSS Module 与 BEM 约束内。
4. 【挂载护盾，排雷兜底】 此时，fe-security 为表格单元格自定义渲染建立输入源和危险 sink 清单，优先复用项目已有 sanitizer、allowlist 或安全封装；fe-performance 则针对密集筛选补上请求取消、去重或后写保护，防止竞态污染。
5. 【机器把关，精准回流】 开发完毕，你 Push 代码提了 MR。在已配置 GitLab Token 和本地 diff 环境的前提下，fe-mr-codereview 串行处理 fe- 前缀项目 MR，深层扫描后指出一处图表实例未在 onUnmounted 时销毁导致的内存泄漏，并在 MR 下打上 [P1 必须修复]。
6. 【安全合并，平稳发版】 你根据评论，让 fe-bugfix 顺着生命周期链路复现、定位并实施最小化修复。再次提交后，增量审查确认历史问题已修复，再进入人工合并判断。

sequenceDiagram autonumber actor PM as 产品经理 actor Dev as 前端开发 (你) participant AI as 🤖 智能流水线 participant Git as GitLab PM->>Dev: 抛出复杂界面截图与零散描述 Dev->>AI: 调用 fe-requirement-comprehension 拆解截图 AI-->>Dev: 输出标准《需求规格书.md》、资源目录和功能参照图 Dev->>AI: 确认需求边界，调用 fe-ai-coding 开启实现 rect rgb(240, 248, 255) Note over AI: 内部严格契约闭环流转 AI->>AI: 架构层定规: 划定拆分边界与数据流(fe-architecture) AI->>AI: 风格层约束: 对齐 TS 类型、注释与命名风格(fe-codestyle) AI->>AI: 风险层护航: 按需落实安全边界与性能预算(security/performance) end AI-->>Dev: 交付符合多重质量边界的业务代码 Dev->>Git: Push 代码，创建 Merge Request Git->>AI: 已配置时触发 fe-mr-codereview alt 审查出 P0/P1 问题 AI-->>Git: 发布 [强制修复] 评论 Git-->>Dev: 回流至 fe-bugfix/fe-security 实施最小修复 Dev->>Git: 修复后重新 Push 触发增量审查 else 审查通过 AI-->>Git: 发布 [通过] 审查结论 end

💡 写在最后：重新定义 AI 编程

真正的 AI 编程，绝不是一键生成万物的黑盒魔法，而是严谨的工程化实践。

这套 FE AI-Coding Skills 的核心价值，就在于帮 AI 建立起了坚如磐石的边界契约与规范流水线。通过明确规定什么阶段干什么事，出了问题回流给谁，我们将 AI 从充满不确定性的"玩具"，彻底锻造成了工业级的前端生产力引擎。

完整配置与源码 ：👉 agent-skills