企业官网建设流程全解析

现在用 Cursor 和 Claude Code 的人越来越多了，但我发现大多数人的用法还停留在“开个对话框，把问题丢进去，等答案”。这其实是非常低效的，因为每次对话你都在重复描述同样的上下文、同样的规范、同样的处理流程，AI 每次都在“重新认识你”，质量自然忽高忽低。

Skills（技能包）就是为终结这种重复劳动而生的。它本质上是给 AI 助手装的一份“可复用操作手册”：你把某个任务的前置条件、执行步骤、判断标准和输出格式都写清楚，存成 Skill。之后只要在 Cursor 或 Claude Code 里触发它，AI 就会按这份手册自动干活，既不需要你反复交代背景，也不会每次都自由发挥。

这篇文章会分四块展开：先讲清楚 Skills 的运行原理和价值；再整理 8 类我实际用过、确实能提效的 Skills 推荐；然后把 Cursor 和 Claude Code 的接入全流程走一遍，包括目录结构、SKILL.md 写法、验证方法；最后记录一些容易踩的坑和排查思路。适合每天重度使用 AI 写代码、想把手头重复工作固化下来的开发者，也适合想在团队里推广统一编码规范和评审流程的工程负责人。

1. 先搞懂 Skills 的核心价值：它到底解决了什么问题

1.1 从“一问一答”到“一劳永逸”

先举个例子。假设你每周都要做代码审查。以前的做法是：把代码贴给 Cursor，然后写一大段提示词，比如“请重点检查性能问题、安全漏洞、边界条件、命名规范，最后按严重程度给结论”。每次贴不同的代码，但提示词几乎一模一样，效率很低，而且每次 AI 的侧重点还不一样，有时候抓了一堆无关紧要的格式问题，真正致命的逻辑漏洞反而没提。

有了 Skill 之后，你只需要把代码丢过去，说一句“用 code-review 检查一下”。AI 自动加载那份写好的审查流程，知道要看哪几个维度、参考什么标准、按什么格式输出。这个变化的本质是：你不再跟 AI“商量”任务怎么做，而是直接给它派一个定义好的活。Prompt 写一次，之后所有项目、所有成员都能复用，AI 的输出质量也从“看当天状态”变成“看手册标准”。我实测下来，同一个审查任务，用 Skill 跑出来的规则覆盖度明显更全，输出也更规整，很少出现漏检或偏题。

再往深一层说，Skill 在工程上其实就是普通文件和目录，核心是一个 SKILL.md。文件头是 YAML 格式的元信息，包含技能名称、场景描述、版本号等；正文则是给 AI 看的行为说明，告诉它这个任务要分几步做、每一步注意什么、最终产出什么样子。当用户的说法命中 description 里描述的场景，Agent 就会把这个文件当成参考手册，按里面的步骤一步步执行。这个机制说白了就是两个词：触发 + 执行。所以后面你会发现，写 Skill 的功夫一大半都花在 description 和步骤设计上，这一步做好了，才能“一劳永逸”。

1.2 Skills 与 Rules、Commands 的区别

很多人会把 Skills 和 Cursor 里的 Rules、Commands 搞混。这三样东西都能影响 AI 行为，但定位完全不一样，我整理了一张对比表。

按我自己的使用习惯，三者分工通常是：Rules 管“不能做什么”，Commands 管“一键发起什么”，Skills 管“拿到任务后按什么流程做”。只要搭配得当，AI 的行为既不会跑偏，又不用每次手动启动。

这里尤其要提醒一点，Skills 和 Commands 最容易被混淆。很多人装完 Skill，非要手动敲个命令去调用，发现没反应就以为没装好。实际上 Skills 的定位是“让 AI 自己判断什么时候用”，触发靠的是 agent 对自然语言的理解，不需要你显式点名。只有当描述写得不清楚、AI 识别不到场景时，才需要你手动提示一下。理解了这一点，后面调试 Skills 会省掉很多力气。

2. 8 类值得装的 Skills：按场景选，别贪多

GitHub 上已经有很多 Skills 集合项目了，像 awesome-claude-skills、superpower skills 这类，动辄收录上百个技能。但我建议别一口气全装，技能太多反而让模型“选择困难”，还会拖慢响应。下面这 8 类是我在不同项目里实际用下来、价值最明显的方向，你可以结合自己的技术栈挑着配。

2.1 代码审查与质量检查类

性价比最高的一类，没有之一。把审查维度前置写死，比如“优先检查空指针、注入风险、未捕获异常、资源泄漏、过度复杂函数”，AI 就会按统一标准去看代码，而不是随机发挥。我还会要求它按“严重 / 中等 / 建议”三档输出，严重级别给出明确的修改示例，方便直接抄作业。

这类 Skill 最合适的应用节点有两个。一个是提交代码前，让 AI 快速过一遍 diff，挡住低级错误；另一个是 PR 阶段，配合 Agent 自动审查，让人工 Review 聚焦在更难的设计问题上。坚持跑一段时间后你会发现，团队代码风格会肉眼可见地变稳定，因为标准统一了，不会因为今天审查人心情好就多写几句、心情差就一笔带过。我还见过有团队把“安全审查”单独拆成一个 Skill，专门看依赖版本、密钥硬编码、权限配置，效果也不错。

2.2 前端还原与 UI 实现类

前端应该是受 AI 编程影响最大的方向。给一张设计稿截图，让 AI 直接生成可运行的 React 或 Vue 组件，已经不算新鲜事。但如果没有 Skill，生成结果经常是“看起来像，细节全崩”，因为 AI 不了解你项目里用的是什么组件库、样式方案是什么、响应式断点怎么切。

这类 Skill 的核心价值，不是让 AI 会写前端，而是让它知道“怎么写才符合当前项目的规范”。我会在 SKILL.md 里写清楚：项目用的是 Element 还是 Ant Design，样式用 Tailwind 还是 CSS Modules，颜色从设计 token 的哪个变量取，间距走几倍栅格，图标怎么引入，移动端断点到多少像素开始堆叠。把这些写进 Skill 后，AI 生成的前端代码基本能达到“可提交评审”的质量，你只需要在交互细节上把把关。

补充一个技巧：在 Skill 里附上一两份“优秀示例组件”的代码片段，AI 会模仿示例的写法，比单纯用文字描述规范有效得多。

2.3 数据库与查询优化类

写过几年后端的人都知道，SQL 优化是最考经验的工作。Skill 在这里的作用，是把一名老手的排查流程固化下来。我见过一个团队把“慢查询分析”做成 Skill：第一步收集 EXPLAIN 输出，第二步识别全表扫描、索引失效、临时排序等问题，第三步根据表结构和数据量给索引建议，第四步用 EXPLAIN 验证优化效果。整个链路非常清晰。

这类 Skill 还有个隐藏价值：它能让新人直接上手。以前团队成员遇到 SQL 慢，只能截图找老同事看，现在只要把 EXPLAIN 结果贴给 AI，按 Skill 流程走一遍，至少能拿到一个靠谱的初步结论，再找人工确认就轻松多了。说白了，这就是把“老师傅的肚子里的经验”变成团队资产。配合数据库模型文件一起放进 Skill 目录，AI 就能结合实际的表结构给出更有针对性的建议，而不是泛泛而谈“建议加索引”。

2.4 测试用例生成类

写单测对很多人来说是件枯燥活，但 AI 恰恰擅长。测试生成 Skill 需要写清楚的内容包括：测试框架是什么（Jest、Vitest、pytest 等）、断言风格偏好、Mock 规则、覆盖率要求，以及哪些东西不要测（比如不要重复测第三方库的行为）。把这几条写清楚，AI 生成的测试代码才符合团队风格，而不是每次都得手工重写。

我个人很推荐一个变体：把“根据 bug 描述生成回归测试”做成 Skill。开发者在修复 issue 以后，直接让 AI 按这个模式生成对应的回归用例，确认这个问题不会再冒出来。这个用法对长期维护的项目特别有价值，相当于每次修 bug 的成果都自动沉淀成保护网。实测下来，配合定时执行，能明显降低重复 bug 率。

2.5 文档与注释维护类

文档是很多人的痛点，但偏偏不得不做。文档类 Skill 能干的事不少：生成 README、维护 CHANGELOG、写 API 注释、生成 Swagger 描述。这类 Skill 最关键的设计点，是明确“给程序员看的文档”和“给用户看的文档”的差异，不能让 AI 写出来的东西两头不靠。

我自己的做法，是在 Skill 里规定 README 必须有项目简介、安装方式、快速开始、常见问题四部分；Swagger 描述则必须覆盖请求参数类型、响应示例、错误码说明。这样一来，AI 生成的文档不会光顾着堆术语，而是真的可读、可维护。另外，如果你维护的开源项目在 GitHub 上，还可以在 Skill 里附上贡献指南模板，让 AI 帮新贡献者生成 issue 模板、PR 模板，也算是一种“隐形文档”。

2.6 技术方案与架构设计类

写技术方案是 AI 能帮上大忙的场景。架构设计类 Skill 的核心，是让 AI 按固定模板来思考和输出：背景与目标、需求分析、技术选型对比、架构图描述（文字版）、数据模型设计、接口设计、风险与备选方案、上线与回滚计划。

这类 Skill 的效果上限，取决于你塞进去的“强制检查项”。比如我会要求 AI 在方案里必须回答“这个设计能应对未来半年的增长吗”“如果这个模块挂了影响范围有多大”这类问题。有了这些硬性约束，AI 出方案的质量会明显提升，而不是写一堆正确的废话。刚开始可以看一些优秀的 RFC 文档，把它们的结构提炼成一个模板，再做成本项目的规范 Skill，比自己凭空定义要靠谱得多。

2.7 图片生成与视觉素材类

可能有人疑惑，图片生成也能做成 Skills？现在确实可以了。在一些编辑器工具链里，通过调用外部图片生成接口，Skill 可以帮助快速出组件预览图、项目封面、占位素材，甚至可以封装成一个“图片生成技能包”，用在文档配图自动化的场景里。

这类 Skill 的设计要点，是提前统一画布尺寸、风格关键词和输出路径。比如我见过有人把“产品功能示意图生成”做成 Skill，规定图片尺寸 16:9、风格简洁插画、输出到 docs/images 目录。这样一来，项目的配图风格保持一致，不会今天一个样明天一个样。如果有版权风险或者出图质量不稳定的情况，也建议在 Skill 里加一步“生成后人工确认”的流程，避免直接进产线。

2.8 代码迁移与重构类

最后一个分类，但使用频率可能最高。代码迁移类 Skill 适合处理“Python 2 迁移到 Python 3”“JavaScript 改造成 TypeScript”“旧框架升级到新框架”这类大工程。这类任务最大的风险是“改着改着把原行为改没了”，所以 Skill 里必须明确强调“保持行为不变”的原则。

具体操作上，我会让 AI 先梳理现有代码的输入输出契约，再生成迁移清单，接着分模块迁移并对比结果，每完成一块输出变更说明。把流程写进 Skill 之后，这类耗时工程就能交给 AI 一步步执行，开发者在关键节点做 Review 就够了。再配合一份迁移前后的测试用例集，效果会好很多，毕竟迁移最大的痛点就是改完不自知地埋了雷。

3. Cursor 与 Claude Code 接入全流程：从零到一落地

先说明一点，Cursor 和 Claude Code 的 Skills 机制都在快速迭代，不同版本在配置入口和参数上可能会略有差异。下面这套流程是基于当前主流版本里兼容性最好的做法，近期版本基本都能跑通；如果你的版本界面有差异，找 Settings 里带“Skills”或“Agent”字样的位置即可。

3.1 先搞懂 Skills 的标准格式：SKILL.md

不管是 Cursor 还是 Claude Code，Skill 的核心文件都叫 SKILL.md。它分两部分：头部 YAML 元信息和正文 Markdown 说明。头部一般包含这几个字段。

正文部分可以自由发挥，但建议要有这几块：适用场景、执行步骤、输出格式、质量标准、参考资源。下面是一个可以直接抄的简化模板。

--- name: code-review description: 当用户要求审查代码、检查代码质量或提交前验证时使用。适用于代码审查场景。 version: 0.1.0 --- # Code Review Skill ## 适用场景 - 提交 merge request 前快速检查 - 团队 Code Review 时辅助发现问题 ## 执行步骤 1. 阅读目标代码，梳理核心逻辑和数据流。 2. 按下列维度逐项检查：空指针与异常处理、安全漏洞、资源泄漏、边界条件、命名与可读性。 3. 对问题分类：严重（可能导致崩溃或安全风险）、中等（影响正确性或性能）、建议（代码风格与可维护性）。 4. 输出问题清单，每个问题包含位置、原因、修改建议和简短的修改示例。 ## 输出格式 - 严重 / 中等 / 建议 三档标题 - 每个问题按：文件位置 -> 问题描述 -> 修改建议 -> 示例代码 组织

写完后把这个文件放到对应的 skills 目录里，目录名最好和技能名一致。一个 Skill 目录里还可以放参考资料、模板文件、示例代码，建议都用相对路径引用，避免 Agent 找不到资源。

3.2 在 Cursor 里接入 Skills 五步走

第一步，确认版本支持。打开 Cursor 的 Settings，搜一下“Skills”或“Agent”，如果能找到相关开关，说明版本支持 Skills。找不到就先把 Cursor 升级到最新版，旧版本是装不了的。

第二步，建目录。在项目根目录创建 .cursor/skills 文件夹。如果你希望 Skills 在多个项目里全局生效，再看 Cursor 的全局配置目录，一般都在用户主目录下的 .cursor 里。我的习惯是：团队规范类的技能放项目级，随 Git 走；个人提效类的放全局，换项目也能用。

第三步，写 SKILL.md。按 3.1 的模板做第一个 Skill。个人建议从“生成 README”这种简单任务开始，跑通流程再去碰复杂的，不然第一个就遇到各种调试问题容易劝退。

第四步，让 Agent 启用。在 Cursor 里切到 Agent 模式，在上下文面板或输入框附近找到 Skills 的开关，打开它。这个开关本质上是允许 Agent 在回答时主动读取技能文件。不开的话，你写好也不会被自动触发。

第五步，联动测试。用一个自然语言问题测试，比如“帮我 review 一下当前文件”。看它有没有按 SKILL.md 里的步骤和格式来执行。如果输出格式跟 Skill 里定义的一致，说明已经生效；如果 AI 自己乱答，说明没读到文件，回头检查目录和开关。

3.3 在 Claude Code 里接入 Skills 五步走

第一步，安装 Claude Code。如果还没装，在终端执行下面这条命令，然后按提示完成登录授权。

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

第二步，建目录。Claude Code 同样支持两个层面的 Skills 目录。项目级是 .claude/skills，跟着代码仓库走，适合团队共享；用户级是 ~/.claude/skills，适合个人通用技能。团队规范类的，建议放项目级，新成员克隆仓库后自动就带上。

第三步，写 SKILL.md。目录建好后，把写好的 Skill 放进去。这里注意，Claude Code 对目录命名建议用英文小写加短横线，比如 skills/code-review/SKILL.md，不要带空格或大写。

第四步，检查加载。在 claude 交互界面里输入 /skills 或 /agents（不同版本命令可能不同，能列出技能列表的就行），看到刚才创建的技能名称就说明加载成功。看不到就先检查目录层级和文件命名。

第五步，真实场景验证。故意给一段有问题的代码，手动触发一次审查类 Skill。在 Claude Code 的日志输出里，通常能看到读取 SKILL.md 的记录，这个细节能帮你快速定位问题出在加载环节还是触发环节。

3.4 让 Skill 真正“好用”的三个设计经验

装好 Skill 只是万里长征第一步，真正好用还差三件事。

第一，description 一定要写“触发场景”，而不是“功能定义”。比如不要写“代码审查工具”，而要写“当用户要求审查代码、检查代码质量或提交前验证时使用”。因为 Agent 是用你的自然语言去匹配 description 的，场景描述越贴近真实说法，触发就越准。你写在 description 里的每一个关键词，都可能成为触发条件，多用用户真正会说的词。

第二，一个 Skill 只做一件事。别想做“万能助手”，那只会让 Agent 读完手册还是不知道具体该怎么办。我见过有人把几十条指令塞进一个 Skill，结果 AI 输出越来越平庸。与其搞一个“大而全”，不如拆成 code-review、test-gen、doc-gen 三个小 Skill，互不干扰，质量都能保证。

第三，执行步骤要能被验证。步骤里一定要有明确的“产出物”，比如“最后输出一个 Markdown 表格”或“每个问题至少要有一行修改示例”。这样你一眼就能确认 AI 有没有照做。如果步骤写得过于开放，AI 自由发挥的空间大，Skill 的约束力就形同虚设了。

补充一点：Skill 里可以引用示例代码作为风格基准。AI 是强模仿模型，给它几个“优秀参考”往往比十条规则更有效。

3.5 快速验证与自测方法

装完 Skill 别急着投入生产，按下面的思路自测一遍，能省下后面一大堆麻烦事。

测试一：触发测试。用一个明确命中 description 的问题去问，比如“帮我审查这段代码”，看 AI 是否按 Skill 的流程走。如果不触发，优先考虑 description 和用户问法是否对得上。

测试二：边界测试。问一个偏离主题但沾点边的问题，比如“给我讲讲代码审查的意义”，正常情况不应该加载审查流程。如果误触发，检查 description 是不是写得范围过大。

测试三：格式稳定性测试。准备两段质量差异很大的代码，分别让 AI 审查，看它是否都严格按照 Skill 里定义的输出格式来给结果。格式稳定，才说明 Skill 的约束真正生效了。

三关都过了，这个 Skill 基本就可以正式启用。以后维护流程就是在仓库里维护这些 Skill 文件，改模板、加规则，都能通过更新文件来完成，比在每次对话里反复叮嘱 AI 要可靠得多。

4. 踩坑实录：不生效、迁移与中文环境问题排查

4.1 为什么 Skill 不触发或没生效？

这是新手最容易碰到的问题。明明按格式写了 SKILL.md，目录也建好了，AI 就是不理。我从项目现场整理了四个最常见的原因：

排查的时候有个小技巧，Cursor 和 Claude Code 都能在输出日志里看到 Skill 的加载记录。如果日志里有加载记录但还是不触发，那就重写 description；如果连加载记录都没有，优先查路径和文件命名。很多时候就是目录大小写、横线写成了下划线这种低级问题。

4.2 跨工具迁移与团队协作问题

Cursor 和 Claude Code 的 Skills 都基于 SKILL.md 约定，所以同一个 Skill 包在这两个工具之间迁移，基本就是复制粘贴的活。但要注意，两个工具对 Skill 里扩展字段和可执行脚本的支持度并不完全一样，直接搬过去有时候会“水土不服”。

我在迁移时发现，最稳妥的做法是让 Skill 只用 Markdown 描述流程，不把可执行脚本写死在里面。如果确实需要脚本，把脚本放在 Skill 目录里，并在步骤中明确告诉 AI“脚本在 scripts/xxx.py，运行前先查看注释”。这样不管在哪个工具里，Agent 都知道先去读脚本再执行，而不是瞎猜。

团队协作方面，我强烈建议把项目级 Skills 目录纳入 Git 管理，并在 README 里写清楚每个 Skill 的用途和维护人。换电脑、加新人、改标准，都不会丢失这套技能资产。另外，如果要同步到 Cursor 和 Claude Code 两套工具，可以在项目里分别建 .cursor/skills 和 .claude/skills，然后把同一份 SKILL.md 放进去。虽然看起来有点重复，但能保证两边行为一致。

4.3 写 Skills 时最容易踩的三个坑

第一个坑：把 Skill 当成角色设定。有些人喜欢在 SKILL.md 里写一堆“你是一名资深架构师”“你精通所有语言”，实际上这对执行帮助不大。Skill 的核心是流程和标准，角色设定一两句带过就够了，写太多反而稀释重点。

第二个坑：description 范围控制不好。我在 3.4 里提过场景化描述的重要性，这里再补充一个反面例子。如果描述写的是“帮助开发者提高代码质量”，那很多问题都可能命中，触发率反而下降；正确写法是“当用户要求审查代码、检查代码质量或提交前验证时使用”。把命中范围缩到最优，触发才能精准。

第三个坑：资源文件路径写错。Skill 目录里引用示例文件或模板时，相对路径很容易出错。因为 Agent 执行任务时的工作目录不一定是 Skill 所在目录，所以最好在正文里明确写一句“所有相对路径都基于本 SKILL.md 所在目录”。这句话看着不起眼，却能省下不少排查时间。

4.4 中文环境设置与常用路径整理

最后回应两个大家问得比较多的小事：在 Cursor 里看中文界面，以及 Claude Code 里的中文交互。

Cursor 的界面语言可以在设置里直接调整。打开 Cursor 的 Settings，找到 Language 这一项，选择“中文（简体）”，重启编辑器就生效了。这个设置不会影响代码编辑和调试能力，只是把菜单和界面提示变成中文，对中文用户更友好。Claude Code 本身是命令行工具，主界面目前基本是全英文，但完全可以用中文交互。你可以在 Skill 的 description 和执行步骤里写中文，比如“当用户要求对代码进行审查时使用”。你用中文提问，Agent 也能识别并触发对应 Skill，输出也可以是中文格式。

常用路径整理如下，建议收藏：

• Cursor 项目级 Skills：项目根目录 /.cursor/skills/
• Cursor 全局 Skills：用户主目录 /.cursor/skills/
• Claude Code 项目级 Skills：项目根目录 /.claude/skills/
• Claude Code 用户级 Skills：用户主目录 /.claude/skills/
• 典型 Skill 结构：skills/ /SKILL.md

结尾：先跑通一个，再复制出去

我自己玩 Skills 差不多两个月，最明显的感觉是：没配 Skills 之前，AI 像一个“不懂就问”的新人，我需要把话讲得非常细，它才能干对活；配好 Skills 之后，AI 更像一个带说明书的同事，我只需要派活，它自己会按流程执行。这种转变带来的提效是全方位的，不只是少打几个字，而是产出质量更稳定、团队成员之间的协作也更统一了。

如果你还没上手，我的建议非常简单：从你平时最常做、最烦做的那件事开始，比如代码审查或者 README 生成，照着 3.1 的模板写一个最少可用的 Skill，跑通一遍完整流程。等你体会到“一次配置、到处复用”带来的快感之后，你会自然地去想：还有什么重复劳动能这样固化下来？到那时候，你大概就理解为什么我说 Skills 是 AI 编程时代最值得花时间研究的东西了。