企业官网建设流程全解析

AI skills 最近成了设计圈和前端圈绕不开的关键词。我在把一个“设计稿转页面结构”的流程做成可复用 skill 之前，一直觉得它只是“把提示词存成文件”，没什么值得深究。后来真正跑完一条完整链路才发现，这个看起来很小的抽象，其实把 AI 的用法从“一次问答”推进到了“能力封装”。对每天要处理设计稿、组件库、响应式适配的人来说，这带来的变化不是省几分钟，而是把很多不确定的重复劳动，变成了一套可以长期维护的标准动作。这篇文章我从自己在 AI 编程场景里使用 skills 的经验出发，说说它到底改变了什么、怎么从零写一个 skill、落地时最容易在哪几个环节出问题，以及最后怎么判断它适不适合你。

1. 先搞清楚 AI skills 真正解决的是哪一类重复劳动

1.1 它不是“多存了几段提示词”，而是把工作流固化了

很多人初次看到 skills 概念，会把它和提示词模板画等号。传统的提示词模板只负责把一段指令保存下来，重新粘贴给 AI 时，AI 仍然不知道整个任务有哪些约束、需要什么输入、输出放在哪里、失败时怎么处理。而一个可供 AI 代理加载的 skill，通常会把“技能说明、使用步骤、输入输出约定、示例、可选脚本”放在一起。

在常见实现里，一个 skill 是放在特定目录下的一个文件夹，里面有一个SKILL.md或类似的描述文件，再加上一些辅助文件。AI 通过读取这个描述文件，知道“什么时候该调用这个技能、执行时需要读哪些文件、生成结果后应该放到哪个目录”。这有点像团队里的“操作手册”：不是告诉新人要做什么，而是让新人遇到对应问题时，能按手册里的约定去执行。

所以，AI skills 真正解决的不是“让 AI 更聪明”，而是“让 AI 的聪明可以被复用、被共享、被约束”。如果你只是想让 AI 聊天聊得更好，用不用 skill 差别不大。但如果你希望 AI 能稳定地完成某个固定流程，skill 就会比一次性聊天可靠得多。

1.2 为什么设计、前端场景最先感到“被震撼”

设计相关的工作流有几个特点：重复度高、规则明确、但每次处理的具体素材又不一样。比如拿到一张设计稿，需要生成对应的页面结构；拿到一组图标，需要统一导出并转换成组件代码；拿到一个设计规范，需要检查现有页面是否匹配。

这类工作过去要么靠人肉复制粘贴，要么靠抽时间写一次性脚本。AI 编程工具出现后，大家发现可以用自然语言指挥 AI 完成一部分，但每次都要重新描述需求、重复说明输出格式，而且结果不稳定。skills 出现后，变化在于：你可以把一整套约定固化下来，AI 下次遇到“页面结构生成”这类任务时，直接按之前验证过的方式执行。

设计界关注 skills，并不奇怪。设计工具导出的素材本身就是比较规整的输入，AI 适合处理“输入规整、输出要求明确”的任务。很多前端开发 skills 正是围绕这类场景出现的。从工程经验看，真正让设计师和前端合作效率提升的，不是 AI 生成了多惊艳的页面，而是“从设计稿到前端结构”这条链路由不可控变成了基本可控。这里的“震撼”不是字面意义上的炫技，而是工作方式的变化。

2. 从零开始写一个可用的 skill：结构、目录和内容

2.1 最小 skill 包含什么

不管用的是 Claude Code、Codex、OpenCode 还是 Cursor，这类工具对 skill 的目录约定在不同版本里会有差异。我在落地时通常会先建一个最小结构，验证工具支持后再继续扩展。一个比较常见的结构是：

skills/ design-to-page/ SKILL.md examples/ input.png output.tsx scripts/ check_input_size.py

SKILL.md是技能的“说明书”，里面写清楚什么时候使用、输入是什么、输出要求是什么、执行步骤是什么。examples存放一个输入输出样例，可以让 AI 更快理解目标格式。scripts用来做输入校验、结果校验、文件清理等辅助动作，不是必须的，但对稳定运行很有帮助。

需要注意，不同工具的加载规则并不完全一致。有的工具要求放在项目根目录的.claude/skills下，有的工具提供独立命令安装，有的工具还支持从远程仓库直接安装社区技能包。因为你无法确定所有平台都遵循同一套约定，所以落地前的第一件事，是打开对应工具的文档，确认当前版本的目录规则。

2.2 在不同工具里组织 skill 的常见方式

从社区现状看，skills 的组织方式大致可以分成三类。

第一类是“项目内嵌型”。把 skill 放在当前项目目录下，只对这个项目生效。这种方式适合团队内部约定流程，比如某个项目里统一使用一套“设计稿转组件”的规则。

第二类是“全局配置型”。把 skill 放在用户级目录里，所有项目都能使用。这种方式适合个人沉淀通用能力，比如“把图片转成可访问的 HTML 结构”这类与具体项目无关的技能。

第三类是“仓库共享型”。把一堆 skill 放到 Git 仓库里，然后通过命令或安装脚本拉取到本地。社区里已经有一些开发者整理的 skill 集合，通常会按用途分类，比如前端开发、测试、文档生成、数据分析。这类集合的好处是开箱即用，坏处是质量参差不齐，而且很多集合更新并不及时，拿回来后往往要根据自己的工具版本做调整。

所以，你在搜索“find skills”“skills 推荐”这类话题时，真正要判断的不是“哪个包火”，而是“这个包里的每个 skill 是不是符合我的输入输出习惯”。一个安装量很高的 skill，如果它的目录约定和你当前工具版本不一致，落地时反而会浪费更多时间。

2.3 写 SKILL.md 时要避免的两种极端

实际使用中，我发现很多开发者在写 skill 说明时会走向两个极端。一种是只写一句话，比如“帮我把图片转成页面结构”，这会导致 AI 执行时既不知道要读哪张图，也不知道输出该放哪里。另一种是写成长篇论文，把背景理论、设计原则、团队历史都写进去，AI 反而会抓不住重点。

一个合理的SKILL.md至少应该包含四个部分：

• 作用：这个 skill 在什么场景下用。
• 输入：需要哪些文件、格式是什么、由谁提供。
• 输出：结果文件放在哪里，命名规则是什么，使用什么格式。
• 执行步骤：按顺序列出 3 到 6 个关键动作，最好包含“不要做什么”。

这样写的好处是，AI 代理在读取说明后，不需要猜测意图。它只需要按照描述去检查输入、执行步骤、生成输出。类似的写法其实也适用于 codex skills、opencode skills 等不同实现，核心逻辑都是“把可重复流程描述清楚，再交给代理执行”。

3. 关键不是“能不能跑通”，而是“能不能长期稳定使用”

3.1 输入边界：设计素材的格式、大小、路径都要检查

一个常见的误判是：单次跑通了一次“把 PDF 设计稿转成页面结构”，就认为 skill 已经可用了。但下次换一张更大的图片、换成 PNG 或者多层 Figma 导出文件时，模型可能突然不读了。

对于设计素材，我会建议在 skill 里写清楚：

• 支持的输入格式：png、jpg、svg、pdf，还是需要先从 Figma 导出。
• 是否检查分辨率、尺寸、色彩模式。
• 文件是放在固定输入目录，还是由用户手工指定路径。
• 对超大文件是否需要先压缩或切片。

你可以在 skill 中加入一个输入校验脚本，在 AI 处理前先检查文件是否存在、格式是否正确、大小是否超过阈值。这样至少可以让失败提前暴露出原因，而不是让模型读一个异常文件后输出一堆无意义内容。

3.2 输出边界：让 AI 的结果能被下一个环节使用

如果 skill 只面向聊天，输出格式不稳定还可以手动调整。但如果你希望把它纳入一条更完整的工作流，输出就必须保持一致。举例来说，生成页面结构时，需要约定好：

• 输出目录是output/还是generated/。
• 文件用.tsx、.jsx还是.vue。
• 是否需要附带一个说明文件，记录本次生成所用的模型和参数。
• 失败时是否生成error.log。

从实际工程经验看，很多批量任务不是 AI 本身能力不够，而是“前面成功、后面失败，且没有日志”，导致整个任务不可恢复。给 skill 增加输出规范和校验脚本，往往比换更大的模型更有效。

3.3 平台间兼容性：一份 skill 不一定处处可用

在写 skills 时，要区分三类内容：

• 通用描述：说明用途、输入输出、执行步骤，大多数工具都能读取。
• 工具特定指令：比如某个工具暴露出的特殊能力、系统调用、内置快捷键。
• 脚本依赖：如果 skill 依赖了 Python 包、Node 包或外部命令，那换一台机器就可能失效。

所以如果团队要在不同工具之间切换，最好的做法是把 skill 拆成“说明文件 + 脚本”，脚本尽量用常见标准库，减少对单一平台的强依赖。这就是为什么说“一份 skill 写好后，别默认在哪里都能直接用”。

4. 设计场景落地：从一个最小痛点开始，不要一上来做全家桶

4.1 第一步：找到“每周至少重复三次”的任务

不要一开始就决定把整个设计交付流程封装成一个巨型 skill。更稳妥的方式是找到一个你每周至少会重复三次的任务，把它做成最小的 skill。

下面这几个都值得先试：

• 设计稿转页面结构。
• 一组图标导出并生成组件代码。
• 根据设计规范检查页面样式是否一致。
• 批量把 PDF 里的文案提取成结构化表格。

这些任务都满足：输入规整、输出明确、重复发生。如果一个任务你自己都不确定下一周还会不会遇到，那就没有必要急着封装。

4.2 第二步：先用普通对话把流程跑通，再固化成 skill

很多人的直觉是先写好 skill 文件，再指望 AI 按说明执行。我的建议相反：先不要考虑 skill，直接用对话方式把这条流程跑通，观察哪些步骤最稳定、哪些地方 AI 总会重复问你。

建议流程：

1. 用 AI 对话完成一次完整任务，手动纠正结果。
2. 把这次对话里最有效的指令整理成文字。
3. 把输入输出约定和步骤写进 SKILL.md。
4. 用一条新的输入测试 skill，看 AI 是否不再需要额外解释。
5. 如果某一步不稳定，再决定是否加入脚本校验。

这个过程看起来慢，其实是最省时间的。因为你把“一次成功对话”变成了一个可复用的“最小技能”，后续每次使用都在复用你已经验证过的判断。

4.3 第三步：批量前先补上日志、计数器和失败记录

当单个 skill 跑通之后，你很容易产生批量使用的冲动。这时候最值得做的不是拉高并行数，而是给 skill 增加“人类可阅读的日志”。至少需要记录：

• 每次执行开始时间和结束时间。
• 输入文件名称。
• 输出文件路径。
• 生成结果是否通过基本校验。
• 失败原因。

这样即使批量任务中途失败，你也能从日志里定位是哪一批文件出了问题。没有这个基础，批量只会放大混乱。

注意：不要一上来就把并发数、批量数拉满。先用一条样例把输入、输出和日志确认正常，再逐步扩大。

5. 遇到问题别先怀疑 AI：一个可复用的排查链路

5.1 按现象、输入、环境、参数、边界逐层排查

当 skill 没有按预期工作时，建议按照下面的顺序排查，而不是直接换一个模型或重写 prompt：

1. 看现象：是报错、卡住、无输出，还是输出内容不对？把现场信息留下来。
2. 看输入：文件是否存在、格式是否匹配、路径是否带中文或空格、图片是否损坏。
3. 看环境：skills 目录是否有读写权限、依赖脚本版本、工具版本是否支持该类 skill。
4. 看参数：批量数、并发数、超时时间、输出路径、模型名称是否设置正确。
5. 看工具边界：当前工具是否支持该 skill 类型、是否存在已知限制。

设计场景里最常见的问题，是输入和环境层。比如 Figma 导出的私有格式不一定能被模型读取，需要先导出成 PNG/SVG；再比如中文字体文件名在部分脚本里会出现编码问题。这些问题和模型聪明程度无关，属于输入和环境的边界。

5.2 四个值得重点检查的坑

• 文件格式不匹配：模型以为自己读的是 PNG，实际是损坏文件或未解压的 PDF。
• 输出目录不存在：脚本没有自动创建目录，导致结果写不进去。
• 缺少示例：AI 对“页面结构大概长什么样”没有概念，输出格式漂移。
• 没有失败重试：批量任务中某一项失败后，整个任务停止，且没有记录。

如果你把检查结果写进 skill 的日志，排查会变成一件很快速的事。“它坏了”到“为什么坏”不再需要靠猜。

5.3 长期维护视角：skill 也要版本管理

如果只是自己临时用，把 skill 放在本地目录就够了。如果团队内共享，建议把 skill 放进 Git 仓库，并在 SKILL.md 里写清楚适用版本和依赖环境。每次修改 prompt 后，先用一条固定输入做回归验证，避免“以前能用的技能因为某句话改动而失效”。

到了这一步，从“写一个 skill”到“长期维护 skill”才形成了一个完整闭环。否则它只是一堆一次性文件，时间一长就没人记得当初为什么这么写。

6. 什么人在什么阶段适合用 AI skills

6.1 现在真正适合的人

结合真实落地场景，我认为以下三类人会很快获益：

• 已经熟悉 AI 编程工具，并且有固定重复工作流的人。
• 负责设计规范和前端组件库维护的人，需要让 AI 按统一标准产出。
• 在做 AI 应用或 Agent 开发的人，需要把某些能力封装成可复用单元。

这类用户的共同特点不是“会用提示词”，而是“有流程意识”。他们能清楚描述一个任务从输入到输出的完整路径，也知道哪些环节容易出现异常。

6.2 暂时不必急着上 skills 的人

• 还没用 AI 跑通过任何一条完整任务的人。
• 只想让 AI 聊天、写点摘要，没有稳定重复任务的人。
• 团队没有统一习惯，也不打算维护文档和目录结构的人。

skills 的收益来自复用。如果你没有固定流程，封装 skill 反而会增加维护负担。先老老实实把普通对话用熟，再考虑技能化。

6.3 我的建议：从一个小技能开始，但今天就可以开始

我不太建议把“设计界震撼”理解成 AI 已经能替代设计师。它真正的信号是：设计、开发里那些既定规则明确、重复次数高的工作，正在变成可以封装、可复用、可复制的最小技能单元。如果你有一个每周都要做的设计或前端任务，今天就可以试着用一次对话跑通，再把它固化成一个 skill。先别管复杂结构，先把最小闭环跑出来。

等到你再回头看时，会发现真正有价值的不只是某一次生成结果，而是那条被固化成 skill 的流程。它会继续稳定地替你处理相似任务，并且可以被同事、团队甚至未来的项目复用。这大概才是 AI skills 最值得长期关注的原因。