Cursor Skills 实战指南：为 AI 编写岗位说明书，稳定复现资深工程师工作流

经常听到有人说“Cursor也就那样，生成出来的代码跟普通聊天模型差不多”。这个评价我听过太多次了，而且绝大多数时候我都同意——如果你只是把 Cursor 当做一个套了编辑器外壳的对话窗口，那它的表现确实很平庸。真正让 Cursor 拉开差距的，是它的 Agent 模式和 Skills 机制。什么是 Skills？一句话说清楚：它是你交给 AI 的一份“岗位说明书”，告诉它在某个具体任务里应该按什么流程、什么规范、什么标准去干活。没有这份说明书，AI 每次都是临时摸索；有了它，AI 才能稳定复现一个资深工程师的工作方式。这篇文章我打算把 Cursor Skills 的标准模板、编写规范和实操经验完整梳理一遍，包括我自己写过的多个 Skill 和踩过的坑，让想上手或者已经在用的人少走弯路。

1. 先搞清楚一件事：Skill 不是插件，而是给 AI 的一份“岗位说明书”

1.1 Cursor 默认行为为什么不够用

很多人一开始接触 Cursor 会觉得它“聪明但毛躁”。让它改个 bug，它可能直接重写整个文件；让它写个函数，它能给你整出十几种风格；同样一个需求，上午问和下午问，输出质量能差出两个档次。原因在于：默认状态下，Cursor 在每个新会话里对“你希望它怎么干活”这件事只有非常模糊的认知，它知道你是程序员，但不知道你在哪个项目、用什么技术栈、遵守什么代码规范、讨厌什么写法、测试要达到什么覆盖率。这些信息如果全靠你在聊天框里反复重申，那效率就太低了。Skills 要解决的就是这个“重复交代背景”的问题。

1.2 Skill、Rules、Prompt 三者到底有什么区别

我在社区里经常看到有人把 Cursor Rules 和 Cursor Skills 混为一谈，也经常看到有人觉得“Skills 不就是把一段 prompt 存起来吗”。这个理解角度不算错，但它们解决的问题层级完全不同。

我整理了一个对比表格，方便直观理解：

从这个表格可以看得很清楚：Rules 适合写“永远成立的规范”，比如代码风格、禁止事项；Skills 适合写“某个完整工作流”，比如“代码审查”“重构优化”“学术论文润色”。它们不是替代关系，而是配合关系——Skill 在运行时，同样会遵循项目里的 Rules 约束。

1.3 什么情况下你才真正需要写一个 Skill

我见过有人一口气装了 40 个 Skills，结果发现 Cursor 反而变笨了。这不是 Skills 的问题，是安装者没搞清楚“什么时候该用”。判断标准其实很简单：如果一个任务你每周要重复做两三次，每次都要给 AI 解释一大堆背景，并且做完之后还想保证结果稳定一致——这个任务就值得你花半小时写成一个 Skill。

反过来，一次性任务、随口聊天的需求、你自己都说不清步骤的探索性工作，完全没必要写成 Skill。它反而会污染模型的理解空间，因为它会多出一堆候选技能，每次决策都要做一次匹配。好的 Skills 库应该是精而不多，每个 Skill 都解决一个你真实反复遇到的痛点。

2. 标准 Cursor Skills 模版长什么样：从 frontmatter 到正文的逐字段拆解

2.1 完整可复制的 SKILL.md 标准模版

下面这份模版是我在实践了大半年、写了十几个 Skill、参考了社区里传播度较高的几套规范之后，反复调整出来的一个相对“标准”的版本。它不是官方强制的格式，而是经过验证、可读性高、触发率稳定的结构。

markdown复制---
name: skill-name-in-english
description: When the user asks about X, or when you need to accomplish Y, or when [specific scenario], use this skill to Z. The skill is especially useful for [target user or scenario].
---

# Skill: 技能名称（中文）

## 1. 使用场景
- 场景一：XXX
- 场景二：XXX
- 场景三：XXX

## 2. 工作流程
### 2.1 第一步：需求确认
- 动作描述
- 必须检查哪些前提条件

### 2.2 第二步：信息收集
- 需要读取哪些文件
- 使用什么命令或工具

### 2.3 第三步：执行方案
- 按什么顺序处理问题
- 每一步的产出是什么

### 2.4 第四步：验证与收尾
- 如何自测
- 输出的最终格式是什么

## 3. 技术规范
- 必须遵守的编码规范
- 禁止事项
- 边界条件处理

## 4. 示例
### 示例 1：场景 A
输入示例：
输出示例：

### 示例 2：场景 B
输入示例：
输出示例：

## 5. 依赖与工具
- 需要读取的配置文件
- 可能用到的命令
- 需要的权限或环境变量

这个模版看起来长，但每个部分都有明确职责。我接下来逐个拆解它为什么要这样写，以及哪些字段是真正决定成败的。

2.2 frontmatter 里 name 和 description 的写法，直接决定 Skill 能不能被触发

frontmatter 是整个 Skill 里最关键的 metadata 区，它只包含两个字段，但这两个字段写得好不好，决定了这个 Skill 会不会在关键时刻被模型想起。

name 字段要求全小写、用英文、单词之间用连字符连接。这样命名的主要原因是为了避免模型在识别文件名时出现大小写混乱或编码问题。我建议把名字取得具有“行动感”，因为它本质上是一个能力标识，比如 code-reviewer、react-refactorer、academic-paper-polisher。name 不要用抽象概念，比如 frontend、optimization 这种名字太宽泛了，以后你想扩展的时候会发现名不副实。

description 字段是全部模板里最容易被忽视却最影响触发成功率的部分。它的写法有几个关键原则：

第一，描述里要列出足够多的“触发器关键词”。你可能注意到传统 prompt 教程会让 AI 忽略 description，但在 Skills 机制里，description 就是模型判断“当前用户请求和哪个 Skill 匹配”的核心依据。描述里包含越多的同义表述，模型就越容易把它和你实际想表达的需求对上。举个例子，如果你的 Skill 是做前端代码审查，那么 description 里除了写“code review”，还应该写“检查代码质量”“找出潜在 bug”“优化建议”“审查 React 组件”等。

第二，要说明触发条件，而不是功能简介。对比一下这两种写法：

• 低效写法：Provide code review for frontend code.
• 高效写法：Use this when the user asks to review or improve frontend code quality, find bugs or potential issues, or requests a detailed code review of React/TypeScript components. The skill is especially suitable for code review before committing or merging.

第二种写法之所以触发率高，是因为它直接描述了“用户在什么场景下会问什么问题”，而不是描述“我能提供什么”。模型在做意图匹配时，本质上做的是用户输入文本和 description 文本之间的语义相似度匹配，所以 description 里要尽可能写用户可能用的表达。

第三，description 最后可以加一句“这个 skill 特别适用于……”，帮助模型在多个候选 Skills 之间做区分，减少误触发。当你装了几十个 Skills 之后，这会明显提升命中率。

2.3 正文结构的设计逻辑：为什么把“工作流程”放在“技术规范”前面

现在看正文部分。我设计的顺序是：使用场景 → 工作流程 → 技术规范 → 示例 → 依赖与工具。这个顺序不是随便排的，它模拟的是一个人接到任务时的心智路径。

使用场景放在最前面，作用是给模型一个快速的“确认信号”，让它进入对应的任务模式。使用场景要写成具体的可识别情形，不能写得太抽象。比如“场景：用户要求对现有前端代码进行代码审查”要比“场景：用户提到代码质量相关需求”可判断得多。

工作流程是整个 Skill 的灵魂。我之前见过一些 Skill 只写了“请按照最佳实践完成任务”这种废话，这等于没写。好的工作流程应该像一份 SOP，让模型知道先做什么、再做什么、每个步骤的输入输出是什么。但这里有个分寸问题：步骤要给到“主干明确、分支可选”的程度，而不是把每行代码都规定死。

技术规范放到工作流程之后，是为了让模型在知道“怎么做”之后再了解“底线是什么”。如果把规范放在流程前面，模型的注意力会被规范吸走，容易变成教条式执行。技术规范里要包含：必须遵守的编码风格、禁止做的事情、边界情况的处理口径。这部分和 Cursor Rules 有部分重叠，但这里更聚焦于这个 Skill 任务本身的特殊约束。

示例部分的价值在于“降低模型对抽象流程的解释成本”。一个真实的输入输出对，比三段流程描述都更能让模型模仿。这也是很多开源 Skill 做得不够好的地方，大家光顾着写干巴巴的规则，鲜少花时间打磨示例。

2.4 文件命名、目录结构与版本管理规范

Skills 的文件组织方式也有规范可循。标准的目录结构是：

text复制~/.cursor/skills/
├── code-reviewer/
│   ├── SKILL.md
│   └── templates/
│       └── review-template.md
├── react-refactorer/
│   ├── SKILL.md
│   └── examples/
│       └── before-and-after.md
└── academic-paper-polisher/
    ├── SKILL.md
    └── scripts/
        └── format-check.py

每个 Skill 一个独立文件夹，文件夹名字和 SKILL.md 中 name 字段保持一致。核心文件只能是 SKILL.md，配套文件放在同目录的子文件夹里，供 Skill 在运行时读取。这个结构最大的好处是可版本化和可分享——整个文件夹可以扔进 Git 仓库管理，也可以打包发给别人安装。

我强烈建议在 Skills 仓库的根目录放一个 README.md，写清楚每个 Skill 的用途、依赖、适用场景。这不仅是给你的团队看的，也是给未来的自己看的。我自己的 Skills 仓库里现在有十几个 Skill，如果没有 README，我根本不可能记得每个 Skill 当初为什么要写。

3. 从零手写一个 Skill：前端 React 代码审查 Skill 的完整过程

3.1 确定使用场景与描述，先想清楚“谁会因为什么触发它”

为了让你直观理解整个编写过程，我带你把我自己写的那个 react-code-reviewer Skill 完整走一遍。这个 Skill 是我日常用的最高频的一个，因为每次提交 PR 之前，我都要自己先审查一遍代码，而现在这件事交给 Cursor 的 Agent 来做，省下的时间非常可观。

首先是想清楚触发场景。我当时列出的使用场景是：

• 用户要求对 React 组件、自定义 Hook、前端工具函数进行代码审查；
• 用户准备提交 Pull Request，希望对变更代码做一次全面的质量检查；
• 用户发现某段前端代码有隐患，希望找出具体问题和改进方案；
• 用户希望检查 TypeScript 类型定义是否严谨，样式是否一致。

然后把这些场景翻译成 description。这个过程比较重要的一个技巧是“场景穷举再压缩”：你先不管语法，把所有能想到的触发情形全部写出来，再花五分钟把它们压缩成一段通顺的英文描述，关键词尽量全部保留。我最后写的 description 长这样：

yaml复制---
name: react-code-reviewer
description: Use this when the user requests a code review for React, TypeScript, JavaScript, frontend components, custom hooks, or utility functions. The skill performs a detailed analysis of code quality, potential bugs, performance issues, type safety problems, accessibility concerns, and provides actionable improvement suggestions. Especially useful before committing or merging frontend code.
---

这段描述我自己用了很久，自动触发率很稳定。关键在于它提到了“React 组件”“自定义 Hook”“工具函数”“代码质量”“potential bugs”“type safety”这些高密度触发词，几乎覆盖了一个前端工程师日常问代码审查时的各种表达。

3.2 把人工审查的 checklist 整理成可执行的工作流程

真正干活的是工作流程部分。我把自己平时做代码审查时会检查的东西全部写下来，然后按优先级排列。这个 Skill 的工作流程我写的是：

markdown复制## 工作流程

### 2.1 需求确认
- 确认用户需要审查的文件或范围，如果用户未指定，则检查当前分支相对于 main 分支变更的文件列表。
- 确认代码所属模块和技术栈，初步判断使用 React 旧版生命周期还是新版 Hooks。

### 2.2 代码通读与分析
- 逐个文件通读，按以下维度进行分析：
  1. 逻辑正确性：是否存在状态更新错误、闭包陷阱、事件处理失效等。
  2. 性能问题：是否存在不必要的重渲染、缺失 memo 或 useCallback、大列表未虚拟化。
  3. 类型安全：是否存在 any、类型断言滥用、接口定义不合理。
  4. 可维护性：命名是否清晰、组件是否过长、逻辑是否耦合。
  5. 可访问性（a11y）：语义化标签、键盘操作、focus 管理、aria 属性。
  6. 代码风格：格式是否符合项目规范，是否与周边代码风格一致。

### 2.3 生成审查报告
- 按严重程度分级输出问题清单：严重（可能导致线上故障）、中等（影响可维护性或潜在缺陷）、建议（代码风格与轻量优化）。
- 对每个问题，给出：问题位置（文件+行号）、问题描述、影响分析、修改建议、参考示例。
- 如果发现问题间的关联性，额外说明它们可能共同触发的故障场景。

这个流程的好处是它把“模糊的代码评审”变成了一条线性的流水线。模型照着这个流程走，出来的结果结构就相对稳定。我特别建议在流程里加入一个“需求确认”阶段——它让模型在动手之前先搞清楚范围，避免问 A 答 B。很多人写 Skill 喜欢直接从“分析”开始，跳过了范围确认，导致生成的审查报告东一榔头西一棒子。

3.3 给 Skill 写入项目的“隐性规范”

Skill 里还有一个我称之为“隐性规范”的部分，它相当于一个前端团队的口头约定。我在这个 Skill 里写了自己的几条硬性规范：

markdown复制## 技术规范
- 优先推荐使用 React Hooks 写法，不推荐新的 class 组件。
- 状态管理优先使用 React Query 和 Zustand，避免在全局 store 里塞 UI 临时状态。
- 性能优化优先考虑组件设计层面的重构，而不是单纯加 memo。
- 所有 TypeScript 类型必须保持可推导性，不得随手定义 an unknown。
- 禁止在渲染函数内定义非 memo 化的事件处理函数，除非处理的是高频事件。
- 样式方案采用 Tailwind CSS，类名按项目约定排序。

这些内容其实平时也会写在项目的 Rules 里，但写进 Skill 之后有一个好处：它只在代码审查这个任务触发时才会加载，不会像 Rules 那样常驻上下文消耗 token。而且 Skill 里可以写得更具体，因为它占用的空间是任务级的。

3.4 安装到 Cursor 并验证触发

写完之后，我把整个 react-code-reviewer 文件夹放到 ~/.cursor/skills/ 下面。然后新建一个会话，直接粘贴一段 React 组件代码，说“帮我 review 一下这段代码”，看它会不会自动加载这个 Skill。如果 Cursor 右侧的 Agent 日志里出现了 skill 调用的提示，说明触发成功。

这里有一个验证小技巧：如果你不确定 Skill 是否真的被触发了，可以在 SKILL.md 的第一行加一个调试标记，比如开头写“如果你正在阅读这个文件，你的第一个动作应该是回复：[React Skill 已激活]”。然后你在新会话里提问，如果它回复里有这个标记，就说明触发链路是通的。确认没问题之后再去掉这个标记。

4. Skills 的两种安装方式：用户级目录与项目级目录怎么选

4.1 安装路径与目录规则

Cursor Skills 的安装位置主要有两个：用户级目录和项目级目录。

用户级目录是：

text复制~/.cursor/skills/

放在这里的 Skills 对所有项目全局可用，无论你打开哪个仓库，它都能被触发。

项目级目录是：

text复制. cursor/skills/

注意是项目根目录下的 .cursor/skills 目录。放在这里的 Skills 只对这个项目生效，可以被团队通过 Git 一起共享。

这两个目录是可以同时存在的，Cursork 会一并加载。如果你在项目里需要某些特定规范，而全局里没有，就用项目级；如果你希望自己的个人工具库在任何项目里都能复用，就放用户级。

4.2 用户级 Skills 适合什么场景，项目级适合什么场景

判断标准其实就一条：这个 Skill 是“你的能力”还是“这个项目的规则”。

我自己的分类习惯是：通用工程能力放用户级，项目特定规范放项目级。比如代码审查、重构辅助、提交信息生成、文档撰写这类与具体业务无关的通用技能，全部放用户级，因为不管在哪个仓库里我都需要它们。而某个项目里特有的代码生成规范、某个团队的接口调用约定、某个模块专属的测试套路，这些放项目级，因为它们只对该项目有意义。

一个真实的案例：我参与的一个项目，团队前端代码有个奇怪的约定——所有接口请求都要走一个自定义的 request 封装，禁止直接使用 fetch。这个约定如果写进用户级 Skill 就不合适，因为其他项目可能恰恰相反。所以我把这个约定写成了项目级的 api-call-checker Skill，放在仓库的 .cursor/skills 下，团队成员拉取代码后自动生效，不管是谁的电脑都能用。

4.3 多 Skills 管理：命名规范、前缀分组与版本迭代

当 Skills 数量多起来之后，管理就变成了一件正经事。我目前的习惯是给 Skill 名加前缀进行分组，形成一种轻量的命名空间：

这样做的好处是，以后想更新某个 Skill 时，一眼就能在文件系统里定位到目标。而且前缀还能作为“触发辅助信号”——如果你在描述里反复提到 fe- 相关词汇，模型在匹配时也会把编码风格相近的 Skill 聚在一起，减少混淆。

版本迭代方面，我强烈建议每个 Skill 文件夹里单独放一个 CHANGELOG.md，每次修改后简单记录一下“哪一天，改了什么，为什么改”。这算不上什么高深技巧，但真的能救命。我在一次大更新后发现自己把重要流程写丢了一段，结果通过 CHANGELOG 直接回溯到了旧版本的写法。

4.4 把 Skill 分享给团队或社区时要注意的两个问题

Skills 的优点是可移植性好，但分享时有两个隐藏坑。

第一个坑是路径依赖。如果你在 SKILL.md 里写死了 /Users/yourname/projects/xxx/ 这种绝对路径，别人拿到之后根本无法使用。规范的写法是在文件里引用相对路径，或者在“依赖与工具”部分明确说明“这个 Skill 需要项目根目录下的 src/ 目录存在”。我见过很多开源 Skills 翻车就翻在这里，作者自己环境里跑得好好的，别人一装就报错。

第二个坑是隐私泄漏。你的 Skill 里可能包含项目内部约定、团队名称、内部 API 地址等敏感信息。分享之前，务必把整个文件夹从头到尾过一遍，把涉及公司、项目、内部服务的具体名称全部替换成通用示例。

5. 实际开发中的常见坑与排查思路：description、细粒度与上下文过载

5.1 坑一：description 写得太像百科，导致Skill永远不会被自动触发

这是我在社区里看到最多的失败案例。有人写了一个 Python 代码审查 Skill，description 是：

yaml复制description: Provides comprehensive code review for Python projects with a focus on best practices, security vulnerabilities, performance bottlenecks, design patterns, and code maintainability.

单看这句话没什么错，但它缺少“什么时候用”的触发信号。用户实际提问时会说“帮我看看这段代码有什么问题”“这块逻辑要不要优化”“这个函数写得太丑了，帮我改改”，这些表达和上面的 description 在语义上有距离，模型匹配时可能觉得“没有完全对上”。结果就是，Skill 装了等于没装。

正确的做法是把用户的自然表达直接写进 description。还是这个 Python 审查的例子，我会改成：

yaml复制description: Use this when the user asks to review Python code, check for bugs or potential security issues, improve code structure and performance, or when the user wants feedback on code quality before a merge. This skill works best with functions, classes, and scripts that are under active development.

这样模型在理解“帮我看看这段代码”“检查一下逻辑漏洞”时，就能在语义空间里找到更多重合点。

我自己的测试经验是：写完 description 后，找三个不同的人用完全不同的措辞提出同一个任务，看 Skill 是否能稳定触发。如果三次里有一次没触发，就继续往 description 里补充关键词。

5.2 坑二：步骤写得太死或太空，模型会变成“提线木偶”或“脱缰野马”

工作流程的细粒度是一个非常微妙的平衡问题。写得过分精细，比如“第一步：打开文件 a.tsx，第二步：在第 34 行找到 xxx，第三步：把 xxx 改成 yyy”，模型会像一个没有判断力的执行器，一旦遇到与描述不符的代码结构，整个流程就卡住了。写得过分宽泛，比如“请审查这段代码”，那模型就只能遵循它自己的本能，你的 Skill 等于白写了。

我的经验是，把流程定义在“动作目标 + 检查维度 + 输出要求”这个层级，而不是“具体到行号和变量名”的层级。比如“确认变更范围”是一个动作目标，“逐个文件按正确性、性能、类型安全、可维护性进行分析”是一个检查维度，“输出按严重级别分级并附带修改建议”是一个输出要求。这样的流程既给了模型清晰的框架，又保留了它的自主判断空间。

5.3 坑三：上下文加载过载，Skill 把整个项目都读进来了

Skill 运行时会按工作流程读取文件，如果流程里写了“读取整个项目的全部文件”这种指令，那么恭喜你，你的 Cursor 上下文窗口很快会被塞满，而且回答速度会慢到让人怀疑人生。

这个问题我有过惨痛教训。我第一次写代码审查 Skill 时，让模型“分析项目结构和所有源代码”，结果 Cursor 开始疯狂读取 node_modules 和 dist 目录，整个会话直接卡死。后来我把工作流程改为“只分析用户指定的文件；如果用户未指定，则检查当前分支相对主干分支变更的文件列表”，并且明确禁止“读取 node_modules、dist、build、.next 等目录”。这样既保住了审查质量，又控制了上下文体积。

另一个控制体积的办法是让 Skill 先输出简版结论，再让用户选择是否深入。比如审查 Skill 可以先输出一份 10 条左右的高优先级问题清单，然后询问“是否需要我逐条详细说明”。如果一次把 50 条问题全部展开，输出长度和 token 消耗都会非常可观。

5.4 如何判断 Skill 是否真的生效：日志确认法与行为确认法

除了我在前面提到的调试标记法之外，还有两种方式可以验证 Skill 是否生效。

第一种是日志确认法：在 Cursor 的 Agent 运行日志里，只要触发了 Skill，通常会有明确的引用记录，显示它加载了哪个 .cursor/skills 目录下的 SKILL.md 文件。如果你在日志里找不到这个记录，说明 Skill 没有被触发，大概率是 description 的匹配度出了问题。

第二种是行为确认法：故意在 Skill 里写一条“如果在执行第一步之前，请先输出一句固定的话”。比如在 Python 审查 Skill 里写“在开始审查前，请先回复：我将按照 Python 规范执行审查”，然后新开一个会话测试。如果模型真的输出了这句话，说明 Skill 被成功加载。这是在没有日志可看时的替代方案。

6. 让 Skills 真正成为你的“第二大脑”:从单个 Skill 到技能库的沉淀

6.1 写 Skill 的本身，就是一次知识萃取

我写了十几个 Skill 之后有一个很深的体会：写 Skill 的过程，其实是在逼自己把“会做一件事”变成“能解释清楚一件事”。 以前我审查代码靠直觉，知道哪些地方容易出问题，但要我系统地说出来，还真说不完整。直到我开始写 Skill，我才被迫把自己脑子的那些隐性知识一条条列出来、分类、排序、验证。这个动作做完之后，我发现自己对“代码审查”这件事的理解比之前更清晰了。

所以我的建议是，不要只把 Skills 当成提升 Cursor 效率的工具，它同时也是你个人知识管理的容器。每当你发现自己“凭感觉就能做但说不清步骤”的事情，就应该动笔把它写成 Skill。你写完之后可能会发现，原来这件事的流程里有几个环节是你自己都没意识到的。

6.2 给 Skill 做维护，和给代码库做重构是一样的

Skills 不是写一次就永久使用的，它需要迭代维护。我给自己定了一个规矩：每次在使用某个 Skill 的过程中，如果发现它生成的输出不够好，就立刻在 Skill 文件里做个标记，等手头的活干完再统一修订。这个过程和代码重构是一样的——先发现问题，再改进设计。

举例来说，我的代码审查 Skill 早期版本没有考虑“性能问题”这个维度，导致它经常忽略一些明显的前端渲染浪费。有一次我给一个列表组件做审查，它竟然只字未提这个组件的重复渲染问题。后来我修改了 Skill，在“分析”阶段明确加入“检查重渲染触发条件”的步骤。从那以后，这个 Skill 的输出质量就有了一次明显提升。

6.3 跨工具复用：同一个 SKILL.md 可以带到其他 AI 编程工具里

最后分享一个我在实践中发现的实用经验：SKILL.md 这个格式的通用性其实比很多人想象的要好。Cursor 的 Skills 机制和 Anthropic Claude 系工具的 Skills 机制，在目录结构和文件命名上高度相似——都是 .cursor/skills 或 .claude/skills 目录下的独立文件夹，都要求有一个 SKILL.md 作为入口，frontmatter 结构也基本通用。这意味着你在 Cursor 里写好的 Skill，绝大多数可以直接拷到其他支持 SKILL.md 的编程工具里使用，只需要改一下目录路径。

我自己现在维护 Skills 的方式是：在 Git 仓库里建一个 skills/ 目录，把所有 Skill 按“前缀-技能名”的规范组织好，然后在 Cursor 的 ~/.cursor/skills 里建符号链接指向对应的目录。这样我更新 Skill 时只改仓库里的一份，本地环境自动同步，还能享受 Git 的版本管理。如果有需要，我还能以最短的路径把它们发布到社区让其他人参考。回头看看，这套流程真正跑通以后，我在 Cursor 里的工作效率比刚开始用的时候提升了不止一个量级，而这一切的起点，不过是在一个空文件夹里写下了第一份 SKILL.md。