写过前端的人都以为 AI 编程只能靠手指点——今天 Cursor 把这件事用两套规则彻底原生化了

写过前端的人都以为 AI 编程只能靠手指点——今天 Cursor 把这件事用两套规则彻底原生化了

配了三年 Cursor，每次让它写代码都要在对话框里反复说「不要用 default export」「样式要用 CSS Modules」「API 错误要抛 throw new Error」。说多了 AI 烦，说少了 AI 自由发挥，最后还是自己手动改。

Cursor 2026 年把这件事彻底原生化了：不是一条 .cursorrules 打天下，而是给你两套规则体系，让 AI 真正知道你项目长什么样。

---

*第一套：.cursor/rules/.mdc，按文件类型精准施教**

旧版 .cursorrules 是根目录下一条文档，规则全写在一起，全局生效。用久了会发现：你在写 React 组件，Cursor 却读到了后端 Python 的 API 规范提示——上下文被污染，规则越写越乱。

新系统用 .cursor/rules/ 目录替代单一文件，每个 .mdc 规则文件都有 YAML frontmatter 声明适用范围和激活方式：

---
description: "React 组件规范"
globs: "src/**/*.tsx"
alwaysApply: false
---

globs 用 .gitignore 语法：*/.tsx 匹配所有 tsx 文件，app/api/*/.ts 匹配 API 目录下的所有 TypeScript 文件。多个模式逗号分隔。

四种激活模式决定何时加载：

• Always：每次请求都注入全局规则，比如项目技术栈说明
• Auto Attached：匹配的 glob 文件出现在上下文时自动加载
• Agent Requested：AI 根据规则描述自行判断是否需要
• Manual：只在聊天里 @-mention 该规则时才加载

实战例子，新建 .cursor/rules/react-patterns.mdc：

---
description: "React 组件规范"
globs: "src/**/*.tsx"
alwaysApply: false
---

内容：

// 使用命名的函数组件，禁止 default export
// 组件名首字母大写，事件处理函数加类型标注
// Props 接口放在组件上方，注释说明用途

// 正确示范
export interface ButtonProps {
  variant: 'primary' | 'secondary';
  children: React.ReactNode;
  onClick?: () => void;
}

export function Button({ variant, children, onClick }: ButtonProps) {
  return <button className={variant} onClick={onClick}>{children}</button>;
}

再新建 .cursor/rules/api-routes.mdc 专门管后端路由：

---
description: "API 路由规范"
globs: "app/api/**/*.ts"
alwaysApply: false
---

内容：

// 所有请求体必须用 Zod 验证
// 错误响应统一格式：{ error: string, code: string }
// 200 返回 NextResponse.json(data)
// 400 Zod 验证失败，500 其他异常，打印 console.error

这样写 React 组件时，Cursor 只读 react-patterns.mdc；写 API 路由时，Cursor 只读 api-routes.mdc——上下文干干净净，规则各司其职。

---

优先级：同文件被多个规则匹配时，内容会合并注入

.cursor/rules/ 里的 .mdc 文件不是互斥的——如果一个 tsx 文件同时匹配 react-patterns.mdc 和 types.mdc（假设你还有个 types.mdc 写 TypeScript 规范），Cursor 会把两份规则内容都注入上下文。

这正是模块化的精髓：把 API 规范、类型规范、测试规范拆成独立文件，按需组合，而不是把所有规则塞进一个大文件。

---

第二套：多根工作区，跨仓库统一上下文

Cursor 支持同时打开多个仓库——File → Add Folder to Workspace。打开后，Cursor 会同时读每个仓库的 .cursorrules，让 AI 理解跨仓库的依赖关系。

比如 monorepo 结构：

workspace/
├── apps/web/      # Next.js 前端
├── apps/api/      # Express 后端
└── packages/shared/ # 共享类型

在 apps/web/.cursorrules 里写清楚前端用什么技术栈，在 apps/api/.cursorrules 里写后端规范。Cursor 会同时理解两套规则，跨仓库改 API 时会知道要同步更新 shared 类型定义。

实战经验（Dyson，6个月多根工作区用户）：跨仓库重构时间减少约 60%，协调沟通 ping 次数大幅下降。

两个注意事项：

1. 文件夹顺序影响 AI 注意力权重：第一个添加的仓库权重最高，把最常用的放在最上面。
2. 不要把所有仓库都加进去：只加当前 session 相关的，过多仓库会吃满上下文窗口。

---

怎么写真正有用的规则

Cursor 官方文档的建议：规则应该来自真实摩擦，而不是复制粘贴风格指南。

起步做法：建一个 .cursor/rules/core.mdc，alwaysApply: true，写 3-5 条最核心的全局规范，控制在 20 行以内。然后每天用，遇到 Cursor 做了让你叹气的事，就问一句「这是不是应该写成规则」。

两周后，你的规则集就长成了，Cursor 真正开始像「读过你代码的人」而不是「随机生代码的 AI」。

---

结论

Cursor Rules 的本质不是堆提示词，而是让 AI 理解你项目的上下文结构。.cursor/rules/*.mdc 解决的是「不同文件类型需要不同规则」的问题；多根工作区解决的是「跨仓库需要统一上下文」的问题。

规则写对了，Cursor 不只是帮你写代码——它会按你项目原有的风格和架构去写，这才是 AI 编程辅助该有的样子。