企业官网建设流程全解析

这几年在AI编程圈子里混，你会发现一个特别明显的风向变化：以前大家比拼的是谁的提示词写得长、写得好，后来是拼谁的上下文塞得准、塞得全，现在呢，最新的话题已经变成了“skills”——也就是把一套完整的、可复用的技能包教给AI智能体，让它像老员工一样按照你的工作方式干活。这个变化不是小打小闹，它直接改变了我们和AI协作的模式。

我这段时间把GitHub上热门的skills仓库翻了个遍，也在Claude Code、Codex、Cursor这些主流工具里实测了十几套不同场景的skills，包括前端开发、学术研究、数学建模，甚至还有测试用例生成。这篇文章想把我的理解和踩坑经验完整写出来。不管你是刚听说“skills”这个概念的新手，还是已经在用但经常遇到“AI不按套路走”的开发者，这篇文章应该都能提供一点实在的参考。

1. Skills到底是什么，为什么一夜之间大家都在谈

我记得第一次看到.claude/skills这个目录的时候，第一反应是“这不就是个强化版的prompt文件夹吗”。但实际用了一段时间之后发现，这个理解太浅了。Skills的本质，是把“如何完成一类任务”的完整方法论打包成一个结构化的技能包，里面既有指令、有步骤、有参考资料，甚至有可执行的脚本或工具配置。它不是让你的AI“听懂一句话”，而是让你的AI“上手就能干活”。

1.1 从上下文工程到技能包：一个自然演进的产物

我们先把时间线拉出来看看。最早的时候，大家玩的是“提示词工程”，核心思路是写一个无敌详细的prompt，把所有要求都塞进去。但这种做法有个致命问题：上下文窗口是有限的，你不可能永远堆内容；而且每次开新会话，之前写的一大堆规范就清零了，重新粘贴又累又容易漏。

后来有了“上下文工程”的概念，比如Claude Code的CLAUDE.md、Codex的AGENTS.md，你可以把项目的全局规范、技术栈偏好、常见约定写进去，让AI每次启动时自动加载。这比复制粘贴进步了一大截，但它偏向“静态背景知识”，相当于给新同事发了一本员工手册。

而Skills在这个基础上又往前走了一步。它不仅仅是“知识”，更是“能力包”。一个设计良好的Skill会包含完整的工作流定义：什么情况下触发、先做什么、后做什么、用哪些工具、遵循什么输出格式、有哪些禁忌。这已经不是“员工手册”了，这是“老带新的传帮带”，把一个熟练工处理某类任务的完整套路都沉淀了下来。

我打个比方你就明白了。CLAUDE.md像是公司墙上贴的规章制度，你什么时候想看都能看到，但它不会主动帮你干活。而Skills更像是给AI装了“行业模板库”，比如你给它一个“前端设计稿还原”的skill，它拿到一张设计图，就知道该先去提取颜色变量、再拆组件层级、然后匹配现有UI库的命名规范，最后输出可运行的Tailwind代码。这一整套流程不需要你反复交代，一次加载，以后每次都能稳定执行。

1.2 和普通提示词、MCP到底有什么区别

这是新手最容易混淆的地方。我经常在社区里看到有人问：“Skills跟MCP（Model Context Protocol）有什么区别？跟普通的提示词又有什么不一样？”这里我直接给一个对照关系，你一看就明白了。

MCP解决的是“连接”问题，它把浏览器、数据库、文件系统、设计工具等等外部能力暴露给AI，让AI能“动手”。Skills解决的是“方法”问题，它告诉AI“你拿到这些工具之后，应该按什么顺序、用什么方式去完成任务”。两者完全不冲突，而且经常组合使用。

举个例子，你做一个“网页查资料并整理摘要”的skill，里面可以定义：先通过MCP的搜索工具检索信息，再根据skill内置的摘要模板输出结构化结果，最后把来源链接按固定格式附上。这里MCP负责“搜得到”，Skills负责“整理得专业”。没有MCP的话AI就是个光说不练的秀才；没有Skills的话，MCP工具给AI了它也是一通乱用，效率上不去。

1.3 为什么正好是现在这个节点爆发

任何技术概念的走红，背后一定有工具生态和社区内容共同助推。Skills能在这几个月突然成为高频热词，我认为有三个关键推手。

第一个是Anthropic率先在Claude Code里推出了官方原生的Skills机制。它允许你把SKILL.md文件放到指定目录，然后AI会扫描并自动学习这些技能的定义和能力边界。这个官方背书起到了很大的示范效应，让大量开发者开始尝试。

第二个是吴恩达（Andrew Ng）专门出了一期关于Agent Skills的教程，他在课程里把一个复杂的Agent任务拆解成多个可复用的“技能单元”，强调通过结构化技能的组合来构建稳定可靠的AI应用。这个教程影响面非常大，让很多原本只做传统机器学习的人也开始关注Skills。

第三个是社区的快速跟进。GitHub上像baoyu skills这类的中文Skills集合仓库、mattpocock's skills这类英文精品合集，以及各种数学建模、渗透测试、前端开发的垂直领域Skills仓库如雨后春笋般冒出来。工具方搭好了台子，社区负责唱戏，内容一多，这个生态自然就热起来了。

2. 主流工具对Skills的支持现状与选型建议

既然是实操向的文章，光聊概念肯定不行。我直接把市面上大家问得最多的几款工具——Claude Code、Codex、Cursor、OpenCode——对Skills的支持情况挨个拉一遍，重点说清楚它们的目录格式和配置方式有什么差异。

2.1 各家实现方式速览：目录结构、格式与加载逻辑

先说Claude Code。它原生支持Skills，官方推荐的做法是在项目的.claude/skills/目录下创建以技能名命名的子文件夹，每个文件夹里放一个SKILL.md文件，还可以附上scripts/、references/等辅助资源。Claude Code启动时会递归扫描这些目录，读取技能的描述和触发条件。SKILL.md的开头部分一般用YAML frontmatter写元数据，比如name、description，正文部分写详细的工作流程。

下面是一个标准的Claude Code Skill目录结构：

.claude/ └── skills/ └── frontend-design-restore/ ├── SKILL.md ├── scripts/ │ └── extract-colors.py └── references/ ├── tailwind-guide.md └── ui-patterns.md

然后是Codex（也就是OpenAI家的编程智能体）。Codex对Skills的接入方式与Claude Code略有不同，它更依赖AGENTS.md这个全局说明文件，同时也能识别skills目录。在Codex里你可以在项目根目录建一个skills/文件夹，然后在AGENTS.md里显式声明这些技能的存在和用途。这样做的好处是，AI在任务开始阶段就会感知到“项目里有全套可用的技能”，并且会主动评估是否需要调用。

再来看Cursor。Cursor本质上是一个AI代码编辑器，它对Skills的支持主要体现在.cursor/rules/目录，这个目录里的.mdc文件扮演了类似SKILL.md的角色。虽然名字不一样，但核心思想相通：给AI预设一份高优先级的指导文件，让它处理代码时遵循里面的规范。需要注意的是，Cursor的规则文件更多是“约束性”的，写法上比较像一套强制执行的编码规范，不像Claude Code的Skills那样强调完整的流程编排和资源文件配套。

最后是OpenCode。这是一个终端版的AI编程工具，它同样支持Skills，而且实现得比较简洁。OpenCode会在启动时读取~/.config/opencode/skills/或者项目内的.opencode/skills/目录，加载里面的技能定义。它的优势是跨平台、轻量，适合喜欢纯终端操作的人。如果你平时用Neovim这类编辑器比较多，OpenCode的Skills体验会比Claude Code更顺手一点。

我把它们的核心差异整理成了一张表格，方便你按需选择：

2.2 一个前端开发者的真实选型建议

我自己平时主力工作流是前端开发加AI辅助，所以对“到底该选哪个工具玩Skills”这个问题有点发言权。我的建议分几种情况。

如果你主要用Claude Code作为AI结对编程工具，那就直接用它的原生Skills机制，完全不需要额外折腾。目前GitHub上质量最高的Skills集合基本都是围绕Claude Code格式写的，你用其他工具还需要转换格式，而Claude Code是开箱即用。

如果你同时使用多个AI编程工具，比如既用Claude Code又用Codex，我建议你以AGENTS.md作为“索引层”，在文件里统一声明你有哪些技能，然后不同工具通过自己的规则文件去加载对应实现。这个思路和代码架构里的“面向接口编程”一个道理——上层统一暴露能力清单，下层各自实现。

如果你只是想快速体验，不太想折腾命令行工具，那Cursor是最低门槛的方案。它毕竟是图形界面，配置规则之后可视化反馈很清楚，适合从传统IDE迁移过来的开发者。

2.3 社区里已经有哪些现成的Skills值得收藏

这个我实测过一些，给大家报几个靠谱的“菜名”。

前端开发方向，最火的就是“图片还原设计稿”。这类Skill一般会告诉AI：拿到设计稿图片后，先分析整体布局和色板，再根据项目已有的组件库拆解页面结构，最后输出Tailwind或CSS Modules代码。我用过之后最大的感受是，AI生成的还原度比裸奔状态下高非常多，至少省掉了我30%的调整时间。

学术研究方向，academic research skills这类仓库做得比较系统。它通常包含文献检索、论文结构分析、引用格式整理等多个子技能，而且每个子技能都带参考文件和步骤模板。对于研究生或者科研狗来说，这东西比自己去写长篇大论的提示词实用多了，因为学术写作的规范太多太细，交给设计好的Skill去执行，出错的概率低很多。

数学建模方向也有不少好东西。热词里多次出现“数学建模skills推荐”不是偶然，因为数学建模涉及问题分析、模型假设、公式推导、代码实现、论文撰写等多个环节，每个环节的套路都很固定，非常适合做成Skills。有的仓库甚至把美赛、国赛的获奖论文结构都总结进了Skill，让AI辅助生成初稿时自动往“评委喜欢看的样子”靠拢。

测试用例设计方向的Skills也值得关注。好的测试Skill会把需求拆解成功能点列表，再按等价类、边界值、场景法等不同方法生成测试用例表，最后还能自动输出可执行的测试脚本框架。这类Skill对做质量保障的团队特别友好，能显著提升用例覆盖率，减少漏测。

还有安全测试方向，确实有人在整理渗透测试相关的Skills，主要是信息收集、资产梳理、报告模板这些授权范围内的测试辅助内容。我一直强调一个原则：安全测试工具和技能只能在获得授权的环境中使用，任何未经许可的测试行为都是不合规的。这里提一下就够了，具体内容不展开。

3. 动手开发自己的第一个Skills：从需求拆解到可用交付

看了这么多现成的Skills，估计你也手痒了。这一章我拿一个我踩过不少坑的真实案例来演示，怎么从零到一开发一个能用的Skills。这个案例就是“前端设计稿还原”，因为它足够典型——有输入、有输出、有中间步骤、有工具依赖，而且几乎每个前端开发者都经历过这个场景。

3.1 先拆需求：别一上来就写SKILL.md

我第一次写Skill的时候，犯过一个特别典型的错误：打开编辑器就开始准备写SKILL.md的正文，结果憋了半天写出一堆正确的废话。后来我发现，正确的姿势是先做需求拆解。

设计一个Skill之前，你必须回答四个问题。

第一，这个Skill在什么时候被触发？触发条件越明确，AI的加载准确率就越高。比如“设计稿还原”这个Skill，触发条件应该定义为：用户上传了一张图片或设计稿文件，同时期望生成对应的前端页面代码。

第二，这个Skill包含哪些工作流步骤？这里要把一个大任务拆成顺序清晰的小步骤。拿设计稿还原来说，我会拆成五步：分析设计稿风格和布局、提取主题色与字体变量、对照项目技术栈确定组件方案、逐区块生成代码、自查和修正样式。

第三，这个Skill需要哪些参考资料或背景知识？比如你的项目用的是Tailwind还是Ant Design，组件的命名习惯是什么，是否有统一的工具函数库。这些都应该作为参考资料放在Skill目录里，而不是写在正文里让AI去猜。

第四，Skill的最终输出应该长什么样？是完整的代码文件，还是带说明文档的代码片段？是直接可以运行的，还是需要人工再润色一步？这个界定了质量标准，AI才知道自己在什么时候算“干完了”。

这四个问题想清楚之后，你脑海里的Skill其实已经成型了一大半，写SKILL.md就变成了一件很顺手的记录工作。

3.2 SKILL.md怎么写才不废话

SKILL.md是这个技能包的“说明书”，它的作用是让AI在最短时间内理解你的意图，所以最忌讳的就是长篇大论、废话连篇。你要把它当成给一个聪明但没经验的实习生写的操作手册，而不是学术论文。

按照Claude Code的规范，SKILL.md开头是一个YAML格式的frontmatter，里面主要是name和description两个字段。需要注意，description字段非常重要，AI就是靠它来判断该不该加载你这个Skill的。你必须在description里写清楚你的Skill“在什么场景下、解决什么问题”，不要泛泛地说“帮助用户写好代码”，那跟没说一样。你要写类似“当用户需要将设计图转换为高保真前端代码时使用此技能，支持从图片中提取色板、布局、字体并生成响应式页面”，这样就具体得多。

正文部分，我习惯用自己的模板，结构固定，实测下来效果很好：

--- name: frontend-design-restore description: 将设计稿图片还原为高保真前端页面的技能。适用于用户提供截图、Figma导出图或设计稿单页时的页面开发场景。支持分析布局、提取主题变量、生成响应式代码。 --- # 将设计稿还原为前端页面 ## 适用场景 - 用户提供设计稿图，期望得到可直接运行的页面代码 - 用户希望新页面与现有项目的组件规范和主题风格保持一致 ## 工作流程 1. **分析设计稿**：识别页面整体布局、区块层次、间距体系与视觉风格。 2. **提取主题变量**：从设计稿中提取主色、辅助色、字体、圆角、阴影，形成Tailwind或CSS变量配置。 3. **确定技术方案**：根据项目的现有技术栈（React/Vue/Tailwind等）选择组件实现方式。 4. **逐区块生成代码**：从上到下依次实现导航、主体内容、侧边栏、页脚等模块。 5. **响应式与细节修正**：检查断点适配、交互态样式和无障碍处理。 ## 输出要求 - 返回可直接打开运行的完整页面代码 - 代码中注释标明关键设计决策 - 标明哪些变量是从原设计稿自动提取的 ## 参考文件 - 读取 `references/theme-tokens.md` 获取本项目主题变量命名规范 - 读取 `references/component-patterns.md` 获取常用组件的实现模式 ## 工作流原则 - 不做过度设计：忠实还原设计稿，不擅自添加装饰元素 - 用上下留白和间距控制层级，避免用大量绝对定位 - 遇到设计稿未覆盖的交互状态时，使用项目中已有模式并显式说明

这个模板的核心理念是“给了AI明确的出口与边界”：适用场景防止误用，工作流程防止遗漏步骤，输出要求保证交付质量，参考文件让它去读配套资料而不是瞎猜。

3.3 资源文件与参考资料的合理组织

一个Skill如果只靠一个SKILL.md撑场面，那它功能再强也有限。真正好用的Skill往往都配套了丰富的资源文件。我自己常用的组织方式有两种：references/放文档类参考资料，scripts/放可执行的辅助脚本。

references/目录适合放什么？我前端项目的主题变量规范、常用UI组件的代码模式、项目的历史页面实现示例，这些能显著提高AI生成代码的命中率。比如我会把一个已经上线页面的组件写法作为“优质范例”放进references，然后在SKILL.md里写明“生成新页面时参考该范例的代码风格”。这样AI输出的代码就不是凭空想出来的，而是贴着项目真实标准来写的，一致性会好很多。

scripts/目录则可以用来放一些自动化工具。比如你可以写一个Python脚本，自动读取设计稿图片里的颜色信息并生成颜色变量文件。技能加载时，AI可以先执行脚本处理输入，再基于处理结果生成代码。这种“工具+流程”的组合，才真正把Skills用出了“多智能体系统”的味道。

需要注意一个细节：资源文件不要塞太大。我之前见过有人把一个几MB的设计规范PDF塞进references里，结果AI每次加载技能都吃几十万的token，对话没几轮就撞上上下文上限了。正确做法是提取精简要点写进Markdown，或者用脚本按需读取原始大文件，而不是让AI把所有参考资料一次性载入。

3.4 实测：用一个能跑的Skills案例走一遍

光说不练假把式。这里我放一个真实的“前端设计稿还原”Skill落地后的调用过程，你可以直观感受一下一个设计良好的Skill是怎么被AI执行的。

# 先创建一个技能目录 mkdir -p .claude/skills/frontend-design-restore/references mkdir -p .claude/skills/frontend-design-restore/scripts # 把主题变量规范放进去 cat > .claude/skills/frontend-design-restore/references/theme-tokens.md << 'EOF' # 项目主题变量规范 - 主色：#2563EB（业务蓝） - 辅助色：#F59E0B（警示黄） - 字体：Inter, system-ui, sans-serif - 圆角：8px 基础圆角；16px 卡片圆角 - 阴影：0 1px 2px rgba(0,0,0,0.05) EOF # 把组件模式示例放进去 cat > .claude/skills/frontend-design-restore/references/component-patterns.md << 'EOF' # 按钮组件实现模式 采用 React + Tailwind 方式，核心类名组合为： `inline-flex items-center justify-center rounded-md bg-blue-600 px-4 py-2 text-sm font-medium text-white hover:bg-blue-500` EOF

然后你在实际干活时，直接把设计稿截图拖进对话，或者粘贴图片路径，接着告诉Claude Code一条极简的指令：“用frontend-design-restore这个技能把这张图还原成页面”。

我实测下来，AI会经历以下过程：先扫描SKILL.md得知整个流程，然后读取references里的主题变量与组件规范，接着调用文件系统工具读取设计稿图片，逐区块生成代码。如果生成的代码里某些间距和设计稿不一致，它会自己走到“响应式与细节修正”这一步去修订。整个过程基本不用我再塞背景知识，最多就是最后我手调一下细节，这套流程跑得非常顺。

4. Skills与MCP的联动，以及常见问题排查实录

Skills真正威力爆发，是在它跟MCP工具串联起来的时候。而且越用深入，你越会发现：Skill调试其实是一门“手工活”，很多问题只要你知道原因，十分钟就能解决。

4.1 Skills如何调用MCP工具：配置与实战

先说场景。你希望“网页查资料”这个Skill能通过MCP检索实时数据，而不是每次都让AI叹气说知识截止日期。这就要在Skill里显式声明对MCP工具的依赖。

在Claude Code环境里，MCP server通常保存在.mcp.json或项目配置中。你的Skill要做的事，就是告诉AI“这个任务需要调用哪些工具”，并把调用方式写明白。我习惯在SKILL.md里加一段“工具依赖”区域，例如：

--- name: web-research-summary description: 基于实时网页搜索和内容抓取，输出结构化研究报告的技能。适用于需要最新资料或数据支撑的场景。 --- ## 工具依赖 - 使用 `web_search` 进行关键词搜索，获取候选页面列表 - 使用 `web_fetch` 抓取目标页面的正文内容 - 使用 `content_extract` 提取页面的核心观点与关键数据

核心思路是：Skill负责定目标，MCP负责干执行。你不需要在Skill里写“具体怎么搜索”这种琐碎指令，因为MCP工具已经实现了搜索逻辑。你只需要告诉AI“什么情况下用哪个工具、用完之后怎么处理结果”。

Codex那边的玩法也类似，但由于Codex对AGENTS.md的依赖更强，我一般会在AGENTS.md里先声明“该项目启用了web-research-summary技能，涉及最新资料查询时请调用此技能”，然后在skills目录里放相应实现。Cursor中对MCP的配置更直观，你在设置页面加好MCP server，然后规则文件里引用工具名即可。

需要提醒的是，不要让Skill每次执行时都强行调用MCP工具。有些操作明显不需要实时数据，比如“生成一个静态HTML邮件模板”，你如果还在Skill里绑定一个搜索工具，反而会拖慢响应、引入噪音。所以设计Skills和MCP联动时，一个很重要的原则是：按需接入，而不是能接尽接。

4.2 开发调试Skills的日常：踩过的坑与习惯养成

Skills开发过程中的坑，我基本都踩过一遍，这里挑几个最典型的说说。

第一个坑是description写得过于抽象导致AI压根不触发这个Skill。我一开始写过“协助用户高效完成前端页面开发”这种描述，结果AI在99%的情况下根本想不起还有这个技能存在，整个Skill形同虚设。后来我改成“当用户提供设计稿截图时使用，输出符合项目Tailwind主题规范的高保真页面代码”之后，触发率一下子涨上来了。核心原因就是：AI在判断“该不该用技能”时，靠的是description与当前任务的语义匹配度，匹配度不够自然就失灵。

第二个坑是参考文件路径写错。Skill里如果你写了“请参考references/xxx.md”，这个路径的基准目录是有讲究的。有些AI理解的是相对项目根目录，有些理解的是相对SKILL.md所在目录。如果你写的路径和AI的理解不一致，它就会跟你要一个不存在的文件，或者自己编一套规范出来。我的习惯是，在SKILL.md开头就用绝对路径或从项目根目录开始的相对路径写清楚，避免歧义，这样调试起来省很多功夫。

第三个坑是上下文塞太多导致模型“东施效颦”。同一个Skill里如果放了太多互相冲突的参考资料，AI反而会不知道该听谁的。比如你在references里既放了一套“简洁风格”的页面范例，又放了一套“信息密度高”的页面范例，那AI生成出来的东西大概率会四不像。现在我维护资源文件的原则是：宁缺毋滥，每个参考文件必须有明确的使用场景，并且在主文档里说清楚什么时候该参考哪一份。

4.3 社区高频问题速查表

最后做个收尾，把Skill开发和使用中最常见的问题整理成一个速查表，方便你遇到问题时直接对号入座。

我在实际使用中的体会是，Skills到了一定规模之后，真正的门槛不在“怎么写单条技能”，而在“怎么让整个技能库互相配合不打架”。你可以建立一套“索引Skill”，它不负责具体任务，只负责把其他Skill按场景分类并说明各自的边界，这样AI在每次开局时就能快速定位到合适的技能。这就像给团队立项目录，每个新需求进来，先查目录再找人，而不是把所有人都问一遍。

如果你也在折腾Skills，欢迎沿着我上面的思路去迭代。先挑一个你自己日常重复度高的场景，按“拆需求—写模板—配资源—接MCP—调试触发率”这个节奏走一遍，大概率能做出第一个有实际生产力的Skill。等跑通了第一个，后面做就会快很多。