Cursor Skills 和 Rules 怎么分
Cursor Rules 是持续约束常进上下文，Skills 是多步流程按需加载。附迁移命令边界与和 MCP 的分工对照。
你在 Cursor 里既写了 .cursor/rules 里的约束，又装了几个 Skill，Agent 还是该踩的坑照踩。搞清 cursor skills 和 rules 区别，先看加载时机：Rules 像常驻宪法，Skills 像按需调用的操作手册。
Rules 管边界，Skills 管流程
Cursor 官方文档 把 Rules 定义成对 Agent 的持续约束，通常会在相关对话里进入上下文。项目级 Rules 放在 .cursor/rules/*.mdc，User Rules 在 Settings 里配，Team Rules 走控制台。它们的共同点是：短、硬、要一直生效。
Skills 是另一套文件：一个目录里放 SKILL.md，写多步流程、检查清单、可执行脚本。触发方式有两种，你手动敲 /skill名，或 Agent 根据描述匹配后按需加载。正文只在被用到时才全量进入上下文，没触发前只占一行描述。
一句话记：alwaysApply: true 的全局禁令写 Rules；第三次粘贴的同一段发版检查写 Skills。这和 Skills 和 MCP 的分工 无关，本文只谈 Cursor 产品内的 Rules 与 Skills，MCP 是连接外部系统的协议层。
体量与上下文代价
Rules 设计上要短。官方建议全局只留一两条 alwaysApply: true 的硬约束，栈相关规则挂 globs，偶发流程靠 @ 手动引用。每条 always 规则都常驻占 token，堆多了模型选择性遵守的概率会上升，和 Cursor Rules 不生效排查 里「三层症状」说的是同一类预算问题。
Skills 可以长得多：步骤、示例、脚本、reference 文件都能塞进目录，但触发前只暴露 frontmatter 里的描述。适合把「先 lint、再跑测试、退出码非零别提交」这类多步流程从 CLAUDE.md 或 Rules 里搬出来，避免每次对话开头塞一整页规范。
| 维度 | Rules | Skills |
|---|---|---|
| 典型长度 | 短，几条硬约束 | 长，多步流程与脚本 |
| 加载时机 | 按类型常驻或匹配 glob | 按需 / 或 Agent 匹配 |
| 适合内容 | 代码风格、禁区、项目身份 | 发版清单、Review 维度、重复流程 |
/migrate-to-skills 能迁什么
Cursor 提供 /migrate-to-skills 命令，把部分旧配置搬进 Skills 体系。迁移范围有硬边界，搞错会以为「迁完了」其实 half 还在 Rules 里。
只迁这两类：alwaysApply: false 且没有 globs 的规则，以及旧的 slash commands。带 alwaysApply: true 的规则不会动，写了 globs 的路径匹配规则也不会动。原因很简单：这两类本来就要按会话或文件范围自动注入，它们仍然是 Rules 的职责，不是 Skill。
迁之前先在 Cursor Customize 页面 里清点现有 Rules 列表，确认每条 frontmatter 的 alwaysApply 和 globs 字段，再决定哪些该手动改写成 Skill、哪些必须留在 Rules。
日常配置怎么排
可用分配法：.cursor/rules/ 里只留一两条 always 全局禁令（比如「禁止改 migrations 目录」「回复用中文」），语言或目录相关的规则挂 glob，其余流程类全部做成 Skills。
新建 Skill 时在 Cursor Settings → Rules, Commands 区域管理，或直接在项目 .cursor/skills/ 下建目录。描述写清楚「什么时候该用」，模型才能在清单预算内正确匹配。手动才该触发的流程，在 Skill frontmatter 里限制自动调用，避免描述占常驻上下文。
Rules 和 Skills 同时存在时不打架：Rules 定「不能做什么」，Skills 定「遇到某场景按什么顺序做」。Agent 先受 Rules 约束，再在允许范围内按 Skill 执行步骤。
从 slash command 迁到 Skill 的实操
旧版 Cursor 里有些团队习惯用 slash command 存片段化指令。/migrate-to-skills 会把这类命令和符合条件的 Rules 转成 Skill 目录结构。迁完后在 Settings → Rules, Commands 里应能看到新 Skill，旧 slash 若仍残留，手动删避免双入口。
迁移后建议抽三条对话做回归：一条纯聊天、一条改代码、一条跑终端。看 always 规则是否仍自动注入、Skill 是否只在相关场景被匹配。若发现某条 always 规则被误迁，说明它 frontmatter 里 alwaysApply 曾经是 false，迁完要改回 true 并放回 .cursor/rules/。
User Rules 与 Team Rules 不受 migrate 影响，它们本来就在云端或账号层，和项目 Skill 目录是两套存储。多人协作时，Team Rules 继续管组织级禁令，项目 Skill 管仓库特有流程，别指望 migrate 一次清掉所有历史配置。
和 MCP、Plugins 别混
Rules 与 Skills 都在 Cursor 本地配置层，不涉及外部连接。要读 Issue 状态、查监控、写 Notion，那是 MCP 或 Plugins 的事。Cursor 近版本也支持 Agent Plugins，但插件管的是能力接入，不是替代 Rules 的常驻约束。
选型时先问「这是边界还是流程还是连接」。边界留 Rules，流程写 Skills，连接接 MCP。三层各管一层，配置文件才不会互相挤占上下文。
若你刚从 Claude Code 迁过来，先别急着把全套 SKILL.md 丢进 .cursor/skills/：先确认哪些是「永远生效的禁令」——那些应改写成 Rules；剩下流程类再按 Skill 放。先分层，再谈互通，比「全盘复制」更省上下文。
常见误配与修正
把长流程写进 alwaysApply: true 的 Rule 是最常见的误配。表现是对话还没问啥，上下文已经塞满发版清单，模型却仍在关键步骤上跳步。修正：剪成两条 always 禁令，流程迁到 Skill，用描述触发。
反向误配是把「禁止 force push main」写进 Skill。Skill 可能被漏触发，禁令应在 Rules 里 always 或 glob。另一个误配是用 Skill 代替 MCP 去「读 Jira 状态」，Skill 只能教步骤，拿不到 live ticket。
和 Cursor Project Rules 排查文 对照：Rules 不生效时先查加载层，Skills 不触发时查描述是否在清单里、是否被 disable-model-invocation 关掉。两类问题排查路径不同，别混为一谈。