企业官网建设流程全解析

AI skills 这个概念，最近在 AI 编程和前端开发圈子里讨论得很多。但“让设计界震撼”这个说法，我觉得要拆开看：真正让设计相关从业者觉得有价值的部分，不是 AI 突然会画画了，而是它能把一套专业工作流固化成可复用的技能包。设计师给出方向、约束和判断，AI 负责执行重复度高的中间步骤，这才是 skills 最值得关注的地方。

这篇文章不聊大而全的概念，只讲清楚三件事：AI skills 到底是什么，它和普通提示词有什么区别；在本地环境里怎么安装和验证一个现成 skills；更重要的是，怎么为一个设计或前端场景写一个自己的 skills，并且让它稳定工作。

如果你用过 Claude Code、Codex 或 OpenCode 这类 AI 编程工具，想进一步控制 AI 的输出结果，不想每次都把长篇背景和规则重新粘贴一遍，这篇文章适合你。如果你是设计师，主要用 Figma、即时设计或直接写 HTML/CSS，想用 AI 做设计规范检查、配色建议或组件代码生成，同样可以参考这里的思路。

1. AI skills 到底改变了什么：从“记住上一步”到“固化专业流程”

先解决一个基础问题：skills 到底是什么，为什么这段时间突然被频繁提到。

1.1 普通提示词和 skills 的本质差异

过去我们和 AI 协作，最常见的方式是在对话框里写一段提示词。比如“你是一位资深 UI 设计师，请帮我检查这个页面的配色是否满足 WCAG AA 对比度要求”，然后 AI 根据这段描述给出一个回答。问题是，下次换一个页面，你又得写一遍，而且 AI 的表现会随着上下文长度、模型版本、对话顺序产生波动。

skills 的思路不一样。它把一段专业任务拆成固定的输入格式、处理步骤和输出要求，然后打包成一个独立文件或目录。AI 工具在遇到对应任务时，会自动加载这个技能包，按照里面定义的规则执行，不需要你每次重新交代背景。

用设计场景举例：

• 没有 skills：每次都要描述“你是设计系统专家，请检查卡片阴影层级是否合理，背景色是…#fff，边框色是…”。
• 有 skills：只要告诉 AI“帮我跑一次设计规范检查”，它会自动读取规范文件、对比设计稿参数、输出不符合项列表和修改建议。

核心差异不是 AI 变聪明了，而是你把专业判断和操作流程沉淀下来了。这就像设计团队把个人审美变成设计规范文档，AI skills 做的就是把规范文档变成可执行脚本。

1.2 为什么设计、前端、测试这类场景最适合先落地

观察目前社区里的 skills 讨论，最容易见效的不是泛泛的文案写作，而是那些有明确输入输出、有固定判断规则、有可重复检核项的任务。设计相关任务刚好符合：

• 设计稿有明确属性，颜色值、字号、间距、圆角、阴影都是可以量化的参数。
• 设计规范有明确标准，比如对比度、栅格倍数、断点范围、组件状态。
• 输出检查有明确目标，要么是通过，要么是不符合并给出原因。

这些特征决定了 AI skills 在设计相关场景不是花架子。它适合用来做设计走查、色彩可访问性检查、前端代码风格统一、组件命名规范校验等工作。

注意：skills 目前更多是增强 AI 工具的任务执行能力，而不是替代设计判断。真正决定结果上限的，仍然是你定义的规则和流程质量。

2. 不同工具对 skills 的支持差异很大，先确认运行环境再动手

AI skills 不是一个统一标准，不同工具的实现方式、配置路径、触发机制都不一样。想把这个能力用起来，第一步不是写 skills，而是确认自己用的工具支持到什么程度。

2.1 常见 AI 编程工具对 skills 的支持情况

从目前能接触到的信息来看，主流的本地 AI 编程工具大多开始支持 skills，但成熟度有差异：

表格里的路径在不同版本中可能变化。我建议动手前先看一眼自己工具的帮助文档，或者直接查看配置目录下有没有skills文件夹。没有就先手动建一个，不影响后续使用。

2.2 本地运行需要什么条件

如果你打算在本地环境安装和使用 AI skills，不需要特别高的硬件配置，但有几个前置条件要满足：

• 已经安装并能正常运行的 AI 编程工具，比如 Claude Code、Codex 或 OpenCode。
• 一个可用的模型访问通道，可以是工具自带的模型接口，也可以是本地部署的模型服务。
• 能访问命令行，因为大部分 skills 都是通过命令行工具加载的。
• 如果涉及设计稿解析、截图检查或大文件处理，要保证内存和磁盘空间够用。

很多人看到“AI skills 推荐”就以为要配一台高显存机器，这个理解有偏差。skills 本质是一个规则包，真正消耗资源的是背后运行的模型。如果你用的是云端模型，本地只需要负责读文件、拼题目、解析输出，压力不大。

踩坑提醒：安装 skills 后如果发现不生效，先不要怀疑模型能力，先看配置目录是否被工具正确识别。很多问题出在目录拼写、文件命名和 frontmatter 格式上，而不是 AI 本身。

3. 安装一个现成 skills，先用最小样例验证完整链路

如果你从来没装过 skills，不建议上来就自己写，也不建议一次性装十几个热门仓库。更稳的做法是：先装一个，跑通单条任务，确认输入、输出、日志都正常，再去扩充。

3.1 找一个可信的 skills 来源

现在社区里可以找到不少现成 skills，比如一些前端开发 skills、测试辅助 skills、学术写作 skills。搜索时可以用“skills 列表”“awesome skills”“SKILL.md 示例”这类关键词，找到的仓库一般会附带 README 和安装说明。

选择时留意几点：

• 仓库是否有明确的目录结构和 README。
• 是否有作者维护和更新记录。
• 是否包含SKILL.md主文件和必要的示例素材。
• 是否说明了适配的 AI 工具版本。

不要看到仓库 star 多就盲目安装。有些项目只写了理念，没有提供真正可运行的技能包；有些项目则是为特定工具写的，换一个工具就不兼容。

3.2 安装步骤和验证方法

以本地目录型 skills 为例，安装流程一般是这样：

# 进入你的项目目录或者全局配置目录 cd your-project # 创建 skills 目录（如果不存在） mkdir -p .claude/skills # 把下载的 skills 复制到对应目录 cp -r ~/Downloads/my-skill .claude/skills/

安装完成后，先不要直接进入复杂任务。打开 AI 工具，用一条最小问题测试：

请使用 my-skill 技能，检查当前目录下 design-tokens.json 文件中的颜色变量是否符合对比度要求。

判断是否成功，看三个信号：

• 工具是否主动加载了 skills 描述，而不是把你说的内容当普通对话。
• 输出是否按照SKILL.md中规定的格式返回，而不是自由发挥。
• 日志或提示中是否出现 skills 的名称或版本标识。

如果三条都满足，说明安装链路没问题。如果工具完全忽略了这个技能，先检查目录路径和SKILL.md的 frontmatter 字段是否完整。

3.3 单条任务跑通后再考虑批量

一个常见误区是：skills 一装好，就希望它能批量处理几十个文件。结果发现第一个文件就卡住了，然后开始怀疑是 skills 写得不行。

其实应该先跑单个文件、单个输入，确认链路完整后再做批量。批量任务不是临时把文件列表丢给 AI 就行，它涉及：

• 输入文件命名是否规范。
• 每个文件的格式是否一致。
• 输出结果怎么命名，避免互相覆盖。
• 某个文件失败时，程序是否继续处理下一个。
• 日志里能否区分是哪个文件生成的哪个结果。

这些内容属于工程化问题，和 skills 本身无关。但如果你不做规划，批量任务一定会在中间某个文件上失败。

4. 手写一个自己的 skills：设计场景的完整示例

安装现成 skills 只能帮你建立体感。真正让 skills 产生长期价值，是学会自己写。下面用一个设计走查场景举例，说明如何从零开始写一个可用的 skills。

4.1 先定义任务边界和输入输出

假设我要做一个“设计规范检查技能”，它的定位是：帮前端开发者和 UI 设计师检查项目里的样式代码是否遵循设计规范。

先明确输入：

• 项目中的 CSS/SCSS 文件。
• 或者一个 design tokens 数据文件。
• 或者一组用 Tailwind 类名编写的组件代码。

再明确输出：

• 不符合规范的项清单。
• 每一项涉及的文件路径、行号、现状值、期望值。
• 修改建议和示例代码。

为什么要先定义输入输出？因为 skills 本身不是一个完整的程序，它是给 AI 看的行为说明书。如果你不把输入输出写清楚，AI 在执行时就会猜测，结果每次都不一样。

4.2 创建 skills 目录和文件

一个最小的 skills 通常包含两类内容：

• SKILL.md：主文件，描述技能的名称、适用场景、执行步骤、输出格式。
• 示例文件：一个或多个样例输入，方便 AI 理解任务格式。

目录结构可以这样设计：

design-review-skill/ ├── SKILL.md └── examples/ ├── input.scss └── expected-output.md

SKILL.md的内容要分成几个区块。下面是一个简化示例，实际使用时可以根据自己的规范补充：

--- name: design-review description: 检查设计稿、样式代码或设计变量是否符合指定设计规范，适用于 UI 走查、前端代码审查、设计系统一致性检查。 --- # 设计规范检查技能 ## 适用场景 - 检查颜色变量是否满足 WCAG AA 对比度要求。 - 检查间距值是否使用设计规范中的间距倍数。 - 检查字体字号和行高是否符合排版规范。 - 检查组件是否存在重复定义或命名冲突。 ## 输入 - 目标文件路径或文件内容。 - 可选：设计规范文件路径。 ## 执行步骤 1. 读取目标文件，识别其中的样式规则。 2. 提取颜色、间距、字号、圆角、阴影等设计属性。 3. 将提取结果与设计规范逐项对比。 4. 输出不符合规范的项目列表。 5. 对每项给出修改建议。 ## 输出格式 - 检查结果：通过 / 不通过。 - 问题列表：文件路径、行号、当前位置、期望值。 - 修改建议：代码片段或推荐参数。 ## 注意事项 - 如果规范文件中没有定义某个属性，不视为问题。 - 遇到提取失败的格式，在日志中记录并跳过。 - 不要在没有依据的情况下修改代码，只输出建议。

这个文件的核心作用，不是教 AI“什么是设计规范”，而是告诉 AI“拿到任务后怎么一步步执行、按什么格式输出”。AI 本身已经知道什么是颜色、什么是间距，它缺的是你的流程约定。

4.3 用最简单场景测试

写好之后，不要直接让它扫整个项目。先给它一个很小的文件：

// input.scss $primary: #007bff; $text-color: #666666; $spacing-md: 8px; $spacing-lg: 18px;

然后发起测试请求：

请用 design-review 技能检查 examples/input.scss，使用的设计规范为：正文字号不小于 12px，主色对比度需达到 AA 级，间距必须使用 4px 的倍数。

重点看 AI 是否能按SKILL.md里规定的格式输出。如果 AI 没有执行步骤，而是直接给出了一段自由格式回答，那说明 frontmatter 里的description与本次请求的匹配度不够，或者工具没有正确加载技能。

这个排查方式同样适用于其他场景：写一个技能后，先准备一个可控输入，跑一次，看输出，再迭代描述。

5. 把 skills 放进真实设计工作流：从单任务到批量处理

会写一个简单的 skills 之后，下一步是考虑怎么把它真正用起来。这一步才是很多教程没有展开的地方：单任务上去了，批量怎么处理，多人协作怎么维护，遇到不同输入格式怎么办。

5.1 设计走查场景的落地流程

我接触过的常见落地方式是这样：

第一步，把团队设计规范中的关键参数整理成独立文件，比如design-tokens.json或design-tokens.yaml。不要把它们散落在各处，让 skills 通过固定路径读取。

第二步，让 skills 同时接受“代码文件输入”和“规范文件输入”两个参数。这样它既检查了代码，又读取了规范，而不是临时把规范粘贴到对话里。

第三步，设计走查时，不是直接把整个项目丢进去，而是先让 AI 扫描项目结构，输出样式文件清单，再逐个文件执行检查。

第四步，把 AI 输出的问题清单导入 Issue 系统或飞书文档，分配给人处理。

这个流程下来，一次走查的重复劳动会大幅减少。但要注意，AI 输出永远需要人工确认。凡是涉及颜色对比度、组件状态、无障碍需求的判断，以实际效果为准，不要只看 AI 给的结论。

5.2 没有代码文件时，怎么用 skills 处理设计稿

有些读者可能不写代码，主要使用设计工具。这种场景下，skills 也能用，但要换一种输入形式。

目前可行的做法：

• 把设计稿导出为 HTML 或 CSS 文件，再用 skills 做检查。
• 把设计稿导出为 JSON 格式的设计变量，比如 Figma Tokens 插件导出的文件。
• 用设计稿截图作为输入，让 AI 基于视觉信息执行检查，配合视觉模型。

第一种做法最稳定，因为它有结构化数据，AI 容易解析。第二种做法适合有设计令牌管理流程的团队。第三种做法依赖视觉模型能力，质量波动会大一些，适合做初筛，不适合做严谨规范验收。

经验：导入 JSON 设计变量比直接传截图可靠得多。如果你已经把设计规范数字化了，优先选择 JSON 或 YAML 输入。

5.3 多人协作时 skills 怎么维护

skills 很容易出现一个现象：写的时候很认真，用了一周之后发现没人维护，规范更新了它不更新，最后被废弃。

要避免这个问题，从一开始就把 skills 当代码管理：

• skills 目录纳入 Git 仓库，变更走分支和提交记录。
• SKILL.md和规范文件分开维护。规范文件每周可能更新，技能主文件尽量保持稳定。
• 遇到规范变化时，只更新规范数据文件，不频繁改技能逻辑。
• 每个技能配套一个示例文件，方便新成员快速理解它的输入输出。

多人协作时，还容易遇到一个问题：不同人复制了不同版本的 skills。建议团队内统一使用同一个仓库路径，通过 Git 拉取，不要用网盘或聊天工具传文件。

6. skills 不生效或结果不稳定时，按这个顺序排查

任何工具用一段时间都会遇到问题。skills 最常见的异常包括：不触发、输出格式不符合预期、中途报错、每个任务结果差异大。下面给出一个实际排查顺序，按优先级从高到低执行。

6.1 先看日志和路径，再怀疑 AI 能力

遇到 skills 没有生效，我的第一反应不是模型不行，而是先确认它到底有没有被读取。

按下面顺序检查：

1. 工具是否输出了错误日志，比如“skill not found”“cannot read SKILL.md”。
2. 配置目录是否正确。~/.claude/skills/、.claude/skills/、~/.codex/skills/不要搞混。
3. 文件是不是叫SKILL.md，注意大小写和扩展名。
4. frontmatter 里的name和description是否存在，格式是否为 YAML。
5. 工具版本是否支持 skills。有些老版本工具根本没有这个能力。

如果这些问题都不存在，再考虑是不是描述写得不够清晰，导致 AI 没有自动匹配到这个技能。

6.2 输出不稳定时，检查输入和规则定义

skills 的表现如果时好时坏，最常见的原因是输入格式没有统一。比如同一个技能既能读 CSS，又能读 JSON，输出自然不稳定。解决办法是明确限定输入类型，或者把不同格式拆成不同技能。

第二个常见原因，是规则定义里存在模糊表达。比如“检查颜色对比度是否达标”，AI 可能不知道你要按哪个标准，是 WCAG AA 还是 AAA，是普通文本还是大文本。这些必须在SKILL.md里写死，或者通过参数传入。

第三个原因，是输出格式约束不够。如果要求 AI 必须按表格输出，就要在技能里写出表格模板，而不是只说“整理成表格”。

6.3 资源占用过高或批量任务失败时，先降并发

如果你在本地跑大模型，并且用 skills 批量处理文件，遇到卡顿或 OOM，优先检查并发数。我一般会先设置单线程任务，确认无异常后再增加并发，而不是一次性把代码文件全部丢进去。

批量处理时还要考虑输出目录是否存在。很多 skills 报错不是模型问题，而是系统权限或路径没有提前建好。比如输出目录./output/reports不存在，AI 无法自己创建目录，任务就会失败。

7. 别把 skills 当银弹：边界、局限和更合适的替代方案

最后聊聊边界。skills 确实能让 AI 在某些场景下更可控，但它不是万能的。对这个能力期待值过高，反而容易忽略更合适的方案。

7.1 skills 适合做什么，不适合做什么

从实际使用反馈来看，skills 适合以下任务：

• 步骤明确、输出格式固定的任务。
• 需要反复执行的标准作业流程。
• 规则可以通过文本清晰表达的场景。
• 可以被模型上下文容纳的中小型文件处理。

不适合的任务包括：

• 高度依赖主观审美判断的任务。比如“这张海报看起来是否高级”，这类判断没有明确规则，skills 无法固化。
• 依赖大型数据集的搜索和分析任务。skills 本身不是数据库，它只是给模型提供操作指导。
• 需要大量长对话上下文的任务。如果任务涉及多个历史追问，skills 的外部规则可能冲淡对话连续性。
• 需要调用复杂外部 GUI 的任务。skills 可以调用命令行程序，但很难稳定操作设计软件界面。

7.2 什么时候用提示词，什么时候用脚本，什么时候用 skills

很多人会把三件事混在一起。实际选择可以按复杂度判断：

如果你的任务只需要处理一次，直接用提示词。如果每周都要做一次，适合用 skills。如果任务要处理大量文件且格式极端稳定，写一个 Python 脚本可能比 skills 更可靠。

7.3 我建议的落地路径

如果你现在正准备入局 AI skills，我的建议是分四步走。

第一步，只安装一个现成的高质量 skills，跑通一次完整链路，培养判断标准。 第二步，写一个自己能控制的最小技能，哪怕只是帮你把两个 CSS 文件里的颜色值提取出来对比。 第三步，把自己最常做的事写进 skills，每两周用一次，根据实际输出调整规则。 第四步，当遇到“想重复但总记不住完整规则”的任务，再继续扩容技能包。

如果只是学习，不建议一开始就追求装几十个技能。真正用起来之后，你会发现常用的就那么三五个。与其堆数量，不如把最重要的几个维护到能用、好用、大家愿意用。

AI skills 这个方向还在快速变化，不同工具的实现方式也在演进。今天写的东西，可能过几个月配置路径就变了。但只要把握住一条原则——把专业流程沉淀成可复用规则，用结构化输入输出约束 AI 的行为——换任何工具，你都能很快上手。