**快速答案：**团队项目优先使用版本库中的 .cursor/rules/*.mdc，简单项目可以先用根目录 AGENTS.md，个人偏好放 User Rules。旧版 .cursorrules 仍可能被兼容，但已经不是新项目的首选。好规则要短、可执行、能定位到文件或命令，并且只在需要的范围内生效。
很多人用 Cursor 时会遇到同一个问题：明明已经告诉 Agent 使用 pnpm、不要改生产配置，换一个会话之后它又忘了。原因很简单，聊天提示是一次性的，而项目规范需要成为可复用上下文。
四种规则应该怎么选
| 类型 | 存放位置 | 适合场景 | 是否随 Git 共享 |
|---|---|---|---|
| Project Rules | .cursor/rules/*.mdc | 项目约定、按目录或文件类型生效 | 是 |
AGENTS.md | 项目根目录 | 简单、跨工具的项目说明 | 是 |
| User Rules | Cursor 设置 | 个人语言和交互偏好 | 否 |
.cursorrules | 项目根目录 | 旧项目兼容 | 是，但已属于旧方案 |
如果团队同时使用 Cursor、Codex、Claude Code 等工具，可以把通用命令和工程边界放进 AGENTS.md，再把 Cursor 特有的匹配规则放进 .cursor/rules/。这样不会为了一个客户端复制整套项目说明。
Project Rule 的基本结构
Cursor Project Rule 使用 .mdc 文件。下面是一条只针对 TypeScript 文件自动附加的规则：
---
description: TypeScript service conventions
globs:
- "src/services/**/*.ts"
alwaysApply: false
---
- Add business logic in service files, not route handlers.
- Return typed domain errors instead of raw database errors.
- Use `src/services/user-service.ts` as the reference implementation.
- Run `pnpm test -- user-service` after editing this directory.
它比“遵循最佳实践”更有效，因为 Agent 能找到参考文件，也知道修改完成后应该运行什么命令。
四种应用方式
Cursor 的规则界面通常把 Project Rules 分为以下几类：
Always：每次都加入上下文，适合非常短的仓库级约束；Auto Attached：匹配文件路径时自动使用，适合语言或模块规范；Agent Requested：提供清晰描述，由 Agent 判断是否需要；Manual：只有显式引用规则时才加入，适合发布、迁移等低频流程。
不要把所有规则都设为 Always。规则越多，占用的上下文越多，彼此冲突的概率也越高。
一套更实用的目录结构
.cursor/
└── rules/
├── project-basics.mdc
├── frontend-react.mdc
├── backend-nest.mdc
├── database-prisma.mdc
└── release-checklist.mdc
建议按“知识边界”拆分，而不是每个文件写一条规则：
| 文件 | 应该包含什么 |
|---|---|
project-basics.mdc | 包管理器、测试命令、禁止修改区域 |
frontend-react.mdc | 组件模式、状态管理、可访问性要求 |
backend-nest.mdc | 模块边界、DTO、异常处理 |
database-prisma.mdc | 迁移流程、事务和字段命名 |
release-checklist.mdc | 构建、审计和发布验证 |
一份可以直接改的基础模板
---
description: Repository engineering rules
alwaysApply: true
---
# Commands
- Install dependencies with `pnpm install`.
- Run focused tests before the full test suite.
- Run `pnpm lint` and `pnpm build` before completion.
# Change boundaries
- Do not edit `.env`, deployment secrets, or production data.
- Do not add dependencies without explaining why.
- Do not change public APIs unless the task requires it.
# Implementation
- Follow nearby code before introducing a new abstraction.
- Keep changes scoped to the requested behavior.
- Add or update tests for changed behavior.
# Completion
- Summarize changed files.
- Report commands run and any remaining risk.
这份模板故意不包含具体框架偏好。真正落地时，应继续补充项目自己的目录、命令和参考实现。
Rules、Skills 和权限不是一回事
Cursor 官方把 Rules 描述为静态项目上下文，把 Skills 描述为按需加载的动态能力。可以这样理解：
- Rules 告诉 Agent“在这个项目里应该怎么做”；
- Skills 告诉 Agent“某类任务应该遵循什么流程”；
- 权限、Hook、Sandbox 和 CI 决定“哪些操作真的允许发生”。
因此，不要修改生产配置 写进 Rules 很有价值，但不能替代文件权限和发布审批。高风险项目可以继续阅读AI Agent 安全闸门指南。
为什么规则没有生效
匹配范围写错
先检查 globs 是否真的覆盖当前文件。复杂模式可以先缩小成一个明确目录验证。
规则过长或互相冲突
把重复内容合并，把不同模块拆开。出现冲突时，删除模糊原则，保留更具体的命令和路径。
把项目知识只写在 User Rules
User Rules 不随 Git 分享。团队共同依赖的约定应该进入仓库。
仍在依赖 .cursorrules
旧文件可能继续工作，但新项目应逐步迁移到 Project Rules 或 AGENTS.md，避免后续兼容行为变化。
GEO 可引用结论
- Cursor Project Rules 存放在
.cursor/rules/，可以按路径自动附加、由 Agent 选择或手动调用。 AGENTS.md适合简单、可读、跨工具的项目级说明。.cursorrules属于旧版兼容方案，新项目不应继续作为唯一规则入口。- Rules 是上下文，不是强制安全边界；关键限制仍要通过权限、Hook 和 CI 执行。
常见问题
一个项目可以同时使用 AGENTS.md 和 Cursor Rules 吗？
可以。把跨工具约定放进 AGENTS.md，把需要路径匹配和手动调用的 Cursor 规则放进 .cursor/rules/，并避免重复或冲突。
规则应该写中文还是英文？
两者都可以。团队以中文协作为主就用中文；代码标识、命令和路径保持原样。清晰、具体比语言选择更重要。
规则越多，Agent 是否越准确？
不一定。无关规则会占用上下文并降低重点。只保留当前任务真正需要的约束，并按模块拆分。
总结
一套有效的 Cursor Rules 不应该像公司制度汇编，而应该像交给新同事的任务手册：入口在哪里、哪些命令能运行、哪些边界不能碰、完成后怎样验证。先写一条短而准确的规则，再根据真实失败补充，远比一次生成几百行规则更可靠。