AI Skills如何重塑设计与前端协作：从提示词到自动化设计交付

刚接触 AI 编程助手的同学，可能对这些名字并不陌生：Claude Code、Cursor、Codex、OpenCode，还包括各种“AI Skills”的分享和下载。但很多人印象里，skills 还是“提示词模板的升级版”，或者“能让 AI 写代码更听话的工具”。如果我告诉你，把 skills 用对方向，它能直接改变设计师和前端工程师之间的协作方式，甚至改变整个 UI/UX 交付流程，你会不会觉得有点夸张？

这篇文章不打算停留在概念层，而是想从一名开发者的视角，拆解“AI skills”到底是什么、它与普通提示词有什么本质区别，以及如何设计一套能真正“震撼设计界”的 AI skills——不只是帮你生成设计稿，而是把设计审查、设计走查、UI 代码生成、设计系统合规检查这些流程全部自动化。全文会给出完整的环境准备、技能包目录结构、SKILL.md 写法、配套脚本和常见问题排查，适合正在学习 AI Agent 开发的开发者，也适合设计团队中的前端同学照着落地。

1. 什么是 AI Skills：先理解“技能包”这个概念

1.1 从“提示词”到“技能”

过去我们用 AI 辅助设计或开发时，通常是复制一段很长的 Prompt，比如：

你是一名资深 UI 设计师，请根据以下设计稿生成对应的 HTML/CSS 代码，要求使用 Tailwind CSS，保持响应式布局……

这种方式的痛点很明显：

• 提示词很难复用，每次都要重新维护。
• 提示词只是“文字约束”，AI 无法主动调用工具完成验证。
• 不同项目之间的规范无法统一，换一个模型表现差异很大。

而“AI Skills”的核心思路，是把“提示词 + 工具调用 + 上下文规范 + 示例输出”打包成一个可复用的技能包。当 Agent 在执行任务时，它能自动加载这个技能包里的技能定义、指令和约束，再配合底层模型和工具，完成一个相对完整的工作流。

用我自己的话概括就是：

提示词是告诉 AI“怎么做”，技能是告诉 AI“你是一个会做这件事的人”，并且还给它配好了工具箱和工作流程。

1.2 Agent Skills 与 Rules / MCP 的关系

在实际工具链中，目前主流 AI 编程助手都在往“技能化”方向发展，但叫法不太一样：

另外还有一个很容易混淆的概念：MCP（Model Context Protocol，模型上下文协议）。简单理解，MCP 是给 AI 接外部工具的“接口协议”，比如让它能读取 Figma 文件、执行浏览器测试、调用设计系统组件库；而 Skills 是对 AI 行为的“能力封装”。两者不冲突，通常一个完整的技能需要同时依赖 MCP 工具和良好的指令定义。

1.3 为什么设计场景特别需要技能包

设计领域有一个长期存在的“翻译损耗”问题：设计师产出 Figma 稿，前端工程师拿到设计标注后要手动还原，期间还要不断确认间距、字号、圆角、颜色 token、断点行为。这个过程中，AI 如果只是“理解提示词”，很难稳定输出符合设计系统的代码。

但如果我们把“设计审查”“设计 token 提取”“UI 转代码”“无障碍检查”这些流程做成技能包，AI 就不只是“看一张图写一段代码”，而是变成了一条自动化的设计交付流水线：

1. 读取设计稿。
2. 提取设计变量和组件规范。
3. 生成符合设计系统的前端代码。
4. 自动检查对比度、交互状态、响应式规则。
5. 输出审查报告和修改建议。

这，才是 AI skills 能让设计界“震撼”的真正原因。

2. AI Skills 对设计工作流的冲击点：不止是“生成一张图”

2.1 设计交付流程中的技能化改造

传统设计交付链路大致是这样的：

• 设计师在 Figma / Sketch 输出设计稿。
• 手动标注设计规范。
• 前端开发根据标注写页面。
• UI 走查阶段人工检查还原度。
• 反复沟通修改。

把 AI skills 引入后，链路可以变成：

• 设计师继续在 Figma 输出设计稿。
• AI 从设计稿中读取结构、样式变量、组件状态。
• AI 生成符合设计系统的组件代码。
• AI 自动执行视觉走查，输出还原度报告。
• 前端只需要处理少量动态交互逻辑。

也就是说，skills 解决的不只是“代码生成”，而是把设计规范、审查标准、输出格式这些“隐性知识”显性化到技能包里。任何一个新成员加入项目，只要加载同一套 skills，就能保持一致的输出质量。

2.2 可直接落地到设计团队的 4 类技能

根据我最近半年在项目里的实践，下面四类技能最值得优先开发：

1. 设计审查技能（Design Review Skill）
   接收设计稿或页面截图，按设计原则、间距系统、配色规范、层级关系进行审查，输出问题清单和修改建议。

2. UI 转代码技能（UI to Code Skill）
   把设计稿转换为 HTML/Tailwind、React/Vue 组件，自动生成响应式代码，并保留设计 token 映射。

3. 设计 Token 提取技能（Design Token Extractor）
   从设计稿或 CSS 文件中提取颜色、字体、间距、阴影等变量，生成统一的 token JSON 文件。

4. 无障碍与合规检查技能（A11y / Compliance Skill）
   自动检查文本对比度、可点击区域大小、ARIA 标签、焦点状态等无障碍问题，输出合规报告。

2.3 工具链现状

这里不展开所有工具的详细安装，先给一个宏观判断：

• Claude Code 的技能机制最适合做“复杂工作流型技能”，因为它支持多步骤工具调用和脚本执行。
• Cursor 的 Rules 更适合做“代码风格约束型技能”，例如输出组件时必须使用某个组件库。
• Codex 和 OpenCode 的生态还在快速迭代，如果你本身就是 CLI 爱好者，可以跟进它们最新版本的 Skills 文档。

后面实战部分，我会以“技能包目录结构 + SKILL.md”为主线讲解，因为它是一种比较通用的组织方式，其他工具只要做少量适配也能复用。

3. 环境准备与技能包文件结构

3.1 运行环境

先说明一下本文示例环境：

• 操作系统：macOS 或 Linux，Windows 建议使用 WSL2。
• 编程语言：Python 3.10+，用于编写辅助脚本。
• 运行时：Node.js 18+，部分工具脚本需要。
• AI 编程助手：Claude Code 或 Cursor，版本以你实际情况为准，本文重点是结构和思路。

这些版本不需要完全一致，因为技能包的核心是“文件组织 + 指令模板”，具有较强的可迁移性。实际使用时请根据自己的模型版本调整。

3.2 技能包目录结构

一个标准的设计类技能包，建议按下面的目录结构组织：

design-skills/ ├── design-review/ │ ├── SKILL.md │ ├── scripts/ │ │ └── check_contrast.py │ └── examples/ │ └── review-report.md ├── ui-to-code/ │ ├── SKILL.md │ ├── prompts/ │ │ └── react-component.md │ ├── templates/ │ │ └── component.tsx │ └── examples/ │ └── sample-output.tsx ├── design-tokens/ │ ├── SKILL.md │ ├── scripts/ │ │ └── extract_tokens.py │ └── schemas/ │ └── token.schema.json └── a11y-check/ ├── SKILL.md ├── scripts/ │ └── run_axe.py └── rules/ └── wcag-rules.md

关键文件说明：

• SKILL.md：技能的主文件，定义技能的用途、触发条件、工作流程、输出规范。
• scripts/：配套脚本，用于执行确定性检查，例如对比度计算、token 提取。
• examples/：示例输出，帮助 Agent 理解理想结果长什么样。
• prompts/或templates/：更细分的指令模板，适合大型技能包。

3.3 SKILL.md 的常见写法

SKILL.md 本质上是一个“结构化 Markdown 文档”，它不需要很复杂，但信息必须清晰。下面是 design-review 技能的主文件示例：

# Design Review Skill ## 技能用途 用于对 UI 设计稿或页面截图进行设计走查，输出结构化审查报告。 ## 适用场景 - 产品发布前 UI 走查 - 设计师交付前的自检 - 前端开发完成后的还原度检查 ## 输入要求 - 设计稿图片路径或 URL - 设计规范 JSON 文件（可选） ## 工作流程 1. 读取设计稿或截图。 2. 提取页面中的颜色、字体、间距、圆角等视觉属性。 3. 与输入的设计规范进行比对。 4. 检查对比度、层级、间距一致性、对齐方式。 5. 输出 Markdown 格式审查报告。 ## 输出规范 审查报告必须包含： - 概述：本次审查范围和时间 - 问题清单：按严重程度分为 P0 / P1 / P2 - 每个问题的截图位置或坐标 - 修复建议 - 若所有项目通过，输出“通过” ## 注意事项 - 不修改原始设计文件。 - 不确定的属性不要臆测，标记为“需要确认”。 - 对比度计算请调用 `scripts/check_contrast.js`。

这段文件看起来不复杂，但它已经把 Agent 的工作范围限制得很清楚。实战中，技能包越详细，AI 输出的稳定性就越高。初学者最容易犯的错误是：只写“请你检查一下这个设计稿”，结果 AI 输出非常随机。正确做法是像上面这样，把输入、流程、输出规范全部写死。

4. 实战一：设计审查技能（Design Review Skill）

4.1 需求拆解

我们希望实现一个“设计审查技能”，它接收一张网页截图或设计稿，能做以下事情：

1. 识别页面主要 UI 元素。
2. 提取关键样式属性。
3. 对比设计规范。
4. 输出结构化审查报告。

为了不让 AI 完全凭“感觉”判断对比度，我们准备一个 Python 脚本计算 WCAG 对比度，AI 在审查时调用脚本获得可靠数值。

4.2 编写技能定义

文件路径：design-skills/design-review/SKILL.md

# Design Review Skill ## 技能用途 对 UI 设计稿、页面截图进行设计走查，输出结构化审查报告。 ## 适用场景 - UI 走查 / 视觉验收 - 设计交付前自检 - 前端还原度检查 ## 输入要求 - 图片路径：设计稿或网页截图 - 可选：设计规范 JSON 文件，包含 color / spacing / font 定义 ## 工作流程 ### 步骤 1：读取并理解设计稿 - 如果输入是图片，描述页面整体布局、主要区块和组件。 - 如果输入是 HTML 或代码文件，直接分析 DOM 结构和样式。 ### 步骤 2：提取视觉属性 - 记录页面中出现的颜色值。 - 记录主要间距、圆角、字号。 - 记录元素之间的对齐关系。 ### 步骤 3：对比设计规范 - 如果提供了设计规范 JSON，逐项比对。 - 如果没有提供规范，则基于常见设计原则做人工判断。 ### 步骤 4：计算对比度 - 对文本颜色与背景颜色调用 `python3 scripts/check_contrast.py <color1> <color2>`。 - 根据 WCAG AA 标准判断是否通过。 - 普通文本：对比度 >= 4.5:1 - 大号文本：对比度 >= 3:1 ### 步骤 5：输出审查报告 报告必须包含： 1. 审查范围概述 2. 问题清单（P0 / P1 / P2） 3. 每个问题的位置、截图坐标、说明 4. 修复建议 5. 最终结论：通过 / 需修改 ## 报告模板 ```markdown ## 设计审查报告 - 审查对象: {页面名称} - 审查时间: {当前时间} - 审查人员: AI Design Reviewer ### 问题清单 | 级别 | 位置 | 问题描述 | 建议 | | --- | --- | --- | --- | | P1 | 顶部导航 | 文本对比度为 3.2:1，低于 WCAG AA 标准 | 将文字颜色调整为 #1A1A1A | ### 通过项 - 间距系统符合 8px 网格规则 - 圆角与 design token 一致 **结论：需修改**

注意事项

• 不修改任何源文件。
• 对颜色值不确定时，标为“需要人工确认”。
• 对比度计算必须使用脚本，不能凭目测估计。

这里有一个很关键的设计：我们要求 AI 必须调用脚本计算对比度，而不是自己“估算”。这是技能包与普通提示词的显著区别，它把确定性计算回归到了代码，从而减少模型幻觉。 ### 4.3 配套脚本 文件路径：`design-skills/design-review/scripts/check_contrast.py` ```python #!/usr/bin/env python3 """ 计算两个十六进制颜色之间的 WCAG 对比度。 用法：python3 check_contrast.py #FFFFFF #000000 """ import sys import re def hex_to_rgb(hex_color: str) -> tuple: """将 #RRGGBB 转为 (r, g, b) 元组，取值 0~255。""" hex_color = hex_color.strip().lstrip('#') if len(hex_color) != 6: raise ValueError(f"无效颜色值：{hex_color}，请输入 #RRGGBB 格式") return tuple(int(hex_color[i:i+2], 16) for i in (0, 2, 4)) def relative_luminance(rgb: tuple) -> float: """计算相对亮度，WCAG 2.x 标准。""" vals = [] for c in rgb: c = c / 255.0 if c <= 0.03928: vals.append(c / 12.92) else: vals.append(((c + 0.055) / 1.055) ** 2.4) return 0.2126 * vals[0] + 0.7152 * vals[1] + 0.0722 * vals[2] def contrast_ratio(color1: str, color2: str) -> float: """计算两个颜色之间的对比度。""" lum1 = relative_luminance(hex_to_rgb(color1)) lum2 = relative_luminance(hex_to_rgb(color2)) lighter = max(lum1, lum2) darker = min(lum1, lum2) return (lighter + 0.05) / (darker + 0.05) def main(): if len(sys.argv) != 3: print("用法：python3 check_contrast.py <color1> <color2>") sys.exit(1) c1 = sys.argv[1] c2 = sys.argv[2] try: ratio = contrast_ratio(c1, c2) except ValueError as e: print(f"错误：{e}") sys.exit(1) print(f"对比度：{ratio:.2f}:1") if ratio >= 4.5: print("结果：通过（WCAG AA 普通文本）") elif ratio >= 3.0: print("结果：通过（WCAG AA 大号文本）") else: print("结果：不通过") if __name__ == "__main__": main()

运行方式：

python3 check_contrast.py "#FFFFFF" "#333333"

预期输出：

对比度：12.63:1 结果：通过（WCAG AA 普通文本）

4.4 运行与验证

把上面的技能包加载到 Claude Code 或 Cursor 后，你可以这样触发：

• 输入：请使用 design-review 技能检查一下 examples/homepage.png，并和 design-tokens.json 对比。
• 技能会先读取图片，再按 SKILL.md 里的步骤执行。
• 遇到颜色对比度判断时，调用 Python 脚本。
• 最后输出 Markdown 报告。

注意：不同 AI 工具的加载方式可能不同，比如 Claude Code 可能会要求你把技能包放到指定目录，Cursor 则可能通过 Rules 文件描述。建议先读官方文档确认，不能用本文的目录结构硬套所有工具。

5. 实战二：UI 转代码技能（UI to Code Skill）

5.1 为什么这会让设计界震撼

如果说设计审查是“辅助检查”，那“UI 转代码”就是直接冲击设计师与工程师协作边界的能力。过去一个设计稿还原成代码，需要前端工程师投入大量手动工作。而当你给 AI 配上 UI to Code 技能后，它能：

• 读取设计稿或设计稿导出图。
• 分析视觉层级和布局。
• 生成符合项目技术栈的代码。
• 自动绑定设计 token。
• 输出响应式和可访问性友好的组件。

下面我们定义一个“UI to Code”技能，以 React + TypeScript + Tailwind 环境为例。

5.2 技能文件

文件路径：design-skills/ui-to-code/SKILL.md

# UI to Code Skill ## 技能用途 将设计稿转换为高质量 React + TypeScript 组件代码。 ## 适用场景 - 根据 Figma 设计稿生成前端组件 - 设计系统组件扩展 - 前端原型快速搭建 ## 输入要求 - 设计稿图片路径，或设计稿导出的 HTML 结构 - 可选：设计 token JSON 文件 - 可选：组件库约定（例如 shadcn/ui，Ant Design） ## 技术栈默认配置 - React 18+ - TypeScript 5+ - Tailwind CSS 3+ - 可选：shadcn/ui 组件 ## 工作流程 ### 步骤 1：解析设计稿 - 识别页面整体布局结构。 - 将设计稿按视觉区块拆分：Header、Hero、Feature、Footer 等。 - 命名组件时使用语义化名称。 ### 步骤 2：映射设计 Token - 如果有 token JSON，颜色、间距、字号必须引用 token，不能硬编码。 - 如果没有 token JSON，在组件顶部生成一个 `const tokens = {...}` 用于集中管理。 ### 步骤 3：生成组件代码 - 每个区块生成独立的组件文件。 - 组件内使用 Tailwind 类名实现样式。 - 对有状态交互的控件（下拉框、弹窗）标注 `需要额外实现`。 ### 步骤 4：添加无障碍属性 - 图片必须包含 alt。 - 按钮必须有可读文本或 aria-label。 - 使用语义化标签：header / nav / main / section / footer。 ### 步骤 5：输出 - 输出文件清单和每个组件的完整代码。 - 组件之间使用默认导出。 - 最后输出一个 `index.tsx` 汇总入口。 ## 输出规范 每个组件文件必须包含： - 技术栈说明注释 - 组件 props 类型定义 - 完整的 JSX 结构 - Tailwind class ## 注意事项 - 没有把握的交互逻辑不要硬写，输出 TODO 注释。 - 必须保证 TypeScript 类型完整。 - 不引入未说明的第三方依赖。

5.3 设计 Token 示例

在实际生成前，你可以让 AI 参考下面这样的 token JSON：

{ "colors": { "primary": "#2563EB", "background": "#FFFFFF", "text": "#1A1A1A", "muted": "#6B7280" }, "spacing": { "xs": "4px", "sm": "8px", "md": "16px", "lg": "24px", "xl": "48px" }, "font": { "body": "Inter, sans-serif", "heading": "Inter, sans-serif", "size-sm": "14px", "size-base": "16px", "size-lg": "24px" }, "radius": { "sm": "4px", "md": "8px", "lg": "12px" } }

配合 token 文件的技能，生成出来的代码不会出现“硬编码颜色”的问题。这也是好评与差评之间的一道分水岭：好的 UI 转代码技能生成的是“符合设计系统的组件”，差的则是“八竿子打不着的临时样式”。

5.4 运行流程

给 AI 提供一张卡片组件的设计稿图，并输入：

请使用 ui-to-code 技能，把这张设计稿转换成 React 组件，参考资料为 design-tokens.json。

预期输出可能包含：

// Card.tsx import React from 'react'; interface CardProps { title: string; description: string; imageUrl?: string; actions?: React.ReactNode; } const tokens = { colorPrimary: '#2563EB', colorBackground: '#FFFFFF', colorText: '#1A1A1A', spacingMd: '16px', spacingLg: '24px', radiusLg: '12px', }; export default function Card({ title, description, imageUrl, actions }: CardProps) { return ( <div className="bg-white rounded-xl shadow-sm" style={{ backgroundColor: tokens.colorBackground, borderRadius: tokens.radiusLg, padding: tokens.spacingLg, }} > {imageUrl && ( <img src={imageUrl} alt={title} className="w-full h-48 object-cover rounded-lg" /> )} <h3 className="mt-4 text-lg font-semibold" style={{ color: tokens.colorText }}> {title} </h3> <p className="mt-2 text-sm" style={{ color: tokens.colorMuted }}> {description} </p> {actions && <div className="mt-4">{actions}</div>} </div> ); }

注意：示例代码只是一个“技能演示”，实际生成结果会根据设计稿内容变化。上面这段代码已经能看出 token 映射的痕迹，也保留了语义化结构和图片 alt，体现了技能约束的效果。

6. 实战三：设计系统与无障碍检查技能

6.1 技能用途

很多团队已经有设计系统组件库，但缺少自动化的“合规检查”。我们可以配置一个 A11y 检查技能，让 AI 自动检查页面中的无障碍问题。

6.2 配置

文件路径：design-skills/a11y-check/SKILL.md

# A11y Check Skill ## 技能用途 对 HTML / React 页面进行无障碍检查，输出 WCAG 2.1 AA 合规报告。 ## 输入要求 - HTML 文件路径，或 React 组件代码 - 可选：页面 URL（需要浏览器工具联动） ## 检查项 1. 图片是否有 alt 属性 2. 表单控件是否有 label 3. 文本颜色对比度是否达标 4. 可点击元素是否有键盘焦点样式 5. 按钮是否使用 button 标签而非 div 6. ARIA 属性使用是否正确 ## 工作流程 1. 解析输入。 2. 逐项检查。 3. 无法静态判断的项，标记为“需要人工验证”。 4. 输出合规报告。

配合脚本时，可以用 axe-core 这类工具做 DOM 级扫描，AI 再结合扫描结果生成报告。这样就避免了 AI 只看代码片段、忽略真实渲染结果的问题。

6.3 与浏览器工具联动

如果使用 Claude Code 或支持 MCP 的工具，可以接入 Playwright MCP Server，让 AI 自动打开页面、执行点击操作、提取真实 DOM。通过这种方式，A11y 检查不再局限于“静态代码”，而是可以做端到端的真实交互检查。

典型流程：

1. AI 使用技能包中的指令。
2. AI 调用 Playwright 工具打开页面。
3. Playwright 执行 axe 扫描。
4. 扫描结果回传给 AI。
5. AI 输出报告，标记严重级别。

这里的配置方式因工具而异，我不展开具体命令行安装步骤，以免版本差异导致误导。核心思路是：技能负责“规则和报告结构”，MCP 负责“连接外部工具”，两者结合才能发挥最大作用。

7. 常见问题与排查思路

在实践 AI skills 的过程中，最容易踩到下面这些坑：

如果你不确定问题出在哪，建议按下面的顺序排查：

1. 先确认技能文件是否被正确加载。很多工具会打印加载日志，或者你可以故意在 SKILL.md 里写一个错误指令，看 AI 会不会执行。
2. 再确认技能指令是否明确。输出规范越明确，结果越稳定。
3. 接着检查脚本是否可独立运行。如果脚本本身失败，AI 就会跳过调用，直接靠直觉输出。
4. 最后看示例输出。技能包里的 examples 文件能显著提升 AI 的模仿质量。

8. 最佳实践与工程建议

8.1 命名与目录规范

技能命名尽量使用“动作 + 对象”的格式，例如：

• design-review
• ui-to-code
• token-extract
• a11y-check

避免使用“ai-design-agent-v1-final”这种名字，时间一长就很难维护。每个技能包内部建议保持统一结构：SKILL.md+scripts/+examples/三个目录是底线。

8.2 版本管理与测试

技能包也是代码，应该纳入 Git 版本管理。每当你修改 SKILL.md 或脚本，建议：

• 使用独立的 Git 分支。
• 用一组固定的测试用例验证输出。
• 把测试用例也放在技能包目录的tests/下。

以 design-review 为例，测试用例可以是这样：

import subprocess def test_contrast(): result = subprocess.run( ["python3", "scripts/check_contrast.py", "#FFFFFF", "#333333"], capture_output=True, text=True, check=False, ) assert "通过" in result.stdout

有了测试，团队其他人修改技能包时就不容易破坏原有行为。

8.3 安全与合规边界

把 AI skills 应用到设计场景时，有几点安全建议：

• API Token 权限最小化：如果技能需要读取 Figma、代码仓库或云服务，建议使用只读 Token，并设置短时效。
• 不自动修改源文件：设计审查类技能默认不要修改原始设计稿。
• 避免上传敏感设计稿：如果设计稿包含未公开产品原型或客户数据，不要直接发送给云端模型。优先选择私有化部署或脱敏处理。
• 版权与授权：生成 UI 代码时，若要参考第三方设计资源、图标库或组件库，必须先确认授权范围。不要从设计稿逆向提取字体文件或素材包。
• 区分 AI 辅助与人工确认：无障碍合规审查、品牌规范检查这些环节，AI 报告只能作为辅助材料，最终应由负责人确认。

8.4 团队共享与文档化

建议把技能包作为团队内部的开源项目维护：

• 一个仓库统一管理所有设计类技能。
• 每个技能包带 README，说明适用场景、调用方式、输出示例。
• 新成员加入时，只需要拉取仓库并在 AI 工具中配置，就能获得同样的“设计加持”。

最终目标是形成一套团队级的“设计语言”：不管是谁来写前端代码，加载同一套技能后，AI 生成的代码会保持高度一致。

9. 后续可以继续优化的方向

到这里，设计类 AI skills 的完整思路已经比较清晰了：

• 我们从“提示词”聊到了“技能包”。
• 从设计审查、UI 转代码、无障碍检查三个实战案例，看到了 AI 自动化设计交付的可能性。
• 同时我们也清楚认识到，AI 并不是万能钥匙，它的有效性高度依赖技能文件的质量、配套脚本的可靠性，以及团队是否遵守安全与合规边界。

如果你接下来想深入，可以从这几个方向继续：

1. 把 design-tokens 技能做成 Figma API 联动，自动拉取设计变量。
2. 给 ui-to-code 技能增加组件库适配，例如让输出直接对接 shadcn/ui 或 Ant Design。
3. 使用 Playwright 做更完整的视觉回归测试，让 AI 定期自动走查页面并生成比对报告。
4. 把技能包发布到团队内部仓库或公共资源平台，形成一个可持续迭代的“设计 AI 插件生态”。

AI skills 并不神秘，它的价值也不在于“一次性生成完美结果”，而在于把你和团队的设计经验沉淀成可复用、可测试、可演进的能力包。希望这篇文章能帮你在“AI 替代一部分设计工作”的浪潮里，掌握主动权，而不是被动接受工具的变化。

如果后面有时间，我再单独拆解 Figma API 对接、Playwright 视觉回归和团队私有化技能仓库的落地细节。你也可以先在本地把设计审查技能跑通，感受一下“AI 从只会聊天到真正会干活”的差别。