企业官网建设流程全解析

过去半年，我把 Cursor 和 Claude Code 当成了日常开发的主力编辑器，基本告别了“自己写一遍再让 AI 重写一遍”的低效循环。真正让这两个工具从“聊天机器人”变成“团队协作者”的，不是模型版本升级，而是 Skills。这个词最近火得不行：不管是 Cursor 用户还是 Claude Code 用户，都在讨论 superpower skills、前端开发 skills、各种 agent skills。说白了，Skills 就是给 AI agent 用的“工作手册 + 工具箱”，你提前把规范、流程、示例写清楚，模型碰到对应场景时自动调用，输出质量立刻不一样。这篇就聊聊我实际装下来有用的 8 类技能，以及把它们接入 Cursor 和 Claude Code 的完整流程，适合正在折腾 AI 编程工具、却总觉得“差点意思”的开发者。

1. Skills 到底是什么？先讲清楚这个“新物种”

1.1 一个需要认真对待的文件：SKILL.md

Skills 的核心是一个名为 SKILL.md 的 Markdown 文件。它像给 AI 备好的岗位说明书：头部用 YAML 写 name 和 description，正文是具体操作步骤、规范、注意事项、示例。当你在对话中提出一个任务，agent 会先读所有候选技能的描述，觉得匹配就把对应技能文件夹里的内容作为背景知识加载进来，再动手干活。这个概念最早由 Anthropic 在 Claude 的 agent 生态里带火，后来 Cursor、OpenAI Codex、opencode 等先后跟进，社区也冒出了 awesome-claude-skills 这类合集仓库。

我常跟团队说的一句话是：模型是大脑，上下文是短期记忆，Skills 就是放在手边的 SOP。真正复杂的项目里，大脑再聪明，手里没有好用的手册也会乱写。以前我们只能把规范写进系统提示词，改一次要等半天，而且所有任务共用同一套上下文；有了 Skills 之后，规范可以按场景拆分，模型自己判断该用哪一本手册，上下文占用量反而更小。

1.2 Skills 和 MCP 到底有什么区别

很多朋友第一次接触时会把 Skills 和 MCP 搞混。我的理解很简单：MCP 解决的是“AI 能不能连上外部系统”，Skills 解决的是“AI 知不知道该怎么把活干漂亮”。MCP 提供工具接口，Skills 提供知识、流程和约束。用生活类比就是：MCP 是给你装了一双手，Skills 是告诉你这双手在具体工种里该按哪个姿势干活。

两者配合使用，而不是二选一。举个例子：你通过 MCP 连上了数据库，AI 能读取表结构了，但如果你没写 SQL 规范类的 skill，它依然可能生成一堆不带索引、不带事务的裸 SQL。我实际把 sql-optimizer 这类技能装进 Claude Code 之后，每次让它写查询，都会主动补上执行计划分析和索引建议，这种变化不是模型升级带来的，而是纪律约束带来的。

1.3 为什么 Skills 突然变得这么重要

因为模型本身的指令遵循能力越强，越需要有人告诉它“你的工作范围和正确姿势”。Skills 把组织里的隐性知识显性化——哪里能改、哪里不能动、提交前要跑哪些检查、错误信息要怎么写。这也是为什么 Agent Skills 会被看作 AI 工程化的重要方向：它把分散在 wiki、代码注释、PR 评论里的经验，沉淀成 agent 可以直接消费的资产。社区热词“superpower skills”能火，本质就是大家发现，给 agent 叠一层技能，比单纯换更强的模型划算得多。

2. 8 类值得装的 Skills，按使用频率排序

我前前后后装过四五十个来自不同仓库的技能，最后真正留在本地的，按使用频率排下来基本就是下面 8 类。每类我给出典型技能、适合场景，以及我个人的使用体感。

2.1 代码评审与质量检查类

这类技能负责把关。典型场景是 code-review skill，它会从可读性、边界条件、安全、性能四个维度审查 diff，而不是只夸“代码写得好”。装过之后，AI 在 Cursor 的 Agent 模式下帮我 review 代码，甚至能指出我临时拼接 SQL 的注入风险。使用诀窍是把仓库里的 CONTRIBUTING.md、代码规范文档放进它的 references 目录，让审查标准跟团队真实规范一致，不然它只会照搬通用规则，产出很空泛。

2.2 架构设计与重构类

项目启动或大重构时很好用。比如 project-bootstrap skill 会根据技术栈生成目录结构、依赖清单、开发环境配置；refactoring skill 会先把改动范围画出来，再按“小步提交、每步可编译”的顺序执行，避免 AI 一次性改出几百行却全崩的尴尬。这类技能的核心价值是让 AI 学会“先计划、后动手”，而不是拿到任务就直接生成代码，所以我建议在 SKILL.md 里强制要求“第一步必须输出改动方案，等用户确认后再改”。

2.3 前端开发专项类

前端开发相关需求的技能包通常包括：React/Vue 组件的写法规范、Tailwind/样式体系的 class 规则、无障碍和响应式检查、性能优化清单。比如我常用的 component-creator skill，会在创建组件时自动带上 story、测试和文档骨架，省去很多重复劳动。社区热门的前端开发 skills 都针对某一类框架做得很细，装之前一定要先看它匹配不匹配你的技术栈，否则 React 的技能跑到 Vue 项目里，反而会帮倒忙。

2.4 后端与数据库类

后端类的关键词是“规范”和“安全”。api-design skill 会约束路由命名、状态码使用、参数校验方式；sql-optimizer skill 会先看执行计划再给优化建议。数据库类的技能尤其值得装，因为模型对数据库 schema 的感知力有限，你最好把表结构和索引信息整理进 references 文件，让 agent 回答时能参考到真实库结构。装这类技能后，生成的接口和 SQL 明显更“可上线”，代码评审时被驳回的次数少了一大截。

2.5 测试与质量门禁类

tdd skill 会把“先写失败测试→再写实现→再重构”的节奏刻进 AI 的工作流；针对具体框架的测试生成技能（如 vitest、pytest）可以按团队模板批量生成用例。我见过很多团队不做技能配置，AI 生成的测试全是 happy path，覆盖率好看但等于没测。这类 skill 的诀窍是让 AI 必须写出断言、边界值、异常场景，并在生成后自检一遍覆盖率。实测下来，有了明确指令的 AI 写测试，比默认状态认真得多。

2.6 Git 与协作流程类

提交信息、PR 描述、变更日志，看起来是小事，却是团队协作里最容易被 AI 搞砸的部分。conventional-commit skill 会根据 git diff 自动生成符合 Conventional Commits 的提交信息；pr-description skill 会把关联 issue、改动清单、测试说明、截图位置整理成规范的 PR 模板。这类技能装上后，code review 流程顺畅很多，因为提交信息本身就是一份小型设计说明，维护者扫一眼就知道这个 PR 在干什么。

2.7 文档与知识沉淀类

docs 类 skill 负责让 AI 好好说话：生成 README、JSDoc 注释、API 文档、架构决策记录。好的文档技能会要求 AI 先列出大纲、再按“背景 - 方案 - 示例”的结构展开，并且禁止输出那种“这段代码用于处理数据”的废话注释。我建议把团队的文档模板放进去，保证产出风格统一，后面维护成本断崖式下降。尤其要注意的是，文档技能里要写清楚目标读者，给新人看的和给架构组看的完全是两种写法。

2.8 内容生成与多模态类

最后一类偏向内容侧：图片生成、设计稿转代码、截图标注、营销文案。图片生成 skills 会把 prompt 规范化，保证出图风格一致、尺寸正确；design-to-code 技能则能把 Figma 截图转成可用的前端代码。很多开发者看不上这类，但实际做内部工具时需要生成示意图、操作指南图，有现成技能能省不少事。社区里“skills 安装包”里最常被下载的，恰恰就是这类能直接看到效果的技能，因为新手装完就能立刻感知到 Skills 的作用。

3. 从下载到落地：Cursor 接入 Skills 全流程

3.1 前置准备：确认版本与技能来源

Cursor 从 0.46 版本左右开始支持项目级 .cursor/skills 目录。动手之前先升级到最新版，否则很多技能装了也不会加载。技能来源主要有三类：

• 官方示例仓库 anthropics/skills，里面有大量可以直接借鉴的 SKILL.md 样例。
• 社区合集 awesome-claude-skills、superpowers 等项目，通常可以 clone 下来挑着用。
• 自己写的内部技能，后面第 5 节会详细讲。

下载时建议先看目录结构，很多“技能安装包”就是一个文件夹，复制进去就能用，不需要去装花哨的包管理器。如果下载的是 superpowers 这类大合集，我个人的习惯是只挑需要的子目录复制，不要整包塞进 skills 目录，否则会给模型匹配造成噪音，而且每次扫描也会慢一点。

3.2 在 Cursor 里放置和触发 Skills

放置位置分两种：

• 项目级：在项目根目录创建.cursor/skills/<skill-name>/SKILL.md，只对当前项目生效。
• 全局：放在用户目录的~/.cursor/skills下，所有项目可见，适合放通用技能。

放好后重启 Cursor 或者新建 Agent 对话。触发机制以自动匹配为主，模型会根据任务描述与技能的 description 判断是否加载；如果它始终没有调用，我建议在对话里直接写明“请使用 xxx skill 完成”，显式触发是最可靠的方式。也可以在聊天框输入 @ 或 / 查看可用的技能提示，不同版本入口不同，以当前版本的提示为准。我踩过的坑是：项目里同时存在同名技能时，项目级会覆盖全局级，所以测试时一定先确认你改的是哪个目录。

3.3 Cursor 中文设置与团队使用小贴士

关于很多人问的“Cursor 怎么设置中文”：当前版本并没有完整、官方的中文 UI，但你可以进 Settings → General（不同版本位置略有差异）看有没有 Language 选项；如果找不到，也可以在设置里搜索 language 或 locale。社区也有汉化扩展可用，但个人经验是汉化后部分翻译不准确，反而影响查文档，我更推荐保留英文 UI、把项目内的规则文档写成中文。

团队使用时，把.cursor/skills提交进 git 仓库，成员 clone 后开箱即用；如果有敏感的内部规范，可以放到私有仓库再做全局安装。另外要注意，Cursor 的 Skills 和 Rules 是并存的，Rules 会常驻在上下文里，Skills 是按需加载，两者不要写重复内容，否则模型会出现指令打架。

4. Claude Code 接入 Skills 全流程

4.1 安装 Claude Code 并完成登录

Claude Code 本体是一个 Node CLI。推荐在系统里装好 Node.js 18+，然后执行：

npm install -g @anthropic-ai/claude-code

安装后运行claude --version确认版本。第一次启动需要登录授权，直接运行claude，按提示在浏览器里完成账户授权即可。进入项目目录后运行claude启动交互式会话。

注意：如果 npm 全局目录不在 PATH 里，运行 claude 会提示找不到命令。先执行npm config get prefix查看实际路径，再把输出路径下的 bin 目录配置进 shell 的 PATH。Linux 上常见手法是在~/.bashrc或~/.zshrc里追加export PATH="$(npm config get prefix)/bin:$PATH"；Windows 上 npm 安装包通常位于%APPDATA%\npm，装好后重启终端一般就能识别。

4.2 Skills 目录与 SKILL.md 规范

Claude Code 的 Skills 约定跟 Cursor 几乎一致，只是默认目录换成了.claude/skills和~/.claude/skills。SKILL.md 的 frontmatter 常用字段包括：

• name：技能名，小写中划线风格，如conventional-commit
• description：一句话说清技能在什么场景下有用，这是自动加载的依据
• allowed-tools：可选，限制该技能可以使用哪些工具，比如只允许读文件
• model/context/version/disabled：进阶控制字段，按需使用

正文部分写具体操作流程、硬性要求、示例和禁忌。下面是一个最小可用的提交信息技能：

--- name: conventional-commit description: 根据 git diff 生成符合 Conventional Commits 规范的提交信息。当用户需要提交代码、生成 commit message 时使用。 --- 1. 先运行 git status 和 git diff 查看改动 2. 判断改动类型：feat / fix / docs / refactor / test / chore 3. 提交信息格式：type(scope): subject 4. 正文列出关键改动，逐条说明

这个技能不需要多余的代码，但效果立竿见影，因为模型手里有了一份清晰的“怎么干”的规则。我在实际项目里还加了一条硬性约束：如果改动里包含 breaking change，正文必须写明影响范围，否则不允许提交。

4.3 验证技能是否被正确加载

Claude Code 加载技能时，会在会话中把匹配到的 SKILL.md 注入上下文。你可以直接在对话里要求“使用 conventional-commit 技能”来验证；如果没反应，用claude --debug启动会话，观察日志里是否有对应目录的扫描记录。也可以用/help查看当前版本支持的命令入口，确认是否有/skills或/plugin之类的管理命令。

装完技能后我强烈建议重启会话再测试，因为部分版本对技能的扫描发生在会话启动阶段，中途改文件不一定会热加载。如果你发现模型能读取技能但执行效果不佳，可以先在对话里问它“你打算按什么步骤做”，看它有没有看到 SKILL.md 里的流程，没有的话就是 description 写得太模糊，根本没匹配到。

5. 手把手写一个自己的 Skill：完整实例

5.1 需求场景与目录规划

举例场景：团队每次发版后需要更新 CHANGELOG.md，但 AI 默认生成的版本记录格式不一。我们来写一个 release-note skill。通常目录结构如下：

.claude/skills/release-note/ ├── SKILL.md └── references/ └── changelog-format.md

其中references/changelog-format.md存放团队历史版本的 changelog 样例，这部分内容比较长，单独放能避免 SKILL.md 本身膨胀。模型判定技能匹配后，会自主决定是否读取 references 里的详细规则，这样只有真正生成 changelog 时才占用上下文。

5.2 SKILL.md 的写法要点

描述里一定要写出触发场景：“当用户要求生成、更新或规范化 CHANGELOG 内容时使用”。正文按步骤编排：

1. 读取 git log 获取本版本提交
2. 按语义化版本规则确定版本号增量
3. 按模板输出变更分组：Added / Changed / Fixed / Removed
4. 若存在references/changelog-format.md，优先参考其中的措辞风格

同时给出明确的反面例子，告诉模型不要重复版本号、不要把 merge commit 写进变更里。一个小技巧是，在 SKILL.md 里加上“输出前三行必须包含版本号和日期”这类硬约束，比模糊的“请认真一点”有效得多。模型对“禁止”和“必须”的响应比对“建议”强得多，这是我反复调整 Prompt 后最明显的一条经验。

5.3 在 Cursor 和 Claude Code 中联调

写完后分别拷贝到.cursor/skills/release-note和.claude/skills/release-note（或者放到全局目录）。在 Claude Code 里启动会话，输入“帮我把最近两个版本的提交生成 changelog”，看输出是否符合模板；在 Cursor 的 Agent 对话框里做同样测试。联调时如果发现模型没有读取 references 文件，多半是因为 SKILL.md 正文里没有明确提到“读取 references 目录下的文件”，模型根本不知道还有资料可用。

另外，Skills 的指令会和 CLAUDE.md、Cursor Rules、系统提示词叠加，测试时如果发现规则冲突，可以暂时把另一处重复规则删掉，保持单一信息源。我自己最开始写 skill 的时候，把团队规范既写进了 CLAUDE.md 又写进了某个 skill，结果模型每次都会来回纠结，后来统一以 skills 为准，情况立刻好转。

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

6.1 为什么我的 Skills 始终不生效

根据我踩过的坑，失效原因通常是下面这几类：

提示：排查技能不生效时，最有效的动作是用--debug启动会话，看扫描日志。日志里会明确列出扫描到的技能目录，没扫到就说明路径有问题，扫到但不调用就是 description 的问题。

6.2 Skills 和 MCP 并存时如何取舍

两者不冲突，但会互相影响。比如你既挂了 GitHub MCP，又装了 pr-description skill，建议在 skill 里写明“调用 MCP 获取 PR 数据后，再按本文模板生成描述”，把工具调用和流程规范串起来。反过来，如果某个 MCP 工具在你的主流程里几乎用不到，却占了不少上下文，也建议先禁用掉，给技能留出更多上下文空间。

我实测下来的经验是：当任务同时涉及多个技能和多个工具时，模型偶尔会“贪心”，把不相关的技能也加载进来。解决办法是在 SKILL.md 的 description 里写清楚“不要用于 xxx 场景”，负面约束和正面约束同样重要。

6.3 团队共享 Skills 的两种主流方式

第一种是直接把 skills 目录提交到业务代码仓库，简单直接，适合大多数团队。第二种是单独建一个 skills 模板仓库，里面存放通用技能和配套文档，其他仓库通过 git submodule 或复制脚本统一同步。我个人更推荐第二种，因为它把 skills 当作独立资产来管理，更新一次、处处生效。

还要注意团队内部技能里不要写死个人路径和私有信息，否则 clone 到别的电脑上就会踩坑。引用文件里的路径一律用相对路径，密钥、token 一律不要出现在 SKILL.md 或 references 里，否则很可能被模型在生成代码时直接带出来。

7. 写在最后：几个让我意外的小体会

第一，Skills 不需要贪多。我一开始从社区批量下载了几十个，最后真正高频使用的也就 10 个左右，剩下的反而让模型在匹配时犹豫。装技能要像整理工具箱，常用的放最上面，不常用的收起来，宁缺毋滥。第二，写技能的过程，其实是把团队规范重新梳理了一遍。很多我以为“大家都知道”的约定，在写进 SKILL.md 的时候才发现定义得并不清楚，这个梳理过程的收益甚至超过了技能本身的收益。第三，不管是 Cursor 还是 Claude Code，Skills 的价值都不是让 AI 变聪明，而是让 AI 更懂你的工作方式。如果你也是刚接触，建议先装一个 conventional-commit 技能顺手验证整套流程，再慢慢积累属于自己的技能库。