Cursor四件套详解：Rules/Skills/Commands/subAgents边界与组合实战

在我用Cursor写代码的第三个月我终于被这四个词搞崩溃了。起因很简单我看到一个帖子说“给Cursor配上skill之后代码审查效率翻倍”然后又看到一个教程说“写好rulesAI才会真正听你的话”。我把两者都配置好之后发现Chat里输入内容时又冒出个Commands再一翻更新日志发现还有subAgents。那一刻我盯着设置面板问自己这些东西到底各管哪一摊如果我把规则写进了Skill把Skill做成了Command把Command塞给了subAgents会发生什么答案是我全都试过。结果就是一连串“奇怪问题”规则没生效、技能唤不出来、指令重复执行、子代理跟个普通Chat一样……排查一圈之后我才意识到这四个概念表面长得很像本质上却是完全不同的四套机制。这篇文章不聊Cursor的安装也不聊模型配置我专门把这四兄弟的边界拆清楚并附上我自己梳理出来的用法组合和踩坑记录。1. 先把四个词放到正确的位置上很多人的第一反应是Rules、Skills、Commands、subAgents不都是“教AI做事的吗”对它们都能影响AI的行为但影响的方式、生效的时机、作用的对象差别极大。我用一句大白话概括Rules是给AI立的规矩Skills是给AI看的操作手册Commands是你替自己准备的快捷输入模板subAgents则是你雇来的专职员工。这四者不是同一层的东西硬放在一起比“谁更强”没有意义你得先看看它们分别在哪个环节起作用。1.1 Rules常驻上下文的“行为准则”Rules最像公司制度。你入职一家公司不需要每次做事前都翻一遍员工手册但手册里的内容会一直在后台约束你上班不能迟到、代码必须过lint、文档必须写注释。在Cursor里Rules就是这样的存在。它写在项目根目录的.cursor/rules下或者通过设置面板里的Rules入口维护。规则文件可以采用Markdown格式通常是.mdc后缀通过文件头部的description和globs字段告诉AI“这条规则在什么条件下要加载”。举个例子我想让Cursor在处理所有TypeScript文件时自动遵守编码规范就可以写一个.mdc文件--- description: 后端TypeScript代码必须遵守的规范 globs: src/**/*.ts --- - 所有函数必须显式声明返回值类型 - 禁止使用 any如需绕过必须注释说明原因 - 错误处理统一返回 ResultT, Error 对象禁止直接抛出字符串 - 新增公共API必须同步补充JSDoc注释注意这行globs: src/**/*.ts。它意味着只要用户打开、编辑、引用src目录下的.ts文件这条规则就会自动被带进AI的上下文。它不需要你“调用”什么也不需要你每次手动提醒只要你触碰了对应的文件规则就跟着走。这就是Rules的核心特征——被动且常驻。它不负责执行某个具体功能它负责给AI的所有行为划定边界。1.2 Skills可以随时取用的“技能包”Skills解决的是另一个问题有些任务有固定套路比如“代码审查”“生成单元测试”“重构某段逻辑”AI如果没经过指导做出来的东西往往不专业。Skill的思想就是把这些套路写成一份操作手册让AI在用户提出相关需求时能“照着手册做”。Skills以文件夹为单位通常是一个目录如.cursor/skills/code-review/里面有一个核心的SKILL.md文件。这个文件的结构和Rules有点像也有name和description但对触发方式的描述更讲究。因为Skill不是常驻的它靠description让AI判断“什么时候该动用这个技能”。比如我写过一个代码审查技能--- name: code-review description: 当用户要求对代码进行审查、检查代码质量、发现潜在Bug时使用。适用于单文件或多文件评审。 --- 执行代码审查时请严格按以下步骤操作 1. 先通读代码弄清函数职责和调用链不要边看边改。 2. 按“正确性、性能、可读性、可维护性”四个维度输出问题清单。 3. 每个问题标注严重级别P0/P1/P2P0为会导致崩溃或数据丢失的问题。 4. 对每个问题给出最小改动的修复示例禁止一次性重写整个文件。 5. 最后输出一段总结说明当前代码的整体健康度。关键在于触发方式。当我在Chat里输入“帮我看看这段代码有什么问题”时Cursor会先识别意图发现这符合code-review技能的description描述于是自动把技能中的步骤注入当前会话。这个过程不需要我输入“使用技能”三个字它是AI基于描述主动匹配半主动式加载。但我得说句实话技能描述写得好不好直接决定了这个机制好不好用。描述太笼统AI可能误触发描述太详细AI可能反而抓不住关键词。这个话题后面单独展开这里先记住定位——Skills是“做具体事的操作手册”。1.3 Commands属于你的“快捷指令宏”Commands这三个里面最好理解。它就是一个可复用prompt模板本质上是帮你省去每次敲一大段指令的麻烦。你可以把它理解为输入法里的自定义短语或者Excel里的宏你存好一段内容想用时一键调出来。Cursor里可以通过命令面板或者直接在输入框输入/唤起命令列表。比如我自定义了一个/chinese-review命令内容是请用中文对当前选中的代码进行review要求 - 先概括这段代码的职责 - 再讲存在的问题 - 最后给出修改建议这个命令本身没有智能它不会像Rules一样自动匹配文件也不会像Skill一样被AI按意图召唤。你只有主动调用它它才存在。它是全手动的效率工具作用仅限于把输入那段话变成一次按键操作。很多人犯的错是把自己常用的Commands一股脑写进了Rules里导致每次对话都要白白占一堆上下文。这个坑我后面细说。1.4 subAgents可以指定角色的“专职员工”subAgents是这四个里最“重”的一个。它相当于你在Cursor里创建一个带专属身份的对话代理给它一个名字、一段角色设定、一整套工作流程然后在需要时切换到它让它以一个独立的身份来处理任务。它更像“团队里的一名同事”而不是一段提示词。比如我建过一个“接口设计评审员”。它的设定是只关注API设计的合理性包括RESTful风格、参数校验、状态码语义、兼容性等。我在写新的接口时切换到这个子代理它会以一个专业评审者的视角挑毛病而不是像主Agent那样更关注整体业务逻辑。这里有一个重要区分subAgents自带上下文隔离。它和主对话处于不同的上下文窗口你给它一个任务它会在自己的“小世界”里干活不会把主对话的历史记录全带进来。这在处理大型任务时能显著节省token也能让AI专注于某个具体角色。为了更直观我把四者的关键差异整理成一张表概念一句话定位生效方式类比Rules行为准则划定边界被动常驻命中即加载公司制度Skills执行某项任务的固定套路半自动按描述匹配意图操作手册Commands可复用的输入模板全手动主动调用快捷键宏subAgents带独立身份和上下文的代理显式切换任务分发专职员工2. 触发逻辑才是四者的真正分水岭我之所以花了很多时间才搞明白这四个概念是因为我一开始总盯着“它们都能让AI做某件事”这个共同点而没有注意到它们各自是怎么被唤醒的。搞清楚触发逻辑比背下各自的功能列表重要得多。2.1 静态匹配与动态注入把四个概念放在一起看本质区别在于“谁来决定什么时候生效”。Rules是由文件路径决定的。AI在处理某个文件时通过globs做静态匹配匹配到了就把规则注入上下文。这中间没有“AI思考”的环节——只要你打开的文件命中了src/**/*.ts规则就是铁打的哪怕你觉得这次对话根本用不到它它也会在。所以Rules需要精简你可以把Rules理解成一个“环境变量”它的存在是持续的。Skills的匹配则是由意图决定的。AI读取对话内容判断“用户是不是想让我做这件事”然后通过description与技能库做语义匹配匹配到就加载该技能匹配不到就不用。它是动态的需要AI“听懂”你的意思。这带来一个天然问题如果用户的表达太模糊技能就匹配不上表现为“技能不生效”。这也是我在社区里看到对Skills抱怨最多的原因——不是技能没配好而是你和AI之间没有一个明确的“信号”。Commands则是三者中最直白的。它不依赖文件路径也不依赖AI理解意图。你按下快捷键它就是执行不存在“漏匹配”的情况。所以Commands最适合用在那些高频、固定、必须生效的场景比如“解释这段代码”“总结本周工作日志”“生成commit message”。它胜在确定性。subAgents比较特殊它的触发是你主动选择一个人格。这相当于你从“和一个全才聊天”变成“和一个专才聊天”。选定之后上下文就切过去了所有后续任务都在这个角色设定之下进行。它跟常规Chat最大的不同是任务边界清晰且带自己的专属指令。2.2 为什么“谁来决定触发”如此重要因为触发方式决定了你的维护成本。Rules一旦写得多而乱整个项目的AI上下文都会变臃肿轻则浪费token重则AI被互相矛盾的规则搞糊涂。Skills一旦description写得不到位就可能出现“AI偶尔调用、偶尔不调用”的玄学状态这种不稳定对工程化的流程是致命的。Commands没有调度问题但你如果存了几百条命令自己都不记得有哪些那它也就失去了快捷的意义。subAgents如果设定不严谨它就会退化成普通Chat徒增管理成本。我常用的一个判断标准是如果希望AI“永远遵守”放在Rules里如果希望AI“遇到同类型任务时按标准流程做”放在Skills里如果只是希望“我一键输入一大段常用话术”放在Commands里如果希望“让不同角色专注解决不同问题”拆成多个subAgents。2.3 一个典型任务的四视角演示我用一个真实场景来演示四者的差异——任务是“把这段代码改成异步版本”。如果只配置了RulesAI在改代码时会遵循我的规则比如“改动前先理清调用关系”“禁止破坏原有错误处理逻辑”但它不会有什么特别的“异步改造手法”它只是按一个合格程序员的通识去做。如果我在项目里加了“async-refactor”这个SkillAI一旦识别出我的需求是“改造异步”就会自动装载技能先分析当前函数的调用栈再检查调用方是否需要同步调整然后逐步修改最后跑一遍类型检查。整个流程被标准化了质量更可控。如果我用一个Command比如/async-refactor那么我调用它时系统只是把一段写好的指令发送给AI让AI按指令做。这里没有技能步骤的约束AI理解多少理解多少效果取决于这个指令本身写得有多仔细。如果我用subAgents我会切换到“异步重构专员”这个身份然后告诉它“当前项目下面这几个文件需要做异步改造”。这个专员会按照我预先给它配置的严谨流程去执行并且只关心这个任务不带入之前闲聊的上下文。所以你看四者可以做完同一件事但稳定性和可预期性完全不同。如果你是靠Cursor混饭吃的开发者想让输出质量稳定Skills和subAgents才是主力Rules做环境约束Commands做效率补充。3. 组合使用的实战方案一份配置四层分工搞清楚了边界真正有价值的是怎么让它们协同工作。我在实际项目中总结出一套“四层配置法”以一个小型的“Python API接口评审文档生成”场景为例完整走一遍。3.1 第一层用Rules设定项目底线我在项目根目录的.cursor/rules下建了一个项目规范.mdc内容不长全部是禁止性和强制性要求--- description: 项目全局开发规范 globs: **/*.py alwaysApply: true --- - 新增接口必须声明在 api/ 目录下的Blueprint中禁止在入口文件堆路由 - 所有请求参数必须通过Pydantic模型校验 - 对外返回的JSON必须使用统一格式{code: 0, msg: ok, data: {}} - 如果你不确定一段代码的归属模块先询问用户禁止自行猜测注意这里有个alwaysApply: true字段它的意思是只要项目内的Python文件被处理不管具体是哪个文件这条规则都强制生效。这适合放那种“必须绝对遵守”的项目级铁律。Rules层要尽量克制。我见过有人把上百条规则塞进Rules结果AI在长对话后半段开始忽略部分规则因为上下文被撑爆了。我的经验是Rules只放“不遵守就会出大问题”的硬性约束理想情况控制在十句话以内。3.2 第二层用Skills沉淀标准流程接下来建立一个“接口评审”技能这是整个组合里的核心。目录结构如下.cursor/skills/api-review/ ├── SKILL.md └── templates/ └── review-report.mdSKILL.md这样写--- name: api-review description: 当用户要求评审接口设计、检查OpenAPI文档、验证接口参数校验逻辑时使用。适合新接口开发完成后的自查阶段。 --- 1. 先定位当前项目所有由该Blueprint注册的路由。 2. 逐一检查每个路由 - HTTP方法选择是否合理POST是否被误用来做查询 - 参数是否经过Pydantic校验是否存在直接使用request.json取值的情况 - 返回格式是否满足统一封装结构 - 是否缺少必要的错误状态码捕获 3. 将问题按“设计问题/实现问题/文档问题”分类输出。 4. 输出审查报告模板见文件templates/review-report.md这套技能被AI通过语义匹配自动触发。比如我在Chat里说“我把新接口写完了你帮我检查下”它就会主动执行上面四个步骤。但如果我说的是“帮我改个Bug”这个技能就不会被调起。把反复要用到的检查流程沉淀到SKILL.md里是我觉得最值得培养的使用习惯。它相当于把“我知道该怎么做”移交给AI让AI每次执行都稳定在一个水平线上。你可以把团队里最资深的评审者的口头检查清单拿出来转写成Skill描述效果立竿见影。3.3 第三层用Commands做快速入口Commands在这套体系里的角色比较“轻”它负责把一些常用操作变成固定入口。我创建了下面几个/review-this内容为“请使用 api-review 技能审查当前打开的文件重点检查参数校验和返回格式输出审查报告”。/gen-doc内容为“基于当前文件中的Blueprint路由生成OpenAPI文档片段并按项目规范输出”。/fix-style内容为“修复当前文件中的代码风格问题仅做格式化不改变行为”。它们的价值在于显式地控制触发。哪怕AI没能在对话中自动识别出你想调用某个技能通过命令入口也能强制指定。这对那些“语义上容易被误判”的场景特别有用。这里有一个细节Commands本身不用写太长因为长逻辑已经被放进了Skill里Command只需要做“指名道姓”的调用即可。3.4 第四层用subAgents做角色分工项目场景变大之后主对话的上下文会越拖越长这时候我会把任务按角色拆给不同的subAgents。比如在当前项目里我维护了三个子代理名角色定位主要负责接口评审官专注于API设计与安全审查新接口的自查与返工文档助手专注于技术文档撰写生成OpenAPI文档、README、接口变更日志性能顾问专注于慢查询与瓶颈排查分析N1查询、索引失效、响应时间瓶颈一个比较关键的点subAgents并不是简单的“换个人设”而是把你对某个角色的全部要求都预先配置好包括工作流程、输出格式、审慎检查清单。这样你切换过去时它的行为是稳定且可预期的。比如“接口评审官”的system提示词里有一条硬性要求“输出所有问题前必须先检查接口的鉴权逻辑禁止在未确认鉴权的情况下通过评审。”这个约束如果你放在主对话里可能因为上下文太长而失效但放在子代理里它就是独立的职责几乎不会被其他话题稀释。3.5 组合起来看整体工作流实际操作时我的流程是这个样子的新接口写完我在Chat里输入/review-this。这个Command会强制调起“接口评审官”这个子代理并让它按api-review技能的步骤执行。子代理审查时项目里的Rules会同时生效确保它输出的修改建议符合统一封装规范。审查通过后我调用/gen-doc让“文档助手”生成OpenAPI片段。最后如果涉及慢查询我再切换到“性能顾问”做专项排查。四个组件各司其职Rules保证底线Skills保证流程Commands保证触发subAgents保证分工。单独拎出任何一个都能工作但组合起来才能应对真正复杂的项目。4. 容易踩的坑我栽过的四类跟斗工具越用越深踩的坑也跟着变多。下面这几个问题我都在真实项目中遇到过这里还原一下排查过程给后来人提个醒。4.1 为什么Rules有时候“不生效”我先说现象我在Rules里写了一条“所有Python文件必须使用类型注解”然后让AI生成一段新代码它确实照做了。但过了一会儿在同一个对话里我让它修改另一个文件时它又写出了无注解的代码。我一度认为Rules失效了。排查之后发现问题出在globs的匹配范围。我最初写的是globs: src/**/*.py这只会命中src目录下的文件。当我在项目根目录新建临时脚本的时候该规则根本不覆盖。后来我改成globs: **/*.py问题就消失了。另一个原因是上下文溢出。当对话历史非常长时旧的Rules内容可能被AI从上下文中“挤出”。这属于大模型机制的固有限制不是Cursor的Bug。应对方法很简单把最关键的规则放在alwaysApply: true的规则文件里并且尽量精简不要在Rules里堆砌无关的废话。4.2 为什么Skill“叫不出来”“我叫AI用技能但它好像完全没听到。”这也是高频问题。排查路径是这样的先看技能文件夹里SKILL.md的description。如果你的description写得比较虚比如“这是一个帮助用户的技能”AI就没法把用户的实际请求和这个技能关联起来。description里必须包含“什么时候用”和“任务关键词”。比如我现在的写法是“当用户要求评审接口设计、检查OpenAPI文档、验证接口参数校验逻辑时使用”这样AI才能精准匹配。还有一个我踩过的坑技能名里带空格或特殊符号。早期我建过一个技能叫code-review-v2因为文件夹路径里带了-倒没出问题但团队里另一个同事命名用了空格结果始终无法正常调用。我的建议是技能名统一使用小写字母和连字符文件夹名保持一致不要干“文件夹叫A文件里的name叫B”这种事。4.3 把Commands当成Rules写结果每次对话都超长这是我自己最典型的反面教材。早期我没有形成“四层分层”的概念觉得“让AI每次都这么做”最稳妥的方式就是写进Rules。结果我把一长串“命令模板”例如“当我说review时请按以下5条执行……”放进了Rules文件。它的确生效了但也意味着每一次对话AI都要把这串长指令充当背景知识白白消耗上下文空间。后来我把这串内容挪到了Skill里把“触发方式”从“常驻加载”改成了“按意图匹配”上下文立刻瘦身。这个教训的本质是常驻的东西越少越好按需加载的东西可以多一点。那Commands的正确用法是什么我认为是“你自己最常用的、不需要AI思考要不要用的动作”。比如“总结当前文件”“生成提交信息”这些动作你自己主动触发就好不需要AI去识别意图。4.4 subAgents“能力弱”其实是设定太单薄有人觉得subAgents相比于直接对话并没有强多少我一开始也这么觉得。后来对比了我和同事的配置发现问题出在“角色设定”的颗粒度上。如果我只写一句“你是Python专家”那它和主对话没有任何区别。但如果我像下面这样配置表现就完全不同了你是本项目的接口评审官。你的职责是在接口合入前发现设计缺陷。 每次审查必须完成以下动作 1. 检查是否包含鉴权校验 2. 检查请求参数是否经过Pydantic模型 3. 检查返回格式是否与统一封装一致 4. 检查是否存在敏感信息泄露风险 在输出结论之前你必须逐条打勾确认。未确认完毕不允许输出“整体无问题”之类的结论。差别就在于我给了它强制流程和审慎检查清单。它不是“一个专家”而是“一个按固定流程办案的执法者”。如果你希望某个子代理稳定输出特定风格的结果你得把它当成一个新员工来培训而不是给它贴个标签了事。4.5 实践中的几条铁律把上面这些教训总结成几条更通用的原则Rules做减法只写硬约束控制在少量条数以内。任何“可以靠按需触发”的内容都不要放这里。Skill的description才是灵魂多花时间打磨触发字段比反复调试技能内容本身收益更高。Commands保持短小如果一段Command超过几行说明里面的逻辑应该下沉到Skill里。subAgents要配流程只给角色名不给流程的subAgents跟普通对话没有区别。命名规范全家桶文件夹、技能名、命令名统一用小写连字符空格和中文最容易在路径匹配时出问题。5. 关于这四者的几个额外建议前面说的偏“道”最后再聊几个更贴近实际操作的细节。如果你的目标只是“让Cursor输出的中文更自然”其实不用折腾界面汉化之类的东西。在全局Rules里加一行“请始终使用中文回复并保持技术术语准确”立刻能让所有对话默认变成中文输出这比改设置面板里的语言选项更直接。这也是我见过很多人在Rules里配置的第一条规则。如果你维护的是团队级项目建议把Rules和Skills的目录纳入Git管理。我现在的项目里.cursor/rules和.cursor/skills都是代码仓库的一部分团队成员克隆代码后立刻获得统一配置。评审口径一致之后团队Pull Request的风格都会收敛不少这算是额外红利。最后再强调一次容易忽略的细节Skills文件夹的名字和SKILL.md里声明的name要严格对应路径不要带空格。我踩过一次之后学乖了现在创建任何技能都先想清楚“用户在什么场景下会提到这件事”然后把这句话反推出description再动笔写正文。这大概也是我推荐所有人采用的工作顺序——不是先写内容而是先设计触发条件。Cursor这四兄弟每代版本都有微调但核心边界不会变Rules管底线Skills管方法Commands管效率subAgents管分工。把这层关系理顺了再看网上那种“一条规则让Cursor飞起”“这个Skill神了”之类的帖子你就能自动过滤掉80%没有营养的内容因为它们都只是这四层里某一层的局部优化而已。