企业官网建设流程全解析

做设计的朋友应该都有过这样的体验：好不容易用 AI 生成了一张满意的视觉稿，结果让 AI “微调一下按钮颜色”之后，整张图的风格直接跑偏；或者前端同事想让 AI 按设计规范把 UI 转成代码，结果每次都要把“主色 #2F54EB、圆角 8px、间距保持 4 的倍数”这段提示词复制粘贴一遍。提示词越来越长，效果却越来越不稳定，团队里很难沉淀出统一的 AI 设计工作流。

最近被设计圈反复讨论的 AI Skills，正好就是为了解决这一类问题而出现的。很多人都把 Skills 简单理解成“更长更结构化的提示词”，实际上它是一个更完整的技能封装机制：既包含让 AI 按什么流程工作的指令，也包含可复用的设计规范、参考资料，以及可执行的校验脚本。这篇文章会从概念讲起，带你亲手做一个 UI 设计系统技能和一个 UI 转前端代码技能，最后聊清楚“为什么这种机制会让设计界重视”，以及团队落地时容易踩的坑。

1. AI Skills 是什么：设计场景带来的真正价值

1.1 从“聊天式提示词”到“技能包”

先给一个通俗理解：AI Skills 就像给 AI 安装了一份“岗位说明书 + 工具箱”。过去我们让 AI 干活，是每次在对话框里重复说明需求，比如“你是一个资深 UI 设计师”“请按照 Material Design 规范”“使用蓝色系”等。这些指令完全依赖人反复描述，换了对话窗口之后，AI 立刻失忆。

Skills 改变了这个路径。你把某个领域的完整工作方式封装成一个文件夹，里面包括 SKILL.md 主指令、参考资料和辅助脚本。之后 AI 会根据任务内容自动判断是否调用这个技能，不需要你再次解释领域背景和执行步骤。

从技术定义上看，Agent Skills 是一组以 SKILL.md 为核心的、可复用的能力包。SKILL.md 使用 Markdown 格式编写，头部包含 YAML 元信息，正文是给 AI 的结构化指令。与普通提示词相比，它有三个明显区别：

1.2 设计领域为什么天然适合 Skills

设计是一个非常依赖规范的领域。一个成熟的设计团队通常有品牌色板、字体层级、间距规则、圆角规范、栅格系统，甚至阴影和动效节奏。这些内容有两个特点：一是高度标准化，二是容易写成 Markdown 或 JSON 文件。

同时，设计工作流也很固定。接到需求后通常要经历“需求拆解-风格探索-规范制定-组件输出-前端还原”几个步骤。这些步骤正好可以被 Skills 固化成 AI 的执行流程。

所以你会看到一个有趣的现象：早期讨论 Skills 最多的是开发者，因为 Claude Code 这类终端工具最早支持它。但真正让 Skills 产生“震撼感”的，反而是设计团队。因为当设计规范可以被 AI 稳定执行时，设计交付物的一致性和前端还原度都会明显提升，团队的重复劳动也会大幅减少。

1.3 Skill 的典型目录结构

一个安全、可维护的技能包通常是这样组织的：

my-design-skills/ ├── ui-design-system/ │ ├── SKILL.md │ ├── references/ │ │ ├── color-tokens.md │ │ └── typography-scale.md │ └── scripts/ │ └── check_contrast.py └── ui-to-code/ └── SKILL.md

其中 SKILL.md 是必选文件，references 和 scripts 是可选目录。references 用于存放模型需要引用的设计规范，scripts 用于存放需要实际执行的计算脚本。这种“主指令 + 参考资料 + 可执行脚本”的结构，让 AI 不再只是“记住规范”，而是真正可以“检查和计算规范”。

2. 环境准备与版本说明

2.1 需要准备什么工具

本文示例以当前主流支持 Agent Skills 的客户端为例，包括 Claude 桌面客户端和 Claude Code 这类命令行工具。如果你使用的是其他支持 SKILL.md 格式的平台，配置思路基本一致，只是技能目录的读取位置可能不同。

建议准备以下环境：

• 一个支持 Agent Skills 的 AI 客户端，具体以你使用的软件版本为准；
• VS Code 或其他支持 Markdown 预览的编辑器；
• Python 3.10 及以上版本，用于运行对比度校验脚本；
• Git，用于对技能包做版本管理。

2.2 版本说明：不要写死细节

需要特别提醒的是，Agent Skills 功能目前迭代非常快。不同版本对技能目录、命令入口、元信息字段的支持可能存在差异。本文不会写死具体版本号，而是重点演示“如何组织一份可用的技能包”。当你实际操作时，如果发现某个字段或目录名不生效，优先查阅当前使用客户端的官方文档。

2.3 两种加载方式

从使用场景上看，有两种加载方式比较常见：

• 项目级加载：在某个前端项目的.claude/skills/目录下放入技能包，只有当前项目生效，适合与具体产品设计规范绑定；
• 用户级加载：放到用户的全局技能目录下，所有项目都可以访问，适合放置通用型设计技能，比如“UI 设计系统”“前端切图助手”。

如果你使用的是图形化客户端，通常还需要在设置中开启 Skills 功能，然后导入技能文件夹或压缩包。不同入口名称不同，但核心都是让客户端能扫描到 SKILL.md 文件。

3. 设计类 Skill 的配置原理

3.1 SKILL.md 的 frontmatter 怎么写

SKILL.md 头部通常有一段 YAML frontmatter，里面至少包含两个关键字段：name 和 description。

--- name: ui-design-system description: 当用户需要设计界面、制定 UI 规范、生成组件库、检查视觉一致性时使用。也可以在处理需要遵循品牌色的页面时调用。 ---

这里有一个非常关键的经验：description 一定要写清楚“什么时候该调用”。因为模型是根据任务描述来自动判断要不要加载这个技能的。如果 description 写得过于泛化，比如“一个设计技能”，模型很难在具体任务中想到调用它；如果写得过于限定，又可能误触发。

建议在 description 中写出典型的触发场景，例如“当用户提到‘设计规范’‘设计系统’‘组件库’‘登录页设计’‘Dashboard UI’等需求时使用”。这样既能提高识别准确率，也能避免无关任务被技能干扰。

3.2 正文指令推荐的“六段法”

在 SKILL.md 的正文部分，建议按照以下顺序组织内容：

1. 角色定义：告诉 AI 它现在扮演什么角色；
2. 输入理解：列出用户可能给出的输入形式和需要提取的关键信息；
3. 执行流程：把工作拆成明确步骤，步骤之间要有先后顺序；
4. 输出格式：说明最终输出的文件、结构或交付物格式；
5. 验收标准：让 AI 在输出前自查是否满足规范；
6. 禁止事项：明确列出不该做的行为，例如“不要使用自定义颜色”“不要随意添加投影”。

这套结构的好处是，AI 执行任务时有了一个稳定的“思考路径”，不会因为用户的表述变化而跑偏。设计类技能尤其需要这样，因为设计判断非常主观，只有给出明确约束，才能保证输出质量稳定。

3.3 参考资料和脚本如何配合

设计类技能的另一大优势是“指令与数据分离”。指令写在 SKILL.md 里，数据放在 references 中。比如一套品牌色板：

# 品牌色令牌 - --color-primary: #2F54EB - --color-success: #52C41A - --color-warning: #FAAD14 - --color-error: #FF4D4F - --color-text-primary: rgba(0, 0, 0, 0.88) - --color-bg-page: #F5F7FA

当 AI 需要生成界面时，它可以打开这个文件取色，而不是从训练记忆里猜一个“蓝色”。这比把颜色写死在提示词里更可靠，因为模型在处理长文本时，对后文内容的注意力可能衰减，但打开参考文件读取，则是定向获取信息。

如果要做更严格的校验，比如检查两个颜色之间的对比度是否满足可访问性标准，就可以利用 scripts 目录下的 Python 脚本。后续实战案例中会给出一个可直接运行的对比度检测脚本。

4. 实战一：制作一个 UI 设计系统技能

4.1 创建项目结构

首先在本地创建一个干净的技能目录。

mkdir -p my-design-skills/ui-design-system/references mkdir -p my-design-skills/ui-design-system/scripts

你可以在任意位置创建这个目录，后续再把它放到客户端能扫描到的技能目录中。

4.2 编写 SKILL.md

在ui-design-system/SKILL.md中写入以下内容：

--- name: ui-design-system description: 当用户需要设计界面、制定 UI 设计规范、生成组件库、输出设计系统文档，或者希望 AI 严格按照品牌色板与字体规范完成任务时使用。典型触发词包括“设计系统”“UI 规范”“设计规范”“组件库”“配色方案”“设计稿”。 --- # UI 设计系统技能 你是一名经验丰富的高级 UI 设计师，擅长设计系统建设、B 端产品界面和品牌视觉规范。你有一套稳定、可复用、强调一致性的设计方法。 ## 任务目标 根据用户给出的产品描述、页面类型和品牌背景，输出一套完整、可落地的 UI 设计方案或设计规范。 ## 执行流程 1. **需求拆解** - 明确产品类型：B 端管理系统、C 端营销页、移动端 App 还是数据可视化大屏； - 提取关键页面：登录页、Dashboard、表单页、列表页、详情页等； - 确认用户偏好：如果用户对风格有明确描述，优先遵循。 2. **读取设计令牌** - 打开 `references/color-tokens.md`，使用其中定义的颜色； - 打开 `references/typography-scale.md`，使用其中定义的字体层级； - 如果存在用户给出的品牌色，则优先使用用户色板，但需要将色号补充进输出规范中。 3. **制定设计规范** - 输出色板，包括主色、功能色、中性色和背景色； - 输出字体层级，包括标题、正文、辅助文字的字号和字重； - 输出间距单位，建议使用 4px 或 8px 为基础单位； - 输出圆角规范、阴影规范和栅格建议。 4. **产出设计成果** - 如果用户需要组件库，输出核心组件列表及其状态说明； - 如果用户需要页面设计，按“布局结构-视觉规范-关键交互”三个层次描述； - 如果用户需要设计系统文档，整理成 Markdown 格式输出。 ## 验收标准 - 所有颜色必须来自色板令牌，不得凭空自定义； - 所有字号必须来自字体层级； - 常规文本与背景色的对比度应达到 WCAG AA 级别； - 组件状态至少包含默认、悬停、禁用和错误态； - 输出内容必须体现一致性，不允许同一组件在不同场景中使用不同尺寸或颜色。 ## 禁止事项 - 不要在未说明的情况下使用品牌色板之外的近似颜色； - 不要随意添加复杂的渐变、夸张的投影或过大的圆角； - 不要只给一句话结论，必须输出完整的设计规范说明； - 不要忽略移动端适配，如果页面可能在移动端打开，需要给出响应式建议。

这个 SKILL.md 的核心能力，是让 AI 拿到需求后，先读取参考资料，再按照固定流程输出规范。你可以在“禁止事项”中继续补充团队内反感的设计风格。

4.3 添加颜色与字体参考资料

在references/color-tokens.md中写入：

# 颜色令牌 ## 品牌主色 - --color-primary: #2F54EB - --color-primary-hover: #597EF7 - --color-primary-active: #1D39C4 - --color-primary-bg: #F0F5FF ## 功能色 - --color-success: #52C41A - --color-warning: #FAAD14 - --color-error: #FF4D4F - --color-info: #1890FF ## 中性色 - --color-text-primary: rgba(0, 0, 0, 0.88) - --color-text-regular: rgba(0, 0, 0, 0.65) - --color-text-secondary: rgba(0, 0, 0, 0.45) - --color-border: #D9D9D9 - --color-bg-page: #F5F7FA - --color-bg-container: #FFFFFF

在references/typography-scale.md中写入：

# 字体层级 - 大标题：28px / 36px，字重 600 - 标题一：24px / 32px，字重 600 - 标题二：20px / 28px，字重 600 - 标题三：16px / 24px，字重 500 - 正文：14px / 22px，字重 400 - 辅助文字：12px / 20px，字重 400 - 小号标签：12px，字重 500，可用于按钮或标签

这里的字体层级参考的是常见 B 端设计系统，你可以按团队实际规范替换。

4.4 添加对比度校验脚本

在scripts/check_contrast.py中写入：

# -*- coding: utf-8 -*- """ 计算两个十六进制颜色之间的对比度，并判断是否达到 WCAG AA 标准。 用法： python check_contrast.py "#2F54EB" "#FFFFFF" """ import sys import re def hex_to_rgb(color: str) -> tuple: color = color.strip().lstrip("#") if len(color) == 3: color = "".join([c * 2 for c in color]) if len(color) != 6: raise ValueError(f"无法解析颜色值: {color}") return tuple(int(color[i:i + 2], 16) for i in (0, 2, 4)) def luminance(rgb: tuple) -> float: def channel_value(c: int) -> float: c = c / 255.0 if c <= 0.03928: return c / 12.92 return ((c + 0.055) / 1.055) ** 2.4 r, g, b = rgb return 0.2126 * channel_value(r) + 0.7152 * channel_value(g) + 0.0722 * channel_value(b) def contrast_ratio(color1: str, color2: str) -> float: l1 = luminance(hex_to_rgb(color1)) l2 = luminance(hex_to_rgb(color2)) if l1 < l2: l1, l2 = l2, l1 return (l1 + 0.05) / (l2 + 0.05) def verify_wcag(ratio: float) -> str: aa_normal = ratio >= 4.5 aa_large = ratio >= 3.0 aaa_normal = ratio >= 7.0 result = [] result.append(f"对比度：{ratio:.2f}:1") result.append(f"WCAG AA 普通文本：{'通过' if aa_normal else '不通过'}") result.append(f"WCAG AA 大文本：{'通过' if aa_large else '不通过'}") result.append(f"WCAG AAA 普通文本：{'通过' if aaa_normal else '不通过'}") return "\n".join(result) if __name__ == "__main__": if len(sys.argv) != 3: print("用法：python check_contrast.py '#2F54EB' '#FFFFFF'") sys.exit(1) color_a = sys.argv[1] color_b = sys.argv[2] try: ratio = contrast_ratio(color_a, color_b) except ValueError as exc: print(f"颜色格式错误：{exc}") sys.exit(1) print(verify_wcag(ratio))

运行脚本测试：

cd my-design-skills/ui-design-system python scripts/check_contrast.py "#2F54EB" "#FFFFFF"

脚本会基于 WCAG 标准输出对比度结果。你可以在 SKILL.md 的“验收标准”中要求 AI 在完成配色方案后，主动调用这个脚本校验可读性。

4.5 加载技能并验证

把这个ui-design-system文件夹放入客户端对应的技能目录。例如在 Claude Code 中，可以创建一个skills目录，将整个ui-design-system文件夹放进去，然后在项目中输入：

帮我用 ui-design-system 技能生成一个后台登录页的设计规范。

如果配置正确，AI 会主动读取references/color-tokens.md中的色板，并按 SKILL.md 中的流程输出一份规范。你可以观察输出里是否存在“品牌主色 #2F54EB”和“字体层级”这些关键内容，来判断技能是否真正被加载。

5. 实战二：做一个 UI 转前端代码技能

5.1 这个技能解决什么问题

设计交付到前端时，经常出现“设计稿和代码不一致”的问题。设计师的标记文件里明明写的是 8px 圆角，前端却用了 12px；设计稿里按钮主色是 #2F54EB，代码里写成了 #1D39C4。表面看是沟通问题，本质上是“规范没有贯穿设计到代码的整个链路”。

AI 可以帮忙把设计描述直接转换成前端代码，但如果只是让 AI“随便写”，它往往会自由发挥，生成的结果和团队现有组件库完全脱节。UI 转前端代码技能，就是把“项目技术栈、组件命名方式、状态定义、响应式规则”全部固化下来，让 AI 生成代码时有章可循。

5.2 编写 SKILL.md

在my-design-skills/ui-to-code/SKILL.md中创建：

--- name: ui-to-code description: 当用户提供设计稿、设计描述、原型图说明或组件规范，希望转换为 React、Vue 等前端代码时使用。典型触发词包括“转成前端代码”“实现这个页面”“写一个组件”“还原设计稿”。 --- # UI 转前端代码技能 你是一名专业的前端工程师，擅长将设计稿还原为高质量、可维护的组件化代码。 ## 技术栈约束 - 默认使用 React 18 + TypeScript + Tailwind CSS； - 如果用户指定 Vue 或项目技术栈，则遵循用户要求； - 优先使用函数组件，不使用 class 组件； - 样式优先使用 Tailwind 工具类，不使用内联样式。 ## 执行流程 1. **解析设计输入** - 如果用户提供文本描述，提取页面区域、布局结构和交互要求； - 如果用户提供截图或设计稿，先描述页面视觉结构，再转化为代码。 2. **拆解组件结构** - 将页面拆分为可复用组件； - 输出组件树，例如：`Page -> Header + FormArea + Footer`； - 每个组件单独生成一个文件。 3. **生成代码** - 组件命名使用 PascalCase； - 变量和函数命名使用 camelCase； - 样式类名使用 kebab-case； - 必须包含必要注释，解释关键区块的作用。 4. **输出文件** - 按目录结构输出代码，例如 `src/components/Header.tsx`； - 如果代码量较大，先列出文件清单，再逐文件输出； - 涉及表单时，使用受控组件并给出状态管理示例。 ## 验收标准 - 页面结构与设计稿保持一致； - 点击区域和按钮交互完备； - 组件拆分合理，不把整个页面写成一个巨大组件； - 代码没有未定义的变量或死代码； - 对布局容器给出必要的响应式样式。 ## 禁止事项 - 不要使用未在技术栈约束中出现的组件库，除非用户明确要求； - 不要忽略表单校验和边界状态； - 不要把所有样式塞进一个 `div` 上，需要合理使用语义化标签； - 不要生成无法直接编译的残缺代码。

5.3 运行与验证

在客户端中，把ui-to-code技能准备好后，可以尝试输入：

请使用 ui-to-code 技能，把下面这个登录页描述转换成 React 组件： 页面中央有一个白色卡片，左侧是品牌 Logo，右侧是登录表单。表单包含手机号和验证码两个输入框，下方有一个“登录”按钮，按钮左侧有一个“记住账号”勾选框。

期望 AI 输出类似下面的组件结构说明，而不会只是一段凌乱的 JSX：

- src/pages/LoginPage.tsx：页面布局 - src/components/LoginCard.tsx：登录卡片容器 - src/components/PhoneInput.tsx：手机号输入框 - src/components/CodeInput.tsx：验证码输入框 - src/components/LoginButton.tsx：登录按钮

当你发现 AI 输出的代码开始稳定遵循组件化拆分、命名规范和响应式规则时，说明这个技能已经生效了。

6. 为什么这种技能会让设计界“震撼”

6.1 规范从“人肉遵守”变成“模型内化”

过去设计规范主要靠设计师自觉，或者靠设计评审时人工检查。AI 生成内容时，如果每次都要临时读一段长提示词，很容易出现“前面记得住，后面开始自由发挥”的问题。Skills 把规范放进了 AI 的工作路径里，等于让模型在完成设计任务时“自带一份内部规范”。它不需要你反复提醒，就会主动读取色板、字体层级和组件规则。

体验过的人会明显感觉，AI 输出的设计方案不再是“看起来差不多”的通用设计，而是“这个团队的设计语言”下的产物。这种一致性，才是让设计团队愿意长期使用 AI 的根本原因。

6.2 技能包成为团队资产

提示词是写在一个聊天窗口里的，很难沉淀；但技能包是一个个 Markdown 文件和脚本，可以放进 Git 仓库，可以做版本管理，也可以供整个团队共享。

这意味着，当团队更新了品牌色板，只需要修改color-tokens.md，所有使用这个技能的成员都会自动获得新的色彩规范。前端和设计师之间也可以共用同一个“设计系统技能”，从设计到代码的链路变得非常顺畅。

社区里已经出现了一些技能集仓库，比如 Superpower Skills 这类聚合了大量技能的合集，也有一些开发者把技能包发布到共享仓库中。使用时需要注意来源安全性，尽量选择可信的官方或社区维护仓库。

6.3 为自动化设计流水线打下基础

如果你把 Skills 和 Agent 结合，就可以把设计工作流进一步自动化。比如：

• 一个 Agent 负责解析产品需求，产出页面结构；
• 一个 Agent 调用设计系统技能，补充视觉规范；
• 一个 Agent 调用 UI 转代码技能，生成前端代码；
• 一个 Agent 调用测试相关技能，检查代码是否符合可访问性标准或组件状态是否完整。

这种结构正在从“AI 聊天助手”进一步走向“AI 协作团队”。设计师的角色也会从“手动完成设计”变成“定义设计标准和审核 AI 产出”。

7. 常见问题与排查思路

在实际使用 AI Skills 的过程中，比较容易遇到下面几个问题：

排查这类问题时，建议按照“先看目录结构，再看 description 触发条件，再看正文指令”的顺序。因为很多问题不是技能内容写得不对，而是 AI 根本没有正确加载技能。

如果某项技能一直没有触发，可以在对话中直接点名技能名称，例如“请使用 ui-design-system 技能处理这个需求”。这样可以判断是技能本身的问题，还是自动触发机制的问题。

8. 最佳实践与工程建议

8.1 一个技能只做一件事

技能包和函数一样，职责越单一，越容易维护。不要把“UI 设计规范”和“UI 转代码”写进同一个 SKILL.md，否则 AI 在执行任务时容易出现流程混乱。建议每个技能聚焦一个完整工作流，比如“设计规范生成”“前端代码生成”“对比度检查”“设计评审”。

8.2 把参考资料和指令分离

不要把所有颜色、字体、间距都写进 SKILL.md 正文。正文越长，AI 对关键指令的注意力越容易分散。把设计令牌放到 references 目录，让 AI 在需要时去读取，这样既清晰又便于更新。

8.3 每一次修改都做冒烟测试

修改技能后，一定要用同一个测试用例重新跑一遍。比如“生成登录页设计规范”这句话，每次修改后都输入一次，观察输出是否有预期变化。这样可以快速定位是技能内容问题，还是自动触发问题。

8.4 用 Git 管理技能版本

技能包本质上是一份代码资产，建议纳入 Git 管理。这样当某个版本的技能导致输出质量下降时，可以快速回滚到上一个稳定版本。提交信息建议写成“调整色板令牌”“补充禁止事项”等，方便后续回溯。

8.5 安全边界与敏感信息

技能包中不要写入任何硬编码密钥、内部系统地址或敏感个人信息。如果技能需要对外共享，请先检查 references 目录中是否有公司内部资料。还有一点很重要：不要在技能脚本中写高危操作命令，比如删除文件、执行不可信链接等。AI 在客户端中运行脚本时，权限控制也是一个需要关注的安全边界，尽量只给技能最小权限。

8.6 从真实的失败案例中迭代

我第一次做设计技能时，把“输出一份设计规范”写成了一句话指令，结果 AI 只返回了三行话，完全没有组件状态和色彩层级。后来我在正文中加入了“任务目标-执行流程-验收标准-禁止事项”四部分，并把参考文件明确绑定，输出质量才稳定下来。经验是：AI 技能并不是“写越多越好”，而是要写清“必须做什么、禁止做什么、如何自我检查”。

9. 总结与学习路线

本文围绕 AI Skills 在设计领域的应用展开，从概念、环境准备、配置原理到两个完整的实战案例，讲解了 SKILL.md 的编写方式、参考资料和脚本的组织方式，以及常见问题的排查方法。核心收获可以总结成三点：

• AI Skills 是一种比提示词更稳定、更可复用的能力封装方式；
• 设计类技能的关键在于把规范、流程和校验脚本拆分开，让 AI 能自动加载并执行；
• 技能包需要像代码一样管理，持续迭代、做版本控制、注意安全边界。

下一步，建议你先从自己的日常设计任务中选择一个最重复、最依赖规范的场景，尝试做一个最小技能包。可以是“页面配色方案生成”，可以是“组件状态说明生成”，也可以是“设计稿转前端代码”。当你熟练掌握 SKILL.md 的编写后，再进一步学习 Agent 编排和多个技能组合使用，把设计流程真正自动化起来。

如果你对 AI skills 开发感兴趣，也可以多关注社区中的技能合集仓库和各类实战案例。不过一定要记住：别人分享的技能包只能作为参考，最终要调整成符合你自己团队规范和项目上下文的版本，才能真正发挥价值。