企业官网建设流程全解析

很多人用Cursor，其实还停留在“把聊天框当百度用”的阶段——问一句，答一句，代码能用就复制走。真正让Cursor脱胎换骨的，是另外三样东西：@注记、Rules、Skills。这三个词单独拆开都不难理解，但把它们组合到位，才算是把Cursor从“会写代码的插件”升级成“真正懂你这个项目的协作者”。

今天不聊基础操作，聊进阶。这篇文章会逐一拆解@注记的引用链路、Rules的规则体系、Skills的技能封装，再给一套可以直接抄的组合打法。适合已经用Cursor写过一段时间代码、但总觉得AI“不够听话”或“记不住项目规范”的人。看完你会发现，过去那些“AI写得不对”“AI又改了我不让它改的东西”的烦恼，大部分根本不用忍。

1. 为什么是这三件套：@注记、Rules、Skills的分工逻辑

1.1 三个功能各管一段：上下文、约束、流程

先说个我常用的类比。你把AI想象成一个新来的程序员，工位已经给他准备好了。

• @注记是“递材料”。你不是跟他说“帮我改一下登录页”，而是把登录页对应的文件、依赖的组件、后端接口文档直接甩到他桌上。AI看到的就不再是想象里的登录页，而是你项目里真实的登录页。
• Rules是“员工手册”。里面写清楚这个团队怎么命名变量、怎么处理错误、用什么状态管理库、代码提交前要过哪些检查。AI每次干活前先翻这本手册，产出的代码天然贴合你的团队规范。
• Skills是“标准作业流程”。比如“新增一个API端点”这件事，在你们项目里是有固定套路的：建路由、加校验、写服务层、补Swagger注释、跑测试。Skill就是把这套动作固化成一份可执行的清单，AI按部就班走完，不会漏步骤。

这三件事的分工极其清晰：上下文靠@注记供给，行为边界靠Rules框定，重复任务靠Skills自动化。三者合起来，才是一个完整的“AI协作系统”。

1.2 为什么这是“进阶”的分水岭

大部分用户只用到了Cursor最浅的一层：对话窗口里描述需求，AI生成代码。这层用法的问题是，AI每一次回答都是“从零开始”的——它不知道你的项目结构、不知道你的编码习惯、也不知道“上一次已经处理过这个问题”。

进阶用法和基础用法的差异，本质上是一个公式：

AI产出质量 = 模型能力 + 上下文质量 + 约束清晰度 + 执行流程完整度

这四项里，模型能力是Cursor定死的，你没法改；但后面三项，恰好就是@注记、Rules、Skills分别补上的。当你的上下文更精确、约束更明确、流程更完整时，AI的产出会从“能跑”跃迁到“不用改就能合进主干”，这个差距是肉眼可见的。

1.3 这套玩法不是Cursor独有，但Cursor把它做进了编辑器

Claude Code里有Skills，Codex里也有类似的文件分组和指令机制。但Cursor的优势在于：这些东西不是命令行里的一次性配置，而是长在编辑器里的日常交互。你在写代码时随手@一个文件、在项目目录里放一份规则，后续所有AI交互都会自动带上这些信息，不需要来回切换工具。

而且更重要的是，Cursor正在兼容社区里通用的Skills格式。这意味着你从Claude Code或Codex社区里淘来的优秀技能包，很多可以直接拿过来用，不用重写。这一点后面第2章会专门展开。

2. 核心细节与实操要点拆解

2.1 @注记：把“AI猜”变成“AI看”

@注记（At Mentions）是Cursor里操作成本最低、但提升效果最明显的功能。在对话输入框里输入@，会弹出当前项目的文件、文件夹列表，以及一系列快捷引用项。选中的内容会作为上下文附加到你的提问里。

实战中我主要用这么几种，按使用频率排：

先说@Codebase。很多人一上来就喜欢用这个，因为它看起来最“AI”。但我实测下来，它是最容易被滥用的——@Codebase会触发一次跨全仓库的向量检索，耗时几秒到几十秒，消耗的token也不小。如果你的问题其实只涉及某一个模块，直接用@Folder把它按进去，精度更高、速度更快。我的习惯是：小改动用@File，模块级改动用@Folder，只有完全不确定代码在哪的时候才用@Codebase。

再说@Docs。这个是隐藏神器。Cursor里可以提前配置一批文档源（Settings -> Docs），把项目依赖的框架、组件库、后端API文档都挂上去。之后在对话里@Docs就能直接引用。我见过很多人在用三方库时，让AI“猜”参数配置，AI一本正经地编了一堆不存在的API，最后全踩坑。挂上官方文档之后，这种情况基本绝迹。

使用@注记有个容易忽略的坑：如果选中了多个文件，AI会把它们当作并列上下文，但不会自动理解文件之间的依赖关系。比如你同时@了一个组件文件和一个工具函数文件，最好在提问里补充一句“这个组件使用了utils里的xxx函数，请注意两者的类型关系”。不然AI可能忽略你给的部分上下文，自己另起炉灶。

2.2 Rules：让AI遵守“这个项目自己的规矩”

Rules在Cursor里承担的是“长期记忆+行为约束”的角色，而且和@注记不一样，Rules不需要每次对话都手动带上——它是自动生效的。

先说存放位置。目前Cursor里有两类规则：

• Project Rules（项目级）：放在项目根目录下的.cursor/rules/文件夹里，支持.mdc格式。这是官方推荐的方式。
• User Rules（全局级）：在Cursor的设置里配置，对所有项目生效。适合放你自己的通用偏好，比如“回答用中文”“代码里不要用console.log”。

老版本还有一个.cursorrules文件放在项目根目录的玩法，现在官方建议往.cursor/rules/迁移。如果你的项目里同时存在.cursorrules和.cursor/rules/，新规则优先，但为了长远考虑，我建议都统一到.cursor/rules/里。

.mdc文件有一个很核心的机制：frontmatter + glob匹配。文件头部用两段---包起来的信息叫frontmatter，里面可以写description和globs。globs是用来控制这条规则作用于哪些文件的。比如：

--- description: 所有 TS 组件文件必须遵守的规范 globs: src/**/*.tsx, src/**/*.ts --- - 组件命名必须使用 PascalCase - 禁止使用 any 类型 - 组件必须有明确的 props 接口定义 - 文件末尾留一个空行

这个机制的意义非常大。你可以把规则拆成好几份文件：一份管TS类型、一份管React组件、一份管样式写法。Cursor会根据当前对话涉及的文件路径，自动匹配合适的规则注入。规则太多太杂反而会稀释AI的注意力，拆开按需生效才是正道。

再强调一遍：规则要写“要什么”，而不是“不要什么”。AI对负面指令的理解和执行远不如正面指令稳定。你说“不要用any”，它可能还是会偶尔漏；但你说“所有类型必须显式定义，禁止隐式推断为any”，执行率会高很多。

2.3 Skills：把“问一句答一句”变成“交给AI执行”

Skills是三者里最新、也最被低估的能力。通俗理解，它就是把一条完整的任务流程打包成一个“技能包”。AI识别到你的需求匹配某个技能后，会自动加载这个技能的步骤说明、代码模板、注意事项，然后一步步执行。

Cursor的Skills目录结构一般长这样：

.cursor/ ├── skills/ │ ├── create-api/ │ │ ├── SKILL.md │ │ └── templates/ │ │ └── api-handler.template.ts │ └── review-code/ │ └── SKILL.md

每个技能文件夹里至少要有一个SKILL.md文件，它是技能的“说明书”。文件头部同样有frontmatter，包含name、description、allowed-tools等字段。真正重要的是description——Cursor会读取它来决定“什么情况下自动触发这个技能”。写清楚触发场景，技能才会被精准命中。

下面是一个简化的SKILL.md示例：

--- name: create-react-component description: 当用户要求创建新的 React 组件时使用。适合带有 props 接口、样式文件和默认导出的组件创建流程。 allowed-tools: write, read, edit --- 1. 读取项目根目录下的 components 目录，理解现有组件的文件组织方式 2. 根据用户提供的组件名，创建同名文件夹 3. 新建 index.tsx，导出组件主体；新建 types.ts，定义 Props 接口 4. 样式文件使用项目已有的 CSS 方案（默认 CSS Modules） 5. 创建完成后，检查是否存在同名 .stories.tsx 规范，若有则补充 Storybook 文件

你看，这个Skill把“创建React组件”这件原本需要AI自由发挥的事，编码成了一个流程。AI不会再问你“要不要单独建文件夹”，而是照着流程走完。

Skills与Rules、@注记最大的区别也在这里：Rules告诉你“什么能做、什么不能做”，它是静态的；Skills告诉你“这件事具体分几步做”，它是动态的、流程化的。而当Skill里要读取具体文件时，它内部仍然会用到@注记的底层能力，这三者不是替代关系，是嵌套关系。

另外提一个非常实用的事：Claude Code和Codex的Skills目录结构，和Cursor高度相似。我试过直接把Claude Code社区的某个代码审查Skill放进.cursor/skills/，稍微改一下frontmatter的字段名就能跑起来。这意味着你不用从零开始造轮子，去社区里找那几个星标高的skills仓库，下载后做微调就能用。

3. 实操：从0到1搭一套“规则+技能”组合

3.1 场景设计

我以一个实际项目为例——React + TypeScript + Vite的B端管理后台，团队风格比较偏保守：组件全用函数组件、样式用CSS Modules、类名遵循BEM、数据请求封装在独立的hooks/useRequest.ts里。过去让AI直接写代码，经常写出带class组件、样式内联、没有复用useRequest的东西。

现在我要做三件事：

1. 在项目里配置一套Rules，告诉AI我们团队到底怎么“说话”。
2. 写一个封装新页面的Skill，把从“创建组件”到“接入路由”再到“联调接口”的标准流程固化下来。
3. 用一个实际对话，演示“@注记 + Rules + Skills”三者怎么共同干活。

3.2 第一步：配置项目级Rules

在项目根目录创建.cursor/rules/，放两份文件。

第一份frontend-rules.mdc，管理通用的前端风格：

--- description: 前端代码通用规范，适用于所有 TS/TSX 文件 globs: src/**/*.{ts,tsx} --- 1. 函数组件为主，禁止使用 class 组件 2. 样式必须使用 CSS Modules，禁止使用内联 style 属性 3. 类名采用 BEM 命名规范：block__element--modifier 4. 数据请求统一走 src/hooks/useRequest.ts 封装，禁止直接在组件内 fetch 5. TypeScript 类型定义放在与组件同级的 types.ts 文件中 6. 组件默认导出必须使用 export default，具名导出仅用于工具函数

第二份page-creation.mdc，专门约束页面创建流程：

--- description: 新建页面时需要遵守的目录规范 globs: src/pages/**/* --- 1. 每个页面目录下必须包含 index.tsx、types.ts、styles.module.css 三个文件 2. 页面级状态管理使用 zustand，禁止使用 redux 3. 新页面必须在 src/router/routes.ts 中手动注册路由 4. 页面文案统一放在 src/locales/zh-CN.ts 中，禁止硬编码中文文本

这两份Rule生效后，AI生成代码就强制被拉回团队的既定轨道上。我实测下来，最明显的改善是：以前AI喜欢把所有样式怼在style={{}}里，现在自动生成styles.module.css，类名也老老实实按BEM走。

3.3 第二步：编写页面生成的Skill

在.cursor/skills/create-page/下创建SKILL.md：

--- name: create-page description: 创建后台管理系统的页面。当用户要求新增页面、新建业务模块或创建CRUD界面时使用。触发关键词包括“创建页面”、“新增模块”、“做一个列表页”等。 allowed-tools: read, write, edit, grep --- # 页面创建流程 ## 1. 环境确认 - 读取 src/pages 目录，确认现有页面结构 - 读取 src/router/routes.ts，理解路由注册方式 ## 2. 创建页面骨架 - 在 src/pages/新建页面名/ 下创建 index.tsx、types.ts、styles.module.css - index.tsx 中导出默认组件，组件名使用 PascalCase - types.ts 中定义页面所需的所有接口类型 ## 3. 接入路由 - 在 src/router/routes.ts 中注册新路由，路径与菜单配置遵循现有格式 ## 4. 对接数据 - 使用 src/hooks/useRequest.ts 进行数据请求 - 所有交互状态用 zustand 管理，store 文件放在 src/store/ 下 ## 5. 自查清单 - [ ] index.tsx / types.ts / styles.module.css 三个文件都已创建 - [ ] 路由已注册且路径无重复 - [ ] 没有硬编码中文字符 - [ ] 没有使用任何 any 类型

这个Skill的核心价值在于：它把“做一个页面”的隐性知识（路由注册、store管理、文案抽取）显性化了。AI执行时相当于照着清单逐项打勾，不会因为忘了注册路由导致页面白屏。

3.4 第三步：用@注记启动对话

现在模拟一个真实操作：我打开Cursor的对话窗口，先输入@Folder选中src/pages目录，让AI看到现有页面的组织方式；再引用src/services目录，让AI知道后端接口大概长什么样。然后输入：

@Folder src/pages @Folder src/services 请按照 create-page 这个技能，帮我新增一个“用户管理”页面。功能包括：用户列表展示、状态切换、搜索过滤。

AI会怎么反应？它会先识别到create-page这个Skill，按SKILL.md里面写的步骤走：读pages目录看结构 -> 创建三个文件 -> 注册路由 -> 联调useRequest。因为Rules注入了frontend-rules.mdc，它生成代码时会自动采用CSS Modules和BEM命名；因为Skill规定了自查清单，它最后会逐项检查有没有漏掉路由、有没有硬编码。

整个过程中，我几乎不需要重复说“记得用CSS Modules”“记得注册路由”这些话。上下文由@注记提供，行为边界由Rules约束，执行步骤由Skills接管。

3.5 效果验证与微调

第一次执行完，我习惯做两件事：

• 检查路由文件，确认AI确实在routes.ts里新增了路由，而不是只创建了页面组件。
• 跑一遍Ctrl+Click跳转，看页面文件里的import路径有没有拼错。

如果某一步AI漏了，我不会只说“你漏了注册路由”，而是打开对应的Rule或Skill文件，把漏掉的步骤补进去。这样下次它就记住了。这个“反馈-沉淀-固化”的循环，才是Rules和Skills真正越用越顺的原因。

4. 常见问题与排查技巧实录

我把过去几个月攒下来的坑整理成了一份速查表，遇到问题先对着查一遍，比自己瞎折腾快得多。

这里单独说一个我掉过最深的坑：规则写在.mdc文件里，但AI每次启动对话后仍然置若罔闻。后来排查发现，是因为我在规则里用了“必须”“禁止”这类命令式表达，但整份规则没有description字段。Cursor依赖description判断“这条规则该不该在当前对话注入”，没有它，规则可能被当作普通文件内容处理，而不是规则。所以，每个.mdc文件务必写好description，这不仅是给AI看的，也是给规则加“触发开关”。

还有一个关于Skills的细节：不要一开始就写非常复杂的Skill。我见过有人把“全流程部署”塞进一个Skill里，结果AI执行到第三步就开始乱，后面全崩了。Skill的粒度最好控制在“单次任务5-10步以内”。宁可拆成“build-feature”和“deploy”两个Skill，也不要硬塞一个巨型流程。流程越长，AI的注意力就越容易漂移，这一步没法完全靠提示词弥补。

另外，如果你遇到AI明明在按Skill执行，但中途还是“发散”了，大概率是因为Skill description里没有说明“执行范围”。比如“创建页面”的Skill，AI可能在第四步“对接数据”时擅自重构了你的useRequest.ts，因为它觉得“顺手优化一下”。要压住这种行为，可以在SKILL.md最后加一行：

本流程只包含页面创建相关操作，不得修改既有工具函数、hooks或其他页面文件。

规则越有边界，AI越不容易跑偏。这跟带新人是一个道理——你只让他收拾桌子，他就不该顺便把别人抽屉也翻一遍。

5. 关于使用这套组合的几点心得

最后分享一些碎片化的个人经验，不算系统教学，但都是我实际踩过之后觉得值得记住的东西。

第一个心得是：Rules和Skills是“越写越准”的资产，不是一次性配置。第一版写的规则肯定有漏洞，AI不按规矩走的时候，不要急着骂它，而是反思规则本身写没写清楚。把每次“AI跑偏”都当成一次规则迭代的机会，你的规则库会越来越像一份真正反映团队文化的员工手册。

第二个心得是：@注记不要滥用，也不要不用。我见过两类极端用户：一类永远只用对话框打字，AI全靠猜，产出自然拉胯；另一类每次把全项目都@进去，token烧得飞快，回答反而被无关代码干扰。最舒服的用法是：先想清楚“这个问题到底依赖哪些上下文”，再精准地@那两三处。

第三个心得是：Skills可以跟别人的项目共用，但一定要“本地化”。从社区下到一个不错的React组件检查Skill，先读一遍SKILL.md，把你的项目路径、团队规范、目录结构同步进去。直接搬来就用的人，十有八九会卡在路径不一致上。

第四个心得是：这套组合不只在代码生成场景有效。我用它来“让AI做代码审查”效果也很好——写一个review-code的Skill，规则里规定审查要检查的几个维度（类型安全、边界情况、依赖引入、命名异味），再用@Codebase让它扫整个模块，AI能像有经验的老手一样给出非常具体的审查意见，甚至帮你找出测试覆盖不到的隐藏分支。

Cursor的进阶玩法没有想象中那么玄乎。核心就是把“你希望AI怎么做”这件事，从你的脑子里搬到配置文件里。一旦搬完了，它就不再依赖你每次对话时反复叮嘱。@注记解决的是“AI看不看得见”，Rules解决的是“AI守不守规矩”，Skills解决的是“AI会不会干活”。三件事各归其位，Cursor才真正从编辑器变成了你的结对编程搭档。