在 Cursor 里写代码，你经常会听到 Agent、Skill、Rule、MCP……它们听起来像一堆营销词，其实各自管一层不同的能力。搞清楚边界，才能知道「该装什么、该说什么话、什么时候该上规范而不是瞎聊」。
本文是一份概念地图 + 常用用法，基于我在本机装过的主流开源 Skill（Superpowers、mattpocock、Vercel、Anthropic、OpenSpec 等）整理。若你更关心「从零写一个 Agent 循环」，可以先看 构建你的第一个 AI Agent。
一张图看懂层级
你（人）
│ 自然语言 / 斜杠命令 / @引用
▼
Cursor Agent（会话里的执行者）
├── Rules（长期规矩，总在）
├── Skills（按任务加载的程序性知识）
├── Commands（斜杠触发的固定流程）
├── MCP / 工具（读飞书、调浏览器、查库……）
└── Subagents（并行/专职的子代理）
│
▼
改你的仓库、跑命令、写文档一句话记忆：
| 概念 | 它是什么 | 类比 |
|---|---|---|
| Agent | 能规划、调用工具、多步改代码的 AI 会话 | 带工具箱的工程师 |
| Skill | 一份 SKILL.md：教 Agent「这类任务怎么做」 |
岗位 SOP / 操作手册 |
| Rule | 项目或全局的硬约束（风格、禁止事项） | 公司制度 |
| Command | /xxx 触发的固定剧本 |
快捷宏 |
| MCP | 外部系统的标准化接口 | USB 外设协议 |
| Subagent | Agent 派出去做独立子任务的小弟 | 并行外包 |
| OpenSpec | 先写规格再写代码的仓库级工作流 | 开工前的设计评审 |
Agent：不是聊天框，是可执行循环
广义上的 AI Agent，是模型在循环里思考 → 调用工具 → 观察结果 → 再思考，直到任务完成（见 ReAct）。Cursor 里的 Agent 模式，就是把这个循环接到了你的 IDE：它可以读文件、搜代码、跑终端、改多文件、开子代理。
和「只补全一行」的区别：
- Chat / Ask：偏问答，改动受限或只读。
- Agent：默认假设你要它把事做完（实现、修 bug、部署），会主动用工具。
你不需要每次解释「怎么用 git / 怎么读 linter」——这些是运行时能力。你需要解释的是业务意图与约束；若某类任务有固定方法论，就用 Skill 来固化。
Skill：可安装的程序性知识
Skill 是开放格式（常见为目录里的 SKILL.md）：里面写何时触发、必须遵守的步骤、反模式、输出物。Agent 在匹配到场景时会加载它，相当于临时给模型一份更厚的 system 指令。
它存在哪
Cursor 会从多处发现 Skill（优先级与具体版本以官方文档为准）：
| 位置 | 典型用途 |
|---|---|
~/.agents/skills/ |
全局业务 Skill（npx skills add … --global 常装到这里） |
~/.cursor/skills/ |
个人全局（例如 GSAP 套件） |
~/.cursor/skills-cursor/ |
Cursor 内置（create-skill、canvas 等） |
项目 .cursor/skills/ |
仅本仓库（OpenSpec 生成的 openspec-*） |
怎么装
主流发现站是 skills.sh。安装示例：
# 装某一个
npx skills@latest add vercel-labs/skills --skill find-skills --global --agent cursor -y
# 装一整包（如 Superpowers 14 个）
npx skills@latest add obra/superpowers --global --agent cursor -y装完后新开一个 Agent 会话，索引才会更完整。
怎么用（比「装了」更重要）
Skill 多数靠自然语言触发，不是菜单按钮。你要说清楚意图，最好点名 skill 或描述它的场景：
# 弱（Agent 可能直接开写）
帮我加一个登录页。
# 强（对齐 Skill）
先用 brainstorming / grill-me 对齐需求，再 writing-plans 出计划，
确认后再按 TDD 实现登录页。Agent 是否「自动」调用，取决于 skill 描述里的触发条件 + 当前上下文。不可靠时，显式点名最稳。
Rule、Command、MCP、Subagent：别和 Skill 搅在一起
Rule（规则）
写在 .cursor/rules 或用户规则里，例如「提交信息用中文」「不要改 nginx 配置」。它是长期默认约束，不按任务装卸。适合团队规范；不适合写完整 TDD 流程（那是 Skill 的活）。
Command（斜杠命令）
例如 OpenSpec 的 /opsx:propose、/opsx:apply。本质是预写好的提示词入口，一打就进入固定剧本。适合「高频、步骤稳定」的流程；Skill 更适合「Agent 自己判断该不该用」。
MCP（Model Context Protocol）
把飞书、浏览器、数据库等做成标准工具，Agent 通过 MCP 调外部世界。Skill 教「怎么做」；MCP 提供「能碰到什么」。例如飞书 lark-* 技能往往配合飞书 CLI/MCP 才有用。
Subagent（子代理）
主 Agent 把可并行、上下文独立的活派出去（例如同时查两个无关模块）。对应 Skill 如 dispatching-parallel-agents、subagent-driven-development。适合大任务拆分，不适合共享同一份脏状态的小改动。
OpenSpec：仓库级的「先规格后代码」
OpenSpec 不是 skills.sh 上的一个全局包，而是：
- 安装 CLI：
npm i -g @fission-ai/openspec - 在项目里：
openspec init --tools cursor --profile core
它会在仓库生成 openspec/、.cursor/skills/openspec-*、.cursor/commands/opsx-*。
推荐循环：
/opsx:explore → 先想清楚，不急着落地
/opsx:propose → 产出 proposal / tasks / spec delta
（人审）
/opsx:apply → 按 tasks 实现
/opsx:archive → 归档这次 change和 Superpowers 的关系：OpenSpec 管**「做什么、验收标准写在哪」；Superpowers 管「怎么执行（TDD、调试、评审）」**。可以叠用，不必二选一。
常用 Skill 怎么用（按场景）
下面按真实干活顺序给「触发话术」。名字以你本机已装的为准。
1. 开干前：对齐问题
| Skill | 你怎么说 |
|---|---|
brainstorming |
「先 brainstorm：我们要做 X，先对齐目标和边界。」 |
grill-me / grill-with-docs |
「先 grill 我，把需求拷问清楚再写代码。」 |
writing-plans |
「写一份可执行的实现计划，分步、可验收。」 |
to-spec / to-tickets |
「把这段需求收成 spec，再拆成 tickets。」 |
2. 实现中：少返工
| Skill | 你怎么说 |
|---|---|
tdd / test-driven-development |
「按 TDD：先写失败测试，再最小实现。」 |
vercel-react-best-practices |
「按 Vercel React 最佳实践改这个组件。」 |
vercel-composition-patterns |
「用组合模式重构，避免一堆 boolean props。」 |
shadcn |
「用 shadcn 组件搭这个表单，别手搓一套。」 |
frontend-design / impeccable |
「用 frontend-design 做视觉；再用 impeccable critique 打磨。」 |
3. 出问题时：结构化排障
| Skill | 你怎么说 |
|---|---|
systematic-debugging |
「用 systematic-debugging，先复现再假设，不要瞎改。」 |
diagnosing-bugs |
「诊断这个回归：现象、范围、最近 diff。」 |
agent-browser |
「用 agent-browser 打开页面，点一遍登录流程并记录失败步骤。」 |
4. 收尾：可合并、可验证
| Skill | 你怎么说 |
|---|---|
verification-before-completion |
「声称完成前先跑验证清单。」 |
requesting-code-review |
「按 code-review skill 自审一遍再让我看。」 |
finishing-a-development-branch |
「功能做完了，帮我收尾：测通、整理提交、准备 PR。」 |
handoff |
「写一份 handoff，方便下个会话接着干。」 |
5. 增长与内容（站点向）
| Skill | 你怎么说 |
|---|---|
seo-audit / ai-seo |
「对 cillian.website/ai 做 SEO audit。」 |
content-strategy / copywriting |
「给下一季 AI 博客定 content strategy，并改首页文案。」 |
6. 元能力：继续发现 Skill
用 find-skills 帮我找：适合 Prisma + Express 鉴权的 skill。或自己搜：
npx skills find prisma一条可复用的工作流配方
面对「新功能」时，我现在习惯这样开场（可直接复制改）：
目标：在 self-monitor-dashboard 增加「导出周报 CSV」。
流程：
1. grill-me：先问我缺什么信息
2. /opsx:propose（若项目已 openspec init）：落规格与 tasks
3. writing-plans：给出实现步骤
4. 按 TDD 实现；React 部分遵循 vercel-react-best-practices
5. verification-before-completion：列验证命令并执行
6. handoff：留下会话交接摘要面对「线上坏了」：
用 systematic-debugging：
- 先稳定复现（必要时 agent-browser）
- 再列假设并逐条证伪
- 最后最小修复 + 回归验证
不要先大范围重构。常见误区
-
Skill 装越多越好
描述冲突时 Agent 会犹豫或乱用。精选装、按领域分批，比整仓灌 Azure/视频套件更有效。 -
以为装了就会自动变强
不说场景、不点名，模型仍可能走默认「直接开写」。关键句式是「先……再……」。 -
把 Rule 写成百科全书
Rule 宜短、硬、稳定；长流程放进 Skill 或 OpenSpec。 -
OpenSpec 与 Superpowers 互斥
不互斥：一个管规格资产，一个管执行方法论。 -
忽略「新开会话」
刚装的 Skill / 斜杠命令，经常要新开 Agent 或重启 IDE 才齐。
小结
- Agent = 能用工具把事做完的执行者。
- Skill = 可安装、可触发的 SOP（
SKILL.md）。 - Rule / Command / MCP / Subagent = 规矩、宏、外设、并行小弟。
- OpenSpec = 把「同意做什么」写进仓库，再让 Agent 按 tasks 落地。
真正提升效率的，不是多记住几个名词，而是形成固定开场白：先对齐 → 再规格/计划 → 再实现 → 再验证 → 再交接。把这句话变成你和 Cursor 的默认协议，比再装 20 个冷门 Skill 更有用。
延伸阅读
- skills.sh — Skill 目录与安装量排行
- obra/superpowers — 方法论技能包
- Fission-AI/OpenSpec — Spec-Driven 工作流
- 本站：构建你的第一个 AI Agent · 从 Prompt 到评测