企业官网建设流程全解析

1. 为什么大多数人用Cursor只发挥了它三成实力

我身边不少朋友都在用Cursor写代码，但聊下来发现一个很有意思的现象：大部分人把它当成"能自动补全的VS Code"在用，装完插件、登录账号，然后就开始写代码了。结果用了两周，抱怨说"也就那样，补全还不如某某工具准"。问题出在哪？不是工具不行，是配置没做对。

Cursor真正的杀伤力不在于它内置的那个模型有多强，而在于它能不能理解你的项目上下文、能不能按照你的编码习惯和团队规范来生成代码。这两件事，靠默认配置是做不到的。默认状态下，Cursor对你的项目一无所知，它不知道你用的是React还是Vue，不知道你的命名规范是驼峰还是下划线，不知道你的API请求封装在哪个目录下。每次生成代码，它都在"猜"。猜对了是运气，猜错了你就得手动改，改来改去反而比自己写还慢。

这套配置体系的核心就是三个东西：.cursorrules（或者新版的项目规则目录）、.cursorignore、以及编辑器层面的个性化设置。把这三样配好，Cursor才能从一个"通用代码生成器"变成"你的专属编程搭档"。我自己配完之后最直观的感受是：以前写一个CRUD接口要来回改三四次，现在基本一次成型，改动的量少了一半不止。

这篇文章适合两类人看：一是刚接触Cursor、还在摸索阶段的新手，我会把每一步操作和背后的逻辑都讲清楚；二是已经用了一段时间但觉得效果一般的开发者，你可以对照检查一下自己的配置是不是漏了关键环节。全文基于我自己的实际使用经验，结合常见的工程实践来展开，不涉及任何特定平台的推广。

2. 项目规则文件：让Cursor真正读懂你的代码库

2.1 .cursorrules与新版规则目录的区别和选择

早期版本的Cursor只支持一个叫.cursorrules的文件，放在项目根目录下，里面写一段自然语言描述，告诉Cursor这个项目是干什么的、用什么技术栈、有什么编码规范。这个方式简单直接，但有个明显的短板：所有规则挤在一个文件里，项目一大就变得臃肿难维护，而且不同模块可能需要不同的规则，一个文件搞不定。

后来Cursor引入了.cursor/rules/目录机制，支持把规则拆成多个.mdc文件，每个文件可以单独指定生效范围（比如只对src/api/目录生效，或者只对.tsx文件生效）。这个改进非常关键，因为它解决了"规则冲突"的问题。举个例子：你的前端组件用PascalCase命名，但工具函数用camelCase，如果写在同一个规则文件里，Cursor可能会混淆；拆成两个.mdc文件，各自指定globs匹配范围，就不会打架了。

那到底用哪个？我的建议是：新项目直接用.cursor/rules/目录机制，老项目如果已经有.cursorrules且运行良好，不必急着迁移，但可以逐步把通用规则抽到新目录里。两者可以共存，Cursor会同时读取。

一个典型的.mdc文件结构长这样：

--- description: API层编码规范 globs: src/api/**/*.ts alwaysApply: false --- - 所有API请求必须通过 `request.ts` 中的封装函数发起 - 请求方法命名使用 `动词+资源名` 格式，如 `getUserList`、`createOrder` - 返回值统一使用 `ApiResponse<T>` 泛型包裹 - 错误处理统一在拦截器中完成，业务层不重复try-catch

头部那段YAML是元数据，description说明这个规则的用途，globs指定生效的文件范围，alwaysApply控制是否全局强制应用。下面才是真正的规则内容。

2.2 规则文件里到底该写什么：四类高价值信息

很多人写规则文件时不知道写什么，要么写得太泛（"请写高质量的代码"），要么写得太细（把整个架构文档贴进去）。这两种都没用。根据我的经验，规则文件里最值得写的是四类信息：

第一类：技术栈和版本约束。明确告诉Cursor你用的是React 18还是19，用的是Vue 3的组合式API还是选项式API，状态管理用的是Zustand还是Redux Toolkit。这个信息直接影响它生成的代码风格。比如你说"使用React 18 + TypeScript 5 + Zustand"，它就不会给你生成useState满天飞的代码。

第二类：目录结构和模块职责。简单描述一下项目的目录组织方式，比如src/components/放通用组件、src/pages/放页面、src/hooks/放自定义Hook、src/utils/放工具函数。这样Cursor在生成新文件时，会知道该往哪个目录放，import路径也不会写错。

第三类：编码规范和命名约定。包括变量命名风格、文件命名规则、组件导出方式（默认导出还是具名导出）、注释语言（中文还是英文）。这些细节看起来琐碎，但恰恰是影响代码一致性的关键。

第四类：常用工具函数和封装。告诉Cursor你项目里已经有哪些封装好的工具，比如request.ts封装了axios、storage.ts封装了localStorage、formatDate在utils/date.ts里。这样它生成代码时会直接调用这些现成的函数，而不是重新造轮子。

注意：规则文件不是越长越好。我见过有人写了三千多字的规则，结果Cursor反而"抓不住重点"。建议单个.mdc文件控制在200-500字，把最重要的约束放在前面。

2.3 规则生效范围的精细控制：globs匹配实战

globs字段是.mdc规则文件里最实用的功能之一，它决定了这条规则对哪些文件生效。写对了，规则精准命中；写错了，要么不生效，要么到处乱套。

常见的匹配模式有这么几种：

我自己的项目里通常会建这么几个规则文件：一个全局的general.mdc（alwaysApply: true），管技术栈和通用规范；一个api.mdc管接口层；一个component.mdc管组件层；一个style.mdc管样式相关。这样分工明确，维护起来也方便。

有个容易踩的坑：globs的路径是相对于项目根目录的，不是相对于.cursor/rules/目录。我一开始就搞混了，写了个./src/**，结果一直不生效，排查了半天才发现问题。

2.4 从零写一份能用的规则文件：完整示例

光说理论没意思，直接上一份我在实际项目中用的规则文件，你可以根据自己的情况改。

全局规则general.mdc：

--- description: 项目全局规范 alwaysApply: true --- ## 技术栈 - 框架：React 18 + TypeScript 5 - 构建：Vite 5 - 状态管理：Zustand - 路由：React Router v6 - UI库：Ant Design 5 - 请求：axios（已封装在 src/utils/request.ts） ## 目录约定 - 页面组件：src/pages/，每个页面一个目录 - 通用组件：src/components/，按功能分子目录 - 自定义Hook：src/hooks/ - 工具函数：src/utils/ - 类型定义：src/types/ ## 编码规范 - 组件使用函数式写法，具名导出 - 变量和函数用camelCase，组件和类型用PascalCase - 常量用UPPER_SNAKE_CASE - 注释用中文，关键逻辑必须写注释 - 禁止使用any，不确定的类型用unknown

API层规则api.mdc：

--- description: API层编码规范 globs: src/api/**/*.ts alwaysApply: false --- - 所有请求通过 src/utils/request.ts 的 request 函数发起 - 每个模块的API单独一个文件，如 user.ts、order.ts - 函数命名格式：动词 + 资源名，如 getUserList、updateOrderStatus - 返回值类型统一用 ApiResponse<T>，定义在 src/types/api.ts - 请求参数超过3个时，使用对象参数而非位置参数 - 错误处理由request拦截器统一处理，业务层不写try-catch

组件规则component.mdc：

--- description: 组件开发规范 globs: src/components/**/*.tsx alwaysApply: false --- - 使用函数式组件 + TypeScript - Props类型命名为 `组件名Props`，如 `UserCardProps` - 组件内部状态用useState，跨组件状态用Zustand - 样式使用CSS Modules，文件名格式 `组件名.module.css` - 每个组件文件不超过200行，超出则拆分 - 事件处理函数命名：handle + 动作，如 handleClick、handleSubmit

这三份规则文件加起来不到100行，但覆盖了日常开发90%的场景。配好之后，Cursor生成的代码基本能直接用，不需要大改。

3. .cursorignore：别让无关文件拖慢你的AI响应

3.1 为什么需要.cursorignore

.cursorignore的作用和.gitignore类似，但目标不同。.gitignore是告诉Git哪些文件不用版本控制，.cursorignore是告诉Cursor哪些文件不用索引、不用读取。

为什么这件事很重要？因为Cursor在回答你的问题时，会扫描项目文件来构建上下文。如果你的项目里有node_modules、dist、.next这些目录，文件数量可能几万甚至几十万。Cursor如果把这些都扫一遍，响应速度会明显变慢，而且上下文窗口会被无关内容占满，真正有用的代码反而被挤出去了。

我做过一个简单的对比测试：同一个项目，不配.cursorignore时，问一个关于组件的问题，响应时间大约8-12秒；配好.cursorignore排除掉依赖目录和构建产物后，响应时间降到3-5秒。差距非常明显。

3.2 一份可以直接抄的.cursorignore模板

下面这份是我在大多数前端项目里都会用的模板，你可以根据项目类型增减：

# 依赖目录 node_modules/ .pnpm-store/ # 构建产物 dist/ build/ .next/ out/ .output/ # 缓存 .cache/ .parcel-cache/ .turbo/ .eslintcache # 环境与密钥 .env .env.local .env.*.local *.pem *.key # 日志 *.log logs/ # 编辑器与系统 .vscode/ .idea/ .DS_Store Thumbs.db # 测试覆盖率 coverage/ # 锁文件（可选，视项目而定） package-lock.json pnpm-lock.yaml yarn.lock

关于锁文件要不要排除，有个小争议。排除的好处是减少索引量，坏处是Cursor看不到你用的具体依赖版本。我的做法是：如果项目依赖比较稳定，就排除；如果经常需要Cursor帮你排查依赖冲突问题，就保留。

3.3 排除规则写错了会怎样：两个真实翻车案例

案例一：把src/误排除了。有一次我复制了一份别人的.cursorignore模板，里面有一行src/generated/，我手滑写成了src/，结果Cursor完全看不到我的源码，问它什么问题都答"我无法找到相关文件"。排查了十几分钟才反应过来。所以写完.cursorignore后，一定要检查一下有没有误伤源码目录。

案例二：排除了类型定义文件。有个项目我把*.d.ts排除了，想着这些是自动生成的不用管。结果Cursor生成代码时完全不知道有哪些全局类型可用，老是给我生成重复的类型定义。后来把*.d.ts从排除列表里去掉，问题就解决了。

提示：.cursorignore的语法和.gitignore基本一致，支持*通配符、/目录分隔、!取反。但注意，Cursor对!取反的支持不如Git完善，复杂场景建议直接用白名单思路，只排除明确不需要的。

3.4 大项目里的分层忽略策略

如果你的项目特别大（比如monorepo），一刀切的.cursorignore可能不够用。这时候可以考虑分层策略：根目录放一份全局的.cursorignore，各个子包目录下再放各自的.cursorignore。Cursor会合并读取。

比如一个典型的monorepo结构：

monorepo/ ├── .cursorignore # 全局排除 ├── packages/ │ ├── web/ │ │ └── .cursorignore # web包专属排除 │ ├── admin/ │ │ └── .cursorignore # admin包专属排除 │ └── shared/ │ └── .cursorignore # shared包专属排除

全局的排除node_modules、.git这些通用目录，各子包排除自己特有的构建产物和临时文件。这样既保证了覆盖面，又不会误伤。

4. 编辑器层面的配置：中文回复、模型选择与快捷键

4.1 让Cursor用中文回复你的三种方法

很多人希望Cursor用中文回复，但默认情况下它经常中英文混着来。有三种方法可以解决：

方法一：在规则文件里声明。在general.mdc里加一行"所有回复使用中文"。这是最省事的方式，一次配置全局生效。但缺点是规则文件主要影响代码生成，对聊天回复的约束力有时不够强。

方法二：在对话中明确要求。每次开新对话时，第一句话就说"请用中文回复我"。这个方法最直接，但每次都要说一遍，比较烦。

方法三：修改用户级别的设置。在Cursor的设置里找到"Rules for AI"（AI规则）选项，在里面写上"Always respond in Chinese"。这个是用户级别的，对所有项目生效，不用每个项目都配。

我自己的做法是方法一加方法三组合：项目规则里写中文要求，用户设置里也写一份。双保险，基本不会出现英文回复的情况。

4.2 模型选择：不同任务用不同模型

Cursor支持切换不同的底层模型，不同模型在不同任务上的表现差异挺大的。根据我的使用经验：

具体选哪个模型，取决于你账号里可用的模型列表。我的建议是：日常补全用一个轻量快速的，遇到复杂任务时手动切换到更强的模型。不要所有任务都用最强的那个，一来浪费额度，二来响应慢影响心流。

4.3 快捷键与交互习惯的调整

Cursor默认的快捷键和VS Code基本一致，但有几个AI相关的快捷键值得自定义：

• Cmd/Ctrl + K：行内编辑，选中代码后直接让AI修改
• Cmd/Ctrl + L：打开聊天面板
• Cmd/Ctrl + I：打开Composer（多文件编辑）
• Tab：接受补全建议

我个人的调整是把Cmd/Ctrl + L改成了Cmd/Ctrl + Shift + L，因为原来的组合和VS Code的"选中当前行"冲突了。这个看个人习惯，没有标准答案。

另外一个小技巧：Cursor的聊天面板支持@符号引用文件、@Codebase引用整个代码库、@Docs引用文档。善用这些引用符号，能让AI更精准地理解你的意图。比如你想让AI参考某个已有组件的写法，直接@那个文件就行，比用文字描述快得多。

4.4 免费额度的合理分配

Cursor的免费额度是有限的，怎么把有限的额度用在刀刃上，是个值得琢磨的事。我的策略是：

• 简单补全让它自动触发，不用刻意省
• 复杂任务先用免费额度试，如果效果不好再考虑其他方案
• 重复性的代码生成（比如根据模板生成CRUD），写好规则文件让一次生成到位，减少来回修改消耗
• 能用行内编辑解决的，不开聊天面板，因为行内编辑消耗的额度通常更少

说到底，配置做得好，一次生成就到位，消耗的额度自然就少。配置做得差，来回改十次，额度很快就见底了。

5. 实战验证：配置前后效率对比与常见问题排查

5.1 一个真实项目的配置前后对比

拿我最近做的一个后台管理项目举例。项目是React 18 + TypeScript + Ant Design 5，大概30个页面，50多个组件。

配置之前的状态：让Cursor生成一个列表页，它给我生成了类组件（我用的是函数式）、用了fetch而不是项目封装的request、样式用了内联style而不是CSS Modules、类型定义直接写在组件文件里而不是放到types/目录。基本上生成完要手动改七八处。

配置之后的状态：同样生成一个列表页，组件写法正确、请求走封装函数、样式用CSS Modules、类型定义自动放到types/目录、命名规范全部符合。需要手动改的地方降到一两处，有时候甚至直接能用。

这个差距不是模型变强了，而是规则文件让模型"知道"了项目的约定。这就是配置的价值。

5.2 规则不生效的排查清单

配了规则但发现Cursor没按规则来？按这个清单逐项排查：

1. 文件位置对不对。.cursor/rules/目录必须在项目根目录下，不能放在子目录里（除非你用的是分层配置）。
2. YAML头部格式对不对。---必须是文件的第一行，description和globs的缩进要正确。YAML对格式很敏感，多一个空格都可能解析失败。
3. globs匹配对不对。检查你的文件路径是否真的匹配了globs里写的模式。可以在Cursor的规则面板里看每条规则的状态，确认是否生效。
4. 规则内容有没有冲突。如果两条规则对同一件事有不同要求，Cursor可能会随机选一条。检查一下有没有矛盾的规则。
5. 有没有重启。修改规则文件后，有时候需要重启Cursor或者重新加载窗口才能生效。
6. 规则是不是写得太模糊。"写高质量的代码"这种规则等于没写。规则要具体、可执行。

5.3 几个我踩过的坑和对应的解法

坑一：规则文件写太长，AI反而抓不住重点。一开始我把整个项目的架构文档都贴进去了，结果Cursor生成代码时经常忽略关键约束。后来精简到只保留最核心的几条，效果反而好了。规则文件不是文档，是约束清单，越精炼越好。

坑二：.cursorignore排除了.env文件，导致AI不知道环境变量名。这个其实不算坑，是安全考虑。但如果你需要AI知道环境变量的结构（不涉及具体值），可以在规则文件里描述一下有哪些环境变量，比如"API基础路径通过VITE_API_BASE_URL配置"。

坑三：不同项目的规则文件互相复制，导致水土不服。每个项目的技术栈和规范都不一样，规则文件不能直接抄。我现在的做法是维护一份"基础模板"，新项目基于模板改，而不是直接复制。

坑四：忘了配.cursorignore，项目大了之后响应特别慢。这个前面说过了，养成习惯，新项目第一件事就是配.cursorignore。

5.4 团队协作中的规则文件管理

如果是团队开发，规则文件应该纳入版本控制，让所有人共享同一套配置。但要注意几点：

• 规则文件里不要写个人的偏好（比如"我喜欢用单引号"），只写团队共识
• 定期review规则文件，随着项目演进更新
• 新成员入职时，把规则文件作为项目文档的一部分介绍
• 如果团队里有人用不同的编辑器，规则文件的内容可以作为编码规范的参考文档

我现在的团队就是把.cursor/rules/目录纳入Git管理，每次代码review时如果发现AI生成的代码有共性问题，就更新规则文件。这样规则文件成了一个"活的"编码规范，比写在Confluence里的文档实用多了。

6. 进阶玩法：让规则文件成为你的编码规范载体

6.1 从规则文件反推项目规范

有个很有意思的用法：如果你接手了一个没有明确编码规范的老项目，可以先让Cursor分析代码库，总结出实际的编码习惯，然后把这些习惯写成规则文件。这样既梳理了项目规范，又让AI后续生成的代码能保持一致。

具体操作：打开Cursor聊天，输入"分析这个项目的代码风格和编码习惯，包括命名规范、文件组织、常用模式等，总结成一份规则文件"。它会扫描代码库给出总结，你再人工审核调整一下，就是一份很实用的规则文件。

6.2 规则文件的版本迭代思路

规则文件不是一次写完就完事了，它应该随着项目一起迭代。我的做法是：

• 每次发现AI生成的代码有重复性问题，就想想是不是规则没写清楚，是的话就补一条
• 每个月review一次规则文件，删掉过时的、合并重复的
• 重大重构后，同步更新规则文件

这样坚持几个月，规则文件会越来越贴合项目实际，AI生成的代码也会越来越准。

6.3 多项目复用的规则模板管理

如果你同时维护多个项目，可以建一个"规则模板库"，把通用的规则抽出来，各项目按需引用。比如：

rule-templates/ ├── base-frontend.mdc # 前端通用规范 ├── base-backend.mdc # 后端通用规范 ├── react.mdc # React专属规范 ├── vue.mdc # Vue专属规范 └── testing.mdc # 测试规范

新项目启动时，把需要的模板复制过去，再补充项目特有的规则。这样既保证了规范性，又减少了重复劳动。

我在实际使用中最大的体会是：Cursor的配置不是一劳永逸的事，而是一个持续优化的过程。刚开始可能觉得麻烦，但每配好一条规则，后面就能少改一次代码。积少成多，省下来的时间非常可观。另外，规则文件写得好不好，直接反映了你对项目的理解程度——如果你自己都说不清楚项目的编码规范，那AI更不可能猜对。所以配置规则文件的过程，其实也是梳理项目规范的过程，一举两得。