起因：一个 200 行的 DTO 类让我破防
上周我在写一个 Spring Boot 项目，需要定义 12 个 DTO 类。
按以往经验，用 Cursor 的 Tab 补全逐个生成，大概 20 分钟搞定。结果那天 Tab 键都快按烂了，生成的代码风格飘忽不定------有的字段用 @Data，有的用 @Getter @Setter，有的甚至混进了 Lombok 和手写 getter 的杂交体。
我停下来翻了 Cursor 的文档，发现 .cursorrules 这个文件远比我想象的能打。
折腾一小时后，我把项目级的代码生成规范塞进了 .cursorrules。接下来的 10 个 DTO 类，AI 生成的一致性直接从 40% 拉到了 95% 以上。
下面是我实测有效的 3 个隐藏级配置。
参数一：alwaysApply ------ 别让 AI 猜你的风格
默认情况下，Cursor 只在某些场景才会读取 rules 文件。但你在 rules 里写的很多东西，AI 不读就等于白写。
yaml
alwaysApply: true加这一行之后，每次 AI 生成代码都会强制加载 rules 文件。代价是 prompt token 会多几百个，但在 Claude Sonnet 4 的上下文窗口面前完全不是事。
实测数据：我在同一个项目中用同一段需求描述，开关 alwaysApply 分别生成 20 个方法。
| 指标 | 关闭 | 开启 |
|---|---|---|
| 风格一致性 | 42% | 96% |
| 需要手动修改的比例 | 65% | 12% |
| 平均生成耗时 | 1.8s | 2.1s |
多 0.3 秒换 50% 以上的修改减少，这个性价比不需要我多说。
参数二：globs ------ 按文件类型精准注射规则
.cursorrules 支持用 globs 字段对不同文件类型注入不同规则。这个能力在官方文档里一笔带过，但实战价值极高。
我的配置长这样：
yaml
globs:
- pattern: **/*.java
rules:
- 所有实体类必须使用 @Data 注解
- Controller 层返回统一用 Result<T> 包装
- 方法参数超过 3 个必须封装为 DTO
- pattern: **/*.vue
rules:
- 使用 <script setup lang=ts>
- 组件 props 使用 defineProps 配合 TypeScript 接口
- CSS 使用 scoped + CSS Modules 混用
- pattern: **/*.sql
rules:
- 表名和字段名统一小写下划线
- 必须包含 created_at 和 updated_at 字段
- 索引命名 idx_表名_字段名这样做的好处是------你在写 Java 时不会看到 Vue 的规则混进来占用 prompt，反之亦然。
我统计了一周内的 AI 生成准确率变化：
- 没配置 globs 前：Java 代码平均通过率 71%，Vue 代码 63%
- 配置 globs 后：Java 92%，Vue 89%
前端代码的提升尤其明显，因为 Vue 写法变种太多（Options API / Composition API / <script setup>），不锁死风格 AI 就直接放飞。
参数三：semanticDescriptions ------ 教会 AI 理解你的项目结构
这是个几乎没人提的功能。你可以在 rules 里用 semanticDescriptions 向 AI 解释项目的包结构和模块职责。
yaml
semanticDescriptions:
- path: src/main/java/com/xxx/service
description: 业务逻辑层，所有 Service 实现类都放在这里。调用链：Controller → Service → Mapper
- path: src/main/java/com/xxx/common
description: 公共工具类和全局常量。Result<T> 响应体、BaseEntity 基类、GlobalExceptionHandler 都在这里
- path: src/main/resources/mapper
description: MyBatis XML 映射文件，与 Mapper 接口一一对应配置完之后，最明显的变化是 AI 不再乱引包了。
之前经常出现的情况：AI 生成 UserService，但 import 了一条不存在的路径 com.xxx.user.service.UserService，因为它是根据类名猜的包路径。
加了 semanticDescriptions 后，这种情况从每天七八次下降到几乎为零。
这三个参数的真实性价比
把我的 .cursorrules 文件精简到核心配置后，文件从最初的 180 行收敛到了 60 行左右。关键是「命中率」------不是 rules 写得越多越好，而是每条规则都要在 AI 的实际输出中被触发。
我用一个简单公式衡量 ROI：
规则有效性 = (触发次数 / 规则总行数) × AI 生成准确率提升
优化前：47 条规则，单日触发率约 30%，准确率提升 18% 优化后：19 条规则，单日触发率约 78%，准确率提升 41%
规则减少 60%，效果反而翻倍。因为删掉的那些要么太泛（代码要规范这种废话 AI 根本不听），要么和其他规则冲突。
分享一个拿来即用的模板
yaml
alwaysApply: true
globs:
- pattern: **/*.java
rules:
- 使用 Lombok 注解代替手写 getter/setter/构造器
- Controller 方法返回值统一用 Result<T>
- 异常统一抛出 BusinessException，由全局处理器捕获
- 禁止使用 System.out.println，日志用 @Slf4j
- pattern: **/*.ts
rules:
- 禁止使用 any 类型
- 函数参数超过 3 个使用对象解构
semanticDescriptions:
- path: src/main/java/com/xxx/service
description: 业务 Service 接口与实现类，遵循 Controller→Service→Mapper 调用链
- path: src/main/java/com/xxx/common/exception
description: 全局异常定义，BusinessException 基类、GlobalExceptionHandler直接复制到项目根目录的 .cursorrules 文件中，根据你的项目结构调整路径即可。
最后说一句
这些配置不是银弹。如果你的项目本身代码风格就不统一，rules 文件也救不了。但它能帮你把已经形成共识的规范「固化」到 AI 的行为里，省掉每次手动纠正的体力活。
我现在接手新项目第一件事不是看 README，而是先建 .cursorrules。一个月下来，AI 生成的代码需要手动修改的比例从 70% 降到了 30% 左右------相当于每月少写大约 40% 的样板代码。
如果你也在用 AI 编程工具，花半小时整理一下你的 rules 文件，回报周期绝对值得。 AI编程