企业官网建设流程全解析

最近这两周，“AI skills”这个词在开发者社区里的热度上升得非常快，而且第一批被吸引过来的，不只是程序员，还有大量设计师和前端工程师。原因并不复杂：过去我们和 AI 对话，它只能“回答问题”或者“生成一段代码”，一旦任务稍微复杂一点——比如“依据设计稿里的 Design Token 生成一整份主题配置，再校验一遍命名是否规范”——AI 就会开始东一句西一句，输出质量完全随机。而 Skills 机制出现之后，这类多步骤、需要专业判断和固定规范的任务，第一次可以被稳定地封装、复用和分发。

这篇文章不打算复述一遍官方文档，而是想讲清楚三件事：第一，AI Skills 到底是什么，它和普通 Prompt、和 AI Agent 有什么区别；第二，为什么它会率先在设计相关的工作流里引发关注；第三，作为开发者或设计师，你可以怎样编写、安装和使用一个真正能落地的 Skill。文章最后会给出完整示例代码，你复制到本地就能跑通一个最小流程。如果你最近正在研究 AI Agent、Claude Code skills、Codex skills 或者前端开发 skills，这篇文章应该能帮你把概念和实操一次性理顺。

1. AI Skills 到底是什么，为什么设计界会关注它

很多人第一次听到“AI skills”，第一反应是：这不就是更长的 Prompt 吗？这个理解只对了一半。

AI Skills 的完整形态，其实是一个“结构化的技能包”。它不只是几句提示词，而是把任务描述、执行步骤、参考示例、可运行脚本、验证规则打包在一起，放在一个独立的目录里。当 AI Agent 接到相关任务时，它会主动读取这个技能包，按照里面定义好的流程去执行，而不是临时凭感觉发挥。

举一个设计场景的例子。

假设你负责一套企业级 UI 组件库的维护，设计团队每次更新 Design Token，前端都要手动把 Figma 导出的 JSON 转换成 CSS 变量、Tailwind 主题配置或者小程序样式文件。这个过程看起来不复杂，但实际做起来很麻烦：命名风格要统一，颜色要转成 hsl 或 oklch，圆角要映射到正确的语义层级，深色模式还要额外处理一套变量。如果直接让 AI 来做，它可能第一次生成得不错，第二次就换了一套命名规则，第三次连缩进都变了。

有了 Skill 之后，你可以把“Design Token 转主题配置”这一整套经验写成一份技能包，里面写明：输入文件是什么样的、输出文件必须用哪套命名规范、转换脚本放在哪个路径、结果校验需要跑哪条命令。Agent 每次启动任务时，会加载这份技能包，输出稳定到像执行一次自动化流水线。

设计界会关注 AI Skills，核心原因就是它解决了 AI 生成结果“不稳定”的问题。设计师和前端配合时，最怕的不是 AI 不会写代码，而是 AI 每次给出的结果都不一样，无法沉淀成团队资产。Skills 机制第一次把“人的经验”变成了“AI 的可执行模块”，这东西对设计规范落地、UI 还原、前端联调这类任务来说，价值是直接且明显的。

2. Skills、Prompt、Agent 三者的边界

要真正理解 Skills，最好把几个高频概念放到一起对比。

从这个角度看，Skills 并不是 Prompt 的替代品，而是 Agent 的“能力底座”。

没有 Skills 的 Agent，像一个有悟性但没有经验的实习生。你给它一个模糊任务，它能做，但质量不稳定。你夸它一句“做得不错”，它下次可能换个思路；你批评一次，它可能改得过头。有了 Skills，Agent 就相当于拿到了一份写清楚“干什么、怎么干、用什么工具干、干完怎么验证”的岗位手册，表现会稳定很多。

在技术实现上，目前主流的 AI 编程工具，包括 Claude Code、Codex、Cursor，以及国内一些 AI 编程助手，都在往这个方向走。不同工具的 Skills 目录结构和加载方式略有差异，但核心思路一致：在项目里放一个skills或.claude/skills目录，里面每个子目录就是一个技能包，包含说明文件、脚本和资源。Agent 在对话中识别到相关任务时，会去读取这些技能包。

这里要划一个重点：Skills 不是魔法，它不会让 AI 突然学会一个它本来就不会的能力。它的作用是“约束过程”和“注入经验”。AI 本身依然是那个大模型，但 Skill 提供了更好的上下文、更明确的步骤、更可靠的校验方式，所以最终结果的质量和稳定性会显著提升。

3. AI Skills 对设计工作流的真实改变

设计行业和软件工程的交界地带，一直有很多“看似简单、实则重复”的工作。它们不需要特别高的创造力，但需要严格遵守规范，比如设计稿还原、Design Token 转换、切图命名、组件状态整理、视觉走查。这些工作恰恰是 AI Skills 最容易发挥价值的地方。

3.1 设计稿转代码从“一次性生成”变成“反复可用”

过去我们用 AI 做设计稿转代码，是一个“一次性对话”的体验：上传设计稿截图，让 AI 生成 HTML/CSS，然后复制到项目里微调。下一次再做类似页面，又得重新描述一遍需求，AI 又是从零开始发挥。

Skill 改变的是这个流程。你可以把团队的前端代码规范、组件库用法、样式方案写进技能包。后续每次做页面还原，Agent 会自动加载这份规范，生成的代码从一开始就符合团队约定，而不是生成完了再改。

3.2 设计系统维护从“人工搬砖”变成“自动同步”

设计系统最核心的资产是 Design Token。设计侧改了主色、间距、字体大小，前端侧需要同步更新多处配置文件。用 Skill 后，整个同步过程可以变成一个命令：

npx ai-token-sync ./design-tokens.json ./src/theme

这条命令背后，Agent 会读取技能包，执行转换脚本，自动生成或更新主题文件，并根据规则校验颜色对比度、命名规范等。传统需要半小时的同步工作，压缩到了几分钟，而且过程可重复。

3.3 视觉走查从“人眼比对”变成“规则校验”

设计师最怕的是前端还原出来的页面，颜色差一点、圆角差一点、间距差一点。用 AI 做视觉走查时，如果只是简单地把设计稿和截图丢给 AI 看，它给出的结论往往比较模糊。但如果写一个视觉走查 Skill，把团队的误差容忍度、重点检查清单、常见问题库都写进去，AI 就能产出格式统一的走查报告，甚至能自动定位到具体元素和样式代码。

这种变化的本质，是把过去存在于资深设计师脑子里的“隐性经验”，变成 AI 可以反复调用的“显性规则”。AI 没有取代设计师的判断力，但它让判断力的传递和复用变得更便宜了。

4. AI Skills 的标准结构与编写方法

目前社区里主流的 Skill 结构，基本可以概括为“一个目录 + 一个说明文件 + 若干脚本/资源”。下面是一个最常见的最小目录结构：

my-skill/ ├── SKILL.md ├── scripts/ │ └── convert_tokens.py ├── assets/ │ └── example-input.json └── README.md

4.1 SKILL.md 是技能包的核心

SKILL.md是整个技能包的大脑。它通常包含两部分内容：开头的 YAML frontmatter 和正文。

YAML frontmatter 里最重要字段是name和description。description尤其关键，因为 Agent 会通过它来判断“当前用户的请求是否应该触发这个技能包”。如果 description 写得太宽泛，Agent 可能会在无关任务时也加载它，浪费上下文；写得太狭窄，Agent 又识别不出来，Skill 形同虚设。

正文部分需要写清楚的事情包括：

• 这个 Skill 适用于什么场景，不适用于什么场景；
• 输入是什么，输出是什么；
• 执行步骤是什么，先后顺序如何；
• 需要调用哪些脚本，脚本的输入参数如何传递；
• 输出结果如何校验，什么样的结果算合格。

听起来像写技术方案，但实际上，这就是把一次高质量人工任务的做事流程，完整地“教”给了 AI。

4.2 一个最小 SKILL.md 示例

假设我们要写一个“Design Token 转 Tailwind 主题配置”的 Skill，SKILL.md可以这样写：

--- name: design-token-to-tailwind description: 将设计团队的 Design Token JSON 文件转换为 Tailwind CSS 主题配置。当用户提供 design-tokens.json 或提到“同步设计变量”“生成 tailwind 主题”“转换 token”时使用。 --- # Design Token 转 Tailwind 主题配置 将输入的设计 Token JSON 转换为 Tailwind CSS 的 `tailwind.config.js` 中 theme.extend 可用的配置片段。 ## 使用场景 - 设计团队更新了 Design Token，需要同步前端主题配置 - 需要从零为项目生成 Tailwind 主题基础变量 ## 不适用场景 - 不需要处理组件级样式代码 - 不负责图片资源压缩 ## 输入 - Design Token JSON 文件，格式参考 `assets/example-input.json` ## 执行步骤 1. 读取 Design Token JSON。 2. 运行 `python scripts/convert_tokens.py <input.json> <output.js>` 转换文件。 3. 检查生成的 JS 文件是否符合输出规范。 ## 输出规范 - 颜色统一使用 hsl 格式。 - 命名采用 camelCase。 - 每个 token 注释中标注原始 token 名，方便追溯。 ## 校验方式 运行 `node -e "require('./output.js')"`，确保没有语法错误。

4.3 脚本放在 scripts 目录

Skill 的优势在于，它可以调用真正的脚本来完成 AI 不擅长的工作。比如格式转换、批量文件处理、数据校验和计算，这些任务用传统编程脚本做更可靠。AI 主要负责理解用户意图、拼接上下文、调用脚本，最后整理输出结果。

这其实是 AI Skills 一个很容易被忽视的设计思想：不要让 AI 做它不擅长的事，而是让 AI 把任务拆解给合适的工具。对于设计 Token 转换这种需要精确计算和稳定格式的任务，脚本比大模型更可靠。

5. 完整示例：把 Design Tokens 转成 Tailwind 主题配置

下面这个示例，你可以直接复制到本地跑通。它能帮你直观理解 Skill 从编写到使用的全过程。

5.1 准备项目目录

先创建一个项目目录，并建立以下结构：

mkdir -p design-token-skill/{scripts,assets} cd design-token-skill

最终目录结构：

design-token-skill/ ├── SKILL.md ├── scripts/ │ └── convert_tokens.py └── assets/ └── example-input.json

5.2 编写输入样例

assets/example-input.json：

{ "color": { "primary": { "default": "#3B82F6", "hover": "#2563EB", "disabled": "#93C5FD" }, "neutral": { "background": "#F9FAFB", "text": "#111827", "border": "#E5E7EB" } }, "radius": { "sm": "4px", "md": "8px", "lg": "12px" }, "spacing": { "page": "24px", "section": "16px", "item": "8px" } }

这个样例模拟了设计团队导出的一份简化版 Design Token，包含颜色、圆角、间距三类变量。

5.3 编写转换脚本

scripts/convert_tokens.py的作用是读取输入 JSON，输出一份 Tailwind 配置片段。这里我们用 Python 标准库实现，不依赖第三方包：

#!/usr/bin/env python3 # scripts/convert_tokens.py import json import sys from pathlib import Path def hex_to_hsl(hex_color: str) -> str: """将 HEX 颜色转换为 hsl() 字符串。""" hex_color = hex_color.lstrip("#") if len(hex_color) != 6: return hex_color r = int(hex_color[0:2], 16) / 255 g = int(hex_color[2:4], 16) / 255 b = int(hex_color[4:6], 16) / 255 max_c = max(r, g, b) min_c = min(r, g, b) delta = max_c - min_c if delta == 0: h = 0 elif max_c == r: h = 60 * (((g - b) / delta) % 6) elif max_c == g: h = 60 * (((b - r) / delta) + 2) else: h = 60 * (((r - g) / delta) + 4) l = (max_c + min_c) / 2 if delta == 0: s = 0 else: s = delta / (1 - abs(2 * l - 1)) return f"hsl({round(h)}, {round(s * 100)}%, {round(l * 100)}%)" def convert_token_group(group: dict, output: dict, prefix: str = "") -> None: """递归转换 token 分组，生成扁平化且保留分组的输出结构。""" for key, value in group.items(): current_key = f"{prefix}{key}" if prefix else key if isinstance(value, dict): output[current_key] = {} convert_token_group(value, output[current_key], prefix="") elif key == "default": output[key] = value else: output[prefix + key] = value def main(): if len(sys.argv) != 3: print("用法: python scripts/convert_tokens.py <input.json> <output.js>") sys.exit(1) input_path = Path(sys.argv[1]) output_path = Path(sys.argv[2]) with input_path.open("r", encoding="utf-8") as f: tokens = json.load(f) theme = {} if "color" in tokens: theme["colors"] = {} for color_group, color_values in tokens["color"].items(): theme["colors"][color_group] = {} for shade, hex_value in color_values.items(): theme["colors"][color_group][shade] = hex_to_hsl(hex_value) if "radius" in tokens: theme["borderRadius"] = {} for size, radius_value in tokens["radius"].items(): theme["borderRadius"][size] = radius_value if "spacing" in tokens: theme["spacing"] = {} for size, spacing_value in tokens["spacing"].items(): theme["spacing"][size] = spacing_value js_content = "// 自动生成，请勿手动编辑\n// 来源: design-tokens.json\n\n" js_content += "module.exports = " + json.dumps(theme, indent=2, ensure_ascii=False) + ";\n" output_path.write_text(js_content, encoding="utf-8") print(f"转换完成，输出文件: {output_path}") if __name__ == "__main__": main()

这段脚本的核心逻辑是：把颜色值统一转成hsl()格式，然后按colors、borderRadius、spacing三个分组生成 Tailwind 配置。设计团队改一次 token，前端跑一次脚本就能重新生成主题配置，避免了手动改 CSS 变量时容易出现的漏改和标注不一致。

5.4 运行并验证

在项目目录下执行：

python scripts/convert_tokens.py assets/example-input.json output.js

预期生成的output.js大致如下：

// 自动生成，请勿手动编辑 // 来源: design-tokens.json module.exports = { "colors": { "primary": { "default": "hsl(217, 91%, 60%)", "hover": "hsl(221, 83%, 53%)", "disabled": "hsl(214, 95%, 78%)" }, "neutral": { "background": "hsl(0, 0%, 98%)", "text": "hsl(220, 9%, 20%)", "border": "hsl(220, 13%, 91%)" } }, "borderRadius": { "sm": "4px", "md": "8px", "lg": "12px" }, "spacing": { "page": "24px", "section": "16px", "item": "8px" } };

验证命令：

node -e "const theme = require('./output.js'); console.log(theme.colors.primary.default);"

如果输出hsl(217, 91%, 60%)，说明脚本和输出文件都是正常的。这一步也是 Skill 描述里“校验方式”可以复用的做法。

6. 如何安装和使用 AI Skills

写完一个 Skill 之后，还需要让 AI Agent 能加载到它。这里以主流的 AI 编程工具为例，介绍通用的安装和配置思路。不同工具的目录名会有差异，但底层逻辑基本一致：把 Skill 放到 Agent 会扫描的目录里，或者在项目配置中声明 skills 目录。

6.1 放置到 Agent 的 Skills 目录

以 Claude Code 这类工具常见的项目结构为例，你可以在项目根目录创建：

mkdir -p .claude/skills/design-token-to-tailwind

然后将前面写好的SKILL.md、scripts、assets拷贝到这个目录下：

cp -r SKILL.md scripts assets .claude/skills/design-token-to-tailwind/

此时目录结构为：

你的项目/ ├── .claude/ │ └── skills/ │ └── design-token-to-tailwind/ │ ├── SKILL.md │ ├── scripts/ │ │ └── convert_tokens.py │ └── assets/ │ └── example-input.json ├── design-tokens.json └── src/

把design-tokens.json放到项目里后，你只需要在对话中告诉 Agent：“根据 design-tokens.json 生成 Tailwind 主题。”Agent 如果正确识别到这个请求，就会自动加载design-token-to-tailwind这个技能包，按SKILL.md里定义的步骤执行转换脚本并输出结果。

6.2 在全局配置中声明 Skills

如果你希望某个 Skill 对所有项目全局生效，一般可以将它放到用户目录下的 Skills 目录中，例如：

mkdir -p ~/.claude/skills/design-token-to-tailwind cp -r SKILL.md scripts assets ~/.claude/skills/design-token-to-tailwind/

不同 AI 编程工具的全局目录名称不太一样，有些使用~/.codex/skills，有些使用~/.cursor/skills，还有团队会习惯放在内部代码仓库统一维护。使用前先确认一下你所用工具的文档，或者直接看社区里分享的安装方式。稳妥的做法是：先在项目级目录里跑通，再决定是否要全局安装，这样可以减少误触发。

6.3 通过命令行快速启用

如果你的 Skill 本身带有命令行入口，也可以直接在项目脚本里配置。比如在package.json中添加一个 npm script：

{ "scripts": { "tokens:sync": "python .claude/skills/design-token-to-tailwind/scripts/convert_tokens.py design-tokens.json src/theme/generated.js" } }

这样团队成员不需要了解 Agent 交互，直接执行：

npm run tokens:sync

也能完成同样的转换任务。也就是说，Skill 里的脚本不一定只能由 AI Agent 调用，它本身也是一个可复用的工程化工具。这种“Agent 可调用，人也可直接运行”的双重属性，是 Skill 比普通 Prompt 更工程化的关键。

7. 常见问题与排查思路

在编写和使用 AI Skills 的过程中，有些问题几乎每个人都会遇到。下面这张表汇总了最高频的几类问题和排查方向。

最需要提醒的是：Skill 的核心价值在“规范”两个字。如果你的SKILL.md写得很模糊，那么 AI 的表现自然也会模糊。写 Skill 跟写需求文档一样，细节越清晰，结果越可控。

8. 最佳实践与工程建议

当你准备把 AI Skills 用到实际项目或团队协作中时，下面这些建议值得提前考虑。

8.1 Skill 描述要写在“触发条件”

description不是简单介绍这个功能，而是写给 Agent 的“触发识别器”。建议用这样的句式：当用户【提供什么输入】或【表达什么意图】时，使用本技能。不要用“这是一个转换工具”这种泛泛的话术，而要用“设计 Token 转 Tailwind”“同步设计变量”“生成主题配置”这类任务导向的描述。

8.2 脚本保持幂等和简洁

Skill 里的脚本应该做到：重复执行多次，结果一致；不依赖执行者的个人环境；不产生意外的副作用。输出文件最好标注“自动生成，请勿手动编辑”，必要的时候可以生成临时文件预览，确认无误后再覆盖正式文件。

8.3 考虑安全边界

让 Agent 自动执行脚本，相当于赋予了它调用本机命令的能力。因此 Skill 脚本里要遵守最小权限原则：只在明确指定的目录内读写文件，不主动删除文件，不读取环境变量以外的敏感信息。如果你希望 Skill 支持自动化写回文件，建议先输出到目标目录的临时文件，经人确认后再替换。任何涉及数据删除、覆盖或认证信息的操作，都要经过合法授权，并在测试环境验证后再用于生产。这一点在团队协作时尤其重要，否则一个写得不严谨的 Skill 可能会误改团队公共配置。

8.4 把 Skill 当作代码来管理

Skill 有目录、有文件、有脚本、有版本，本质上就是一个代码工程。团队内部使用多个 Skill 时，建议单独建一个仓库维护，使用语义化版本号。Skill 的更新要走代码评审，而不是改完就广播。设计团队的 Style Guide 更新后，Skill 里的转换规则和示例样例也要同步更新，否则会出现“设计规范已经变了，但 AI 还在沿用旧规则”的情况。

8.5 先跑通最小示例，再扩展复杂度

如果你是第一次接触 AI Skills，不建议一上来就写一个庞大的技能包。先复制本文第 5 节的示例，在你的 Agent 工具里跑通一次，确认加载机制、脚本调用路径都正常，再逐步加入校验命令、多场景分支、参考样例。这个顺序能帮你快速建立对 Skill 工作方式的直觉，也更容易定位问题。

9. 下一步可以做些什么

如果你已经理解了 AI Skills 的机制，下一步最值得做的事情是：从你自己最讨厌的那类重复工作里，抽一个出来写成 Skill。设计师可以从“导图规范命名”开始，前端可以从“接口数据转 TypeScript 类型”开始，测试同学可以从“按缺陷模板生成 Bug 报告”开始。一个 Skill 不需要覆盖很大的场景，只需要把一个小任务做到稳定、可复用，它的价值就已经超过了大部分泛泛而谈的 AI 使用技巧。

Skill 的本质不是魔法，而是把过去散落在人脑里的经验，压缩成一个 Agent 可以稳定执行的工作包。设计界的下一步，也许不是让 AI 取代设计师，而是让每一位设计师都能把自己的判断写成 Skill。当这些技能包慢慢沉淀下来，设计系统维护、设计稿还原、前端联调这些琐碎工作，才会真正变轻。