企业官网建设流程全解析

你有没有遇到过这样的尴尬：让Cursor帮你写一个团队的React组件，结果它完全按自己的习惯来，跟你们项目的命名规范、路由风格、注释习惯全对不上；或者让它帮你排一份LaTeX论文，它每次都从零开始问你格式要求，答完这次下次又忘。过去我的解决办法很粗暴——把规范写进全局Rules里，或者每次手动贴一大段“工作手册”进提示词。规则越攒越多之后，整个上下文都被这些固定内容占着，真正重要的代码反而没空间了。

后来我把目光转向了Cursor里的Skills机制，用了一段时间之后，最大的感受是：这东西本质上就是给AI配了一本“按需翻开的SOP手册”。比起把所有规则一股脑塞给模型，Skills是在你真正处理某类任务时才把对应内容加载进来。这篇文章我会从Skills在Cursor里的定位讲起，依次聊到现成技能包的获取安装、触发机制、自己怎么写一个可用的Skill，以及我实测中踩过的那些坑。无论你只是想把别人做好的技能直接用起来，还是打算给团队沉淀一套内部规范，这篇文章都适合你。

1. Skills在Cursor里解决的是什么问题

先说清楚一个基本问题：Skills在Cursor里到底是什么。Cursor中的Skills，形式上是一个带SKILL.md描述文件的文件夹，里面装着某个领域任务的“操作手册”——包括工作流程、代码规范、输出格式、检查清单，甚至配套的脚本和参考文档。当你在对话里让Cursor处理某类任务时，模型会根据技能描述判断要不要加载这份手册，并按照手册里的步骤去执行。

听起来好像只是“多了一个文件”，但真正用过之后你会发现，它解决的问题比想象中要大。

1.1 没有Skills时，我们在怎么“重复造轮子”

在Skills出现之前，我身边大多数人的做法分三类。

第一类是把规范写进全局Rules。这个做法的好处是每次对话都生效，但坏处也明显——无论你在写Python还是改配置文件，所有规则都压在上下文里。全局规则一多，不仅浪费token，还容易让模型在无关任务上也“过度守规矩”，反而影响灵活性。

第二类是每次手动粘贴规范。这个方式看似精准，实际上很累。你需要在对话前整理一份“临时手册”，一旦忘了贴，模型就按默认习惯来，产出的代码风格立刻打回原形。而且不同项目有不同规范，每次都要从收藏夹里找对应文本，麻烦程度不亚于复制粘贴一段长代码。

第三类是依赖模型“自己记住”。靠对话记忆显然不靠谱——换个新会话就断片了，团队里换了同事也接不上。

Skills的解决思路其实很朴素：把规范做成独立的、可复用的文件夹，每个文件夹专门管一类任务。写React组件时自动加载React规范，做LaTeX排版时自动加载排版规范，谁也不耽误谁。需要的时候才翻开手册，不需要的时候完全不影响对话。这个“按需加载”的思路，就是它和Rules最大的区别。

1.2 Skills、Rules与MCP：三者的分工别搞混

刚接触Cursor生态的人，经常会问一个问题：我有Rules了，也有MCP，为什么还要一个Skills？这三者的边界不少人是模糊的。我用一张表说明白。

这三者并不互斥，实际项目中往往是组合使用。比如你可以用Rules规定“所有代码必须写注释”，用Skills规定“React项目里组件怎么拆分、Hooks怎么命名”，再用MCP让Cursor能直接查询你们公司的接口文档。Rules管底线，Skills管专业能力，MCP管外部连接，各司其职。

理解这个分工之后，再看Skills就很清晰了：它解决的是“专业工作流标准化”的问题。你不需要在每次对话里重复告诉Cursor该怎么干活，它只需要在合适的时机自己翻开那本手册。

2. 先跑通现成的：开源Skills的获取与安装

很多人的第一反应是“我不会写Skill，直接用别人做好的行不行”。当然行，而且我强烈建议你先从现成的开始，跑通一遍再考虑自己写。这个领域的生态已经比较热闹了，虽然早期高质量技能包不多，但找一些通用场景的完全够用。

2.1 从哪些地方能找到靠谱的Skills源

目前找现成Skills最主流的两条路：一是GitHub上的聚合仓库，二是一些社区维护的技能集市网站。GitHub上直接搜“awesome-claude-skills”“cursor skills”这类关键词，能找到不少人整理的技能列表。除了综合仓库，还有一些特定方向的合集也值得关注，比如前端开发技能包、LaTeX排版技能包、图片生成技能包、AI漫剧分镜脚本技能包，甚至连全国大学生数学建模比赛用的论文排版技能都有现成的。这些技能包的质量参差不齐，下载前我习惯先看两点：一看Star数和最近更新时间，二看SKILL.md里写的描述是否具体。描述写得含糊的，往往触发效果也不好。

另外一个很实用的途径是直接在Cursor的对话框里问AI：“你了解有哪些常用的Skills源网站吗？”让模型帮你梳理一遍社区里的知名项目，再去GitHub核对。这比自己在搜索引擎里翻半天高效得多，尤其是对刚上手的人。

2.2 安装到全局目录还是项目目录

找到技能包之后，安装本身没什么技术含量，核心就是选对目录。Cursor的技能包位置分为两种。

全局目录在用户主目录下：

• macOS / Linux：~/.cursor/skills
• Windows：%USERPROFILE%\.cursor\skills

全局目录里的技能包对所有项目生效，适合放那些“通用型”技能，比如代码审查规范、通用写作规范、LaTeX排版规范。

项目级目录在项目根目录下：.cursor/skills。这个目录里的技能包只对这个仓库生效，而且因为文件夹会随代码一起提交，团队里的人clone下来之后能力是共享的。适合放跟业务强绑定的规范，比如你们公司自己的后端代码结构、特定框架的组件写法、数据表命名规则。

实际操作时，只需要把下载下来的技能包文件夹（注意是整个包含SKILL.md的文件夹）放到对应目录里就行。比如你想让所有项目都能用一个“前端开发规范”技能，就把那个文件夹复制到~/.cursor/skills下面。装完建议执行一次“Reload Window”，让Cursor重新扫描技能目录，再开始测试。

2.3 装完之后怎么确认Cursor真的读到了

这一步是很多人忽略的。装完技能包就直接开聊，结果发现模型根本没调用，于是开始怀疑自己哪里装错了。我建议用两个方法来验证。

方法一：直接问。在Cursor的输入框里问一句“你现在有哪些可用的skills”，正常情况下模型会把它能看到的技能包名称和描述列出来。如果列出来的技能跟你放进去的对不上，说明扫描路径有问题或者格式不对。

方法二：制造一个必须触发技能的请求。比如你装了一个“LaTeX排版”技能包，就让它“帮我用LaTeX写一份学术论文的模板”。如果技能真的被加载了，模型会按照技能里的格式要求一步步输出；如果没有，你就得回头检查目录结构和SKILL.md格式。

这里还想提醒一句：不同版本的Cursor对Skills的入口位置有差异。新版里有的桌面端在Settings里增加了SKills路径的管理入口，最稳妥的方式是直接以文件管理器的方式打开上面说的目录路径，手动确认文件夹确实在那。别只依赖设置界面，文件路径才是最终的判断标准。

3. 让技能真正被调用：Agent触发机制与使用细节

安装只是第一步，真正让Skills发挥价值的是“触发”这个环节。不少人在这一步卡住——技能明明装好了，模型就是不调用。这背后其实涉及Cursor对Agent模式、模型能力、上下文管理的一整套逻辑。

3.1 自动触发和手动引用的配合方式

Skills的触发方式主要有两种。自动触发是指当用户描述的任务和技能包description高度匹配时，模型会自动决定加载该技能。比如技能描述里写着“当用户需要编写或审查React组件时使用”，那么你只要说“帮我写一个带筛选功能的用户列表组件”，模型就会尝试加载这个技能包。这种机制的最大好处是自然——你不需要记得自己装了什么技能，正常说话即可。

手动引用则适合那些场景特别明确的时刻。在Cursor的输入框里，你可以通过@引用的方式把技能包路径贴进对话，比如@你的技能包文件夹路径，让模型明确知道你要用这个技能。这种方式适合一张对话里有多个技能候选、你不想靠模型猜的场景。

两者怎么配合？我的习惯是：通用任务靠自动触发，重要且复杂的任务靠手动引用。比如平时写点小代码，让模型自己判断就好了；一旦要输出正式的团队代码评审或者论文排版，我一定手动引用对应技能包，确保它跑不了。

3.2 为什么有时候Agent就是不调用Skills

如果模型就是不调用你装的技能，先别急着怪技能包。逐个排查下面几个因素。

第一，模型模式不对。只有Agent模式下，模型才具备“主动决定加载技能”的能力。如果你用的是普通的快速问答模式（尤其是一些轻量模型），它可能根本不会去看技能目录。在Cursor里执行复杂任务前，先把模式切到Agent，否则装再好的技能也白搭。

第二，技能描述写得不好。这其实是最大概率的原因。描述太笼统——比如只写“前端开发技能”——模型遇到具体任务时很难判断“这件事属于前端开发技能的范围吗”。描述里应该包含明确的触发场景和任务类型，越具体召回率越高。

第三，上下文太长，模型“忘”了还有技能可用。在长对话里，早期加载的内容会逐渐被挤出上下文。如果聊了很久才提到要写React组件，模型可能不再记得自己有哪些技能包。遇到这种情况，直接手动引用技能包路径最省事。

第四，版本兼容问题。老版本的Cursor可能根本还没支持Skills，或者支持的目录格式不同。如果验证了目录、模式、描述都没问题还是不生效，优先检查Cursor版本，把它升级到最新版再试。

3.3 模型选择与上下文预算的平衡

用Skills时，很多人忽略了模型选择对效果的影响。需要主动调用技能包里的流程、并严格按照手册执行任务的场景，建议选择Agent能力强的模型，比如Claude系列更靠后的版本，或者各家最新旗舰模型。轻量模型不是不能用Skills，但可能“读”了手册却不认真执行，效果会打折扣。

上下文预算同样重要。Skill被触发后，SKILL.md的内容会被注入对话上下文。如果你把整个操作手册写成一个几千行的大文件，光加载它就会吃掉大量上下文空间，留给真正代码和对话的空间就少了。这也是为什么我后面第四节会专门讲“渐进式披露”的写法——主文件只保留摘要和触发条件，细节放进references子文件里按需加载。这不仅是写给别人看的技巧，更是为了省token。

4. 从零写一个Skill：以前端开发规范为例

现成技能包用熟练之后，很多人会萌生一个念头：我也写一个属于自己的Skill。这个门槛其实不高，照着固定结构来就行。这一节我拿一个“前端React开发规范”技能包举例，从目录结构到SKILL.md内容，一步一步讲清楚。

4.1 一个Skill的标准目录结构

Skills的能力来自一套约定的目录结构。一个最小的技能包长这样：

my-react-skill/ ├── SKILL.md └── references/ └── react-code-review.md

外层文件夹的名字（比如my-react-skill）可以随便起，方便识别就行。但里面那个SKILL.md是固定的文件名，不能改，也不能改成小写skill.md，否则Cursor可能压根不认。references目录是可选的，用来放那些“用得着但没必要一上来就全文加载”的详细资料，比如代码审查细则、组件拆分策略、命名对照表。

如果技能包里带脚本，还可以加scripts/目录。比如写一个自动检查组件命名是否符合规则的Python脚本，放在scripts/check_component_name.py。Agent在执行到对应步骤时可能会调用它，不过是否执行脚本、执行时要不要授权，取决于Cursor的权限策略。

4.2 SKILL.md怎么写才不会被Agent无视

SKILL.md是整个技能包的核心，控制着它“会不会被触发”以及“触发后怎么干活”。头部是YAML格式的元信息，用---包裹起来，至少需要name和description两个字段。

name用来标记技能名，description的作用则大得多——前面反复提到，模型判断“要不要用这个技能”就是靠读description。所以description写得越具体越好。不要只写“用于前端开发”，而要写成“当用户需要编写、审查或重构React函数组件时使用。包括组件目录结构、Hooks命名规范、props设计原则、代码审查清单等”。这样模型才能在你提出相关需求时产生匹配。

正文部分不要上来就堆细节。SKILL.md的主体应该写清楚几个内容：这个技能适合什么场景、不适合什么场景、标准工作流程是什么、输出什么格式、有哪些硬性规则。比如写React组件规范，可以规定：组件文件必须放到src/components/[功能名]/目录；每个组件带一个index.ts导出；Hooks命名必须以use开头并遵循驼峰式；禁止在组件内部直接写行内样式，等等。

一个非常好用的写法是“显式指出触发条件”。在描述或正文开头顶格写一句“当用户提到以下关键词或需求时，必须使用本技能：React组件、前端组件、组件审查……”。这句话相当于给模型一个强指令，能明显提高召回率。

4.3 一套可直接改用的React组件Skill示例

下面我给一个简化但完整的SKILL.md示例，你可以直接抄走改成自己团队的版本。

--- name: react-component-standard description: 当用户需要编写、审查或重构React函数组件时使用。覆盖组件目录结构、Hooks命名、props设计、代码审查清单。适合前端开发场景，也适合要求输出团队规范的场景。 --- # React组件开发规范 ## 使用场景 - 用户要求创建新的React组件 - 用户要求审查已有组件代码 - 用户要求重构组件并保持团队规范 ## 不适用场景 - 后端接口设计 - 数据库表结构设计 - 非React的前端页面开发 ## 工作流程 1. 确认组件功能与使用场景 2. 参考references/react-code-review.md中的目录结构和命名规则 3. 输出组件代码，包含必要的类型定义 4. 附上checklist，逐项说明是否符合规范 ## 硬性规则 - 组件使用function声明，不使用class组件 - props通过interface定义，统一放在组件文件底部导出 - 所有Hooks以use前缀开头，语义化命名 - 禁止行内样式，统一使用CSS Modules - 组件文件放在src/components/[功能名]/目录下 - 默认导出组件，同时导出类型定义 ## 输出格式 代码块输出组件完整代码，代码块之后给出Checklist列表： - [ ] 目录结构是否合规 - [ ] Hooks命名是否合规 - [ ] props是否有类型定义 - [ ] 是否有行内样式

这个示例麻雀虽小，五脏俱全。它明确了触发场景，给出了工作流程，并且把“输出检查清单”也写进技能里——这样模型每次写完组件都会附带一个自检清单，团队评审的时候就很省事。

4.4 细节放进references，按需加载

你可能会发现，上面的SKILL.md正文里，详细规则只写了6条。真正团队的规范肯定不止这些，什么组件注释怎么写、样式命名用BEM还是别的、目录下要不要额外放storybook文件……这些全写进主文件，上下文空间就浪费了。

正确做法是把详细规则拆分到references子文件里。SKILL.md里只留一句话：“组件结构、样式命名、注释规则的详细说明，见references/react-code-review.md”。当Agent需要深挖时，它会自己去读那个子文件。这就是前文说的渐进式披露——主文件负责“告诉模型有这个技能、以及大概的执行框架”，子文件承载“具体怎么做”的全部细节。这套思路跟写技术文档时“摘要+正文”的结构如出一辙，只是服务对象变成了模型而已。

5. 实测中踩过的坑：路径、缓存与兼容性

技能包用了一段时间之后，我确实踩过一些不大不小的坑。这些问题单看都不难解决，但第一次遇到时多少会让人愣一下。这一节把几个典型的坑记录下来，希望你能绕开。

5.1 目录命名和YAML格式：第一道翻车点

最容易翻车的其实不是概念性问题，而是最基础的格式问题。首先，技能包的内部必须有SKILL.md，这个文件名是全大写固定名称，一旦写成skill.md或者SKILL.MD，Cursor很可能直接忽略。其次，YAML头部里冒号后面一定要有空格，name: react-component-standard是合法的，name:react-component-standard就会解析失败。再次，YAML头部里的字段不要用Tab缩进，统一用空格，解析更稳定。

文件夹的名称反而没那么多讲究，中英文都可以，但建议还是用英文小写加横线命名，一是避免编码问题，二是团队协作时更通用。我最初把一个技能包文件夹命名为“前端规范”，虽然也能用，但在命令行和配置里进出目录时并不方便，后来统一改成了英文命名。

5.2 改了不生效：加载与缓存机制的真相

这个问题几乎每次更新技能内容时都会遇到。你改了SKILL.md里的某个规则，回到Cursor里重新提需求，发现模型还在按旧规则输出，完全无视你的修改。

原因通常不是写错了，而是Cursor没有重新扫描技能文件。对于大多数修改，执行一次“Developer: Reload Window”就能解决。如果是在项目级技能目录里改的，注意确认当前打开的工作区确实是这个项目。还有个细节容易被忽略：技能包内容的加载时机，可能在你发起请求的瞬间才确定。所以如果你改了文件，但上一轮对话已经处于激活状态，最好新开一个会话再测试，避免旧会话粘着旧技能的状态。

5.3 同一套Skills在Cursor与Claude Code的差异

因为Skills的概念在其他AI编程工具里也存在，比如Claude Code。同一个技能包文件夹，在Cursor和Claude Code之间有时可以互通，但有几个地方需要注意。

首先，目录位置不一样。Cursor读的是~/.cursor/skills或项目里的.cursor/skills；Claude Code读的是~/.claude/skills或项目里的.claude/skills。要让两边共用，最简单的办法是把技能包复制到两边各自的目录里，而不是试图让某一方“跨界”读取。

其次，YAML里的元信息字段在两个工具之间不完全通用。比如有的技能包会带allowed-tools字段，声明技能执行时可以调用哪些工具，这类字段在Cursor里未必生效，甚至可能在解析时报出警告。跨工具使用前，建议把这类工具相关的字段清掉或按目标工具的文档重新配置。

最后，模型的执行风格不同。Claude Code更倾向于严格按照技能里的Workflow一条条走，而Cursor的Agent在步骤控制上更灵活一点。如果技能里写了“必须按顺序执行1、2、3、4”，在Cursor里最好再叠加一句“未完成上一步之前不要跳到下一步”，否则模型可能合并步骤跑。这也算是我迁移技能包时发现的一个小经验。

5.4 脚本执行与权限：安全第一

有些技能包会附带可执行脚本，比如检查代码规范、批量生成文件等。这类脚本在Cursor里执行时通常会触发权限确认。如果你为了省事，在Agent设置里把自动接受权限全部打开，风险就来了——技能包来自第三方，你根本不知道它内部脚本会不会做超出预期的事情。我的建议是：技能包里的脚本先人工打开看一遍，确认没有可疑操作再允许执行；尤其是那些从GitHub上下载、来源不明、却要求联网或写文件到系统目录的脚本，更要留个心眼。Cursor本质上是把执行权交给了模型，而模型会忠实地执行技能包里的指令——包括你不希望它执行的指令。所以审查技能包内容，跟你审查第三方依赖库一样重要，不能省。

最后再分享一点我的个人体会

把Skills用成习惯之后，我最大的感受是：它逼着我把“怎样算做得好”这件事想清楚了。以前我口头告诉Cursor“写规范一点”，它永远无法理解我们团队到底要怎么个规范法。现在我可以把规范拆成技能包，用SKILL.md一条条写清楚，再把检查清单塞进去让它自查。这样做的好处不只是代码风格统一了，更重要的是新人接手项目时，不用翻团队文档也能让AI按团队规范干活。

一个小技巧分享给大家：给技能包取description的时候，我习惯用“当用户提到……时使用，覆盖……，适合……，不适合……”的句式，把触发条件、能力范围、边界都写清楚。实测下来，这样写的技能包召回率比只写一句话的明显高。你们也可以试试，把自己手头反复贴给别人看的那些规范文档，先挑一个整理成技能包，用一次就知道这套机制有多顺手了。