企业官网建设流程全解析

这两年只要你在用 AI 写代码，大概都听过同一个词：skills。尤其是 Claude Code、Codex、OpenCode 这类编码代理流行起来之后，前端开发 skills、测试用例 skills、数学建模 skills 到处刷屏，GitHub 上光是搜“awesome skills”就能翻好几页。我第一次真正被 skills 震撼到，是拿到一份社区里分享的“图片还原设计稿”skills，它能把一张截图直接变成一版接近还原的前端代码，整个过程比我手动写 prompt 再反复纠偏快了不止一倍。

但说实话，一开始我是懵的。skills 到底是提示词、插件、脚本还是某种新的 Agent 框架？为什么别人用的 skills 效果那么好，我自己照着抄却经常“失灵”？后来花了两三周，把 Claude Code、Codex、OpenCode 几套流程都跑了一遍，自己又造了几个内部常用的 skills，才慢慢摸清这东西的门道。这篇文章就把我从“听概念”到“自己写”再到“批量落地”的完整经验拆开讲，适合刚接触 skills 的开发同学，也给那些已经用过但效果不稳的人一份避坑清单。

1. 内容整体设计与思路拆解

1.1 skills 到底是什么：不是插件，也不是普通提示词

先说结论：skills 是一套结构化的、可复用的、面向 Agent 的能力单元。它比一条 system prompt 更重，比一个完整的独立应用更轻，核心目标是把某个高频任务的处理流程固化下来，让 AI 代理下次遇到同类任务时，能按固定步骤执行，而不是每次从零开始猜。

我用一个生活化的类比来解释。你让一个实习生去整理会议纪要，普通 prompt 相当于你口头说一句“把纪要整理好”，实习生可能理解成用户要逐字稿、可能整理成待办、也可能写一封邮件，结果全看运气。而 skills 相当于你给实习生一份标准作业指导书：先读原文、按“结论—讨论—待办”三段拆分、输出 Markdown、同时生成一封摘要邮件。只要实习生肯照着做，质量就差不了。

放到编码代理里，skills 的典型形态是一个文件夹，里面包含SKILL.md作为主说明文件，再加上脚本、模板、引用资料等附属资源。Agent 在执行任务时，会先加载SKILL.md，按里面描述的行为流程和调用规则工作。比如一个“代码审查 skills”，它会约定先检查什么文件类型、按什么顺序看、重点看并发还是安全性、最终输出什么格式的报告。这个流程一旦被固化，结果的可控性会大幅提升。

注意：很多网上的“skills 推荐”文章把 skills 和 MCP 服务器混为一谈。实际上两者不是一回事。skills 偏“做事的方法论和步骤”，MCP 偏“接外部工具和数据源的能力”。它们可以搭配，但功能层级不同。

1.2 为什么 skills 是 Agent 时代的“超级能力”

很多人会有个疑问：我有 ChatGPT、有 Claude，为什么还要专门搞一套 skills？直接对话不就行了？我刚开始也这么想，直到我在一个真实项目里被逼疯了。

那个项目要从一个老旧的 Vue 2 后台系统迁移到 Vue 3 + TypeScript。我让 Claude 帮我分析代码现状，它回答得很流畅，但每次分析的方式都不一样：有时候先统计文件数量，有时候先看 package.json，有时候直接给我一段改造路线图。对话一长，它就把之前的分析框架忘光了，同一个问题换个问法，结果又不一样。

后来我把“Vue 2 迁移分析”做成了一个 skills，里面固定了分析步骤：先扫描 package.json 确认依赖，再统计options API/mixin/$emit的使用频率，再识别路由和状态管理，最后按优先级输出迁移清单。从那以后，同类项目我只需要把路径丢给代理，它就能按照统一标准输出，我一个人维护多个迁移任务也不乱。

这就是 skills 真正的价值——它把你的最佳实践、领域经验和执行标准沉淀下来，让 AI 不是“聪明但随心所欲”，而是“聪明并且稳定可预期”。在团队协作里尤其重要：一个精心打磨的 skills 就是团队能力的拷贝，新人用起来也能达到老手七成功力。

1.3 适合谁用：前端、测试、数据建模都受益

理论上，任何需要 AI 反复执行同一套流程的领域都适合引入 skills。我从实际试用中感受到收益最明显的三波人：

• 前端开发者：把页面还原、组件生成、样式梳理、可访问性检查做成 skills，日常工作压力会小很多。而且前端任务范式非常统一，特别适合 skill 化。
• 测试工程师：把测试用例设计、边界值分析、自动化测试脚本生成做成 skills，能显著提高用例覆盖的完整度，减少漏测。
• 数学建模 / 数据分析人员：把数据探索、特征工程、模型对比、论文图表风格统一等工作固化，能让分析过程可复现、结果更规范。

这几类人群最大的共同点，就是他们的工作里“流程”非常重，而且流程可以抽象成明确的步骤。换句话说，只要你能把一件任务说清楚步骤，它就有成为 skills 的潜力。

1.4 先认清边界：skills 不是万能钥匙

说了这么多好处，我也得泼盆冷水。skills 不是银弹，它解决的是“标准化流程的稳定性”问题，解决不了“完全创新的探索”问题。如果你每天的任务都是全新且没有固定套路的，比如研究某个从没见过的算法、写一篇需要强创意的文案，那 skills 的帮助会非常有限。

另外，skills 需要维护。它和代码一样，会过期、会失效。API 变了、框架版本升级了、你团队的规范调整了，skills 里的旧指令就成了绊脚石。我看到不少人下载了社区 skills 之后不与自己的项目做任何适配，跑了一次发现效果一般，就断定“skills 是智商税”。实际上，任何工具都需要配置期投入，skills 也一样。

2. 核心细节解析与实操要点

2.1 标准目录结构与SKILL.md的撰写规范

想动手写自己的第一个 skills，首先得理解它的标准目录长什么样。拿目前社区里最常见的一套规范举例：

my-skill/ |-- SKILL.md # 主说明文件，Agent 首先读取这个 |-- reference/ # 参考资料，可选，放领域相关的文档 |-- scripts/ # 可执行脚本，可选，例如格式化、抓取、计算 |-- templates/ # 输出模板，可选，让结果格式统一 `-- assets/ # 其他静态资源，可选，比如样例图片

SKILL.md是整个 skills 的大脑。它通常包含以下模块：

• 名称与适用场景：说明这个 skill 解决什么问题，什么时候值得加载。
• 行为流程：明确 Agent 要按照什么顺序做哪几步，每步输入输出是什么。
• 规则边界：告诉 Agent 哪些不该做，哪些问题要拒绝回答，防止越界。
• 输出格式：规定最终交付物的结构，比如用 Markdown 表格、JSON 还是特定目录结构。

举个例子，我在给团队内部做一个“前端页面设计稿还原”的 skills 时，SKILL.md里开篇就写了：当用户输入一张图片或一个设计稿链接时，先判断图片类型和尺寸，然后按从整体布局、配色、字体、间距、交互状态到响应式断点的顺序进行还原，最后输出 Vue + Tailwind 组件代码，并附一个实现说明。这让代理从一开始就知道该往哪个方向努力。

实操心得：写 SKILL.md 时，指令越具体越好。不要用“请仔细分析”这种废话，要用“先列出接口返回的 JSON 字段，标注每个字段的用途和类型，再据此生成界面”这种可执行描述。Agent 对模糊指令的发挥空间比你想象的大得多，限制越好，结果越稳。

2.2 顶层目录、命名与版本管理

一个容易被忽略但实际操作中很要命的点，是 skills 的目录和命名规范。不同工具对 skills 存放位置的要求不同，但通用的习惯是放进个人配置目录下的skills文件夹中。以 Claude Code 为例，通常会放在~/.claude/skills/下，每个子文件夹就是一个 skill；Codex 和 OpenCode 也有类似的约定，只是路径不同。

命名上，我强烈建议用小写英文 + 短横线连接，比如frontend-design-recovery、api-test-case-generator。不要用中文命名、不要带空格、不要起特别长且没有意义的名字。原因很简单：skills 名字会被 Agent 用作加载触发的一部分，越清晰的名字越容易被准确地唤醒。如果一个叫frontend-design-recovery的 skills 和一个叫frontend-recovery-toolkit的 skills 同时存在，Agent 很可能会混淆它们的职能。

版本管理同样重要。我是一个人 solo 开发，但也会给每个 skills 目录加 Git 仓库，打 tag。因为 skills 迭代速度快，有时候只是加了一条新规则，效果就完全不同。没有版本管理的话，回滚会非常痛苦。

2.3 触发机制：怎么让 Agent 正确调用 skills

真正上手之后你会发现，写好 skills 只是第一步，怎么让代理“想起来”用它才是关键。很多人的失败，是把 skill 下载下来放在目录里，然后发了一个很普通的请求，Agent 根本没去加载这个 skill，结果自然和平时没什么两样。

要解决这个问题，核心是让触发词和你的任务描述强关联。比如你写了一个“代码审查”的 skill，那在 prompt 里最好明确带上“用 code review skill”或“按 review 规范检查”这样的短语。老手还会在 SKILL.md 的顶部写一段“触发条件描述”，告诉 Agent 当用户请求中出现了哪些关键词时，应当加载本 skill。例如：

当用户要求“还原这个设计稿”、“把这个图变成页面”、“根据截图写前端代码”时，加载frontend-design-recoveryskill。

这样一来，就算用户没有直接点名 skill，Agent 只要理解到这是设计稿还原任务，就会主动加载。我在实际测试中，加了这段说明之后，命中率从不到一半提升到了九成以上。

2.4 资源文件怎么准备：参考知识库与模板

很多网上的 skills 模板只提 SKILL.md 和 scripts，但我实际用下来的经验是，reference/和templates/这两个目录对结果稳定性的提升非常显著。

reference/适合放领域文档的摘录、团队规范、项目风格指南。比如你做前端开发，可以在 reference 里放一份团队的代码规范摘要，让 Agent 在生成代码时自动对齐。我见过有人把整个项目的 README、接口文档、设计 token 都塞进去，效果立竿见影——生成出来的代码风格和团队已有代码如出一辙。

templates/适合放输出模板，尤其在测试用例、需求文档、代码审查报告这类的场景下。只要规定了“输出必须包含背景、改动点、风险、测试建议”这四个模块，生成结果就不会长成一篇散文。我建议 templates 里的模板要精简，一页左右即可，太长的模板反而会让 Agent 迷失重点。

3. 实操过程与核心环节实现

3.1 手写一个“测试用例生成” skills 的完整过程

概念说太多了，直接上实操。以一个很常见也很有价值的“测试用例生成” skills 为例，我带大家从零写一遍，顺便讲讲我在过程中踩过的坑。

第一步，新建目录结构：

mkdir -p ~/.claude/skills/test-case-gen/{scripts,templates,reference} touch ~/.claude/skills/test-case-gen/SKILL.md

第二步，写 SKILL.md 的核心内容。我一开始写得特别简单，只有一段话“请生成测试用例”。结果生成的用例都是教科书级的“输入正确数据，验证结果正确”这种废话。后来我改成下面这种结构化描述：

# 测试用例生成 Skill ## 适用场景 当用户提供接口定义、函数代码或需求描述，要求生成测试用例时使用。 ## 执行流程 1. 解析输入，明确被测对象的输入参数、输出、边界条件和外部依赖。 2. 按等价类划分法列出有效等价类和无效等价类。 3. 按边界值分析法列出上点、内点、离点。 4. 检查异常场景：超时、依赖失败、空值、并发、权限不足。 5. 输出测试用例表格，包含编号、场景、前置条件、输入、操作步骤、预期结果、优先级。 ## 规则 - 每个参数必须覆盖至少 3 个有效值，3 个无效值。 - 涉及第三方服务的用例，必须使用 Mock 描述。 - 不输出与测试无关的内容，不输出代码实现建议。

第三步，写一个简单的脚本，用来从接口定义里提取参数。这个脚本不强求，但对于接口比较多的项目，它能显著提升效率。我用的就是一个 Python 脚本，解析 OpenAPI 文档，输出参数清单，然后 SKILL 里引用它：

# scripts/extract_params.py import json import sys def main(spec_path): with open(spec_path, "r", encoding="utf-8") as f: spec = json.load(f) for path, methods in spec.get("paths", {}).items(): for method, detail in methods.items(): params = detail.get("parameters", []) for p in params: print(f"{method.upper()} {path} | {p.get('name')} | {p.get('in')} | {p.get('schema', {}).get('type')}") if __name__ == "__main__": main(sys.argv[1])

第四步，找一个真实接口跑一遍，看输出是否达到预期。我拿一个登录接口做了测试，它给了我非常细的用例表，包括密码长度 6-20 位的边界值、连续输错五次的锁定场景、验证码过期场景等。这个粒度已经可以拿去直接和开发对齐测试范围了。

注意：这里有一个很重要的教训，就是第一次跑的时候，它把所有用例的优先级都标成了 P0。我就在 SKILL 的规则里补了一句“将不常见且低影响的异常场景标记为 P2”，后面输出就合理多了。这种小修小补是 skills 迭代的常态。

3.2 如何利用 skills 调用 MCP 工具

关于 skills 和 MCP 的关系，我前面提到过，不是一回事，但它们可以配合得很好。很多人搜索“skills如何调用MCP工具”，其实就是想问，怎样在固定流程里接入真实的数据源或外部操作能力。

举一个场景：我的“前端页面还原” skill 里，需要在还原前拉取设计稿对应的接口真实数据，否则还原出来的页面全是假数据。这时候我会在 SKILL.md 里声明：

在分析设计稿之前，如果设计稿标注了接口地址，使用 MCP 的 fetch 工具请求该接口，获取真实返回 JSON，再基于该 JSON 设计页面结构。

然后再通过 MCP 服务器配置好 fetch 工具，Agent 在执行 skill 的流程时，一旦需要真实数据，就会调用这个 MCP 工具去请求接口。这样 skills 负责“决定怎么做”，MCP 负责“能把事做成”。

再举个例子，我做数学建模的时候经常要操作 Excel、CSV 数据集。我把“数据探索分析”做成一个 skill，里面规定要先查看数据维度、缺失值、分布情况，再决定要不要做特征工程；而具体读写表格文件的操作，就通过 MCP 的文件工具加上 Pandas 脚本来执行。两者一配合，分析流程高度自动化。

实操中有一点要留心：MCP 工具调用是有副作用的，比如写文件、发请求。所以在 SKILL.md 里一定要写明哪些阶段允许调用工具、哪些阶段禁止，避免 Agent 在分析阶段就把文件改了。我最早没写这条，它跑着跑着直接把源文件覆盖了，还好有 Git 兜底。

3.3 从 GitHub 下载并适配社区 skills 的正确姿势

我知道大部分人不是想从零写，而是想直接“skills 下载”现成的。社区里比较好的 skills 项目通常会自带 README 和使用示例，但直接复制粘贴往往效果不佳。我总结了一套下载之后必须做的适配流程：

第一，先看 SKILL.md 的依赖声明。很多高级 skills 会依赖特定脚本、Python 包甚至 MCP 服务器。如果它说需要pandas，你就得确认环境里装了，否则流程走到一半必然报错。

第二，把 skill 里的示例路径改成你自己的项目路径。这是最常见的坑。很多仓库作者写死了自己的路径，比如/Users/xxx/project/src，你下载下来不改成/data/my-project/src，Agent 一执行就是文件找不到。

第三，用自己的典型任务跑一遍，记录偏差。我下载任何 skills 之后，都会拿一个我已经知道正确答案的旧任务做回归测试。如果输出和我知道的正确答案偏差很大，我就去读 SKILL.md 里哪条规则导致了偏差，逐句修正。这个过程的收益，远大于你花一天时间去找更多的 skills。

我试过几个社区里较火的、含前端开发相关的 skills，比如“图片还原设计稿”和“组件代码生成”，坦白讲，开箱即用的惊喜存在，但大多数组件生成的视觉效果距离设计稿还有差距。真正把它调到可用的状态，花了我大概一个下午。调完之后，这个 skill 就成了我日常写页面最常用的搭档之一。

4. 常见问题与排查技巧实录

4.1 Skill 不被触发：问题多半出在触发条件上

现象：我把 skill 放进了正确目录，也发了请求，但代理完全没有采用，行为跟没装一样。

排查思路：先看 SKILL.md 的“适用场景/触发条件”里写没写清楚。如果没有写，Agent 就不知道什么时候该用。如果写了但没触发，就检查用户请求里是否存在足够明确的关键词。还有一个我经常踩的坑：多个 skill 的适用场景描述重叠，Agent 不知道该加载哪个，最后干脆都不加载。遇到这种，把每个 skill 的场景描述改成互斥的。

还有一个容易被忽略的问题：目录嵌套层级错误。比如 Claude Code 要求 skill 直接放在skills/xxx/SKILL.md，如果你多套了一层，变成了skills/xxx/more/SKILL.md，有的版本能识别，有的不能。我的建议是严格遵守工具文档的目录说明，不要想当然。

4.2 输出“模板感”太重或太泛：规则写得不够紧

现象：技能确实被加载了，流程也走了，但输出的内容非常泛泛，换个项目也能用，等于没用的废话报告。

这几乎是新手写 skills 最普遍的问题。根源在于 SKILL.md 里只有“要做什么”，没有“不许做什么”，也没有“具体到什么粒度”。比如你写“分析代码质量”，Agent 可能输出“代码存在结构问题”这种废话。你要改成“列出所有超过 200 行的函数，并标注各自负责的职责；检查是否有重复超过 30 行的代码段落”。

我后来养成了一个习惯：每次看到输出里出现像是废话的句子，就把它反推成规则写回去。比如看到“建议使用更安全的鉴权方式”这种废话，就补一条规则“必须指出具体是哪一处接口缺少鉴权、属于何种类型、建议改成 JWT 还是 OAuth”，输出质量立刻好得多。

4.3 技能有过期风险：依赖包和 API 版本

现象：skill 上个月还好好的，这个月突然失灵，或者输出结果明显过时。

这里分两类。第一类是外部 API 变化，比如它依赖的 MCP 工具地址变了、第三方服务接口升级了。第二类是知识过期，比如 SKILL.md 里写的是某个框架的旧 API 用法，而项目已经升级到新版本了。

排查办法：打开 skill 的脚本和 reference 文档，看是否存在硬编码的版本号、URL、Schema。把这些经常变化的内容独立到配置文件中，而不是写死在 SKILL.md 里。每次工具大版本升级时，顺手跑一遍测试脚本，比等到出错再排查高效得多。

还有一个不起眼但实用的经验：给每个 skill 在文档头部加一个“最后验证日期”字段。我和团队约定的规则是，如果某个 skill 超过 30 天没验证过，用之前先做一次冒烟测试。这个习惯帮我们避免了好几次生产事故级别的误操作。

4.4 社区 skills 良莠不齐：怎么快速判断是否值得下载

现象：GitHub 上 skills 项目又多又杂，不知道哪个靠谱。

我的筛选方法有这么几步：首先看 SKILL.md 是否写得足够详细，是否有明确的执行流程和规则边界，如果一个 skill 只有三句话，大概率价值有限。其次看是否带测试样例和示例输出，这比 README 写一堆吹捧性描述有用得多。最后看更新时间和 issue 区，如果作者已经半年没动静，而 issue 里有人反馈新版本不兼容，就要谨慎了。

4.5 常见问题速查表

5. 从 skills 到 superpower skills：进阶组合玩法

5.1 把多个 skills 串成一条流水线

单个 skill 解决单个任务，但真实工作往往由多个任务组成。这时候就轮到“superpower skills”出场。所谓 superpower，不是单个技能多复杂，而是把多个 skills 排成一条流水线，让代理按照顺序协同完成一个大目标。

我举个我日常的例子。接到一个“新页面开发”任务时，我实际上会依次用到三个 skills：

• 先用“设计稿分析” skill，把图片里的布局、颜色、字体、交互拆解成结构化描述。
• 再用“前端组件生成” skill，根据结构描述生成 Vue/React 组件。
• 最后用“代码审查” skill，检查生成代码里有没有可访问性问题、性能隐患、命名不一致。

如果这三个 skills 独立调用，我得手动切换上下文，效率提升有限。但把这套流程写成一个新的“super skill”，在 SKILL.md 里依次调用子 skill，代理就能一口气把整个任务跑完。我实际对比过，同样的需求，分步调用大概要 20 分钟的人工介入，流水线化之后 5 分钟就能拿到完整交付物，而且中间不需要我来做“翻译”。

5.2 用变量和条件分支让 skill 适应更多场景

简单的 skill 适合稳定场景，复杂场景就得引入变量和条件分支。我常用的做法，是在 SKILL.md 里用“如果……则……”的句式，让代理根据输入的不同走不同流程。

比如我的“接口文档生成” skill，会判断输入的接口类型：如果输入是 OpenAPI JSON，走“解析 JSON，提取每个接口的路径、方法、参数、响应”这条流程；如果输入是代码里的函数定义，走“静态解析函数签名，推断入参类型与返回值”这条流程。条件分支让一个 skill 的覆盖面变宽，同时不牺牲单一流程的清晰度。

这里有个平衡问题：分支太多会让 SKILL.md 变得臃肿，代理反而容易迷失。我的建议是，一个 skill 最多支持三到五条主分支。一旦超过这个量，就拆成多个子 skill 再串成流水线。

5.3 让 skill 变成团队经验库

单个开发者的 skills 再强也不过是个人效率工具，真正有规模效应的是把 skills 变成团队的经验库。我和小伙伴们在实践中有几个做法值得分享：

第一，每个 skill 必须有一个“作者”字段和“设计背景”说明。这样后来人阅读时，能理解当初为什么制定这条规则，而不是机械执行。第二，skill 必须是活文档，每当有人在使用中发现更好的流程，直接在 issue 里提改进，而不是私下改自己的副本。第三，团队仓库里放一套“黄金样例”，也就是这个 skill 的最优输出结果，新成员可以照着黄金样例来校验 AI 的输出质量。

这种做法在团队协作里的价值，远超单个 skill 本身。它本质上把每个成员踩过的坑、总结出的套路都固化成了资产，新人不用踩一遍前辈踩过的坑，就能直接站在不错的起点上。

5.4 从效率到创造力：skill 还有哪些想象空间

很多人以为 skills 只能用来干那些“无聊的重复活”，其实不是。我测试过把创意设计类的工作也 skill 化，比如给一个“文案风格迁移” skill，让它先拆解原作者的句式节奏、用词偏好、开头钩子结构，再把这些特征应用到新的主题上。效果虽然不完美，但能稳定地输出具有某种风格的初稿，再经过人工微调，效率确实翻倍。

所以，判断一个任务能不能 skill 化，关键不是看它“重不重复”，而是看你能不能把它拆成清晰且可指导的流程。哪怕是偏创作的任务，只要你能总结出自己的方法论，就可以用 skill 来放大它。

6. 写在最后的实践体会

我在实际使用中发现，把 skills 用好，最关键的品质不是技巧，而是“持续迭代的耐心”。任何一个成熟的 skill，都不是一次写成的，而是通过一次次垃圾输出的打击、一句句规则的反推、一次次回归测试的打磨，才慢慢变得好用起来的。

现在我的工作流里，凡是遇到过两次以上的任务，我都会下意识地想一想：这个能不能抽象成一个 skill？如果能，花半小时把流程固化下来，下次再遇到，我就不用再做重复劳动。这个习惯的改变，比我会写多少种 prompt 模板都更有价值。

最后再分享一个小技巧：刚开始做 skills 时，不要贪多，先挑一个自己每天都会做的任务，写到能用为止。一个真正好用的 skill，胜过十个躺在目录里吃灰的半成品。等你跑通一次“设计—落地—迭代”的闭环，后面再做新 skill 就是水到渠成的事了。