企业官网建设流程全解析

1. 为什么"技能包"正在取代"提示词收藏夹"

前两年大家聊 AI 编程，聊的都是"提示词工程"——收藏一堆咒语，用的时候翻出来粘贴。但真在项目里跑过几轮的人都知道，这套玩法有个致命问题：提示词是无状态的。你这次让它按团队规范写单测，下次开新会话，它又忘了。你得反复贴、反复调，最后干脆放弃，回到"能跑就行"的状态。

Skills 这套机制解决的正是这个问题。它把"怎么做某件事"从一次性的对话里抽出来，固化成一个带元数据的文件——通常叫SKILL.md——放在约定的目录下。AI 编程工具在需要的时候自动读取、按需加载，不需要你每次手动喂。你可以把它理解成给 AI 装的"插件"，只不过这个插件不是代码，而是结构化的操作说明。

我最初接触这个概念是在 Cursor 和 Claude Code 上。当时团队里有个痛点：新人写的接口层代码风格五花八门，有人用async/await，有人用 Promise 链，错误处理有的抛异常有的返回{code, msg}。我们试过写 ESLint 规则，但规则只能管语法，管不了"这个场景该用哪种模式"。后来把团队约定写成 Skill，让 AI 在生成代码前先读一遍，风格统一度肉眼可见地提升了。

这篇内容适合三类人：一是刚听说 Skills 但不知道从哪下手的开发者；二是已经在用 Cursor 或 Claude Code，但还在靠复制粘贴提示词的人；三是想自己写 Skill 分享给团队或社区的人。我会把"装什么""怎么装""装完怎么验证"这三件事讲透，中间穿插我自己踩过的坑。

提示：Skills 不是万能的。它擅长的是"流程性、重复性、有明确规范"的任务。如果你的需求是"帮我随便想个创意"，那 Skill 帮不上忙，那是模型本身的能力范畴。

2. 八类真正值得装的 Skills，以及它们各自解决什么问题

市面上的 Skill 仓库已经不少了，但大部分是玩具。我按"实际项目里能不能省时间"这个标准，筛出八类真正值得装的。每一类我都会说清楚：它解决什么痛点、适合什么场景、装之前要注意什么。

2.1 代码规范与风格统一类

这是最刚需的一类。典型场景是：团队有一套内部规范，但 ESLint/Prettier 覆盖不到，比如"service 层必须返回统一的 Result 对象""日志必须带 traceId""数据库查询必须走 repository 层不能直接调 ORM"。

这类 Skill 的核心是把隐性的团队约定显性化。写的时候要注意，不要写成"要写高质量代码"这种废话，而要写成可判定的规则。比如：

## 错误处理规范 - 所有对外接口的异常必须捕获，转换为 Result.fail(code, msg) - 禁止在 controller 层直接 throw，必须走全局异常处理器 - 日志使用 logger.error，禁止 console.log

我装过的一个坑是：规则写太细，细到"变量名必须用驼峰且不超过 20 字符"，结果 AI 每次生成代码都要纠结命名，反而拖慢速度。后来我把这类交给 ESLint，Skill 里只留"业务语义层面"的约定，效果好很多。

2.2 测试生成与用例补全类

写单测是很多人的噩梦。这类 Skill 的价值在于：让 AI 按你项目的测试框架、断言风格、mock 方式来生成用例，而不是生成一堆跑不起来的样板。

关键点在于告诉 AI 你的测试基础设施。比如你用 Jest 还是 Vitest，用jest.mock还是vi.mock，断言用expect().toBe()还是assert.equal()。这些不写清楚，生成的测试十有八九要手改。

我自己的做法是在 Skill 里附一个"参考测试文件"的路径，让 AI 先读那个文件再生成。这招比写一堆文字描述管用得多，因为模型对代码示例的理解远好于对自然语言规则的理解。

2.3 提交信息与变更日志类

Conventional Commits 规范大家都知道，但真正每次都写对的人不多。这类 Skill 让 AI 在git commit前帮你生成符合规范的 message，还能顺带更新 CHANGELOG。

我实测下来，这类 Skill 的准确率和你的 diff 质量强相关。如果一次提交改了 20 个文件、跨了三个模块，AI 也很难总结出一句话。所以我的建议是：小步提交，每次提交聚焦一件事，Skill 才能发挥价值。

2.4 代码审查与安全扫描类

这类 Skill 相当于给 AI 装了一双"审查眼"。它会按你定义的检查项过一遍代码：有没有硬编码密钥、有没有 SQL 拼接、有没有未处理的 Promise rejection、有没有越权风险。

要注意的是，这类 Skill 容易产生误报。比如它看到eval就报警，但你的场景是解析配置文件，其实安全。所以我在 Skill 里加了一条"如果判断为误报，说明理由并跳过"，避免每次审查都刷一屏无用告警。

2.5 文档生成与注释补全类

老项目最缺的就是文档。这类 Skill 能读代码生成 API 文档、补全 JSDoc、画模块依赖关系。我拿它处理过一个三年没维护的 Node 服务，生成的接口文档虽然不能直接用，但至少让我快速摸清了有哪些路由、参数是什么。

这里有个技巧：让 AI 生成文档时标注置信度。对于它读得懂的代码，标"高"；对于动态拼接、反射调用的部分，标"低，需人工确认"。这样你 review 的时候知道哪些要重点看。

2.6 数据库与迁移脚本类

涉及数据库变更时，这类 Skill 能帮你生成迁移脚本、回滚脚本、以及对应的实体类。它解决的是"改表容易忘同步代码"的问题。

我踩过的坑是：AI 生成的迁移脚本没有考虑大表加字段的锁表风险。后来我在 Skill 里明确写了"超过百万行的表，加字段必须用 online DDL 或分步迁移"，才避免了一次生产事故。

2.7 前端组件与样式规范类

前端场景下，这类 Skill 管的是组件结构、样式方案（CSS Modules / Tailwind / styled-components）、状态管理约定。比如"所有列表组件必须处理 loading、empty、error 三态"。

前端 Skills 的难点在于框架版本差异大。React 18 和 19 的写法不同，Vue 2 和 3 差异更大。所以装之前一定要确认 Skill 声明的版本和你项目一致，否则生成的代码可能跑不起来。

2.8 项目脚手架与初始化类

新项目启动时，这类 Skill 能按你的技术栈生成目录结构、配置文件、CI 模板。它省的是"每次开新项目都要重新配一遍"的时间。

我的经验是：这类 Skill 要定期更新。因为依赖版本、构建工具、CI 平台都在变，半年前写的脚手架 Skill 可能已经过时了。我一般每季度过一遍，把废弃的配置删掉。

3. 从零接入 Cursor：目录放哪、怎么触发、怎么验证

Cursor 对 Skills 的支持相对直接，但目录位置和触发方式有几个容易搞错的点。我按实际操作顺序讲一遍。

3.1 目录结构：全局还是项目级

Cursor 读取 Skill 的位置有两个层级：

• 项目级：放在项目根目录下的.cursor/skills/里。只对当前项目生效，适合团队共享。
• 全局级：放在用户目录下的.cursor/skills/（macOS/Linux 是~/.cursor/skills/，Windows 是%USERPROFILE%\.cursor\skills\）。对所有项目生效，适合个人通用规范。

我的建议是：团队规范放项目级，个人习惯放全局级。项目级的可以提交到 Git，新人 clone 下来就自动生效；全局级的放自己机器上，不污染团队仓库。

每个 Skill 是一个独立文件夹，里面至少有一个SKILL.md。文件夹名就是 Skill 名，建议用英文短横线命名，比如api-error-handling、test-generation。

.cursor/ skills/ api-error-handling/ SKILL.md test-generation/ SKILL.md reference-test.ts # 可选，参考文件

3.2 SKILL.md 的头部元数据怎么写

SKILL.md开头有一段 YAML frontmatter，这是给工具读的，不是给人读的。格式大概是这样：

--- name: api-error-handling description: 统一 API 层的错误处理规范，适用于 controller 和 service 层 --- ## 规范内容 ...

name和description是关键。description写得好不好，直接决定 AI 能不能在正确的时机触发这个 Skill。我见过有人写description: 代码规范，太笼统，AI 根本不知道什么时候该用。好的写法是说清楚适用场景，比如"当生成或修改 controller、service 层代码时使用"。

3.3 触发方式：自动还是手动

Cursor 里 Skill 的触发有两种：

• 自动触发：AI 根据description判断当前任务是否匹配，匹配就自动加载。这是默认行为。
• 手动引用：在对话里用@skill-name显式引用。适合你明确知道要用哪个 Skill 的场景。

我实测下来，自动触发的准确率大概七成。有时候你明明在改 controller，它却没加载错误处理 Skill。这时候手动@一下更稳。所以我的习惯是：关键任务手动引用，日常任务靠自动。

3.4 验证 Skill 是否真的生效

装完 Skill 别急着信，先验证。方法很简单：开一个新会话，让它做一件 Skill 覆盖范围内的事，然后看输出是否符合规范。

比如你装了"错误处理规范"Skill，就让它写一个查询用户的接口。如果它返回的是Result.fail()而不是直接 throw，说明生效了。如果还是老样子，检查三件事：

1. SKILL.md的 frontmatter 格式对不对，有没有多余空格或缩进错误。
2. description是否足够具体，能不能让 AI 判断出适用场景。
3. 文件是不是放在了正确的目录层级。

注意：Cursor 不同版本对 Skills 的支持程度不一样。如果你用的是较老版本，可能需要在设置里手动开启相关选项。升级到最新版通常能省掉这些麻烦。

4. Claude Code 的 Skills 接入：和 Cursor 的差异在哪

Claude Code 是命令行工具，Skills 的接入逻辑和 Cursor 有相似之处，但细节差异不小。如果你两个都用，这部分要重点看。

4.1 安装与目录约定

Claude Code 的 Skill 目录通常在~/.claude/skills/（全局）和项目根目录的.claude/skills/（项目级）。结构和 Cursor 基本一致，也是每个 Skill 一个文件夹加一个SKILL.md。

但 Claude Code 有个额外机制：它支持从 GitHub 仓库直接安装 Skill。如果你看到别人分享的 Skill 仓库，可以用命令直接拉下来，不用手动复制文件。具体命令各版本略有不同，建议以官方文档为准。

我手动装过 GitHub 上的 Skill，流程是：clone 仓库，找到里面的skills目录，把需要的文件夹复制到.claude/skills/下。听起来简单，但有个坑：有些仓库的 Skill 依赖额外的脚本或资源文件，只复制SKILL.md会缺东西。所以复制前先看一眼文件夹里还有什么。

4.2 Claude Code 的 Skill 加载时机

Claude Code 在启动时会扫描 Skill 目录，但不会一次性全部加载到上下文里。它是按需加载的——当你的任务匹配某个 Skill 的description时，才把内容读进来。这个设计很聪明，避免了上下文被一堆用不上的 Skill 占满。

这也意味着description的质量在 Claude Code 里更加关键。因为它是唯一的触发依据。我建议description里同时包含动作和对象，比如"生成数据库迁移脚本时使用"，而不是"数据库相关"。

4.3 和 VS Code 配合使用的场景

很多人是在 VS Code 里用 Claude Code 的。这种组合下，Skill 的目录位置不变，但触发方式可能受 VS Code 插件影响。我的经验是：在 VS Code 集成终端里跑 Claude Code，Skill 行为和纯命令行一致。如果你用的是图形化插件，注意看它有没有自己的 Skill 配置入口，别配了两套。

VS Code 本身也有 AI 相关扩展，但它们和 Claude Code 的 Skills 是两套体系，不要混为一谈。Skill 是 Claude Code 的能力，VS Code 只是承载它的编辑器。

4.4 两个工具共用 Skill 的可行性

如果你 Cursor 和 Claude Code 都用，会想能不能共用一套 Skill。答案是可以，但要处理格式差异。两者的 frontmatter 字段基本兼容，但触发机制和加载逻辑不同，所以同一个SKILL.md在两个工具里的表现可能不一样。

我的做法是：维护一份"源 Skill"，放在独立仓库里，然后用脚本同步到两个工具的目录。这样改一处，两边都更新。如果懒得搞脚本，至少保证description写得足够通用，两边都能识别。

5. 自己写一个 Skill：从需求到落地的完整过程

装别人的 Skill 只能解决通用问题，真正贴合你项目的还得自己写。我拿一个真实案例走一遍：给一个 Node + Express 项目写"接口错误处理"Skill。

5.1 先想清楚：这个 Skill 要解决什么具体问题

不要一上来就写。先回答三个问题：

1. 现在不做这件事，会出什么问题？我们的情况是：新人写的接口有的返回{code: 0, data}，有的返回{success: true, result}，前端对接时经常搞错。
2. 这个问题出现的频率高吗？高。每个新接口都可能踩。
3. AI 能帮上忙吗？能。只要告诉它统一格式，它生成代码时就会遵守。

三个问题都过了，才值得写 Skill。如果只是偶发问题，写个文档提醒一下就行，没必要上 Skill。

5.2 把隐性知识拆成可执行的规则

这一步最难。团队老手觉得"这不是常识吗"的东西，恰恰是新人最容易错的。我的方法是翻最近的 code review 记录，把被反复指出的问题列出来，那就是 Skill 要覆盖的内容。

针对错误处理，我列出的规则是：

• 所有 controller 方法必须用 try/catch 包裹
• catch 里统一调用next(error)，交给全局错误中间件
• 全局中间件把错误转换为{code, message, data: null}格式
• 业务错误用自定义BizError，带错误码
• 系统错误记录完整堆栈，业务错误只记 message

这些规则写进SKILL.md，配上正例和反例代码，AI 就能照着执行。

5.3 写 description 的技巧：让 AI 在对的时候想起来

description是 Skill 的"广告语"，要同时满足两个条件：AI 能判断适用场景，人能看懂这是干嘛的。

我最初的写法是description: 错误处理规范，结果 AI 很少触发。改成description: 当生成或修改 Express controller、service 层代码，或处理接口异常时使用，统一错误返回格式之后，触发率明显上升。

关键是把触发条件写进去。AI 判断是否加载 Skill，靠的就是这段描述和当前任务的匹配度。描述里包含的动作词越多，匹配机会越大。

5.4 正例反例对照：比纯文字规则有效十倍

我试过纯文字规则，AI 遵守率一般。加上代码对照后，遵守率大幅提升。因为模型对代码模式的学习能力远强于对抽象规则的理解。

// 反例：直接返回，格式不统一 app.get('/user/:id', async (req, res) => { const user = await db.findUser(req.params.id); res.json({ success: true, result: user }); }); // 正例：统一走错误中间件 app.get('/user/:id', async (req, res, next) => { try { const user = await db.findUser(req.params.id); if (!user) throw new BizError(40401, '用户不存在'); res.json({ code: 0, message: 'ok', data: user }); } catch (err) { next(err); } });

正例反例不用多，每个规则配一组就够。多了反而让 Skill 文件臃肿，加载时占用上下文。

5.5 测试与迭代：怎么知道 Skill 写得好不好

写完不是结束，要测。我的测试方法是：开三个新会话，分别让它写一个查询接口、一个创建接口、一个删除接口，看输出是否符合规范。三个都过，基本可用；有一个不过，回去改 Skill。

迭代时重点看两类问题：一是规则没覆盖到的场景，补进去；二是规则被误解的场景，改表述。我那个错误处理 Skill 迭代了三版，第一版漏了"参数校验失败"的处理，第二版补上后又发现 AI 把校验错误也当系统错误记堆栈了，第三版才把两类错误分开。

6. 装了一堆 Skill 之后，我踩过的那些坑

Skill 装多了，问题也跟着来。这部分讲几个真实踩过的坑，都是文档里不会写的。

6.1 Skill 之间规则打架

我同时装了"代码规范"和"快速原型"两个 Skill。前者要求"所有函数必须写 JSDoc"，后者要求"原型阶段省略注释保持简洁"。结果 AI 生成代码时一会儿加注释一会儿不加，非常混乱。

解决办法是给 Skill 划分明确的适用边界。在description里写清楚"仅在正式代码中使用"或"仅在原型验证阶段使用"。如果两个 Skill 场景重叠，就合并成一个，用条件分支处理。

6.2 上下文被 Skill 挤占

Claude Code 的上下文窗口有限。如果一次加载了五六个 Skill，每个几百行，留给实际代码的空间就少了。我遇到过加载太多 Skill 后，AI 开始"忘记"前面的对话内容。

对策是精简 Skill 内容。规则能一句话说清就别写三段，正例反例各一个就够。另外，不常用的 Skill 及时从目录里移走，别让它有机会被加载。

6.3 Skill 过期导致的错误建议

我有个数据库迁移 Skill，是半年前写的，里面推荐的迁移工具已经换了 API。结果 AI 按旧 API 生成脚本，跑起来直接报错。

这件事之后我养成了习惯：每个 Skill 标注最后更新日期，超过三个月的过一遍。特别是涉及第三方库、框架版本的 Skill，过期风险最高。

6.4 团队共享时的路径问题

把项目级 Skill 提交到 Git 后，同事 clone 下来发现不生效。排查半天，发现是.cursor目录被.gitignore忽略了。很多项目的 gitignore 模板里默认忽略.cursor和.claude，需要手动加白名单。

# .gitignore 里加上 !.cursor/skills/ !.claude/skills/

这个坑很隐蔽，因为本地测试时 Skill 是生效的，只有别人 clone 才暴露。

6.5 过度依赖 Skill 导致的能力退化

这个坑比较主观，但我觉得值得说。有段时间我什么任务都想让 Skill 代劳，连"这个函数该叫什么名"都要问 AI。结果是自己对代码的掌控感变弱了，review 时也看不出问题。

后来我调整了策略：Skill 处理重复性、规范性任务，创造性、决策性任务自己来。比如架构设计、技术选型，这些不该交给 Skill。Skill 是工具，不是替你把活干完的保姆。

7. 让 Skills 真正融入日常开发流的几个习惯

装好 Skill 只是开始，用起来才有价值。分享几个我坚持下来的习惯。

7.1 新项目初始化时先配 Skill

我现在开新项目，第一件事不是写代码，而是把团队通用的 Skill 复制进去。这样从第一个 commit 开始，代码风格就是统一的，省得后期再改。

具体做法是维护一个"Skill 模板仓库"，新项目 clone 下来后，把skills目录复制到项目里，改一下项目相关的配置（比如框架版本），就能用。

7.2 把 code review 的高频问题沉淀成 Skill

每次 code review 发现重复问题，我就问自己：这个问题能不能写成 Skill？能就写，不能就写进团队文档。坚持几个月后，review 里指出的问题明显减少，因为 AI 在生成阶段就规避了。

这个习惯的关键是及时。review 完当场记下来，别攒着。攒着就忘了，或者记的时候已经想不起具体场景。

7.3 定期清理和更新 Skill 库

我每个月花半小时过一遍 Skill 目录，做三件事：删掉不再用的、更新过期的、合并重复的。听起来麻烦，但比让一堆失效 Skill 拖慢 AI 响应强。

清理时我会看每个 Skill 的"最后触发时间"（如果工具支持的话），超过两个月没触发的，基本可以删了。说明要么场景不匹配，要么有更好的替代。

7.4 和团队同步 Skill 的使用情况

Skill 是团队资产，不是个人玩具。我会在团队周会上花五分钟同步：这周新增了什么 Skill、哪个 Skill 效果好、哪个有问题。这样大家能互相借鉴，避免重复造轮子。

同步时重点讲效果，不讲原理。比如"这个测试生成 Skill 让写单测的时间少了一半"，比"这个 Skill 用了什么机制"更能引起兴趣。

8. 关于 Skill 选型和自建的几点个人判断

最后聊几个我自己的判断，不一定对，但都是实际用下来形成的观点。

第一，Skill 不在多，在精。我见过有人装了三十多个 Skill，结果 AI 响应变慢，还经常触发错误的 Skill。我现在稳定在用的就六七个，覆盖规范、测试、提交、审查四类核心场景，够用了。

第二，优先装"约束型"Skill，谨慎装"生成型"Skill。约束型（比如规范、审查）是告诉 AI"不要做什么"，风险低；生成型（比如脚手架、文档）是让 AI"创造什么"，质量参差。生成型的装之前一定先小范围试用。

第三，自建 Skill 的投入产出比，取决于你的项目有多"特殊"。如果你的项目就是标准 CRUD，用社区 Skill 就行；如果有一堆内部约定、自研框架，那自建才划算。判断标准很简单：社区 Skill 生成的代码，你需要改多少才能用。改得少就用社区的，改得多就自己写。

第四，Skill 的维护成本被严重低估。写一个 Skill 可能只要一小时，但维护它要持续投入。依赖变了要改、团队规范变了要改、工具版本升级了要改。所以别贪多，写之前想清楚能不能坚持维护。

第五，别指望 Skill 解决人的问题。如果团队本身没有统一规范，写 Skill 也没用，因为你自己都不知道该让 AI 遵守什么。Skill 是规范的载体，不是规范的替代品。先把规范定下来，再考虑用 Skill 落地。

我在实际使用中最深的一个体会是：Skill 真正的价值不在于"让 AI 多干活"，而在于"让 AI 按你的方式干活"。前者是效率问题，后者是质量问题。效率提升有限，但质量提升是复利的——每次生成的代码都符合规范，长期下来省下的返工时间远超预期。

如果你刚开始接触，我的建议是从一个 Skill 开始，就用你最痛的那个场景。跑通一遍完整流程——写、装、测、迭代——你就理解这套机制了。剩下的就是复制这个流程，慢慢积累自己的 Skill 库。