企业官网建设流程全解析

1. Skills到底是个什么东西

最近几个月，网上到处都在聊Cursor的Skills功能。我一开始是有点不屑的，觉得这不就是把提示词做成了文件吗？直到我把手头几个反复用了很久的提示词模板收拾干净，写成了四个标准Skill目录之后，我才发现这东西跟普通提示词完全是两个物种。

其实名字已经说明问题了。Skills不是一个独立的命令或插件，它是一套以目录和文件为核心的“技能包”，让AI在合适的场景下自动加载对应的规则、模板和流程。你可以把它理解成“给AI装的岗位手册”：普通提示词是你临时交代任务时说的话，Skills则是AI上手新员工培训时人手一本的操作规范。

现在广为流传的Skills格式，最早来自Claude Code里的Agent Skills。Cursor后来跟进，在Agents模式下做了兼容支持。也就是说，你不需要为了用Skills去刻意记住一套新的语法，只要把合适的SKILL.md文件放进Cursors识别的目录里，工作区里的Agent模型就能在需要时自动读取。

这东西解决了一个很现实的问题：AI对话的上下文窗口总是有限的，而你又不想每次开新对话都把几十条要求重新说一遍。以前大家积累提示词，无非是保存在备忘录里，用到时复制粘贴；再高级一点，用Command/Prompt库管理。但问题是，这些提示词不会自动触发，也不会根据你当前的任务类型自己去寻找对应规则。Skills则恰恰补上了这一步：任务进入时，Cursor可以在后台按需加载相关的Skill描述和完整内容，相当于在对话开始前就把你的“操作要求”喂给了模型。

我在自己的实际项目中感受最明显的场景是这样的：做前端页面时，我总会要求AI严格遵循项目的组件约定，比如不要在样式文件里写死颜色、优先使用设计系统里的Token、函数式组件统一如何命名。以前这些规则散落在多个文档里，AI经常忘，现在一个frontend-coding.skill文件夹就能搞定。每次让Agent改界面时，它在行动前先读取这个Skill里的规范，后面产出的代码风格稳定得多。

所以我的结论是：在Cursor里用Skills，不是锦上添花，而是把AI从“一次性问答工具”变成“拥有长期记忆和执行规范的生产力工具”的重要一步。特别是如果你的工作流已经开始依赖Agent模式，这一点尤其明显。因为Agent和普通补全的区别，就是它真的会自己去理解任务、拆解任务、执行多步操作；而Skills能在这个过程里插入你的“组织纪律”。

2. 上手体验：安装、目录与使用姿势

2.1 Skills文件放在哪里

Cursor里的Skills本质上就是一堆Markdown文件，所以安装和卸载都极其简单——拷贝目录或者删除目录就行了，不需要重启编辑器，也不需要装额外的扩展。

目前能被Cursor识别到的位置主要有两个：

• 工作区级：放在项目根目录的.cursor/skills/下面。比如你的项目叫my-app，那么Skill就放在my-app/.cursor/skills/。
• 全局级：放在~/.cursor/skills/下面（Windows上类似，路径可能是C:\Users\你的用户名\.cursor\skills\）。

全局Skills对你的所有项目都生效，工作区Skills则只服务于当前项目。我的建议是：通用能力（比如代码审查规则、提交信息规范）放全局；跟具体技术栈强相关的内容（比如某个项目的组件结构约定、API调用方式）放工作区。

这里有个小坑要提一下。很多人第一次配置的时候把目录建成了.cursor/skill（少一个s），或者把文件夹直接命名为xxx.skill，结果Cursor就是不识别。正确格式是每个Skill一个独立子目录，目录里至少包含一个SKILL.md文件。

2.2 一份标准的SKILL.md长什么样

Skill的核心文件就是这个SKILL.md，它通常由两部分组成：开头的一段YAML元信息和后面的正文内容。

YAML元信息主要包含name和description，其中description尤其重要，因为它决定了Cursor在什么时候主动加载这个Skill。Cursor的Agent会在对话过程中根据你的任务描述，与各个Skills的description做语义匹配，一旦发现匹配度高，就会把这个Skill的具体内容塞给模型。

一个典型的元信息长这样：

--- name: frontend-coding-review description: 用于前端代码审查，重点检查组件设计、样式规范、可访问性和性能问题。当用户要求检查React/Vue组件或其他前端代码时使用。 ---

后面正文是整个Skill的核心指引。它可以包含背景说明、检查清单、代码示例、禁止事项等。Cursor官方文档里建议正文字数控制在500行以内，但实际使用中，我认为关于具体开发规范的Skill写几百行完全没有问题，只要内容有组织性，不要流水账。

2.3 从哪里开始试第一个Skills

如果你是第一次接触，不建议上来就自己写，先装几套现成的感受一下工作流。目前在技术圈讨论最多的几套包括：

• Anthropic官方发布的agent-skills仓库，里面收集了很多基础但实用的技能，比如PDF处理、图片信息提取、浏览器自动化的思路等。虽然是给Claude Code准备的，但大部分能直接在Cursor里用。
• 社区流传很广的superpower skills，这套更像是一个“提示词增强包”，里面包含了不少写作、分析、代码生成的高阶套路，有些人觉得它太玄乎，但拿来拆解学习非常值。
• 各种开发向的Skills，比如前端组件生成、Python项目脚手架、代码重构、测试用例生成等等，在GitHub上搜awesome cursor skills或者awesome claude skills能找到不少。

我个人的建议顺序是：先装一套结构图/图表示类的Skill，再装一套代码审查类的，然后把其中一份打开来完整读一遍。用不了半小时，你对这个东西的设计逻辑就会有直观理解。

2.4 实际操作：装一个结构图Skill试试

我们以在Cursor里装一个“生成结构图”的Skill为例，走一遍全流程。这个Skill的作用是，当你让AI画架构图、流程图时，它有自己偏好的表达方式和输出格式。

先建目录：

mkdir -p .cursor/skills/structure-diagram

然后在.cursor/skills/structure-diagram/下创建SKILL.md，写入类似下面的内容：

--- name: structure-diagram description: 当用户请求生成架构图、流程图、时序图或系统组件图时使用。适合系统设计、代码结构梳理、业务流程分析等场景。 --- # 结构图生成指引 ## 输出原则 - 优先考虑用文本形式呈现结构，便于后续修改和讨论。 - 如果必须生成图片，使用Mermaid语法，但确保图表逻辑完整、方向清晰。 - 在给出图表之前，先花一段话说明整体结构，再做图。 ## 默认流程 1. 明确图的类型（流程、架构、时序、状态）。 2. 分析输入信息，提取关键实体和关系。 3. 先口述结构，再产图。 4. 在图下方补充关键节点说明。 ## 常见要求 - 节点命名使用统一风格。 - 避免过多颜色，以黑白可打印为底线。 - 如果结构复杂，按模块拆分为多张小图。

保存之后，你直接在当前项目的AI对话框里说“帮我把这三个模块的关系画成图”，Cursor的Agent如果判断需要，就会自动读取这个Skill。如果没触发，你还可以手动在对话中告诉AI“参考structure-diagram这个Skill”。

说实话，这种触发机制一开始会有点“玄学”感觉，因为你不确定它到底什么时候会加载。我的经验是，description写得越贴合真实任务表达，触发率越稳定。比如你写“当用户要求绘制图表时”，它的覆盖面就远不如“当用户要求生成架构图、流程图、时序图、状态图或系统组件图时”来得准。

3. 我推荐和实测过的好用Skills样例

3.1 前端开发类Skills：风格统一立竿见影

前端开发类Skills是社区讨论度最高的一类，因为前端项目里约定俗成的东西实在太多了。你随便打开一个中型React项目，就会发现组件划分、状态管理、样式方案、目录组织方式，每一样都有内部约定。用Cursor做前端开发时，如果这些约定不告诉AI，它就很容易写出“看起来很对但完全不符合项目风格”的代码。

我自己一直使用的一份前端Skill，重点约束了以下几个点：

• 组件文件命名统一使用PascalCase，文件夹用kebab-case；
• 所有样式必须使用项目已有的设计变量，不能随手写死像素值；
• 状态提升的逻辑和hooks封装边界；
• 不允许在组件中直接使用any类型，需要对props做显式接口定义；
• 每个新组件必须给出一个基础测试用例。

实际效果说数据可能太夸张，但就我的观察，在加入这些规则之后，AI生成前端代码的“改造成本”明显下降了。以前生成一个列表页，提交过来之后总要自己再修一修样式变量、改改命名，现在基本可以直接跑。原因是这些规则不是让我每次临时口述，而是Agent在动手写代码前已经读到并遵守了。

3.2 结构图与文档类Skills：让AI产出更规范

前面提到的structure-diagram只是最基础的一类。如果你做的是技术方案设计，一个写好的“技术方案文档Skill”会非常有用。

这类Skill的正文一般会要求AI按照固定的文档结构输出，比如背景、目标、方案选型、详细设计、风险点、验证计划。我见过很多人在用Cursor做方案时，AI输出的内容东一块西一块，结构松散；而有了Skill约束之后，你只需要说“帮我写一个订单服务的重构方案”，AI就会自动按照既定模板把内容填进去，甚至连段落编号、标题层级都保持一致。

这类Skill才是真正体现“积累”价值的地方。同一个团队里如果大家一起维护这套模板，那不管谁让AI生成文档，产出的质量都是稳定可控的。之前热词里有人提到“数学建模Skills”，思路也是类似的——把常用模型的适用范围、参数说明、验证步骤写进SKILL.md，AI在建模时就不会犯一些低阶错误。

3.3 代码审查类Skills：静态检查之外的第三只眼

代码审查Skill是我用得最久的一类。它的核心价值不是替代人，而是帮人在提PR之前先过一遍机器能发现的问题。

一份好的代码审查Skill应该包含这些层次的检查点：

• 逻辑层：是否有明显的边界条件遗漏、错误处理缺失、并发问题；
• 代码风格层：命名、格式、不合理的注释；
• 架构层：是否出现了职责不清、耦合过高、过度设计；
• 安全层：是否存在注入风险、敏感信息硬编码、不安全的依赖。

我实际对比过，让Cursor做代码审查时，如果带着一份几百行的规范Skill，它给出的审查意见明显更有条理，而且会引用具体代码行来说明问题。比起那种“看起来分析得很全面但实际上没说啥”的泛泛而谈，能打得多。

3.4 避免“提示词堆砌”式Skills

这里我想多说一句反方向的体会。现在网上有太多所谓的“superpower skills”集合，动辄一百多个Skill文件。刚开始我也兴奋地全装了一遍，心想这下AI岂不是要起飞了。结果发现，装了太多之后反而触发了两个问题：一是一些无关Skill的description会干扰Agent判断，明明在做Python后端，它却莫名其妙去匹配了那份“前端面试题”Skill；二是过量的上下文注入会把重要指令淹没掉。

所以我现在维护Skills的原则是：少而精。每个Skill必须服务于你的高频真实场景，而不是“以后可能用得上”的囤积心态。装了一百个却只用两三个，和直接在两三个上面深耕，效果是完全不一样的。

4. 从0到1开发一个自己的Skills

4.1 先把重复劳动梳理出来

开发自己的Skill不需要什么高深的编程能力，但需要你有意识地记录自己的工作流。我的方法比较简单，每天下班前打开对话记录，把当天让AI重复做过的事情整理出来。只要同一类需求出现三次以上，我就会考虑建一个对应的Skill。

比如有一段时间我经常让AI把接口返回的数据转成TypeScript类型定义，这个操作本身不复杂，但每次都要先说一遍字段命名规则、可选参数怎么处理、枚举类型怎么定义。后来我直接写了一个api-type-generator的Skill，把规则固定下来，再让AI做这件事时就再也不用重复解释了，就是一句话的事。

4.2 写一份高质量SKILL.md的三个关键部分

抛开YAML头，一份好用的Skill正文，我总结下来至少要有三个关键部分。

第一部分是“背景与目标”。开篇用几句话说清楚这个Skill解决什么问题、适用的场景边界在哪里。这样不仅AI能更好地理解，你自己过几个月回来看时也知道当初为什么要建它。

第二部分是“执行步骤”。这是整个Skill的骨架。AI最擅长的事情之一就是按照步骤执行，所以你在Skill里给它的步骤越清晰，它的产出就越稳定。比如写一个“代码重构Skill”，步骤可以是：先分析当前代码的职责和依赖，再列出重构目标，然后分步骤实施，最后给出测试验证方案。

第三部分是“约束与偏好”。这部分是很多人容易忽略的，也是决定Skill质量的分水岭。AI生成代码的时候天然会倾向于比较“泛化”的方案，如果你想让它符合你团队的内部规范，必须明确写出来。比如“不允许改变公共API签名”“不允许在业务代码中直接打印日志，必须通过logger”“不允许在未开启事务的情况下执行批量更新”这种话，写下来就是规则，不写就是遗憾。

也许你写出来的第一个Skill不会特别完美，但不要紧。Skill的好处是它可以持续迭代，你每发现一次AI没按你的预期做事，就可以在SKILL.md里补一条规则。经过几轮修改，它就会越来越贴近你的真实需求。

4.3 从文本走向调优：迭代方法

开发Skills还有一套比较笨但很有效的方法：先不用专门准备测试数据，就直接拿平时那些让你头疼的真实需求来试。我一般会准备三四个不同类型的任务，在每次修改Skill之后分别跑一遍，观察AI是否真的遵守了新增的规则。如果某一次AI没遵守，我会先检查是不是description的问题导致Skill根本没被加载，然后再看是规则本身不够清晰，还是规则太长被忽略了。

关于防止被忽略这件事，我有个心得：重要的规则要放在正文靠前的位置。AI读模型指令时，结构越靠前、越独立的内容，权重往往越高。如果你把最重要的约束埋在第两百行，那它被遵守的概率会低很多。

还有一个小技巧是，每个Skill的正文里都可以加一个“负面清单”，明确列出不要做什么事情。这和写代码时“防御式编程”是一个思路，你不能只告诉AI要做什么，还要告诉它不能做什么。比如我给自己写的前端Skill里就有一条：不要主动使用需要额外安装的第三方依赖，优先用项目已有的库。这一条至少帮我省了无数次删掉没必要的依赖的功夫。

4.4 版本管理与团队共享

Skills本质上是纯文本，这给了我们一个巨大的优势：可以像管理代码一样管理它。我自己会把全局Skills目录放在一个git仓库里，每次有改动就提交一次，还能清楚地看到每一次修改的原因。如果你的团队也想统一使用Skills，建议把一些公共的Skill放在一个共享仓库里，通过子模块或者下载脚本的方式同步到各人的本地目录。

这里我推荐一个最简单的同步方案：在项目的package.json里加一个setup-skills脚本，从远程仓库下载最新的Skill文件到.cursor/skills/目录。这样团队成员拉取代码后自动执行一次，就能保证大家用的是同一套AI行为规范。对吧，这个思路跟管理eslint配置、prettier配置差不多，本质都是“把约定变成工程资产”。

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

5.1 Skill根本没生效怎么办

如果AI始终没有按你的Skill行动，不要急着怀疑是Cursor版本问题，十有八九是这三个原因之一。

一是目录路径写错了。Skill放错目录是最常见的问题，注意必须是.cursor/skills/某个子目录/SKILL.md，不能直接把SKILL.md扔在.cursor/skills/根目录下。

二是description写得不够“像人话”。如果description本身就写得绕来绕去，Agent在匹配时猜不到你的Skill跟当前任务有关，自然就不会加载。我建议description写得直白一点，把场景、任务类型、触发条件都列出来。

三是Skill内容本身有语法问题。YAML头如果格式不对（比如少个冒号），整个Skill可能都不会被识别。遇到这种情况，可以打开命令面板，查看Cursor的日志，也可以直接把SKILL.md的内容复制给AI，问它“解析这个文件的元数据”。

排除完这些技术因素之后，还有一个很隐蔽的原因：你的对话没有走Agent模式。在普通的Chat模式下，Cursor不一定具备完整的多步骤执行能力，所以有些Skill可能不会被读取。要完整使用Skills，建议切到Agent模式。

5.2 热词里的“提示词泄露”到底怎么回事

最近很多人在聊“cursor提示词泄露”，这其实不是因为Cursor故意把用户的提示词暴露出去，而是因为一些基于Cursor做的“套壳AI工具”或者浏览器插件，在收集用户输入的提示词和对话内容。这类消息越传越玄，搞得很多人都不敢在Cursor里写敏感信息了。

我的建议比较朴素：不要把核心密钥、密码、个人隐私信息直接写进Skill里或者对话里。Cursor的对话记录是保存在本地的，但如果你用的是团队版或者第三方封装，数据会不会被额外上传，你无从得知。所以对于技能文件，凡是涉及内部地址、账号信息的内容，尽量用占位符引用，比如写成YOUR_API_KEY，然后在对话里手动输入。

另外给一个小建议：如果你要从网上下载别人做的Skills，先通读一遍内容再装进本地目录。GitHub上那些几十个Skill的合集，良莠不齐是很正常的，有些Skill里塞的提示词可能并不适合你的场景，甚至可能是恶意注入。既然是明文的Markdown，花几分钟扫一遍，基本不会有什么风险。

5.3 Cursor里面的Skills跟Claude Code、Codex的有什么区别

因为Skills格式最早是Anthropic在Claude Code里推的，所以很多第一次接触的人会有疑问：我在Cursor里用的这套东西，跟Claude Code里的Agent Skills是不是一回事？

其实在核心文件格式上，两者基本是兼容的。你在GitHub上看到的awesome claude skills仓库里的绝大多数Skill，下载下来放到Cursor的.cursor/skills/目录下都能正常使用。这背后的逻辑不难理解：Anthropic设计了一套简单通用的Markdown格式，而Cursor作为AI代码编辑器，很大程度上对标了Claude Code的Agent行为，所以直接吃下了这套格式。

至于OpenAI那边的Codex，它有自己的一套机制，配置方式不太一样，但思路是类似的。我觉得对于普通用户来说，不必太纠结于生态差异，重点是你需要的那份Skill格式能不能用、好不好改。目前来看，Claude Code的Skill生态最丰富，Cursor兼容性最好，所以按这个组合入手基本没错。

5.4 关于Pro额度和使用限制的几句实话

热词里很多人搜“cursor pro有多少额度”，说明大家已经关心到使用量这一步了。我个人的感受是，Skills本身不会增加额外消耗，它真的只是“约束AI行为”的上下文信息。真正影响额度消耗的是你对话的数量和Agent执行任务的复杂度。

Cursor的付费方案里，Pro版主要包含的是足够的Agent请求次数、Tab补全等功能。如果你重度使用Agents，消耗的速度确实会快。但Skills实际上并不能帮你省额度，反而因为让AI更精准地执行任务，减少了你反复纠正的次数，间接提高了额度利用率。所以与其纠结技能本身的消耗，不如把重点放在如何用好Agent上面。

还有一个热词是“cursor怎么设置中文”，这跟Skills的关系不大，但既然大家经常遇到，我就顺带说一句：目前Cursor自身还没有特别完善的官方汉化，市面上一些汉化包和插件本质上是通过修改界面语言包实现的，存在一定的更新滞后风险。如果使用第三方汉化工具，建议确认来源可靠，不要因此影响工作区里的代码文件。相比之下，我更推荐直接用英文界面，配合Skills去约束AI输出中文注释或者中文文档，这样既避免了版本更新带来的界面错乱，也更好融入开发者社区。

5.5 调试Skill时的5个小技巧

最后分享几个我在调试Skill时积累的小技巧，算是给已经动手写Skill的读者一些实用建议。

给Skill的描述中添加触发词时，可以故意加入不同写法的同义词，比如“流程图”“flowchart”“流程图绘制”同时出现，这样能提高匹配成功率。代价是description会略长，但不影响整体。

每次修改SKILL.md之后，不需要重启Cursor，但建议新开一个对话测试。因为在同一个会话里，即使Skill更新了，AI可能还是会沿用之前已经读取到的旧指令。

测试Skill时，准备一个专门的测试项目目录，不要在正式项目里来回试。测试目录里放几个伪造的示例代码和需求描述即可，这样不会污染真实项目的对话记录。

多关注Cursor的版本更新日志。Skills功能在早期版本里是有一些限制的，比如某些Agent参数对Skill内容的读取顺序不同，升级版本之后可能会有变化。记住，工具的更新往往会改变一些隐性的行为规则。

如果某个Skill长期用不上，果断删掉。一个充满无用技能文件的目录，和一个整洁高效的目录，感受真的是天差地别。我把Skills数量从几十个精简到七八个之后，AI的行为稳定性反而提升了，这让我确信“少即是多”在AI提示词世界里同样成立。

我在实际使用中的体会是，Skills引来一种思维方式的转变：以前我问AI问题，是把AI当成一个全能实习生，每次都要把来龙去脉讲清楚；现在通过Skills，我相当于给这个实习生发了一整套公司制度手册，交代任务时只需要讲出目标和关键点。这种转变带来的效率提升，不是那种瞬间惊艳的感觉，而是一种稳定、持续、越用越顺畅的变化。

如果你现在还在犹豫要不要试着把第一份提示词变成SKILL.md，我建议你先做最简版本——哪怕里面只有三句话规则，先让它跑起来，用起来，再迭代。这个工具真正的价值，不在于收藏了多少现成的Skills，而在于你愿不愿意花一点时间，把自己的经验和团队规范沉淀成机器能理解的文件。这一步迈出去之后，你会发现Cursor用起来的感觉完全不一样了。