包包和糖葫芦先聊几句题外话。很多刚上手Cursor的朋友，第一件事是折腾界面汉化、换个主题，或者到处找免费次数的偏方。这些都不是重点。真正让Cursor从一个"能补全代码的编辑器"变成"能顶半个初级开发者的助手"的，是那套藏在Chat和Agent背后的进阶机制——@注记、Rules和Skills。这三样东西用好了，你在项目里能省下的时间不是按小时算，而是按天算的。
这篇文章不聊基础操作，直接把我这几个项目里踩过的坑、总结出来的模板、以及这三者怎么配合出完整工作流的经验全部摊开讲。无论你是刚用Cursor两个月的新手，还是已经在写自定义规则的老手，这里面应该都有你能直接抄走的东西。
1. 先把三件套的关系理清楚：它们不是三个孤立功能
很多人把@注记、Rules和Skills混在一起用，结果就是越用越乱。这三个东西其实各管一段，搞明白分工，后面的所有技巧才有意义。
@注记是"喂上下文"的手段。 它的作用是告诉AI："你现在要看的是这几个文件、这段代码、这个网页，别跑到别处瞎猜。"它解决的是AI"不知道你在说什么"的问题。
Rules是"定规矩"的方式。 它的作用是告诉AI："在这个项目里，代码要按这个风格写、提交说明要按这个格式来、这个目录下的东西不许乱动。"它解决的是AI"产出风格不稳定、不贴合项目现状"的问题。
Skills是"给能力"的封装。 它把一整套操作流程、任务模板、甚至配套脚本打包成一个可复用的技能。以后想执行同类任务，直接点名这个技能就行。它解决的是"同一个任务每次都要重新描述一遍"的问题。
用一个生活化的类比：你要招待客人做饭。@注记等于告诉厨师"食材在左边冰箱、调料在右边柜子"；Rules等于交代这桌人忌口什么、口味偏咸还是偏淡；Skills则是一张完整的菜谱，照着走就能出菜，不用每次现编。
这里有个关键认知：这三者不是替代关系，而是正交配合。比如你做了一个"代码评审Skill"，里面的评审标准完全可以引用项目的Rules；而在执行Skill的时候，你又需要先用@注记把目标代码指给AI看。三件套一起上，才是完整形态。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. @注记的进阶玩法：从"会引用文件"到"精准控制AI的视野"
2.1 基础引用大家都懂，但很多人用错了场景
@File、@Folder、@Codebase这些基础操作，教程里都有，我不复读了。但在我看过的大量实际用法里，最常见的问题是：一上来就@Codebase。
Codebase Search确实强，它会对整个项目做embedding检索，然后给出相关文件。问题是，在超过几万行代码的仓库里，它经常返回一堆"看起来相关但实际没用"的文件。你以为AI理解了项目，其实它只是拿几个片段在拼凑答案。结果就是生成的代码风格诡异，或者改了半天发现改错了模块。
我的建议是：索引只能当辅助，视野必须靠你手动框定。
如果你明确知道问题出在哪个文件，直接@File，别偷懒；如果涉及一个模块，@Folder更精准；只有当你确实不熟悉代码分布、需要AI帮你定位时，才用@Codebase。控制好输入范围，输出的质量会明显上一个台阶。
2.2 三个直接抄的@注记进阶模板
第一个模板："只看这个文件里的某个函数"。
code复制@File: payment_service.py
只参考其中的 refund() 函数逻辑，帮我把新的撤销退款流程接进去，
不要改动其他函数的签名。
这样AI就不会自作主张去"优化"相邻代码。我见过太多次，AI顺手把旁边一个无关函数也给重构了，一个简单的需求改出一堆diff。范围限定得越死，行为越可控。
第二个模板：多文件组合+限定角色。
code复制@File: types.ts
@File: api/client.ts
@File: pages/checkout.tsx
你是这个项目的前端负责人，基于以上三个文件的数据结构和接口约定，
帮我设计 checkout 页面里优惠券模块的状态管理方案。
同时引用多个文件时，AI能自己把数据流串起来。但注意，别贪多，一次3到5个文件是甜蜜点，超过这个数，模型容易在一堆上下文里"走神"，回复的质量直线下降。
第三个模板：结合@Git做改动分析。
code复制@Git: main
请对比当前分支和 main 的差异，列出所有改动点，并检查：
1. 是否有未处理的边界条件
2. 是否影响了老接口的兼容性
3. 给出每个改动点的自测建议
这是我目前用下来最实用的一组@场景。做Code Review、写上线前检查清单的时候，效率非常高。AI能基于git diff给出有针对性的建议，而不是泛泛而谈。
2.3 这两个@注记的坑，我帮你踩过了
第一个坑：@注记不等于上下文无限。 每个文件都会消耗上下文窗口，尤其是大文件。你@进来一个2000行的文件，可能一两轮对话窗口就满了，AI开始忘事。解决办法是：能用@Folder收窄就收窄，能在引用的同时用文字说明"只看第100到200行"就说明。不要为了省事把整个仓库喂进去。
第二个坑：@Docs链接外部文档后，AI会"迷之自信"。 @Docs确实可以接项目文档、第三方库文档，但索引有时候不是最新的。我遇到过一次，AI引用了某个库的旧API文档，生成了已经废弃的写法，整个模块白写。建议在依赖库升级后，重新同步Docs索引，并且对关键库的用法，让AI在回复里标注来源版本号，方便核对。
3. Rules：让AI在轨道里跑，而不是每次随缘发挥
3.1 全局Rules和项目Rules怎么分工
Rules分两层：全局Rules管你所有项目的通用规范，项目Rules管单个项目的特殊约定。
全局Rules适合放那些你希望无论做什么项目都遵守的东西，比如：
- 代码注释必须用中文，命名用英文
- 禁止生成
any类型（针对TypeScript项目） - 提交信息遵循Conventional Commits格式
- 不在代码中硬编码敏感信息
项目Rules适合放和当前项目绑定的东西，比如：
- 这个项目用Vue 3组合式API，禁止写Options API
- 接口请求统一走
src/api里的封装，不许直接fetch - 后端联调用mock服务，mock数据放
mock/目录 - 样式必须用Tailwind，禁止写CSS文件
我的实践经验是：全局Rules要克制，只保留你真正在意、跨项目通用的规则；项目Rules要具体，把项目的技术选型、目录约定、编码约束写清楚。
3.2 怎么写一条"AI明白且不会反弹"的规则
写Rules最容易犯的毛病是：写得太抽象。比如"代码要优雅""注意性能"，这种话AI看了等于没看，因为它不知道怎么执行。
有效的规则要包含三个要素：场景、动作、标准。举个例子。
不行的写法：
code复制请保证代码有良好的错误处理。
能落地的写法：
code复制在涉及网络请求或文件读写的位置，必须使用 try-catch 包裹，
捕获错误后统一走 notifyError(message) 方法提示用户，
不允许静默吞掉异常。
你看，场景（网络请求、文件读写）、动作（try-catch + notifyError）、标准（不允许静默吞掉）全部明确了，AI执行起来就不会自由发挥。
另外还有一个细节：规则尽量用肯定句，少用否定句。不是说否定句不能用，但一长串"不要xxx"很容易让模型进入防御状态，它不知道该主动做什么。我习惯把"不要做什么"作为边界补充，核心还是"遇到什么情况，就做什么动作"。
3.3 一份可以直接改着用的项目Rules模板
下面是我在某个后台管理前端项目里实际用过的Rules文件结构，供参考。你可以按项目情况删减。
markdown复制# 项目基础
- 技术栈：React 18 + TypeScript + Vite + Zustand + Tailwind
- 组件库：Ant Design 5，表格封装基于 ProComponents
# 代码风格
- 函数名、变量名使用 camelCase；组件名使用 PascalCase
- 常量全部大写加下划线，禁止魔法数字
- 类型定义集中在 src/types 中，业务组件内部不做复杂类型推导
# 目录约定
- 页面组件放 src/pages，业务组件放 src/components
- 全局状态只放认证信息和主题配置，页面级状态用组件本地状态
- API 请求函数统一放 src/api，按后端模块拆文件
# 交互与错误处理
- 用户可触发的操作需要 loading 状态，按钮在请求期间 disabled
- 失败提示统一用 message.error，成功提示用 message.success
- 在接口调用处捕获异常，不得吞错
# 提交规范
- 提交信息格式：type(scope): subject
- type 取值：feat / fix / docs / refactor / perf / test / chore
把这样的内容放在项目根目录的.cursorrules文件里（或通过Cursor的Rules设置指向它），AI在这个项目里的所有回复基本都会贴着这套规范走。
3.4 规则太多？小心把AI"绑死"
有一个高频问题是：规则写了一大堆，结果AI变得畏手畏脚，让它写个组件，它反复追问"我应该用哪个分支来写"，效率反而变低。
我在实践中摸索出的平衡点是：规则只约束"边界"，不约束"过程"。代码风格、目录结构、错误处理、安全红线，这些属于边界，值得写进Rules；至于思路怎么展开、技术方案怎么选，那是AI的能力范围，交给它发挥就好。规则文件控制在30到50行左右，语义重合的条目越多，模型的遵守率反而越低。
4. Skills：把"一次表达得特别清楚"沉淀成永久的肌肉记忆
4.1 Skills到底是啥，和Rules区别在哪
Skills这个概念是从Agent类工具里流行开的。简单说，它就是一套"封装好的任务执行方案"。你平时会在提示词里反复描述的那种复杂任务——比如"帮我对这段代码做一次代码评审，按严重程度分组输出问题清单，并给出修改建议"——完全可以写成一个Skill，以后一行指令触发。
它和Rules的区别在于：Rules是"一直都在"的约束条件，相当于项目的交通规则；Skills是"按需调用"的执行方案，相当于一个专用的工具箱。你不需要把评审标准挂在Rules里让每次对话都背一遍，而是写一个code-review的Skill，需要的时候拿出来用。
4.2 SKILL.md的编写格式
以我目前在用的方式为例，一个Skill放在项目（或全局）.cursor/skills/<skill-name>/目录下，核心是一个SKILL.md文件，格式长这样：
markdown复制---
name: review-code
description: 对指定代码做严格评审，输出按严重程度分级的发现清单
agent: chat
---
当你被要求执行代码评审时，请严格遵循以下流程：
1. 先让用户用 @ 注记指定需要评审的文件
2. 读取文件后，按以下维度检查：
- 正确性：边界条件、空值处理、并发安全
- 可维护性：命名、函数长度、重复代码
- 性能：是否能在循环中减少计算、是否存在不必要的重渲染
- 安全：注入风险、敏感信息泄露
3. 输出格式：
- 用表格列出所有发现，列为：严重程度 / 文件行号 / 问题描述 / 修改建议
- 严重程度分为 Critical / Major / Minor / Nit
4. 最后用一段话总结整体质量，不要修饰问题。
这里面的agent字段可以控制这个Skill是给普通Chat用还是给Agent模式用。名称和描述要写得让模型一眼看懂"这个Skill是干嘛的，什么时候该调用它"。
4.3 实战：写一个"前端页面生成器"Skill
这个Skill是我个人用下来价值最高的一个。以前接手一个新页面，需求描述清楚之后，AI生成的代码总是差口气：要么样式风格不对，要么忘了写loading态，要么接口错误处理不规范。把生成流程打包成Skill之后，质量稳定多了。
markdown复制---
name: gen-page
description: 根据需求生成标准后台管理页面，包含列表、筛选、分页、增删改查弹窗
agent: chat
---
执行流程：
1. 先向用户确认：接口文档、字段清单、页面类型（列表/表单/详情）
2. 页面结构统一为：
- 顶部筛选区（SearchForm）
- 操作按钮区（新增、刷新、批量操作）
- 数据表格（ProTable）
- 分页器
- 新增/编辑弹窗（Modal + Form）
3. 请求逻辑：
- 列表请求走 src/api 下对应模块
- 请求参数类型化，使用 TypeScript interface
- 失败时 message.error 提示，并保留原数据
4. 渲染要求：
- 表格列必须包含 dataIndex、title、ellipsis
- 日期字段统一格式化为 YYYY-MM-DD HH:mm:ss
- 状态字段用 Tag 组件展示，颜色按状态映射
5. 生成完成后，检查一遍代码，确认没有 any 类型和未使用的 import。
这样设置之后，哪怕换一个项目，只要Rules里约定的目录结构一致，这个Skill照样能工作。可以说，Skills是你跨项目迁移"效率"的最好载体。
4.4 写Skill的几条实操心得
心得一：给Skill加"前置问题清单"。 很多Skill不生效的原因不是模型不会做，而是信息不足。你在Skill开头写明"执行前必须先确认xxx"，可以逼着AI先收集关键信息，而不是闷头开写。
心得二：Skill内部引用的工具函数要写清楚依赖。 比如上面那个页面生成器依赖ProTable、依赖项目里已有的搜索组件，这些都要在Skill里写明，换到别的项目时你才知道需要适配什么。
心得三：常规小任务不要全塞进Skill。 如果每个三五行的操作都做成Skill，你的Skill库会变成一个"提示词垃圾场"，到时候模型反而不知道该调用哪个。一般只封装那些流程稳定、步骤多于五步、你明显感觉到重复次数很多的任务。
5. 三件套联动实战：从零到一跑通一个完整功能开发
只讲单独用法不讲配合，等于没讲。我拿一个实际场景，把这套流程串一遍。
假设你要在现有后台系统里开发一个"优惠券管理页面"。以前我的做法是：打开Chat，把需求粘贴进去，让它生成，然后从一堆不符合项目规范的代码里改bug。现在我的流程是这样的。
第一步，确认Rules已经在场。项目根目录有.cursorrules，包含了项目的技术栈、目录约定和交互规范。这一步保证了后面所有生成都贴着项目风格走。
第二步，@注记给出上下文。我会引用这几个文件：
code复制@File: src/pages/existing_promotion_page.tsx （参考已有类似页面结构）
@File: src/api/coupon.ts （接口定义）
@File: src/types/coupon.d.ts （类型定义）
这样AI很清楚：新页面长什么样可以参考兄弟页面，接口和类型已经在后端约定好了，不需要它自己编。
第三步，调用Skills。在对话中直接说"使用 gen-page 技能生成优惠券管理页面，接口文档见 @File: src/api/coupon.ts"。模型会读取Skill里的流程，按部就班地生成列表、筛选、分页、弹窗，并且自动带上loading、错误处理和类型定义。
第四步，一轮代码评审。组件生成完后，我不急着用，直接说"用 review-code 技能对刚生成的文件做一次评审"。这时候它会把刚才的代码拿出来过一遍评审标准，给出Critical/Major/Minor的分级清单。我只需要处理Critical和Major，Minor直接放行。
整个过程在十五分钟以内完成，而且生成代码的规范性比我手写的还稳定。对比一下没有这套流程之前：光在对话里反复交代"列表要自适应""请求要统一走api模块""弹窗要带表单校验"，就够我敲一大段提示词了。
这还没完，真正的精髓在于：这套流程可以完全交给Agent模式跑。 你把上下文、Skill、Rules都配好之后，在Agent对话框里一句"帮我完成优惠券管理页面，前后端接口按 src/api/coupon.ts 来"，它是一个Agent，可以自己调用Codebase Search、自己执行Skill、自己修编译错误。你只需要在最后做Code Review。这个改变是真的省时间。
6. 常见问题排查与避坑实录
这几个问题是我在社群答疑时被问得最多的，列成清单，按"现象-原因-解决"对齐。
6.1 @注记引用的文件内容不是最新的
现象：让AI读某个文件，但它读到的还是旧代码，经常把已经删掉的函数拿来说事。
原因：Cursor的索引没有及时同步。
解决：打开设置里的索引管理，对当前项目手动触发一次"Reindex"，或者直接重启Cursor。顺手检查一下有没有大文件、二进制文件被误索引进来，这些会影响索引准确性。
6.2 Rules写在.cursorrules里但不生效
现象：规则文件放好了，但AI回答完全无视规则。
原因：大概率是文件名、路径或格式问题。
解决：先确认文件名是.cursorrules，没有额外后缀；再确认Cursor的Rules设置里，"项目规则"指向的路径和实际文件路径一致；最后检查文件编码，最好用UTF-8无BOM格式。如果这些都没问题，新建一个对话试试，规则是随会话加载的，不会对历史会话生效。
6.3 Skill可以被对话看到，但执行时跑偏
现象：描述里说了"使用gen-page技能"，AI却只按普通对话处理，没有执行Skill里的流程。
原因：可能是Skill的name或description不够明确，模型没识别出应该调用它。
解决：把description写得更有"触发感"，比如明确写上"当用户要求生成一个后台管理页面时，你必须使用此技能"。另外，对话里明确点名技能名，比自然语言描述更可靠。还有一个提升调用率的办法：把Skill名称设计成你平时说话会用的词，而不是又长又绕的英文。
6.4 上下文窗口被占满，AI聊着聊着开始"失忆"
现象：长任务执行到一半，AI开始忽略前面的要求，生成的代码和前面对不上。
原因：Agent任务消耗上下文很快，尤其是多次工具调用之后。
解决：把任务拆成小块，每一块用独立的对话/Agent会话完成。比如"生成组件"和"组件评审"分两次对话执行，不要让一个会话从头撑到尾。同时做好Rules和Skills，让AI在上下文较少的情况下也能按标准输出。
6.5 团队协作时，Rules和Skills的同步问题
现象：你本地配得好好的规则和技能，同事电脑上是空的，生成出来的代码风格天差地别。
原因：.cursorrules和Skills目录没有纳入版本管理，或者同事不知道要去读。
解决：我的建议是把.cursorrules和.cursor/skills/目录直接放进Git仓库（前提是里面没有私密信息）。然后在项目README里加一条"开发前必读：请使用Cursor打开项目根目录，以确保加载项目规则和技能"。这样规范就能随代码库走，新同事第一次打开项目就已经全部就绪。
7. 最后分享几点我的使用体会
用Cursor这段时间，我最深的体会是：工具的价值上限，由你的沉淀能力决定。 那些只用对话功能的人，每一轮都需要把项目背景、代码规范、页面需求重复交代一遍，所以效率始终上不来。而把@注记、Rules、Skills用起来之后，相当于你把自己长期积累的"项目认知"和"开发习惯"全部交给了AI，让它从第一次对话就站在你的肩膀上干活。
还有个小建议：不要把Skills做成一次性的。我每次在项目里发现一个"重复了两遍以上"的任务，都会顺手把它升级成Skill，哪怕第一版粗糙一点。写完之后试用几轮，根据AI的执行结果不断修正流程描述。三个月下来回头看，你会发现自己沉淀的这套"个人提示词资产"，远比花大把时间找各种偏方更有价值。
你可以从今天开始，先只做两件事：给手头上最常做的任务写一个Skill；把项目里最让你头疼的三条规范写进Rules。用起来之后，你大概就能理解为什么我说这三件套才是Cursor真正值得研究的核心功能了。