企业官网建设流程全解析

1. 从“skills”这个热词说起：它到底是什么，为什么突然火了

最近几个月，不管是在技术社区还是开发者群聊里，“skills”这个词出现的频率高得离谱。你随便翻翻热搜词列表就能看到：claude code skills、codex skills、agent skills测试、skills开发、好用的skills、skills推荐……一大堆。很多人第一次看到会懵：这跟“技能”有什么关系？是某种新框架？还是某个插件市场？

我一开始也以为是营销概念，直到自己动手把几个主流AI编程工具（Claude Code、Codex、各类agents）的skills机制都跑了一遍，才发现这东西确实解决了一个非常实际的痛点：让AI编程助手从“通用聊天机器人”变成“懂你项目规矩的专属助手”。

简单说，skills就是一套可复用、可组合、可版本管理的指令包。它通常以文件夹或配置文件的形式存在，里面写清楚了“在什么场景下，AI应该按照什么步骤、用什么工具、遵守什么约束来完成任务”。你可以把它理解成给AI看的“操作手册”或者“岗位SOP”。比如你有一个前端项目，每次让AI改组件，它总是忘记你们团队用的CSS命名规范，那你就写一个frontend-component.skill，里面把规范、目录结构、常用命令全列进去。下次AI再动手之前，会自动加载这个skill，按规矩办事。

这波热度背后有三个推手。第一，Claude Code和Codex这类终端里的AI编程工具开始支持本地skill加载，开发者发现“调教一次，终身受益”。第二，agents概念爆发，大家意识到光有模型不够，还得有“技能库”才能让agent真正干活。第三，社区开始出现skills市场，比如claude 国内安装skills 官方市场、find skills这类搜索词，说明大家已经在找现成的轮子了。

这篇文章适合谁看？如果你是刚接触AI编程工具的新手，想搞清楚skills到底怎么装、怎么用、怎么自己写，那这篇就是为你准备的。如果你已经在用Claude Code或Codex，但总觉得AI“不够听话”，那更该看看——大概率是你还没把skills用到位。我会从设计思路、核心细节、实操流程、常见坑四个维度，把skills这件事彻底讲透。

2. 整体设计思路：为什么是“技能包”而不是“提示词”

2.1 从提示词工程到技能工程的演进逻辑

过去两年，大家用AI编程工具的主要方式是在对话框里敲提示词。你想让AI帮你写个React组件，就得把项目背景、代码规范、依赖版本、文件路径全塞进一段话里。下次再写另一个组件，又得重新塞一遍。这种方式的效率极低，而且容易漏掉关键约束。

skills的出现，本质上是把“一次性提示词”升级成了“持久化技能包”。它的设计哲学很直接：把重复性的上下文和操作流程从对话中抽离出来，变成可加载的模块。这跟传统软件工程里“不要重复自己”的原则是一脉相承的。

我拿一个实际场景对比一下。假设你有一个Vue项目，团队规定所有组件必须用<script setup>语法，样式必须用SCSS，文件名必须用PascalCase。没有skills的时候，你每次让AI写组件都得说一遍：“用Vue3的script setup，样式用SCSS，文件名大驼峰，不要用Options API……”AI有时候记住了，有时候写着写着就忘了。有了skills之后，你只需要在项目根目录放一个.skills/vue-component.md，里面把这些规矩写清楚。AI在检测到你要创建Vue组件时，会自动读取这个skill，然后严格按照里面的步骤执行。

提示：skills不是替代提示词，而是把“系统级约束”和“流程性知识”从提示词里剥离出来。日常对话还是用提示词，但那些每次都要重复的规矩，交给skills。

2.2 主流工具的skills机制差异：Claude Code vs Codex vs 通用agents

目前市面上支持skills的工具主要有三类，它们的实现方式各有侧重，我整理了一个对比表格，方便你根据自己用的工具来选方案。

Claude Code的skills机制是我用得最顺手的。它默认会扫描项目里的.claude/skills/目录，每个skill是一个Markdown文件，文件名就是skill名称。你可以在对话里用/skill 名称来手动触发，也可以让AI根据上下文自动匹配。Codex那边更偏向“命令式”，你需要在配置文件里注册skill，然后通过特定命令调用，适合那些需要精确控制执行时机的场景。

通用agents框架就五花八门了。比如LangChain的deep agents，它把skills当作一种“工具”来注册，你需要自己写加载器。好处是你可以把skills存在数据库里，动态下发；坏处是前期搭建成本高。如果你只是想让AI帮你写代码，直接用Claude Code或Codex的内置机制就够了。

2.3 一个skill的典型结构：从元数据到执行步骤

不管哪个平台，一个设计良好的skill通常包含四个部分。我拿一个前端组件开发的skill举例，让你直观感受一下。

第一部分是元数据，包括skill名称、适用场景、触发条件。比如name: vue-component-generator，trigger: 当用户要求创建Vue组件时。这部分决定了AI什么时候该加载这个skill。

第二部分是上下文约束，也就是项目的基本信息。比如“本项目使用Vue 3.4 + Vite + TypeScript，组件目录在src/components/，样式方案为SCSS”。这些信息AI每次都需要知道，但不需要你每次都说。

第三部分是执行步骤，这是skill的核心。比如“第一步，询问组件名称和用途；第二步，在src/components/下创建PascalCase命名的.vue文件；第三步，使用<script setup lang="ts">模板；第四步，生成对应的.scss文件并引入”。步骤要写得足够具体，AI才能稳定执行。

第四部分是校验规则，告诉AI怎么检查自己做对了没有。比如“检查文件名是否为大驼峰，检查是否使用了defineProps而不是props选项”。这部分能大幅降低AI“跑偏”的概率。

注意：skill不是越长越好。我见过有人写了两千行的skill，结果AI加载后反而抓不住重点。单个skill建议控制在200-500行，复杂流程拆成多个skill组合使用。

3. 核心细节解析：写一个好用的skill需要注意什么

3.1 触发条件的设计：让AI在该出手时才出手

skill的触发条件设计是最容易被忽视、但又最关键的一环。如果你把触发条件写得太宽泛，比如“当用户提到组件时”，那AI可能在你想聊架构的时候突然开始生成组件代码，非常烦人。反过来，如果写得太窄，比如“当用户输入‘请用Vue3的script setup语法创建一个名为Button的组件’时”，那这个skill基本永远不会被触发。

我的经验是，触发条件要围绕意图而不是关键词来写。比如“当用户表达‘创建/新建/生成一个前端组件’的意图时”，这样AI就能根据语义来判断，而不是死板地匹配字符串。Claude Code的skill系统支持自然语言描述触发条件，你写得越像在跟人解释，AI判断得越准。

另外，多个skill之间可能会有冲突。比如你有一个“React组件生成”skill和一个“Vue组件生成”skill，如果触发条件都写“创建组件”，AI就懵了。解决办法是在触发条件里加上技术栈限定，比如“当项目根目录存在vite.config.ts且依赖中包含vue时”。这样AI会先检查项目环境，再决定加载哪个skill。

3.2 步骤拆解的颗粒度：多细才算够

写skill步骤的时候，新手最容易犯两个错误：要么太粗，只写“生成组件代码”，AI自由发挥；要么太细，把每一行代码都写死，skill变成了模板复制。

合适的颗粒度是**“决策点+操作”**。决策点是指那些需要AI根据实际情况判断的地方，操作是指具体的执行动作。举个例子：

• 决策点：询问用户组件名称，如果用户未提供，则根据功能描述自动生成一个PascalCase名称。
• 操作：在src/components/目录下创建{组件名称}.vue文件。
• 决策点：检查项目是否已安装sass依赖，如果没有，提示用户安装。
• 操作：写入<script setup lang="ts">模板，包含defineProps和defineEmits。

这样写的好处是，AI知道哪些地方需要动脑子，哪些地方照做就行。实测下来，这种颗粒度的skill执行成功率最高，而且不同AI模型之间的表现差异也最小。

3.3 上下文注入的边界：什么该写进skill，什么不该

很多人写skill的时候，恨不得把整个项目的README都塞进去。结果skill文件巨大无比，AI加载慢不说，还容易“迷失在细节里”。我的原则是：只写AI每次都需要知道、但又不方便从代码里直接读到的信息。

具体来说，这几类信息适合写进skill：

• 项目技术栈和版本约束（比如“必须用React 18的并发特性”）
• 目录结构和命名规范（比如“所有hook放在src/hooks/，文件名以use开头”）
• 团队约定的代码风格（比如“禁止使用any，必须写JSDoc注释”）
• 常用命令和脚本（比如“运行测试用pnpm test:unit”）

这几类信息不适合写进skill：

• 具体的业务逻辑（这些应该从代码里读）
• 频繁变动的配置（比如API地址，应该用环境变量）
• 大段的代码示例（除非是模板，否则AI自己能生成）

提示：你可以把skill想象成“新员工入职手册”。新员工需要知道公司规矩、项目结构、常用工具，但不需要知道每个业务细节——那些他看代码就能学会。

3.4 版本管理与团队协作：skill不是一次性用品

skills一旦写出来，就会成为项目的一部分，需要像代码一样管理。我建议把.claude/skills/或.codex/skills/目录纳入Git版本控制，每次修改都走正常的代码审查流程。这样有几个好处：一是团队成员可以共享skill，新人入职直接拉代码就能用；二是skill的变更历史可追溯，出了问题能回滚；三是可以通过分支来试验新skill，不影响主分支。

团队协作时，还要注意skill的命名规范。我一般用{领域}-{功能}.md的格式，比如frontend-component.md、backend-api.md、devops-deploy.md。这样一眼就能看出skill的用途，也方便AI根据文件名做初步匹配。

另外，不同人的skill可能会有重叠。比如张三写了一个“React组件生成”skill，李四也写了一个。这时候不要简单合并，而是先分析两者的差异：如果只是风格不同，可以抽出一个“基础规范”skill，然后各自继承；如果功能确实重复，就保留更完善的那个，删掉另一个。skill库也需要定期清理，不然会越来越臃肿。

4. 实操过程：从零搭建一套可用的skills体系

4.1 环境准备：Claude Code和Codex的安装与配置

在开始写skill之前，你得先把工具装好。Claude Code的安装方式取决于你的操作系统。Windows用户可以通过npm全局安装，命令是npm install -g @anthropic-ai/claude-code，然后运行claude启动。macOS和Linux用户可以用Homebrew或者直接下载二进制包。安装完成后，首次运行需要登录，按照终端提示操作即可。

Codex的安装稍微不同。它通常作为VS Code插件或者独立CLI工具存在。如果你用VS Code，直接在扩展市场搜索“Codex”安装就行。独立CLI的话，去官网下载对应平台的安装包，解压后把可执行文件放到PATH里。安装完成后，运行codex init初始化项目配置。

这里有个小坑要注意：如果你在国内网络环境下，安装过程中可能会遇到下载超时的问题。我的建议是提前配置好npm镜像源，或者使用工具自带的离线安装包。另外，Claude Code和Codex都支持配置本地模型，比如通过LM Studio加载本地模型，这样就不依赖网络了。具体配置方法是在设置文件里指定baseUrl和model参数，指向本地服务的地址。

注意：安装完成后，先运行一个简单的测试命令，比如让AI写一个“Hello World”函数，确认工具能正常工作。不要一上来就写复杂的skill，不然出了问题你分不清是skill写错了还是环境没配好。

4.2 创建第一个skill：以“前端组件生成”为例

假设我们有一个Vue 3 + TypeScript + Vite的项目，现在要创建一个skill，让AI能按照团队规范生成组件。步骤如下。

第一步，在项目根目录创建.claude/skills/目录（如果你用Codex，就创建.codex/skills/）。然后新建一个文件frontend-component.md。

第二步，写入元数据。文件开头用YAML格式写清楚skill的名称、描述和触发条件：

--- name: frontend-component description: 按照团队规范生成Vue 3组件 trigger: 当用户要求创建、新建或生成一个Vue组件时 ---

第三步，写入上下文约束。这部分告诉AI项目的基本情况：

## 项目上下文 - 技术栈：Vue 3.4 + TypeScript + Vite + SCSS - 组件目录：src/components/ - 命名规范：文件名和组件名均使用PascalCase - 样式方案：每个组件对应一个同名.scss文件，使用BEM命名 - 状态管理：使用Pinia，store文件放在src/stores/

第四步，写入执行步骤。这是skill的核心，要写得具体但不过死：

## 执行步骤 1. 询问用户组件名称和功能描述。如果用户未提供名称，根据功能描述生成一个PascalCase名称。 2. 检查src/components/目录下是否已存在同名文件，如果存在，提示用户并询问是否覆盖。 3. 创建{组件名称}.vue文件，使用以下模板： - <script setup lang="ts">块，包含defineProps和defineEmits - <template>块，包含基本的语义化HTML结构 - <style scoped lang="scss">块，引入对应的.scss文件 4. 创建{组件名称}.scss文件，写入BEM风格的基础样式。 5. 如果组件需要状态管理，在src/stores/下创建对应的Pinia store文件。 6. 运行pnpm lint检查代码规范，如果有错误，自动修复。

第五步，写入校验规则：

## 校验规则 - 文件名是否为PascalCase - 是否使用了<script setup>而不是Options API - 是否定义了props和emits的类型 - 样式文件是否与组件文件同名 - 是否通过了ESLint检查

写完这五部分，一个可用的skill就完成了。保存文件后，在Claude Code里输入“帮我创建一个用户卡片组件”，AI就会自动加载这个skill，按照你定义的步骤执行。

4.3 调试与迭代：怎么知道skill写得好不好

skill写完之后，不要指望一次就完美。你需要反复测试和迭代。我的方法是准备一组“测试用例”，覆盖各种边界情况。比如：

• 用户提供了明确的组件名称
• 用户只描述了功能，没给名称
• 组件名称与已有文件冲突
• 组件需要复杂的props类型
• 组件需要调用API

每次修改skill后，把这组测试用例跑一遍，看看AI的表现是否稳定。如果某个用例失败了，就分析是触发条件没写清楚，还是步骤有歧义，然后针对性修改。

Claude Code提供了一个很有用的调试功能：你可以在对话里输入/skill debug frontend-component，它会显示skill的加载状态和匹配结果。如果skill没有被触发，它会告诉你原因，比如“触发条件未匹配”或“项目环境不满足”。这个功能能帮你快速定位问题。

提示：skill的迭代不要一次改太多。每次只改一个地方，然后测试。否则你分不清是哪个改动导致了行为变化。我一般用Git来管理skill的版本，每次修改都提交一次，方便对比。

4.4 组合多个skill：让AI处理复杂任务

单个skill能解决单一场景的问题，但实际开发中往往需要多个skill配合。比如你要开发一个完整的页面，可能涉及“组件生成”、“API调用”、“路由配置”、“状态管理”四个skill。这时候就需要设计skill的组合机制。

Claude Code支持在skill里引用其他skill。你可以在frontend-page.md里写：“本skill依赖frontend-component、frontend-api、frontend-router三个skill，执行时按顺序加载。”这样AI在处理页面生成任务时，会自动把相关skill都加载进来，形成一个完整的“技能链”。

组合的时候要注意执行顺序。一般来说，先加载“基础规范”类skill（比如代码风格），再加载“具体任务”类skill（比如组件生成），最后加载“校验”类skill。这样能确保AI在动手之前已经掌握了所有约束。

另外，skill之间不要有循环依赖。比如A引用B，B又引用A，AI会陷入死循环。设计的时候用有向无环图来规划依赖关系，保持层级清晰。

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

5.1 skill不生效？先检查这三个地方

这是最常见的问题。你写好了skill，但AI好像完全没看到。别急，按顺序检查以下三点。

第一，检查文件路径和命名。Claude Code默认扫描.claude/skills/目录，Codex扫描.codex/skills/。如果你放错了目录，AI肯定找不到。文件名也要注意，必须是.md后缀，而且不能有特殊字符。我见过有人把文件命名为frontend component.md，中间有个空格，结果加载失败。

第二，检查触发条件。如果触发条件写得太窄，AI可能匹配不到。你可以临时把触发条件改宽一点，比如改成“当用户提到组件时”，看看skill是否能被加载。如果能加载，说明是触发条件的问题，再慢慢收窄。

第三，检查项目环境。有些skill依赖特定的项目配置，比如“当项目使用Vite时”。如果你的项目没有vite.config.ts，skill就不会触发。这时候要么调整触发条件，要么先配置好项目环境。

注意：Claude Code的skill加载有缓存机制。如果你修改了skill文件但没生效，试试重启Claude Code或者运行/skill reload命令刷新缓存。

5.2 skill执行到一半卡住了怎么办

有时候AI加载了skill，执行了几步之后突然停住，或者开始胡言乱语。这通常是因为skill的步骤里有歧义，AI不知道下一步该干什么。

排查方法是把skill的步骤逐条读一遍，问自己：“如果我是AI，看到这条指令，我知道具体要做什么吗？”比如“生成组件代码”这种指令就太模糊了，AI可能生成一个空文件，也可能生成一堆无关代码。改成“在src/components/下创建{名称}.vue文件，写入包含<script setup>、<template>、<style scoped>三个块的模板”，就清楚多了。

另一个常见原因是skill里引用了不存在的工具或命令。比如你写“运行pnpm test”，但项目里根本没有配置测试脚本。AI执行到这一步就会卡住。解决办法是在skill里加上前置检查：“先检查package.json中是否有test脚本，如果没有，跳过测试步骤并提示用户。”

5.3 多个skill冲突时的优先级处理

当你装了多个skill，它们可能会对同一个任务给出不同的指令。比如“组件生成”skill说用PascalCase命名，“代码规范”skill说用kebab-case。AI夹在中间，不知道该听谁的。

解决冲突的原则是：越具体的skill优先级越高。你可以在skill的元数据里加一个priority字段，数值越大优先级越高。比如“组件生成”skill的priority设为10，“代码规范”skill设为5。当两者冲突时，AI会采用priority更高的那个。

如果没有priority字段，Claude Code会按照skill的加载顺序来决定，后加载的覆盖先加载的。所以你可以通过调整加载顺序来控制优先级。在组合skill的时候，把更具体的任务skill放在后面加载。

5.4 常见问题速查表

5.5 几个我踩过的坑和独家技巧

第一个坑：skill文件里用了中文标点。比如把trigger:写成了trigger：，YAML解析直接失败。这个坑我踩了两次才记住，现在写skill都用英文标点，只在描述性文字里用中文。

第二个坑：skill的触发条件里写了“当用户要求创建组件时”，结果AI在用户只是“讨论组件设计”的时候也触发了。后来我改成“当用户明确要求创建、新建或生成组件文件时”，就准确多了。关键词是“明确要求”和“文件”。

第三个技巧：给skill加一个“退出条件”。比如“如果用户说‘不用了’或‘取消’，立即停止执行并回到普通对话模式”。这样能避免AI在用户改变主意后还傻乎乎地继续执行。

第四个技巧：用/skill list命令查看当前加载的所有skill。Claude Code支持这个命令，能列出skill名称、触发条件和优先级。调试的时候非常有用，一眼就能看出哪个skill被加载了。

第五个技巧：把常用的skill导出成模板，分享给团队成员。Claude Code支持/skill export命令，能把skill打包成.skill文件。新人入职时直接导入，省去手动配置的麻烦。

6. 进阶玩法：让skills成为团队的基础设施

6.1 把skill纳入CI/CD流程

skill不只是给AI用的，它也可以成为团队规范的一部分。比如你可以在CI流水线里加一步“skill校验”，检查所有skill文件是否符合格式规范，触发条件是否与现有skill冲突。这样能防止有人提交了有问题的skill，影响整个团队的AI助手。

具体做法是写一个简单的Node.js脚本，遍历.claude/skills/目录，用js-yaml解析每个文件的元数据，检查必填字段是否存在，然后输出报告。如果校验失败，CI就报错，阻止合并。这个脚本我放在GitHub Actions里跑，每次PR都会自动检查，效果很好。

6.2 根据项目类型定制skill库

不同类型的项目需要不同的skill库。我一般会准备几套基础模板，新项目直接复制过去改改就能用。

前端项目的基础skill库包括：组件生成、页面生成、API调用、路由配置、状态管理、样式规范、测试生成。后端项目包括：接口生成、数据库迁移、服务部署、日志规范、错误处理。DevOps项目包括：容器构建、流水线配置、监控告警、回滚流程。

每套模板里的skill都遵循相同的结构，只是具体内容不同。这样团队成员切换项目时，不需要重新学习skill的用法，直接看内容就行。

6.3 社区skill的筛选与本地化改造

现在社区里有很多现成的skill可以下载，比如claude 国内安装skills 官方市场里就有不少。但直接拿来用往往水土不服，因为每个项目的技术栈和规范都不一样。

我的做法是：先下载社区skill，通读一遍，理解它的设计思路。然后根据自己项目的情况，修改触发条件、上下文约束和执行步骤。最后在本地测试通过后，再纳入团队的skill库。千万不要直接复制粘贴，不然AI执行的时候会各种报错。

筛选社区skill的时候，重点看三个指标：更新频率、issue数量、star数。更新频繁说明作者在维护，issue少说明质量稳定，star多说明经过多人验证。三个指标都好的skill，值得花时间改造。

6.4 未来可能的方向：skill市场与标准化

从最近的热搜词来看，find skills、skills推荐、skills开发这些词的出现频率越来越高，说明社区对skill的需求正在从“自己写”转向“找现成的”。我猜测未来会出现几个趋势：一是skill的标准化格式，不同工具之间可以互相导入；二是skill市场平台，开发者可以发布和交易skill；三是skill的自动生成，AI根据项目代码自动推导出需要的skill。

不过这些都是后话。眼下最实际的做法，还是先把你自己项目里的重复性工作梳理一遍，挑出最耗时的三个场景，写成skill。用起来之后，你自然会发现更多可以优化的地方。skill这件事，起步比完美重要得多。