企业官网建设流程全解析

1. 为什么 Skills 值得开发者认真对待

1.1 从一个真实场景说起

你可能已经习惯了这样的工作流：打开 Cursor 或 Claude Code，敲一段提示词，AI 帮你补全代码、解释报错、生成测试。用了一段时间之后你会发现一个问题——每次都要重新交代背景。项目用什么框架、代码风格是什么、目录结构怎么组织、提交信息用什么格式，这些信息你反复输入，AI 反复遗忘。

Skills 要解决的就是这件事。

简单说，Skill 就是一份写给 AI 看的“操作手册”。它把某类任务的背景知识、执行步骤、约束条件、输出格式固化成一个结构化文件（通常是SKILL.md），放在约定目录下。AI 在需要执行相关任务时，会自动读取这份手册，按照你预设的方式工作。你不需要每次重复交代，AI 也不会再“自由发挥”。

我最初接触这个概念时也没太当回事，觉得不就是把提示词存成文件吗。但实际用下来发现差别很大：普通提示词是“一次性”的，Skill 是“常驻”的；提示词靠你手动粘贴，Skill 靠 AI 主动识别调用。这个从“人找工具”到“工具找人”的转变，才是它真正有价值的地方。

1.2 Skills 到底解决了什么问题

从我这段时间的实践来看，Skills 主要解决三类痛点。

第一类是重复交代成本高。团队里每个人用 AI 的习惯不一样，有人喜欢让 AI 写详细注释，有人喜欢简洁风格。如果没有统一约束，AI 产出的代码风格五花八门，Code Review 时全是格式问题。把团队规范写成 Skill，AI 每次生成代码都会自动遵守。

第二类是专业任务门槛高。比如生成数据库迁移脚本、写符合特定规范的 API 文档、做安全审计检查，这些任务有固定的流程和检查点。新手不知道从哪下手，老手也容易漏步骤。Skill 把这些流程固化下来，相当于把老手的经验打包成了可复用的资产。

第三类是跨工具迁移麻烦。你在 Cursor 里调教好的一套工作方式，换到 Claude Code 里要重新来一遍。Skill 作为标准化的文件格式，理论上可以在支持它的不同工具之间复用，减少重复劳动。

注意：Skill 不是万能的。它擅长的是“有固定套路的任务”，对于需要大量创造性判断、需求本身还在探索阶段的工作，Skill 的帮助有限，甚至可能因为约束太死而限制 AI 的发挥。

1.3 适合谁来用

如果你符合下面任意一条，Skills 值得花时间研究：

• 每天用 AI 编程工具超过 1 小时，觉得重复交代背景很烦
• 团队里有代码规范或文档规范，希望 AI 产出一致
• 经常执行某类固定流程的任务（比如写周报、生成测试用例、做代码审查）
• 想把自己积累的工作经验沉淀成可复用的东西

如果你只是偶尔用 AI 问几个问题，那暂时不需要折腾 Skill，直接对话就够了。

2. 八类值得安装的 Skills 详解

2.1 代码规范类 Skill

这是最基础也最实用的一类。它的核心作用是让 AI 生成的代码符合你或团队的编码规范。

一个典型的代码规范 Skill 会包含这些内容：命名约定（驼峰还是下划线、常量全大写等）、缩进和换行规则、注释风格（行注释还是块注释、是否要求函数级注释）、导入顺序、错误处理模式、日志格式。

我自己的做法是把 ESLint 或 Prettier 的配置要点提炼成自然语言写进SKILL.md，而不是直接贴配置文件。原因是 AI 读自然语言的理解效果比读 JSON 配置更好，它能理解“为什么”而不只是“是什么”。比如与其写"semi": false，不如写“语句末尾不加分号，保持与现有代码库一致”。

这类 Skill 的触发场景通常是：AI 生成新代码、重构现有代码、修复 lint 报错。你可以在 Skill 里明确写清楚“当生成 JavaScript 或 TypeScript 代码时应用本规范”。

2.2 项目上下文类 Skill

这类 Skill 解决的是“AI 不了解我的项目”这个问题。

内容一般包括：项目技术栈和版本、目录结构说明、核心模块职责、数据流向、环境变量说明、常用命令（启动、构建、测试、部署）。

写这类 Skill 有个技巧：不要试图把整个项目文档搬进去。AI 的上下文窗口有限，信息太多反而会稀释重点。我的经验是控制在 500 到 800 字，只写“AI 做决策时需要知道的信息”。比如“本项目使用 Next.js 14 App Router，所有页面组件放在app/目录下，数据获取统一用 Server Components，客户端交互才用use client”——这种信息能直接指导 AI 把代码写对地方。

2.3 测试生成类 Skill

写测试是很多开发者的痛点，也是 AI 比较擅长的领域。但如果不加约束，AI 生成的测试往往质量参差不齐：要么只测 happy path，要么 mock 写得过于复杂，要么断言太弱。

测试生成 Skill 应该规定：测试框架和断言库、测试文件命名和存放位置、mock 策略（什么时候 mock、用什么工具）、覆盖率要求、必须覆盖的边界条件类型。

我通常会在 Skill 里列一个检查清单，比如“每个函数至少覆盖：正常输入、空值、边界值、异常抛出”。AI 拿到这个清单后，生成的测试完整度明显提升。另外建议在 Skill 里写明“不要为了凑覆盖率写无意义的断言”，否则 AI 会生成一堆expect(result).toBeDefined()这种废话。

2.4 文档生成类 Skill

包括 API 文档、README、变更日志、代码注释等。

这类 Skill 的关键是定义清楚输出格式。比如 API 文档要包含：接口路径、请求方法、请求参数表、响应示例、错误码说明。README 要包含：项目简介、安装步骤、快速开始、配置说明、常见问题。

我踩过的一个坑是：早期没规定语言，AI 有时候写中文有时候写英文，同一个项目里混着来。后来在 Skill 里明确写“所有文档使用中文，代码注释使用英文”，就统一了。

2.5 Git 工作流类 Skill

这类 Skill 管的是提交信息格式、分支命名规范、PR 描述模板。

提交信息建议遵循 Conventional Commits 规范：feat:、fix:、docs:、refactor:等前缀。在 Skill 里写清楚每种前缀的使用场景，AI 生成提交信息时就不会乱用。

PR 描述模板可以规定：变更类型、变更说明、测试方式、影响范围、截图（如果是 UI 变更）。这样每次让 AI 帮忙写 PR 描述，格式都是统一的，Review 的人看起来也舒服。

2.6 代码审查类 Skill

让 AI 做 Code Review 时，如果没有约束，它往往只会说“这段代码看起来不错”或者提一些无关痛痒的建议。

代码审查 Skill 应该定义审查维度：安全性（SQL 注入、XSS、敏感信息泄露）、性能（不必要的循环、内存泄漏风险）、可维护性（函数长度、圈复杂度、重复代码）、错误处理（是否吞异常、是否有兜底）。

还可以定义严重等级：blocker、major、minor、nit。让 AI 按等级分类输出，这样你能快速判断哪些必须改，哪些可以忽略。

2.7 特定框架/库类 Skill

如果你深度使用某个框架，可以给它单独写一个 Skill。比如 React、Vue、Django、Rails，每个框架都有自己的最佳实践和常见陷阱。

以 React 为例，Skill 里可以写：优先使用函数组件和 Hooks、状态管理选型建议、性能优化手段（memo、useMemo、useCallback 的使用时机）、副作用处理规范。

这类 Skill 的价值在于把框架社区的最佳实践浓缩成 AI 能直接执行的规则，避免 AI 生成过时的写法（比如还在用 class 组件）。

2.8 领域知识类 Skill

这类 Skill 比较特殊，它不针对某种编程任务，而是注入特定领域的知识。

比如你做的是金融系统，可以写一个 Skill 说明金融计算中的精度处理规则、货币格式化方式、时区处理注意事项。你做的是医疗系统，可以写 HIPAA 合规相关的数据处理要求。

这类 Skill 的门槛在于：你得先把领域知识梳理清楚。但一旦写好，AI 在这个领域的输出质量会有质的提升，因为它不再需要你每次解释“金额不能用浮点数”这种背景。

3. SKILL.md 文件结构与编写要点

3.1 基本结构

一个标准的SKILL.md通常包含以下几个部分：

--- name: skill-name description: 一句话说明这个 Skill 做什么 --- # Skill 标题 ## 何时使用 描述触发条件 ## 执行步骤 1. 第一步 2. 第二步 ## 约束条件 - 约束一 - 约束二 ## 输出格式 描述期望的输出结构 ## 示例 给出输入输出示例

文件头部的 YAML front matter 是关键，name和description决定了 AI 能否正确识别并调用这个 Skill。description要写得具体，不要写“帮助处理代码”这种模糊描述，而要写“当用户要求生成 React 组件测试时使用，输出 Jest + React Testing Library 格式的测试文件”。

3.2 编写原则

具体优于抽象。不要写“遵循良好的编程实践”，要写“函数不超过 50 行，参数不超过 4 个，嵌套不超过 3 层”。AI 需要可执行的规则，不是价值观。

正面表述优于负面禁止。与其写“不要使用 var”，不如写“使用 const，需要重新赋值时用 let”。正面指令更容易被正确执行。

示例胜过千言万语。在 Skill 里放一两个输入输出示例，AI 的模仿效果比读十条规则还好。

控制长度。单个 Skill 建议在 300 到 1000 字之间。太短信息不足，太长 AI 抓不住重点。如果一个 Skill 超过 1500 字，考虑拆成两个。

3.3 目录组织

不同工具对 Skill 存放位置的要求不同，但常见约定是放在项目根目录的.skills/或.ai/skills/目录下，每个 Skill 一个子目录：

.skills/ code-style/ SKILL.md test-gen/ SKILL.md git-workflow/ SKILL.md

有些工具支持全局 Skill（放在用户主目录下）和项目级 Skill（放在项目目录下）。项目级的优先级通常更高，适合放项目特有的规范；全局的放通用规范，比如个人编码偏好。

4. 接入 Cursor 的完整流程

4.1 前置准备

确保你的 Cursor 是最新版本。Skills 功能依赖较新的版本支持，老版本可能读不到 Skill 文件。在设置里检查更新，或者去官网下载最新安装包。

确认你的项目目录结构清晰。如果项目根目录下一堆乱七八糟的文件，建议先整理一下，至少让.skills/目录能放在显眼位置。

4.2 创建 Skill 文件

在项目根目录创建.skills/目录，然后在里面创建你的第一个 Skill。建议从代码规范类开始，因为这类 Skill 最容易验证效果。

写好后保存，注意文件名必须是SKILL.md，大小写敏感。有些系统对文件名大小写不敏感，但为了跨平台兼容，统一用大写。

4.3 配置 Cursor 识别 Skill

Cursor 对 Skill 的支持方式随着版本更新有变化。目前常见的做法是在项目的.cursorrules文件或 Cursor 的设置中引用 Skill 目录。

如果 Cursor 版本支持自动扫描.skills/目录，那创建好文件就能用。如果不支持，需要在对话中手动引导，比如“请参考.skills/code-style/SKILL.md中的规范来生成代码”。

我实测下来，最稳妥的方式是在项目根目录的规则文件里加一行说明，告诉 Cursor 去哪个目录找 Skill。这样每次新开对话，Cursor 都会自动加载。

4.4 验证 Skill 是否生效

写一个简单的测试：让 Cursor 生成一段代码，看它是否遵守了 Skill 里的规范。比如你的 Skill 规定“函数必须有 JSDoc 注释”，那就让 Cursor 写一个函数，看它有没有自动加注释。

如果没有生效，检查几个点：文件路径对不对、文件名是不是SKILL.md、front matter 格式是否正确、Cursor 版本是否支持。排查顺序从简单到复杂，大部分问题出在路径和文件名上。

4.5 Cursor 中文设置与 Skills 的配合

很多人在找 Cursor 中文怎么设置。界面语言在设置里可以切换，但要注意：Skill 文件的内容语言和界面语言是两回事。界面切成中文不影响 Skill 的读取，Skill 里写中文还是英文取决于你的偏好。

我的建议是 Skill 内容用中文写，因为你自己维护起来更方便，AI 对中文的理解也没问题。但如果团队里有非中文使用者，或者你希望 Skill 能跨工具复用，用英文写兼容性更好。

5. 接入 Claude Code 的完整流程

5.1 安装与基础配置

Claude Code 的安装方式取决于你的操作系统。macOS 和 Linux 通常通过包管理器或安装脚本，Windows 建议在 WSL 环境下使用。

安装完成后，首次运行需要配置 API 密钥和基本偏好。这些步骤按照官方指引操作即可，不复杂。

5.2 手动安装 GitHub 上的 Skills

这是很多人关心的问题：Claude Code 怎么手动装 GitHub 上的 Skills。

流程其实很简单：把 GitHub 仓库克隆到本地，找到里面的 Skill 文件，复制到 Claude Code 能识别的目录下。Claude Code 通常识别项目目录下的.claude/skills/或用户主目录下的对应位置。

具体步骤：

1. 克隆仓库：git clone <仓库地址>
2. 查看仓库结构，找到SKILL.md文件所在目录
3. 把整个 Skill 目录复制到.claude/skills/下
4. 重启 Claude Code 或重新加载项目
5. 在对话中测试 Skill 是否被识别

注意：从 GitHub 安装第三方 Skill 时，先读一遍SKILL.md的内容。确认它做的事情是你想要的，没有奇怪的指令。Skill 本质上是给 AI 的指令，来源不可控的 Skill 存在一定风险。

5.3 VS Code 中配置 Claude Code

如果你习惯在 VS Code 里工作，可以安装 Claude Code 的 VS Code 扩展。安装后，Claude Code 会在侧边栏或命令面板中可用。

配置要点：确保扩展能访问到你的项目目录，Skill 文件放在项目目录下就能被识别。如果遇到识别问题，检查扩展的工作目录设置是否正确。

VS Code 和 Claude Code 的配合有个好处：你可以在编辑器里直接看到 AI 的修改，边看边调整 Skill。这种即时反馈对打磨 Skill 很有帮助。

5.4 跨工具复用 Skill 的注意事项

Cursor 和 Claude Code 对 Skill 的支持细节有差异。比如 front matter 的字段要求可能不同，触发机制也可能不一样。

如果你想让同一个 Skill 在两个工具里都能用，建议：front matter 只写最基础的name和description，不要用工具特有的字段；内容尽量用通用表述，避免引用特定工具的功能；在两个工具里分别测试，确认都能正常工作。

6. 常见问题与排查技巧

6.1 Skill 不生效怎么办

这是最高频的问题。排查顺序如下：

我遇到最多的情况是 front matter 格式错误。YAML 对缩进和空格很敏感，name: xxx冒号后面必须有一个空格，这个细节很容易忽略。

6.2 Skill 太多导致 AI 混乱

有人装了几十个 Skill，结果 AI 反而不知道该用哪个。这不是 Skill 的问题，是组织的问题。

建议：项目级 Skill 控制在 5 到 8 个，覆盖最常用的场景。其他不常用的做成全局 Skill，需要时手动引导。定期清理不再使用的 Skill，保持精简。

6.3 Skill 内容冲突

两个 Skill 对同一件事有不同规定，比如一个说用分号一个说不用。AI 遇到这种情况会随机选一个，结果不稳定。

解决办法：建立 Skill 的优先级规则。在项目规则文件里写明哪个 Skill 优先。或者干脆合并冲突的 Skill，把规则统一。

6.4 如何调试 Skill

调试 Skill 有个笨办法但很有效：在 Skill 里临时加一条明显的规则，比如“所有变量名用拼音”。然后让 AI 生成代码，看它有没有遵守。如果遵守了，说明 Skill 被正确加载；如果不遵守，说明加载环节有问题。确认加载正常后，再把这条测试规则删掉。

6.5 常用 Skill 源网站

目前 Skill 的分享还比较分散，没有特别集中的平台。GitHub 上搜索SKILL.md或agent skills能找到一些开源集合。另外一些 AI 编程工具的官方文档里会提供示例 Skill，可以作为起点。

我的建议是：先从自己写开始。别人的 Skill 不一定适合你的项目，自己写的虽然粗糙，但贴合实际需求。用顺了之后再参考别人的优化。

7. 我个人的实操心得

7.1 从一个小 Skill 开始

不要一上来就写十个 Skill。选一个你最常重复交代的事情，写成 Skill，用一周，感受效果。有感觉了再写第二个。

我第一个 Skill 是提交信息规范。因为每次让 AI 写 commit message 都要说一遍格式，烦得不行。写完之后，AI 自动按 Conventional Commits 格式输出，省了不少事。这个正反馈让我有动力继续写其他的。

7.2 Skill 要迭代

第一版 Skill 不可能完美。用着用着你会发现某些规则 AI 理解不了，或者某些场景没覆盖到。随时改，改完立刻测试。Skill 是活文档，不是一劳永逸的东西。

我有个 Skill 改了七八版才稳定。早期版本规则写得太抽象，AI 执行不到位。后来把每条规则都配上正反示例，效果才好起来。

7.3 不要过度约束

Skill 的目的是让 AI 更好地完成任务，不是把 AI 变成只会按按钮的机器。留一些灵活空间，让 AI 在框架内发挥。

比如代码规范 Skill，我规定了大方向（命名、缩进、注释），但具体实现方式不限制。这样 AI 生成的代码既符合规范，又不会千篇一律。

7.4 团队协作中的 Skill 管理

如果团队一起用 Skill，建议把 Skill 文件纳入版本控制。谁改了什么都看得到，也方便回滚。

另外建议指定一个人负责维护 Skill，避免多人同时改导致冲突。定期 Review Skill 内容，清理过时规则，补充新规范。

7.5 关于 Superpower Skills

最近 Superpower Skills 这个词出现频率挺高。它指的是一类功能比较强大的 Skill 集合，通常包含多个相互配合的 Skill，覆盖从需求分析到代码生成的完整流程。

我的看法是：Superpower Skills 适合作为参考，看看别人怎么组织 Skill 体系。但直接拿来用效果未必好，因为每个项目的情况不同。更好的做法是理解它的设计思路，然后根据自己的需求定制。

安装 Superpower Skills 的流程和普通 Skill 一样：下载、放到对应目录、测试。但装完之后一定要花时间读一遍内容，知道它在做什么，不然出了问题都不知道从哪查。

7.6 图片生成 Skills 的安装

图片生成类 Skill 的安装包通常包含 Skill 文件和相关的配置说明。安装时注意依赖项，有些 Skill 需要额外的 API 密钥或本地工具支持。

这类 Skill 的SKILL.md里一般会写明前置条件，装之前先读一遍，确认环境满足要求。不满足的话先补依赖，不然装了也用不了。

8. 后续可以怎么扩展

Skill 体系搭起来之后，有几个方向可以继续深入。

一是自动化触发。目前很多工具还需要手动引导 AI 使用 Skill，未来如果能做到根据任务类型自动匹配 Skill，体验会更好。你可以关注所用工具的更新日志，看有没有相关功能。

二是Skill 组合。单个 Skill 能力有限，多个 Skill 串联能完成复杂任务。比如“需求分析 Skill → 代码生成 Skill → 测试生成 Skill → 文档生成 Skill”形成完整流水线。这需要 Skill 之间的接口设计得当，是个值得研究的方向。

三是效果度量。怎么知道一个 Skill 好不好用？可以记录使用前后的效率变化、AI 输出质量的提升程度。有数据支撑，优化方向更明确。

四是跨项目复用。把通用 Skill 抽出来做成全局配置，新项目直接继承。项目特有的 Skill 单独维护。这样既保证一致性，又保留灵活性。

我在实际使用中最大的体会是：Skill 的价值不在于技术多复杂，而在于它强迫你把“隐性知识”显性化。很多规范和经验在你脑子里是模糊的，写 Skill 的过程就是梳理和明确的过程。哪怕最后 AI 用得不多，这个梳理本身就有价值。