你已经会用 .cursorrules 文件了。但如果你在一个 5 人以上的团队里，或者在维护多个不同类型的项目，基础的单文件规则远远不够。

这篇文章讲 Cursor Rules 的高级用法——让规则真正成为团队的"AI 编码标准"。

一、Cursor Rules 的层级系统

Cursor 支持多层规则叠加：

~/.cursor/rules/          ← 全局规则（所有项目）
  └── global.md
project/
  ├── .cursorrules         ← 项目级规则（旧格式，仍支持）
  └── .cursor/
      └── rules/
          ├── base.mdc     ← 项目基础规则
          ├── frontend.mdc ← 前端专属规则（按需激活）
          ├── backend.mdc  ← 后端专属规则
          └── testing.mdc  ← 测试规则

规则优先级：项目规则 > 全局规则，更具体的规则覆盖更通用的规则。

二、.mdc 格式：自动触发规则

新的 .mdc 格式比 .cursorrules 强大得多，支持按文件类型自动激活：

markdown

description: React 组件开发规范
globs: ["src/components//*.tsx", "src/pages//*.tsx"]
React 组件规范
命名规则
组件文件名和函数名必须用 PascalCase
Props 接口命名为 {ComponentName}Props
事件处理函数命名为 handle{EventName}
代码结构
组件文件结构：imports → types → component → exports
不超过 200 行；超过时拆分成子组件
不在组件内写业务逻辑，提取到 hooks
状态管理
服务器状态用 React Query
客户端全局状态用 Zustand
表单状态用 React Hook Form + Zod
禁止事项
禁止使用 any 类型
禁止 inline style（除非动态值）
禁止在 JSX 里写复杂逻辑，提取到变量

这个规则只会在打开 src/components/ 或 src/pages/ 目录下的 TSX 文件时自动激活，不会干扰其他文件。

三、团队规则共享方案

方案1：规则文件提交到 git

在 .cursor/rules/ 目录下创建规则文件，直接提交到代码仓库。团队成员 clone 后自动获得相同的 AI 辅助规则。

规则文件结构建议：

.cursor/rules/
├── 00-project-overview.mdc   # 项目整体介绍（永远激活）
├── 01-code-style.mdc         # 代码风格（所有文件）
├── 02-react-components.mdc   # React 组件规范（tsx 文件）
├── 03-api-routes.mdc         # API 路由规范（app/api/ 目录）
├── 04-database.mdc           # 数据库操作规范（/db/ 目录）
└── 05-testing.mdc            # 测试规范（**/*.test.* 文件）

方案2：脚本统一同步

如果团队有多个项目，可以维护一个"规则中心"仓库，用脚本同步：

bash
#!/bin/bash
sync-cursor-rules.sh
RULES_REPO="git@github.com:your-org/cursor-rules.git"
TEMP_DIR=$(mktemp -d)
git clone $RULES_REPO $TEMP_DIR
cp -r $TEMP_DIR/rules/* .cursor/rules/
rm -rf $TEMP_DIR
echo "Rules synced!"

四、高级规则技巧

4.1 用规则注入项目上下文

markdown

description: 项目架构上下文（所有文件激活）
globs: ["**/*"]
项目概览
这是一个 B2B SaaS 项目，主要功能是帮助企业管理 AI 工具订阅。
核心概念
Organization：企业账户，可以有多个 User
Subscription：订阅记录，关联 Organization 和 Plan
Plan：订阅计划（Free/Pro/Enterprise）
技术栈
前端：Next.js 15 + TypeScript + Tailwind CSS v4
后端：Supabase（PostgreSQL + Edge Functions）
认证：Clerk
部署：Vercel
重要约定
所有数据库操作通过 src/lib/db/ 下的函数进行
API 路由不直接查询数据库
用户权限检查在中间件层完成

4.2 防止常见错误的规则

markdown
安全检查清单（每次生成代码时自动检查）
在生成涉及以下场景的代码时，必须主动检查：
SQL 注入：所有数据库查询必须使用参数化
XSS：用户输入在 HTML 渲染前必须转义
CSRF：修改状态的 API 必须验证来源
权限越权：用户只能访问自己的数据，必须在查询中加 userId 过滤
敏感数据：日志里不能出现密码、token、手机号

4.3 规则里的示例代码

好的规则会包含"要这样写"和"不要这样写"的对比：

markdown
API 错误处理规范
✅ 正确写法：

typescript export async function GET(req: Request) { try { const data = await fetchData(); return Response.json({ data }); } catch (error) { console.error('[API Error]', error); return Response.json({ error: 'Internal server error' }, { status: 500 }); } }

❌ 禁止写法（不捕获错误）：

typescript export async function GET(req: Request) { const data = await fetchData(); // 没有 try-catch return Response.json({ data }); }

五、规则维护建议

定期 review：每个月检查一次规则是否还准确（技术栈升级后规则可能过时）

团队共建：规则应该是团队共识，不是一个人制定

渐进式添加：从最重要的规则开始，不要一次写几百行规则（Cursor 读不完）

测试规则效果：写完规则后，让 Cursor 生成一段代码，看看是否符合预期

---

延伸阅读

Claude Code 完整使用教程

Windsurf vs Cursor vs Claude Code 对比

GitHub Copilot 进阶技巧 2026