Cursor 完全解析：规则 (Rules) 与 MCP 插件实战指南 (2025 版)

大家好，我是老金。今天咱们聊聊 Cursor 这个 AI 代码编辑器。这玩意儿出来有段时间了，迭代也挺快 (现在都 0.49.x 版本了，基于 VS Code 1.93.1 或更高版本) (1)。身边不少朋友都在用，或者在观望。它跟 GitHub Copilot、Windsurf 这些工具有啥不一样？核心优势在哪？特别是它那个听起来有点玄乎的 “Rules” 和 “MCP” 到底是个啥，怎么用才能真正提高咱们写代码的效率？

今天这篇，咱就把它掰开了揉碎了，讲透彻。从基础概念到深度解析，再到实战案例和竞品对比，争取让你看完就能上手，还能跟人吹吹牛。内容有点多，咱们分章节慢慢来。

一、引言：Cursor 是啥？为啥要关注它？

简单说，Cursor 就是一个把 AI 能力深度集成到代码编辑器里的工具，你可以把它看作一个魔改版的 VS Code (4)。它不满足于像 Copilot 那样只做个“副驾驶”，而是想成为一个更主动、更懂你项目的“结对编程伙伴” (6)。

它的核心特点包括：

1. 深度代码理解：通过索引你的项目代码库，能更好地理解上下文，提供更靠谱的代码补全和建议 (5)。

2. 多种 AI 交互模式：

• Tab 补全 (Cursor Tab)：智能预测并补全代码，甚至能自动导入 (1)。

• ⌘K (Cmd/Ctrl+K) 行内编辑：选中代码，按 ⌘K，用自然语言描述修改意图，AI 直接帮你改 (7)。

• 聊天面板 (Chat)：核心交互区，包含多种模式 (7)：

• 提问 (Ask)：像跟人聊天一样问代码问题，可以 @ 文件、@ 文件夹、@ 网页、@ Git 历史来提供精确上下文 (7)。

• 编辑 (Edit)：类似 ⌘K，但更适合多文件、复杂的修改。

• Agent 模式：这是 Cursor 的一大特色，能执行更复杂的、跨文件的任务，比如根据需求实现新功能、重构代码、修复 Bug 等，还能调用外部工具 (通过 MCP) 和执行终端命令 (7)。

1. 多模型支持：可以选择不同的 AI 大模型，比如 OpenAI 的 GPT-4o、GPT-4.1，Anthropic 的 Claude 3.7 Sonnet (包括普通版和 MAX 版)、Claude 3.5 Sonnet/Haiku，Google 的 Gemini 2.5 Pro (包括 MAX 版) 等，甚至还有免费模型 (1)。特别是 Claude 3.7 Sonnet，现在是很多场景下的默认或推荐模型，性能很强 (12)。

2. 可定制化：这就是咱们今天要重点讲的 Rules 和 MCP。它们让 Cursor 不再是一个通用的 AI 助手，而是可以根据你的项目、你的团队、你的习惯进行深度定制的专属工具。

[图示：Cursor 编辑器主界面截图 (中文注释：展示聊天面板、代码编辑区、@ 符号上下文引用)]

为啥要关注它？因为 AI 辅助编程是大势所趋。Cursor 代表了 AI 与 IDE 深度融合的一个重要方向。搞懂它，特别是它的 Rules 和 MCP，能让你在 AI 时代写代码更高效、更轻松。

二、基础篇：搞懂 Cursor 的两个“秘密武器”

1. 规则 (Rules) 系统：给 AI 立规矩

这是啥？

简单理解，Rules 就是你给 Cursor 的 AI 定下的一系列“规矩”或“指导原则” (17)。它告诉 AI 在你的项目里，代码应该怎么写、遵循什么规范、使用哪些库、避免哪些坑。

为啥重要？

大模型虽然聪明，但它不知道你项目的具体情况。比如，你项目用的是 React + TypeScript + Tailwind CSS，有一套自己的组件规范和接口格式。如果不告诉 AI，它可能会生成用 Vue 写的代码，或者用了你不想要的库，或者代码风格跟你团队格格不入。Rules 就是解决这个问题的，它把这些项目级的上下文、偏好、工作流固化下来，让 AI 的输出更符合你的要求，减少返工 (19)。

规则的类型 (20)

Cursor 支持三种类型的规则：

1. 项目规则 (Project Rules)：这是目前推荐的方式。规则文件存储在项目根目录下的 .cursor/rules/ 文件夹里，通常是 .mdc (Markdown Cursor) 文件。这些规则是项目的一部分，可以跟代码一起纳入版本控制 (Git)，方便团队共享和协作 (20)。

2. 用户规则 (User Rules)：这是全局规则，在 Cursor 的设置里配置 (Settings > General > Rules for AI)。这里的规则对你所有的项目都生效，适合定义一些个人的编码习惯或通用的指令，比如“总是用中文回答”、“代码要简洁”等 (20)。用户规则是纯文本格式，不支持 .mdc 的元数据 (20)。

3. .cursorrules (Legacy)：这是老版本的项目规则文件，直接放在项目根目录。现在虽然还支持，但官方已经不推荐了，建议迁移到 .cursor/rules/ 目录下使用 .mdc 文件 (18)。

项目规则 (.mdc) 的结构 (18)

.mdc 文件本质上是 Markdown 文件，但头部可以包含元数据 (用 --- 分隔)，用来控制规则的行为：

Code snippet

---
# 元数据区 (Metadata Section)
description: 这条规则是干啥的 (比如：React 组件编码规范)
globs: ["src/components/
**/*.tsx", "src/features/**
/*.tsx"] # 文件匹配模式，决定何时自动应用 (Auto Attached)
# 或者 alwaysApply: true # 如果是 Always 类型
# 或者 tags: ["frontend", "react"] # 标签，可能用于未来管理或 AI 选择
# 或者 priority: 1 # 优先级 (1 最高)，可能用于冲突解决
# 或者 version: 1.0.0 # 版本号
---
# 规则内容区 (Content Section)
这里写具体的规则指令，可以用 Markdown 格式化。
## 组件结构
- 必须使用函数式组件和 Hooks。
- Props 必须用 TypeScript `interface` 定义。
-...
## 状态管理
- 简单状态用 `useState`。
- 跨组件状态优先考虑 `useContext` 或 `useReducer`。
- 复杂全局状态可以使用 Zustand (参考 @./zustand-guidelines.mdc)。
## 引用文件
这是项目配置: @../tsconfig.json
这是基础样式: @../../styles/base.css

• 元数据 (Metadata) (20)：

• description: 规则描述，非常重要，尤其是 Agent Requested 类型，AI 会根据这个描述来判断是否应用此规则。

• globs: 文件匹配模式 (Glob patterns)，用于 Auto Attached 类型，当聊天或编辑涉及到匹配这些模式的文件时，规则会自动加载。

• alwaysApply: 布尔值，用于 Always 类型，设为 true 则规则总是加载。

• tags, priority, version: 可能用于分类、冲突解决和版本管理，具体支持情况看 Cursor 版本。

• 内容 (Content) (20)：

• 就是你给 AI 的具体指令，可以用 Markdown 编写，包含文本、代码示例等。

• @file 引用 (20)：

• 可以在规则内容里通过 @文件名 (如 @../tsconfig.json) 来引用项目中的其他文件，AI 在应用这条规则时，会把被引用文件的内容也一并加载进来作为上下文。这对于提供配置文件、代码模板等非常有用。

项目规则的触发方式 (17)

项目规则 (.mdc) 有几种不同的应用时机：

1. Always (总是应用)：只要在这个项目里使用 AI (聊天或 ⌘K)，这条规则的内容就会被加载。适合定义项目级的基本规范，比如使用的主要语言、框架、代码风格等。元数据里通常设置 alwaysApply: true (20)。(有用户发现不设置 globs 也能达到类似效果 (27))。

2. Auto Attached (自动附加)：当 AI 的上下文涉及到匹配 globs 模式的文件时，这条规则会自动加载。比如，你可以写一条只针对 .tsx 文件的 React 规范，当你在聊一个 .tsx 文件或者让 AI 编辑它时，这条规则就会生效 (17)。

3. Agent Requested (Agent 请求)：规则对 AI 可见，但由 AI 根据当前的对话和任务，自行判断是否需要加载这条规则。这种类型的规则必须提供清晰的 description 元数据，帮助 AI 做决策 (17)。

4. Manual (手动引用)：规则默认不加载，只有当你在聊天中明确使用 @规则文件名 (比如 @react-style-guide) 引用它时，它才会被加载 (17)。

如何创建和生成规则？ (20)

• 手动创建：

• 在项目根目录下创建 .cursor/rules/ 文件夹。

• 在该文件夹下创建 .mdc 文件 (文件名建议用 kebab-case，如 react-components.mdc) (25)。

• 按照 .mdc 格式编写元数据和规则内容。

• 也可以通过 Cursor 的命令面板 (Cmd/Ctrl + Shift + P) 搜索 "New Cursor Rule" 来快速创建 (20)。

• 还可以在 Cursor Settings > Rules > Project Rules 界面管理和创建规则 (20)。

• AI 生成：

• 在聊天中，当你和 AI 就某个编码规范或工作流程达成一致后，可以直接让 AI 帮你生成规则。可以说 “把刚才讨论的内容整理成一条 Cursor 规则” 或使用 /Generate Cursor Rules 命令 (20)。这对于快速固化讨论成果非常方便。

• 网上也有一些工具或仓库可以根据项目文件 (如 package.json) 自动生成规则，比如 cursor.directory/generate (30) 或 cursor-rules-cli (31)。

``

[图示：一个.mdc 规则文件的示例结构 (中文注释：标明元数据区和内容区)]

写好规则的技巧 (17)

• 目标明确，语言清晰：规则要写得像给同事解释一样，避免模糊不清的指令。用简洁、直接的语言。

• 由简入繁：先从最核心的几条规则开始，比如项目使用的技术栈、基本代码风格。跑顺了再逐步增加更细致的规则。

• 结构化组织：对于复杂的项目，可以把规则按功能、模块或类别分成多个 .mdc 文件，并在需要时通过 @ 引用组合起来，或者使用清晰的 Markdown 标题组织单个文件 (17)。

• 提供正反例：光说理论不够，最好能提供具体的代码示例，说明什么是推荐的写法，什么是应该避免的写法 (17)。

• 包含验证步骤：可以要求 AI 在生成代码后进行自我检查，比如“确保所有函数都有 JSDoc 注释”、“检查是否引入了未使用的库” (17)。

• 明确禁止项：对于绝对不能做的事情（比如使用已废弃的 API、不安全的写法），要明确、强硬地禁止 (17)。

• 保持简洁：规则文件不是越长越好。尽量保持在 500 行以内，太长了 AI 可能抓不住重点，也增加 Token 消耗 (20)。

• 充分测试：写完规则后，要用各种不同的 Prompt 来测试 AI 的反应，看看规则是否按预期生效，有没有被误解或忽略 (17)。

• 利用社区资源：GitHub 上有很多优秀的 awesome-cursorrules 或 awesome-cursor-rules-mdc 仓库，可以参考或直接使用 (28)。Cursor 官方论坛和 cursor.directory 也是找灵感的好地方 (23)。

Rules 系统是 Cursor 的一大法宝，善用它，能让 AI 更懂你的项目，成为真正得力的助手。

2. 模型上下文协议 (MCP)：让 AI 拥有“超能力”

这是啥？

MCP，全称 Model Context Protocol (模型上下文协议)，是 Anthropic 公司（Claude 的娘家）发起的一个开放协议 (45)。你可以把它想象成 AI 应用的 USB-C 接口 (45) 或者 插件系统/扩展坞 (50)。

它的目标是标准化 AI 模型（比如 Cursor 里的 Claude 或 GPT）与外部数据源、工具、系统进行连接和交互的方式 (45)。

为啥重要？

现在的 AI 模型本身很强大，但它们通常是“离线”的，不了解你本地的文件系统、数据库里的实时数据、或者某个特定 API 的用法。以前，每要连接一个新的外部系统，开发者都得写一套定制的集成代码，非常麻烦，难以扩展 (所谓的 M×N 问题) (45)。

MCP 就是为了解决这个问题。它提供了一套统一的“语言”和“接口规范”，让各种外部工具或数据源可以把自己“打包”成一个 MCP 服务器 (Server)，而像 Cursor 这样的 AI 应用则作为 MCP 客户端 (Client)，通过这套标准协议与服务器进行通信 (45)。

这样一来，Cursor 的 AI 就不再仅仅局限于分析你打开的代码文件了。通过连接不同的 MCP 服务器，它可以：

• 直接查询你的数据库 (50)。

• 读取你 Notion 里的文档 (50)。

• 操作你的 GitHub 仓库（创建 PR、查找代码等）(50)。

• 调用 Stripe API 管理订阅 (50)。

• 访问你的本地文件系统 (54)。

• 执行 Git 命令 (54)。

• 运行 Puppeteer 进行浏览器自动化 (45)。

• 连接成千上万的应用 (通过 Zapier MCP) (55)。

• 甚至控制 Kubernetes 集群 (57)。

基本上，只要有人为某个工具或数据源写了 MCP 服务器，Cursor 的 AI 就有可能通过 MCP 协议来使用它，极大地扩展了 AI 的能力边界，让它能完成更复杂、更贴近真实开发场景的任务 (50)。

Cursor 中的 MCP 实现 (50)

• 架构：Cursor 扮演 MCP 客户端 (Client/Host) 的角色。它会连接并管理用户配置的 MCP 服务器。

• 通信方式 (Transport Types)：Cursor 支持两种连接 MCP 服务器的方式：

1. stdio (标准输入输出)：服务器程序在你本地运行，由 Cursor 自动启动和管理。Cursor 通过标准输入/输出管道与服务器进程通信。这种方式配置简单，适合本地工具。配置时需要指定启动服务器的 command (命令) 和 args (参数)。

2. sse (Server-Sent Events)：服务器作为一个独立的 HTTP 服务运行（可以在本地或远程），由用户自己管理。Cursor 通过 HTTP 连接到服务器暴露的 /sse 端点，并使用 Server-Sent Events 协议进行通信。这种方式更灵活，可以连接到远程服务或共享服务。配置时需要指定服务器的 url。

• 配置文件 (mcp.json)：

• 位置：可以在项目本地配置 (项目根目录/.cursor/mcp.json)，也可以全局配置 (用户主目录/~/.cursor/mcp.json)。项目配置只对当前项目生效，全局配置对所有项目生效。

• 结构：是一个 JSON 文件，核心是 mcpServers 对象，里面包含了你配置的各个 MCP 服务器。每个服务器有一个自定义的名称作为 key。

• stdio 配置示例：

• JSON

{
  "mcpServers": {
    "my-local-tool": {
      "command": "node", // 或者 python, npx, /path/to/executable"args": ["/path/to/server-script.js", "--port", "8080"],
      "env": { // 可选，设置环境变量"API_KEY": "your_secret_key",
        "DB_HOST": "localhost"
      }
    }
  }
}

• 注意： 对于需要 API Key 等敏感信息的 stdio 服务器，直接写在 env 里如果 mcp.json 被提交到 Git 会有安全风险。官方建议创建一个包装脚本 (wrapper script) 来设置环境变量，然后在 command 里调用这个脚本 (50)。社区也有 envmcp 这样的工具来简化从 .env 文件加载变量的过程 (59)。

• sse 配置示例：

• JSON

{
  "mcpServers": {
    "my-remote-service": {
      "url": "https://my-mcp-server.example.com/sse"// 可能还有 headers 用于认证等，具体看 Cursor 是否支持及服务器要求
    }
  }
}

• 使用 MCP 工具：

• 自动使用：配置好后，Cursor 的 Agent 模式会自动发现可用的 MCP 工具。当它认为某个工具对当前任务有帮助时，就会尝试调用它 (50)。

• 手动触发：你也可以在聊天中明确指示 Agent 使用某个工具，比如 “用 GitHub MCP 创建一个 issue” 或 “用数据库 MCP 查一下用户表结构” (50)。

• 审批流程：默认情况下，Agent 调用 MCP 工具前会弹出一个确认框，显示要调用的工具名称和参数，需要你点击 “Run Tool” 确认 (50)。

• 自动运行 (Yolo Mode)：可以在设置里开启 “Auto-run”，允许 Agent 不经确认直接运行工具。可以配置允许或禁止自动运行的工具列表，需要谨慎使用，特别是对于能执行命令或修改数据的工具 (50)。

• 图片注入：如果 MCP 服务器返回的是图片（比如网页截图、图表），并且格式正确（Base64 编码，指定 type: "image" 和 mimeType），Cursor 可以在聊天中显示这张图片，甚至可以把它交给支持图片理解的模型进行分析 (50)。

[图示：Cursor Agent 聊天界面截图 (中文注释：展示 MCP 工具调用前的审批提示)]

局限性：

• 工具数量限制：Cursor 可能对一次性传递给 Agent 的工具数量有限制（比如文档提到过可能是前 40 个）(50)。如果配置了太多 MCP 服务器和工具，Agent 可能无法看到所有的。

• 协议版本兼容性：MCP 协议本身还在发展。Cursor 客户端支持的 MCP 协议版本可能与最新的规范或某些服务器的实现存在差异，导致兼容性问题或部分功能无法使用 (61)。

• 配置复杂度：虽然 MCP 简化了集成，但配置和管理（尤其是环境变量、认证、服务器部署）仍然需要一定的技术知识 (50)。

总的来说，MCP 是 Cursor 实现其“AI-First IDE”愿景的关键技术。它打破了 AI 只能在代码层面打转的局限，让 AI 能够与外部世界互动，从而完成更强大、更实用的任务。

三、Rules 系统篇：实战案例与最佳实践

光说不练假把式。Rules 到底怎么用？下面咱们结合不同开发领域，看一些具体的例子和编写技巧。

1. Rules 实战案例

记住，好的 Rules 文件应该是专注、可操作、范围明确的 (20)。尽量简洁，把大的概念拆分成多个可组合的规则。

a. 前端领域 (以 React + TypeScript + Tailwind 为例)

场景：规范团队 React 组件的写法，强制使用 TypeScript，并遵循 Tailwind CSS 的最佳实践。

规则文件 (.cursor/rules/react-typescript-tailwind.mdc) (20)：

Code snippet

---
description: React + TypeScript + Tailwind CSS 项目编码规范
globs: ["src/**/*.{ts,tsx}"] # 自动应用于 src 目录下的 TS/TSX 文件
alwaysApply: false # 不需要总是应用，根据文件类型自动附加
tags: ["frontend", "react", "typescript", "tailwind"]
---
# React + TypeScript + Tailwind CSS 编码规范
## 核心原则
- 
**技术栈**
: 本项目使用 React 18+, TypeScript 5+, Tailwind CSS 3+。
- 
**代码风格**
: 遵循 Airbnb JavaScript Style Guide，使用 Prettier 自动格式化。
- 
**组件化**
: 优先采用函数式组件 (Functional Components) 和 Hooks。
## TypeScript 使用规范
- 
**类型优先**
: 尽可能为所有变量、函数参数、返回值添加明确的类型。避免使用 `any` 类型，除非绝对必要且有注释说明。
- 
**接口 (Interface) vs 类型别名 (Type)**
: 定义对象结构或组件 Props 时，优先使用 `interface`。对于联合类型、交叉类型等复杂类型，使用 `type`。
  ```typescript
  // Props 推荐使用 interface
  interface MyComponentProps {
    userId: string;
    isActive?: boolean;
  }
  // 复杂类型使用 type
  type Status = 'loading' | 'success' | 'error';

• 严格模式: 启用 TypeScript 的 strict 模式 ("strict": true in tsconfig.json) 以获得更强的类型检查。

React 组件规范

• 函数式组件: 必须使用函数式组件和 Hooks。

• TypeScript

// 正确 ✅const MyComponent: React.FC<MyComponentProps> = ({ userId, isActive = false }) => {//... component logic using Hooksreturn <div>{userId} is {isActive? 'active' : 'inactive'}</div>;
};

// 错误 ❌ (避免使用类组件)// class MyComponent extends React.Component<MyComponentProps> {... }

• 命名: 组件名使用 PascalCase。组件文件名使用 PascalCase.tsx 或 kebab-case.tsx (根据团队约定)。

• 导出: 组件优先使用命名导出 (export const MyComponent) 而不是默认导出 (export default MyComponent)。

• Props: Props 解构时提供默认值。Props 应视为只读，不可在组件内部修改。

• 状态管理:

• 简单组件内部状态使用 useState。

• 跨多层组件共享状态使用 useContext + useReducer。

• 复杂全局状态参考项目状态管理方案 (如 Zustand，参考 @./zustand-rules.mdc)。

• 副作用: 使用 useEffect 处理副作用。务必提供正确的依赖项数组。在组件卸载时清理副作用（如事件监听、定时器）。

• 自定义 Hooks: 将可复用的逻辑（特别是包含状态或副作用的）抽取到自定义 Hook 中 (命名以 use 开头，如 useFetchData.ts)。

Tailwind CSS 使用规范

• Utility-First: 优先使用 Tailwind 的原子类。

• 避免 Arbitrary Values: 尽量使用 tailwind.config.js 中定义的主题值 (颜色、间距、字号等)，少用 [ ] 语法创建任意值，除非必要。

• 组件抽象: 对于重复的样式组合，考虑封装成 React 组件，而不是使用 @apply 大量组合原子类。

• 配置文件: 项目的 Tailwind 配置位于 @./tailwind.config.js。自定义主题或插件需在此文件中配置。

• 常用模式:

• 布局: Flexbox (flex, items-center, justify-between), Grid (grid, grid-cols-*)。

• 间距: Margin (m-, mx-, mt-), Padding (p-, px-, py-)。

• 响应式: 使用屏幕尺寸前缀 (sm:, md:, lg:)。

禁止事项

• 禁止在组件中使用内联样式 (style={{}})，除非是动态计算的样式。

• 禁止直接操作 DOM。

• 禁止使用已废弃的 React API 或生命周期方法。

• 禁止在生产代码中留下 console.log。

代码示例参考

• 基础按钮组件: @./src/components/BaseButton.tsx

• 表单输入组件: @./src/components/FormInput.tsx

AI 验证步骤

• 生成代码后，请检查：

1. 是否遵循了上述 TypeScript 和 React 的规范？

2. 是否正确使用了 Tailwind CSS 的原子类，并尽量避免了任意值？

3. 是否包含了必要的 Props 类型定义？

4. 是否处理了 useEffect 的依赖和清理？

#### b. 后端领域 (以 Python + Django 为例)

场景
：确保 Django 项目遵循 MVT 模式，使用 ORM，遵守 PEP 8 规范，并实施基本的安全措施。

规则文件 (`.cursor/rules/python-django-best-practices.mdc`)
 [26, 30, 68, 69, 70]：
```mdc
---
description: Python + Django 项目开发最佳实践和规范
globs: ["**/*.py"]
alwaysApply: true # 对于核心技术栈规范，通常设为 Always
tags: ["backend", "python", "django"]
---
# Python + Django 开发规范
## 核心原则
- 
**技术栈**
: 本项目使用 Python 3.10+, Django 4+。
- 
**代码风格**
: 严格遵守 PEP 8 规范。使用 `black` 和 `flake8` (或 `ruff`) 进行代码格式化和检查。
- 
**项目结构**
: 遵循标准的 Django 项目和应用布局。使用独立的 Django App 来组织功能模块。
## Django 最佳实践
- 
**MVT 模式**
: 严格遵循 Model-View-Template (或 Model-View-Controller) 模式，保持各层职责清晰。
    - 
**Models (`models.py`)**
: 定义数据模型。包含字段、`Meta` 选项、`str` 方法。业务逻辑尽量放在 Service 层或 Model Managers 中，保持 Model 简洁。
    - 
**Views (`views.py`)**
: 处理 HTTP 请求和响应。保持 View 瘦 (Thin Views)，将业务逻辑委托给 Service 层或 Form。优先使用类视图 (Class-Based Views, CBVs) 处理复杂逻辑，函数视图 (Function-Based Views, FBVs) 处理简单逻辑。善用 Django 的通用视图 (Generic Views)。
    - 
**Templates (`templates/`)**
: 负责展示。使用 Django Template Language (DTL)。将模板放在 App 内的 `templates/app_name/` 目录下。使用模板继承 (`{% extends %}`, `{% block %}`)。
- 
**ORM**
: 必须使用 Django ORM 进行数据库交互。避免编写原生 SQL 查询，除非有明确的性能优化需求且经过评审。
    - 使用 `QuerySet` API 进行高效查询。
    - 注意 N+1 查询问题，使用 `select_related` 和 `prefetch_related` 进行优化。
- 
**Forms (`forms.py`)**
: 使用 Django Forms 处理用户输入和验证。优先使用 `ModelForm` 来简化基于模型的表单创建。验证逻辑应放在 Form 中。
- 
**URLs (`urls.py`)**
: 定义清晰、符合 RESTful 风格的 URL 模式。使用 `include()` 组织 App 的 URL。使用 `path()` 或 `re_path()`。
- 
**Settings (`settings.py`)**
:
    - 不要硬编码敏感信息 (如 `SECRET_KEY`, 数据库密码, API Keys)。使用环境变量 (如 `python-dotenv`) 或专门的配置管理工具加载。参考 `@./django-secrets-management.mdc`。
    - 为不同环境 (开发、测试、生产) 创建不同的设置文件或使用条件加载。
- 
**Middleware**
: 合理使用 Middleware 处理全局请求/响应逻辑，如认证、日志、安全头等。
- 
**Admin**
: 定制 Django Admin 界面以方便内容管理，但不要在 Admin 中实现核心业务逻辑。
- 
**静态文件与媒体文件**
: 正确配置 `STATIC_URL`, `STATIC_ROOT`, `MEDIA_URL`, `MEDIA_ROOT`。生产环境使用 `collectstatic`。
## Python 编码规范
- 
**类型提示 (Type Hinting)**
: 强烈推荐为函数参数和返回值添加类型提示 (Python 3.5+)。使用 `mypy` 进行静态类型检查。
- 
**错误处理**
: 使用 `try...except` 块处理可能发生的异常。定义具体的异常类型，避免捕获宽泛的 `Exception`。记录详细的错误信息。
- 
**虚拟环境**
: 每个项目必须使用独立的虚拟环境 (如 `venv`, `conda`)。使用 `requirements.txt` 或 `pyproject.toml` (配合 `pip-tools` 或 `poetry`) 管理依赖。
## 安全实践
- 
**CSRF 保护**
: 确保 Django 的 CSRF 中间件已启用，并在所有 POST 表单中使用 `{% csrf_token %}`。
- 
**XSS 防护**
: Django 模板引擎默认开启 HTML 转义。在使用 `mark_safe` 时要格外小心。对用户输入进行清理。
- 
**SQL 注入防护**
: 使用 Django ORM 可以有效防止 SQL 注入。避免使用原生 SQL。
- 
**认证与授权**
: 使用 Django 内建的认证系统。通过 `Permissions` 或第三方库 (如 `django-guardian`) 实现对象级权限控制。
- 
**依赖安全**
: 定期使用 `pip-audit` 或类似工具检查依赖库的安全漏洞。
## 测试
- 
**测试框架**
: 使用 `unittest` (Django 内建) 或 `pytest` (配合 `pytest-django`)。
- 
**测试覆盖**
: 为 Models, Views, Forms, Services 编写单元测试和集成测试。目标是达到高测试覆盖率。
- 
**测试数据**
: 使用 Fixtures 或工厂库 (如 `factory-boy`) 生成测试数据。
- 
**测试隔离**
: 确保测试用例之间相互独立，使用测试数据库。
## AI 验证步骤
- 生成代码后，请检查：
    1. 是否遵循了 MVT 模式？View 是否保持简洁？
    2. 数据库操作是否通过 ORM 进行？
    3. 是否遵循了 PEP 8 规范和类型提示建议？
    4. 是否处理了常见的安全风险 (CSRF, XSS, SQLi)？
    5. 是否包含必要的测试用例？

c. API 设计 (RESTful)

场景：指导 AI 设计和实现符合 RESTful 风格的 API。

规则文件 (.cursor/rules/api-design-restful.mdc) (18)：

Code snippet

---
description: RESTful API 设计规范和最佳实践
globs: ["
**/views.py", "**
/controllers.py", "
**/routes.js", "**
/api/**/*.ts"] # 匹配常见的 API 实现文件
alwaysApply: false
tags: ["api", "rest", "design"]
---
# RESTful API 设计规范
## 核心原则
- 
**资源导向**
: API 应围绕资源 (Resources) 进行设计，资源是 API 操作的核心对象 (如用户、产品、订单)。
- 
**使用名词**
: URL 路径应使用名词复数表示资源集合 (e.g., `/users`, `/products`)。
- 
**HTTP 方法**
: 正确使用 HTTP 动词表达对资源的操作：
    - `GET`: 获取资源 (单个或列表)。幂等。
    - `POST`: 创建新资源。非幂等。
    - `PUT`: 完整替换/更新现有资源。幂等。
    - `PATCH`: 部分更新现有资源。非幂等 (但通常期望幂等)。
    - `DELETE`: 删除资源。幂等。
- 
**状态码**
: 使用标准的 HTTP 状态码准确反映操作结果：
    - `2xx` (成功): `200 OK`, `201 Created`, `204 No Content`。
    - `3xx` (重定向): `301 Moved Permanently`, `304 Not Modified`。
    - `4xx` (客户端错误): `400 Bad Request`, `401 Unauthorized`, `403 Forbidden`, `404 Not Found`, `422 Unprocessable Entity`。
    - `5xx` (服务器错误): `500 Internal Server Error`, `503 Service Unavailable`。
- 
**无状态 (Stateless)**
: 每个请求应包含所有必要信息，服务器不应依赖先前请求的状态。认证信息通常通过 Header (如 `Authorization: Bearer <token>`) 传递。
## URL 设计
- 
**简洁明了**
: URL 应易于理解和预测。
- 
**层级关系**
: 使用 `/` 表示资源的层级关系 (e.g., `/users/{userId}/orders`)。
- 
**避免动词**
: URL 中不应包含动词 (e.g., 错误: `/getUser`, 正确: `GET /users/{userId}`)。
- 
**过滤、排序、分页**
: 使用查询参数 (Query Parameters) 实现：
    - 过滤: `GET /products?category=electronics&in_stock=true`
    - 排序: `GET /users?sort=-created_at` (降序), `GET /users?sort=name` (升序)
    - 分页: `GET /orders?page=2&limit=20` 或使用基于游标的分页。
- 
**版本控制**
: 在 URL 中包含版本号 (e.g., `/api/v1/users`) 或使用 Accept Header。
## 请求与响应
- 
**数据格式**
: 请求体和响应体优先使用 JSON (`Content-Type: application/json`, `Accept: application/json`)。
- 
**请求体**
: 对于 `POST`, `PUT`, `PATCH` 请求，数据应放在请求体中。
- 
**响应体**
:
    - 成功响应 (`2xx`) 应包含所请求或操作的资源数据。
    - `POST` 成功创建资源后，应返回 `201 Created` 状态码，并在 `Location` Header 中包含新资源的 URL。
    - `DELETE` 成功后，通常返回 `204 No Content`，响应体为空。
    - 错误响应 (`4xx`, `5xx`) 应包含清晰的错误信息，建议使用统一的错误对象格式，如：
      ```json
      {
        "error": {
          "code": "INVALID_INPUT",
          "message": "Validation failed.",
          "details": [
            { "field": "email", "issue": "Email format is invalid." }
          ]
        }
      }
      ```
- 
**命名约定**
: JSON 字段名建议使用 `camelCase` 或 `snake_case` (保持一致)。
## 安全性
- 
**HTTPS**
: 所有 API 通信必须使用 HTTPS。
- 
**认证 (Authentication)**
: 使用标准的认证机制，如 OAuth 2.0, JWT, API Keys。认证信息通过 `Authorization` Header 传递。
- 
**授权 (Authorization)**
: 在处理请求时，必须检查用户是否有权限执行该操作。
- 
**输入验证**
: 对所有传入的参数和请求体数据进行严格验证。
- 
**速率限制**
: 对 API 请求进行速率限制，防止滥用。
## 文档
- 
**OpenAPI/Swagger**
: 使用 OpenAPI 规范编写 API 文档。可以使用工具自动生成交互式文档。文档应包含所有端点、参数、请求/响应示例和状态码说明。
## AI 验证步骤
- 设计或实现 API 后，请检查：
    1. URL 是否使用了名词复数表示资源？
    2. HTTP 方法是否与操作语义匹配？
    3. 是否正确使用了 HTTP 状态码？
    4. 请求/响应格式是否为 JSON，并遵循了命名约定？
    5. 是否实现了过滤、排序、分页（如果需要）？
    6. 是否考虑了版本控制？
    7. 是否包含认证、授权和输入验证？
    8. 是否有对应的 OpenAPI 文档？

d. 测试领域 (以 Jest 为例)

场景：规范 Jest 测试用例的编写，强调 AAA 模式和 Mocking。

规则文件 (.cursor/rules/testing-jest.mdc) (64)：

Code snippet

---
description: 使用 Jest 进行 JavaScript/TypeScript 测试的最佳实践
globs: ["**/*.{test,spec}.{js,jsx,ts,tsx}"] # 自动应用于测试文件
alwaysApply: false
tags: ["testing", "jest", "javascript", "typescript"]
---
# Jest 测试规范
## 核心原则
- 
**测试目的**
: 测试应验证代码单元 (单元测试) 或组件交互 (集成测试) 的行为是否符合预期。
- 
**可读性**
: 测试代码应清晰、简洁、易于理解。测试名称应明确说明测试的场景和预期结果。
- 
**可靠性**
: 测试应稳定，避免偶发性失败 (flaky tests)。测试结果应具有确定性。
- 
**独立性**
: 每个测试用例应相互独立，不应依赖于其他测试用例的执行顺序或状态。
## 测试结构 (AAA 模式)
- 
**Arrange (准备)**
: 设置测试所需的前提条件，包括初始化变量、模拟依赖项等。
- 
**Act (执行)**
: 调用被测试的代码或函数。
- 
**Assert (断言)**
: 验证执行结果是否符合预期。使用 Jest 提供的 `expect` 和匹配器 (matchers)。
```typescript
import { add } from '../math'; // 被测试的函数
describe('add function', () => {
  it('should return the sum of two positive numbers', () => {
    // Arrange
    const num1 = 5;
    const num2 = 10;
    const expectedSum = 15;
    // Act
    const result = add(num1, num2);
    // Assert
    expect(result).toBe(expectedSum);
  });
  it('should return the sum when one number is zero', () => {
    // Arrange
    const num1 = 0;
    const num2 = 7;
    // Act
    const result = add(num1, num2);
    // Assert
    expect(result).toBe(7);
  });
});

Mocking (模拟)

• 目的: 隔离被测试单元，避免对外部依赖 (如 API 调用、数据库、其他模块) 的真实调用。

• 方法: 使用 jest.fn() 创建模拟函数，jest.spyOn() 监视现有函数，jest.mock() 模拟整个模块。

• 验证 Mock: 使用 expect(mockFn).toHaveBeenCalled(), expect(mockFn).toHaveBeenCalledWith(...), expect(mockFn).toHaveReturnedWith(...) 等断言来验证 Mock 函数是否按预期被调用。

TypeScript

// a-service.tsexport const fetchData = async (id: string): Promise<{ data: string }> => {// 假设这里是真实的 API 调用const response = await fetch(`/api/data/${id}`);if (!response.ok) {throw new Error('Failed to fetch data');
  }return response.json();
};

// a-component.test.tsimport { fetchData } from './a-service';
import { processData } from './a-component'; // 假设 processData 调用了 fetchData// 模拟 a-service 模块
jest.mock('./a-service');

// 类型断言，确保 mock 函数类型正确const mockedFetchData = fetchData as jest.MockedFunction<typeof fetchData>;
describe('processData', () => {
  beforeEach(() => {// 在每个测试前重置 mock
    mockedFetchData.mockClear();
  });
  it('should process data successfully when fetch is successful', async () => {// Arrangeconst mockData = { data: 'test data' };
    mockedFetchData.mockResolvedValue(mockData); // 设置 mock 返回值// Actconst result = await processData('123');
// Assert
    expect(mockedFetchData).toHaveBeenCalledWith('123'); // 验证 mock 被调用
    expect(result).toEqual('Processed: test data'); // 验证处理结果
  });
  it('should handle error when fetch fails', async () => {// Arrangeconst errorMessage = 'Failed to fetch';
    mockedFetchData.mockRejectedValue(new Error(errorMessage)); // 设置 mock 抛出错误// Act & Assertawait expect(processData('123')).rejects.toThrow(errorMessage); // 验证是否抛出预期错误
    expect(mockedFetchData).toHaveBeenCalledWith('123');
  });
});

其他最佳实践

• 测试覆盖率: 目标是高覆盖率，但更要关注测试的质量和有效性。使用 --coverage 选项生成覆盖率报告。

• 异步测试: 对于返回 Promise 或使用 async/await 的函数，确保正确处理异步操作。使用 async/await 配合 expect(...).resolves 或 expect(...).rejects。

• React 组件测试: 使用 @testing-library/react 进行组件测试，关注用户交互和可访问性，而不是内部实现细节。

• 快照测试 (Snapshot Testing): 谨慎使用。适用于 UI 组件的结构验证，但容易因小的改动而失败，维护成本较高。

• 测试文件组织: 测试文件应与被测试文件放在一起 (e.g., component.tsx 和 component.test.tsx) 或放在专门的 tests 目录下。

AI 验证步骤

• 编写测试后，请检查：

1. 是否遵循了 AAA 模式？

2. 对于外部依赖，是否正确使用了 Mocking？

3. 测试名称是否清晰描述了测试场景和预期？

4. 异步操作是否得到了正确处理？

5. 断言是否充分验证了预期行为？

#### e. 运维领域 (以 Dockerfile 为例)

场景
：规范 Dockerfile 的编写，强调镜像优化和安全。

规则文件 (`.cursor/rules/dockerfile-best-practices.mdc`)
 [75, 76]：
```mdc
---
description: Dockerfile 编写的最佳实践，旨在创建优化、安全、可维护的 Docker 镜像。
globs: ["
**/Dockerfile", "**
/Dockerfile.*"]
alwaysApply: false
tags: ["devops", "docker", "infrastructure"]
---
# Dockerfile 最佳实践
## 核心原则
- 
**镜像最小化**
: 只包含运行应用所必需的组件。
- 
**构建速度**
: 优化 Dockerfile 指令顺序以利用构建缓存。
- 
**安全性**
: 遵循安全最佳实践，减少攻击面。
- 
**可维护性**
: Dockerfile 应清晰、易懂、易于更新。
## 最佳实践
1.  
**选择合适的基础镜像**
:
    *   优先选择官方、维护良好的镜像。
    *   选择体积小的基础镜像 (如 `alpine`, `-slim` 变种)。例如，使用 `python:3.11-slim-bookworm` 而不是 `python:3.11`。
    *   明确指定基础镜像的版本标签 (如 `ubuntu:22.04`)，避免使用 `latest` 以确保构建的可重复性。
2.  
**利用构建缓存**
:
    *   将不经常变化的指令放在 Dockerfile 的前面 (如安装系统依赖)。
    *   将经常变化的指令放在后面 (如 `COPY` 应用程序代码)。
    *   例如，先 `COPY` 依赖管理文件 (`requirements.txt`, `package.json`) 并安装依赖，再 `COPY` 整个应用代码。
3.  
**减少镜像层数**
:
    *   将多个相关的 `RUN` 指令用 `&&` 连接起来合并为一层。
    *   例如：`RUN apt-get update && apt-get install -y --no-install-recommends package1 package2 && rm -rf /var/lib/apt/lists/*`。
4.  
**使用 `.dockerignore`**
:
    *   创建 `.dockerignore` 文件，排除不需要复制到镜像中的文件和目录 (如 `.git`, `node_modules`, `*.log`, `.env`, 临时文件, 构建产物等)。
    *   这可以显著减小构建上下文的大小，加快构建速度，并减小最终镜像体积。
5.  
**多阶段构建 (Multi-stage Builds)**
:
    *   对于需要编译或构建步骤的应用 (如 Go, Java, Node.js)，使用多阶段构建。
    *   在一个临时的构建阶段安装所有构建依赖、编译代码，然后在最终的生产阶段只从构建阶段复制必要的运行时文件和产物。
    *   这能极大地减小最终镜像的大小，因为它不包含任何构建时的依赖。
6.  
**安装必要的依赖**
:
    *   只安装生产环境运行所必需的包。
    *   使用 `--no-install-recommends` (对于 `apt`) 减少不必要的包安装。
    *   在安装包后清理缓存 (如 `apt-get clean`, `rm -rf /var/lib/apt/lists/*`, `npm cache clean --force`, `pip cache purge`)。
7.  
**使用非 Root 用户运行**
:
    *   创建专门的应用程序用户和组 (`RUN groupadd -r appgroup && useradd -r -g appgroup appuser`)。
    *   使用 `USER appuser` 指令切换到非 Root 用户运行后续指令和应用程序。
    *   确保应用程序文件对该用户具有正确的权限。
8.  
**`COPY` 优于 `ADD`**
:
    *   优先使用 `COPY` 指令，因为它更透明，只复制本地文件或目录。
    *   仅在需要 `ADD` 的特定功能时 (如从 URL 下载文件或自动解压 tar 包) 才使用 `ADD`。
9.  
**管理敏感信息**
:
    *   
**绝对禁止**
将任何密钥、密码、Token 等敏感信息硬编码到 Dockerfile 或镜像层中。
    *   使用运行时注入的方式传递敏感信息，如：
        *   环境变量 (`-e` 或 `docker-compose.yml` 中的 `environment`)。
        *   Docker Secrets。
        *   卷挂载配置文件。
    *   对于构建时的秘密，使用 BuildKit 的 `--secret` 挂载。
10. 
**使用 `CMD` 和 `ENTRYPOINT` 的 Exec 格式**
:
    *   优先使用 JSON 数组格式 (Exec form)，例如 `CMD ["python", "app.py"]` 或 `ENTRYPOINT ["/app/run.sh"]`。
    *   避免使用 Shell 格式 (e.g., `CMD python app.py`)，因为 Shell 格式会通过 `/bin/sh -c` 运行，可能导致信号处理问题，且不易传递参数。
    *   通常 `ENTRYPOINT` 用于设置容器主进程，`CMD` 用于提供默认参数。
11. 
**暴露端口**
:
    *   使用 `EXPOSE` 指令声明容器打算监听的网络端口。这主要是文档性质的，实际端口映射在 `docker run -p` 或 `docker-compose.yml` 中完成。
    *   只暴露应用程序实际需要的端口。
12. 
**使用 `LABEL` 添加元数据**
:
    *   使用 `LABEL` 指令为镜像添加有用的元数据，如维护者、版本号、描述、源码链接等。
13. 
**实现 `HEALTHCHECK`**
:
    *   添加 `HEALTHCHECK` 指令来定义如何检查容器内的应用程序是否健康运行。Docker 可以利用这个信息来管理容器状态。
14. 
**保持更新**
:
    *   定期更新基础镜像和依赖包，以获取最新的安全补丁和功能。
15. 
**使用 Linter**
:
    *   使用 `hadolint` 等工具检查 Dockerfile 是否符合最佳实践。
## AI 验证步骤
- 编写 Dockerfile 后，请检查：
    1. 基础镜像是否合适且版本明确？
    2. 指令顺序是否有利于缓存？
    3. 是否有效利用了 `.dockerignore`？
    4. 是否使用了多阶段构建（如果适用）？
    5. 是否只安装了必要依赖并清理了缓存？
    6. 是否以非 Root 用户运行？
    7. 敏感信息是否已移除？
    8. `CMD`/`ENTRYPOINT` 是否使用了 Exec 格式？
    9. 是否添加了 `HEALTHCHECK` 和 `LABEL`？

f. 安全领域

场景：强调通用的安全编码实践，如输入验证和秘密管理。

规则文件 (.cursor/rules/security-best-practices.mdc) (35)：

Code snippet

---
description: 通用安全编码最佳实践，适用于所有项目和语言。
globs: ["**/
*.*
"] # 应用于所有文件，但优先级可能低于特定语言/框架规则
alwaysApply: true # 安全是基础，应该总是考虑
tags: ["security", "owasp"]
priority: 1 # 安全规则优先级最高
---
# 通用安全编码最佳实践
## 核心原则
- 
**纵深防御**
: 不依赖单一安全措施，采用多层防护。
- 
**最小权限**
: 程序、用户、服务只应拥有完成其任务所必需的最小权限。
- 
**安全默认**
: 默认配置应是安全的。
- 
**不信任输入**
: 永远不要信任来自外部（用户、第三方 API、文件等）的任何输入。
## 关键实践领域
### 1. 输入验证与清理 (Input Validation & Sanitization)
- 
**验证所有输入**
: 对来自任何不可信来源的数据（HTTP 请求参数、请求体、Header、数据库、文件、环境变量等）进行严格验证。
- 
**验证类型、格式、长度、范围**
: 确保输入符合预期的数据类型、格式（如 email、URL）、长度限制和数值范围。
- 
**使用白名单**
: 优先使用白名单验证（只允许已知的安全字符/模式），而不是黑名单（尝试阻止已知的危险字符/模式）。
- 
**服务器端验证**
: 客户端验证可以改善用户体验，但
**必须**
在服务器端进行强制验证，因为客户端验证可以被绕过。
- 
**使用成熟库**
: 利用框架或库提供的验证功能 (如 Django Forms, Pydantic, Zod, Joi)。
- 
**输出编码/转义**
: 在将数据插入 HTML、SQL、LDAP、OS 命令等上下文之前，必须进行适当的编码或转义，以防止注入攻击 (XSS, SQLi, Command Injection)。
### 2. 秘密管理 (Secrets Management)
- 
**禁止硬编码**
: 
**绝对禁止**
在源代码、配置文件、Dockerfile 或版本控制中硬编码任何敏感信息（API 密钥、数据库密码、私钥、Token 等）。
- 
**使用环境变量**
: 将秘密存储在环境变量中，并在运行时读取。
- 
**使用秘密管理工具**
: 对于更复杂的场景，使用专门的秘密管理系统 (如 HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager)。
- 
**配置文件分离**
: 将配置与代码分离。敏感配置不应提交到 Git。可以使用 `.env` 文件（并将其加入 `.gitignore`）结合 `python-dotenv` 或类似库加载。
- 
**限制访问**
: 确保只有需要访问秘密的服务或人员才有权限。定期轮换密钥。
### 3. 认证与授权 (Authentication & Authorization)
- 
**强认证**
: 使用强密码策略，推荐多因素认证 (MFA)。
- 
**安全会话管理**
: 使用安全的会话 Cookie (HttpOnly, Secure, SameSite 属性)。会话 ID 应随机且难以猜测。设置合理的会话超时时间。安全地处理会话注销。
- 
**令牌安全 (JWT)**
: 如果使用 JWT，确保使用强签名算法 (如 RS256)，验证签名和过期时间。不要在 Payload 中存储敏感信息。考虑令牌吊销机制。
- 
**最小权限原则**
: 授权时，确保用户只能访问其被明确授权的资源和操作。
- 
**检查权限**
: 在执行任何敏感操作或访问受限资源之前，必须检查用户的权限。
### 4. 错误处理与日志记录
- 
**避免泄露敏感信息**
: 错误消息不应向最终用户泄露过多的系统内部信息（如堆栈跟踪、数据库错误详情、文件路径）。提供通用的错误提示，并将详细信息记录在安全的日志中。
- 
**记录安全事件**
: 记录关键的安全相关事件，如登录成功/失败、权限变更、重要操作等。日志应包含时间戳、源 IP、用户身份（如果可用）和事件描述。
- 
**保护日志**
: 确保日志文件受到适当的访问控制，防止未授权访问或篡改。考虑将日志发送到集中的、安全的日志管理系统。
### 5. 依赖管理
- 
**定期更新**
: 保持所有库、框架和依赖项更新到最新稳定版本，以修复已知的安全漏洞。
- 
**漏洞扫描**
: 使用工具 (如 `npm audit`, `pip-audit`, OWASP Dependency-Check, Snyk, Dependabot) 定期扫描项目依赖，查找已知漏洞。
- 
**来源可靠**
: 只从官方或可信赖的源获取依赖。
### 6. 安全配置
- 
**移除不必要功能**
: 禁用或卸载应用程序、服务器或框架中不需要的特性、组件或示例文件。
- 
**安全头**
: 配置必要的 HTTP 安全头，如 `Content-Security-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options`, `X-Frame-Options`。
- 
**框架安全特性**
: 充分利用所用框架提供的内建安全功能。
## AI 验证步骤
- 生成或修改代码后，请检查：
    1. 是否对所有外部输入进行了严格的验证？
    2. 是否避免了硬编码敏感信息？秘密管理是否安全？
    3. 认证和授权逻辑是否健全？是否遵循最小权限原则？
    4. 错误处理是否恰当，是否避免了敏感信息泄露？
    5. 是否考虑了依赖项的安全？
    6. 是否应用了必要的安全配置和 HTTP 头？

2. Rules 编写与管理最佳实践

• 版本控制：将 .cursor/rules/ 目录纳入 Git 管理，像代码一样追踪规则的变更，方便团队协作和回滚 (20)。

• 团队共享：对于跨多个项目的规则，目前 Cursor 没有内建的共享机制 (20)。常见做法是：

• 创建一个专门的 Git 仓库存储共享规则。

• 通过脚本、Git Submodule 或手动复制/符号链接 (symlink) 的方式将共享规则同步到各个项目的 .cursor/rules/ 目录下 (20)。

• 模块化与组合：将大型规则集拆分成更小、更专注的规则文件。可以通过 @ 引用在其他规则中组合它们 (18)。例如，可以有一个基础的 typescript.mdc，然后在 react.mdc 中通过 @./typescript.mdc 引入它。

• 命名与组织：使用清晰的文件名 (如 kebab-case) 和合理的目录结构 (如果规则很多) 来组织 .cursor/rules 目录，方便查找和维护 (18)。

• 测试与迭代：规则不是一蹴而就的。编写后要反复测试，观察 AI 的行为，根据实际效果不断调整和优化 (17)。

• 处理冲突：如果多条规则对同一件事有不同规定，目前 Cursor 如何处理冲突尚不完全明确。设置 priority 元数据可能是一种方式 (25)，或者需要通过更精确的 globs 或更具体的指令来避免冲突。

• 注意 Bug：有用户报告过 Cursor 的规则编辑器 UI 或规则文件保存存在 Bug，有时修改不生效或丢失。如果遇到问题，尝试重启 Cursor 或直接在外部编辑器中编辑 .mdc 文件 (26)。

3. 相关 GitHub 仓库与资源推荐

• 官方文档:

• Cursor Rules 文档: https://docs.cursor.com/context/rules (20)

• 社区规则集合:

• PatrickJS/awesome-cursorrules: 较早的集合，包含 .cursorrules 和一些 .mdc 转换思路 (37)

• sanjeed5/awesome-cursor-rules-mdc: 专注于 .mdc 格式，包含大量自动生成的规则文件 (31)

• squirrelogic/cursor-rules: 包含一些标准化规则，如 Conventional Commits, SOLID 等 (28)

• Mawla/cursor_rules: 包含 Rails 8, ViewComponent 等规则 (38)

• ivangrynenko/cursorrules: 包含 PHP, Drupal, 安全相关规则 (39)

• grapeot/devin.cursorrules: 结合了工具和规则，尝试模拟 Devin (40)

• 讨论与分享:

• Cursor 官方论坛 (How To, Showcase, Discussion 板块): https://forum.cursor.com/ (34)

• Reddit (r/cursor): https://www.reddit.com/r/cursor/ (26)

• 规则生成与管理工具:

• cursor.directory/generate: 在线工具，可根据项目文件生成规则 (30)

• cursor-rules-cli (by sanjeed5): 命令行工具，扫描项目自动查找并安装规则 (31)

通过学习和借鉴这些资源，你可以更快地掌握 Rules 的精髓，并为你的项目量身定制出高效的 AI 指导规则。

四、MCP 插件篇：热门插件深度解析

MCP 让 Cursor 的能力不再局限于编辑器本身。下面我们来看看一些热门或有代表性的 MCP 服务器（插件），了解它们能做什么以及如何配置。

1. MCP 基础回顾

• 是什么：一个开放协议，用于连接 AI (如 Cursor) 和外部工具/数据源 (45)。

• 作用：让 AI 能调用 API、查询数据库、访问文件、执行命令等 (50)。

• 架构：Cursor 是客户端 (Client)，外部工具/数据源通过 MCP 服务器 (Server) 暴露能力 (45)。

• 连接方式：stdio (本地命令) 或 sse (HTTP Server-Sent Events) (50)。

• 配置：通过项目或全局的 mcp.json 文件 (50)。

2. MCP 服务器展示 (精选 20+ 示例)

以下列举一些来自官方、社区或第三方提供的 MCP 服务器，涵盖不同领域。配置提示主要基于通用原则和已有示例，具体细节可能需要查阅对应服务器的文档。

[注意：以下配置示例中的路径、API Key 等都需要替换为你自己的实际值。]

a. 版本控制 (Version Control)

1. Git (本地) (54)

• 功能: 读取本地 Git 仓库信息，如提交历史、文件变更、分支信息，甚至可能执行一些 Git 命令。

• 场景: 让 AI 分析代码演变历史，查找特定修改，或者基于 Git 状态生成提交信息。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "local-git": {
      "command": "uvx", // 或 npx, 或直接可执行文件路径"args": ["mcp-server-git", "--repository", "/path/to/your/repo"], // 需要指定仓库路径"transport": "stdio" // 明确指定 stdio
    }
  }
}

• 环境变量: 通常不需要特定环境变量，但需要本地安装 Git 且环境可访问。

1. GitHub (54)

• 功能: 通过 GitHub API 与远程仓库交互，管理 Issues, Pull Requests, 文件，搜索代码等。

• 场景: 让 AI 根据代码 TODO 创建 Issue，总结 PR 内容，搜索相关代码片段。

• 配置提示 (mcp.json): 官方或常用实现通常通过 Docker 运行。

• JSON

{
  "mcpServers": {
    "github-official": {
      "command": "docker",
      "args":,
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_GITHUB_PAT" // 在这里设置 PAT
      },
      "transport": "stdio"
    }
  }
}

• 或者使用 npx 运行社区版本：

• JSON

{
  "mcpServers": {
    "github-community": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_GITHUB_PAT"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 必须提供 GITHUB_PERSONAL_ACCESS_TOKEN。对于 GitHub Enterprise，可能还需要 GH_HOST (89)。

1. GitLab (54)

• 功能: 类似 GitHub MCP，但针对 GitLab API，管理项目、Issues, Merge Requests 等。

• 场景: 在 GitLab 环境中实现类似 GitHub MCP 的 AI 辅助开发流程。

• 配置提示 (mcp.json): 假设存在一个 npx 包：

• JSON

{
  "mcpServers": {
    "gitlab-mcp": {
      "command": "npx",
      "args": ["-y", "gitlab-mcp-server"], // 假设包名"env": {
        "GITLAB_PERSONAL_ACCESS_TOKEN": "YOUR_GITLAB_PAT",
        "GITLAB_HOST": "https://gitlab.example.com" // 如果是自托管实例
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 很可能需要 GITLAB_PERSONAL_ACCESS_TOKEN，以及可能的 GITLAB_HOST。

b. 数据库 (Databases)

1. PostgreSQL (只读) (45)

• 功能: 连接到 PostgreSQL 数据库，执行只读 SQL 查询，检查数据库 Schema。

• 场景: 让 AI 查询业务数据作为上下文，理解表结构以生成正确的 ORM 代码或 SQL。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "pg-readonly": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://db_user:db_password@db_host:5432/db_name" // 提供连接字符串
      ],
      "transport": "stdio"
    }
  }
}

• 环境变量: 连接信息直接在 args 中提供，也可以通过包装脚本使用环境变量。

1. Supabase (57)

• 功能: 与 Supabase 平台深度集成，不仅能查询 Postgres 数据库 (基于 PostgREST)，还能管理项目、Auth、Storage、Functions 等。

• 场景: 让 AI 直接操作 Supabase 项目，如根据需求创建表、编写 RLS 策略、部署 Edge Function。

• 配置提示 (mcp.json): 官方推荐使用 npx。

• JSON

{
  "mcpServers": {
    "supabase": {
      // Windows 用户 command 可能需要是 "cmd", args 前加 "/c"// WSL 用户 command 可能需要是 "wsl""command": "npx",
      "args":,
      "transport": "stdio"
    }
  }
}

• 也可以省略 --access-token 参数，通过环境变量 SUPABASE_ACCESS_TOKEN 提供 (97)。对于本地 Supabase 实例，可以改用 Postgres MCP 连接本地 DB URL (94)。

• 环境变量: SUPABASE_ACCESS_TOKEN (如果不在 args 中提供)。

1. Neon (57)

• 功能: 专为 Neon Serverless Postgres 设计，提供项目管理、分支管理、SQL 查询、数据库迁移等功能。

• 场景: 通过自然语言管理 Neon 数据库，如创建分支、执行迁移、查询数据。

• 配置提示 (mcp.json):

• 远程 (推荐): 使用 Neon 托管的服务器，通过 OAuth 认证。

• JSON

{
  "mcpServers": {
    "neon-remote": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.neon.tech/sse"],
      "transport": "stdio" // 注意：虽然是远程 SSE，但通过 npx mcp-remote 包装成了 stdio
    }
  }
}

• 本地: 需要 Neon API Key。

• JSON

{
  "mcpServers": {
    "neon-local": {
      // Windows 用户 command 可能需要是 "cmd", args 前加 "/c""command": "npx",
      "args":,
      "transport": "stdio"
    }
  }
}

• 也可以使用 smithery 工具安装 (104)。

• 环境变量: 本地模式需要 Neon API Key (通过参数或环境变量)。

1. Redis (54)

• 功能: 连接和操作 Redis 数据库 (GET, SET, DELETE, etc.)。

• 场景: 让 AI 访问或管理缓存数据、会话信息等。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "redis-mcp": {
      "command": "npx",
      "args": ["-y", "redis-mcp-server", "--url", "redis://:password@host:6379/0"], // 提供连接 URL"transport": "stdio"
    }
  }
}

• 环境变量: 连接信息可能通过参数或环境变量传递。

1. SQLite (54)

• 功能: 连接和查询本地 SQLite 数据库文件。

• 场景: 分析本地应用数据、日志等存储在 SQLite 中的信息。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "sqlite-mcp": {
      "command": "npx",
      "args": ["-y", "sqlite-mcp-server", "--db", "/path/to/your/database.db"], // 提供数据库文件路径"transport": "stdio"
    }
  }
}

• 环境变量: 通常不需要，路径通过参数指定。

1. Vector DBs (Qdrant, Weaviate, Pinecone) (55)

• 功能: 与向量数据库交互，用于存储和检索向量嵌入，实现语义搜索或 RAG (Retrieval-Augmented Generation)。

• 场景: 为 AI Agent 提供长期记忆能力，或根据用户问题从知识库中检索相关信息。

• 配置提示: 具体配置依赖于数据库和服务器实现。通常需要 API Endpoint 和 API Key。例如 (假设 Qdrant):

• JSON

{
  "mcpServers": {
    "qdrant-mcp": {
      "command": "npx", // 假设"args": ["-y", "qdrant-mcp-server"],
      "env": {
        "QDRANT_URL": "https://your-qdrant-cluster.cloud",
        "QDRANT_API_KEY": "YOUR_QDRANT_KEY"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 通常需要数据库的 URL/Endpoint 和认证信息 (API Key)。

c. 云平台与 DevOps (Cloud & DevOps)

1. Vercel (55)

• 功能: 通过 Vercel API 管理项目、部署、域名、环境变量等。

• 场景: 让 AI 触发部署、检查部署状态、添加/删除域名、管理环境变量。

• 配置提示 (mcp.json): Vercel 官方提供了基于其 SDK 的 MCP 服务器。

• JSON

{
  "mcpServers": {
    "vercel-mcp": {
      "command": "npx",
      "args":,
      "transport": "stdio"
    }
  }
}

• Token 也可以通过环境变量 VERCEL_TOKEN 提供 (111)。

• 环境变量: VERCEL_TOKEN (或通过 --bearer-token 参数)。

1. Kubernetes (kubectl) (55)

• 功能: 执行 kubectl 命令，查询和管理 Kubernetes 集群资源 (Pods, Deployments, Services 等)。

• 场景: 让 AI 检查 Pod 状态、获取日志、扩缩容 Deployment、应用 YAML 配置。

• 配置提示 (mcp.json): 有多种实现，如 kubectl-mcp-tool (Python) 或 kubernetes-mcp-server (Node/Binary)。以 kubectl-mcp-tool 为例 (114)：

• JSON

{
  "mcpServers": {
    "kubernetes": {
      "command": "/path/to/your/python", // 或直接 python 如果在 PATH 中"args": ["-m", "kubectl_mcp_tool.minimal_wrapper"], // 使用推荐的包装器"env": {
        "KUBECONFIG": "/path/to/your/.kube/config" // 指定 kubeconfig 路径
      },
      "transport": "stdio"
    }
  }
}

• 另一个实现 kubernetes-mcp-server (58) 可以通过 npx 运行：

• JSON

{
  "mcpServers": {
    "kubernetes-js": {
      "command": "npx",
      "args": ["-y", "kubernetes-mcp-server@latest"],
      "transport": "stdio"
    }
  }
}

• 还有 Docker 实现，如 k8s-mcp-server (118)，需要挂载 kubeconfig：

• JSON

{
  "mcpServers": {
    "kubernetes-docker": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-v", "/path/to/your/.kube:/home/appuser/.kube:ro", // 挂载 kubeconfig (只读)"ghcr.io/alexei-led/k8s-mcp-server:latest"
      ],
      "transport": "stdio"
    }
  }
}

• 环境变量: 通常需要 KUBECONFIG 环境变量指向配置文件，或者依赖 kubectl 的默认配置。需要本地安装 kubectl 且能访问集群。

1. Docker (86)

• 功能: 与本地 Docker 守护进程交互，管理容器、镜像、卷、网络等。

• 场景: 让 AI 启动/停止/删除容器、构建镜像、查看容器日志。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "docker-mcp": {
      "command": "npx",
      "args": ["-y", "docker-mcp-server"], // 假设包名"transport": "stdio"
    }
  }
}

• 环境变量: 可能需要配置 Docker Host (如果不是默认的本地 socket)。需要本地安装并运行 Docker。

1. Sentry (54)

• 功能: 连接 Sentry API，获取错误报告和性能监控数据。

• 场景: 让 AI 分析 Sentry 中的报错信息，提供问题摘要或可能的解决方案。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "sentry-mcp": {
      "command": "npx",
      "args": ["-y", "sentry-mcp-server"], // 假设包名"env": {
        "SENTRY_AUTH_TOKEN": "YOUR_SENTRY_TOKEN",
        "SENTRY_ORG_SLUG": "your-org-slug"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 很可能需要 SENTRY_AUTH_TOKEN 和 SENTRY_ORG_SLUG。

d. 生产力与协作 (Productivity & Collaboration)

1. Filesystem (本地文件系统) (48)

• 功能: 安全地访问（读、写、列出）本地文件系统，需要配置允许访问的路径。

• 场景: 让 AI 读取项目配置文件、模板文件，或者将生成的内容（代码、文档）写入本地文件。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "local-fs": {
      "command": "npx",
      "args": [
        "-y", "@modelcontextprotocol/server-filesystem",
        "/path/to/allowed/dir1", // 指定允许访问的目录"/path/to/allowed/file.txt" // 也可以指定具体文件
      ],
      "transport": "stdio"
    }
  }
}

• 环境变量: 通常不需要。

1. Slack (45)

• 功能: 通过 Slack API 发送消息、管理频道等。

• 场景: 让 AI 将代码片段、构建结果或通知发送到指定的 Slack 频道。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "slack-mcp": {
      "command": "npx",
      "args": ["-y", "slack-mcp-server"], // 假设包名"env": {
        "SLACK_BOT_TOKEN": "xoxb-YOUR_SLACK_BOT_TOKEN"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 SLACK_BOT_TOKEN。

1. Notion (50)

• 功能: 通过 Notion API 读取或写入 Notion 页面和数据库。

• 场景: 让 AI 从 Notion 读取项目需求文档，或将生成的文档、笔记保存到 Notion。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "notion-mcp": {
      "command": "npx",
      "args": ["-y", "notion-mcp-server"], // 假设包名"env": {
        "NOTION_API_KEY": "secret_YOUR_NOTION_KEY"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 NOTION_API_KEY。

1. Jira (55)

• 功能: 通过 Jira API 创建、更新、搜索 Jira Issues。

• 场景: 让 AI 根据代码中的 TODO 注释自动创建 Jira 任务，或根据需求描述更新任务状态。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "jira-mcp": {
      "command": "npx",
      "args": ["-y", "jira-mcp-server"], // 假设包名"env": {
        "JIRA_URL": "https://your-domain.atlassian.net",
        "JIRA_USER_EMAIL": "[email protected]",
        "JIRA_API_TOKEN": "YOUR_JIRA_API_TOKEN"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 Jira 实例 URL、用户邮箱和 API Token。

1. Figma (55)

• 功能: 读取 Figma 文件数据（图层、样式、节点信息）。某些实现可能通过 WebSocket 连接 Figma 插件来实现编辑功能。

• 场景: 让 AI 根据 Figma 设计稿生成前端代码 (HTML/CSS, React/Vue 组件)，提取设计规范。

• 配置提示 (mcp.json): 实现方式多样。

• 只读 (API): 如 figma-developer-mcp (127)

• JSON

{
  "mcpServers": {
    "figma-readonly": {
      "command": "npx", // Windows: "cmd", args 前加 "/c""args":,
      "transport": "stdio"
    }
  }
}

• 读写 (Plugin Bridge): 如 cursor-talk-to-figma-mcp (125)，需要同时运行 WebSocket 服务器和 Figma 插件。

• JSON

{
  "mcpServers": {
    "TalkToFigma": {
      "command": "bunx", // 或 node, npx 等"args": ["cursor-talk-to-figma-mcp@latest"],
      "transport": "stdio"
    }
  }
}

• (还需要单独启动 bun socket)

• 环境变量: 通常需要 Figma Personal Access Token (PAT)，通过参数或环境变量 FIGMA_API_KEY / FIGMA_ACCESS_TOKEN 提供。

e. Web 交互 (Web Interaction)

1. Fetch (54)

• 功能: 从指定的 URL 获取网页内容。

• 场景: 让 AI 读取在线文档、博客文章、API 文档等作为上下文。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "fetch-url": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"],
      "transport": "stdio"
    }
  }
}

• 环境变量: 通常不需要。

1. Puppeteer (45)

• 功能: 启动和控制一个无头 (Headless) Chrome/Chromium 浏览器，用于网页自动化和抓取。

• 场景: 让 AI 访问需要 JavaScript 渲染的页面、填写表单、点击按钮、截屏。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "puppeteer-mcp": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-puppeteer"],
      "transport": "stdio"
    }
  }
}

• 环境变量: 通常不需要。需要本地安装 Chromium。

1. Brave Search (54)

• 功能: 调用 Brave Search API 进行网页搜索。

• 场景: 让 AI 搜索最新的信息、查找特定问题的解决方案或相关的技术文章。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "brave-search": {
      "command": "npx", // 假设"args": ["-y", "brave-search-mcp-server"],
      "env": {
        "BRAVE_SEARCH_API_KEY": "YOUR_BRAVE_API_KEY"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 BRAVE_SEARCH_API_KEY。

f. 工作流与自动化 (Workflow & Automation)

1. Zapier (55)

• 功能: 通过一个 MCP 端点连接到 Zapier 平台上的数千个应用和数万个动作 (Actions)。

• 场景: 让 AI 触发复杂的跨应用工作流，例如“当 GitHub 有新 Issue 时，在 Slack 通知并在 Trello 创建卡片”。

• 配置提示 (mcp.json): 使用 mcp-remote 连接到 Zapier 提供的个人 MCP 端点 URL。

• JSON

{
  "mcpServers": {
    "zapier-mcp": {
      "command": "npx",
      "args":,
      "transport": "stdio" // 通过 mcp-remote 包装
    }
  }
}

• 环境变量: 不需要，认证通过端点 URL。需要在 Zapier 网站配置允许的 Actions。

1. Command Line Execution (通用命令行) (55)

• 功能: 允许 AI 执行任意（或受限的）本地 shell 命令。（安全风险高，需谨慎配置和使用）

• 场景: 运行构建脚本、代码 linter/formatter、自定义工具。

• 配置提示 (mcp.json): 实现方式多样，需要特别注意安全。假设一个简单的实现：

• JSON

{
  "mcpServers": {
    "local-cli": {
      "command": "python", // 或其他脚本语言"args": ["/path/to/secure_cli_wrapper.py", "--allow-list", "npm,git,lint"], // 包装脚本，限制可执行命令"transport": "stdio"
    }
  }
}

• 环境变量: 取决于具体实现和包装脚本。

1. E2B Code Sandbox (86)

• 功能: 在安全的云端沙箱环境中执行代码片段。

• 场景: 让 AI 安全地测试生成的代码片段，验证其功能，而无需在本地执行。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "e2b-sandbox": {
      "command": "npx",
      "args": ["-y", "e2b-mcp-server"], // 假设包名"env": {
        "E2B_API_KEY": "YOUR_E2B_API_KEY"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 E2B_API_KEY。

g. 邮件与其他通信 (Email & Other Communication)

1. Resend (57)

• 功能: 通过 Resend API 发送邮件。

• 场景: 让 AI 根据生成的内容（如报告、摘要）自动发送邮件。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "resend-mcp": {
      "command": "npx", // 假设"args": ["-y", "resend-mcp-server"],
      "env": {
        "RESEND_API_KEY": "re_YOUR_RESEND_KEY"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 RESEND_API_KEY。

1. Mailtrap (57)

• 功能: 通过 Mailtrap API 发送（通常是测试）邮件。

• 场景: 在开发和测试阶段，让 AI 发送邮件到 Mailtrap 的虚拟收件箱进行验证。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "mailtrap-mcp": {
      "command": "npx", // 假设"args": ["-y", "mailtrap-mcp-server"],
      "env": {
        "MAILTRAP_API_TOKEN": "YOUR_MAILTRAP_TOKEN"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 MAILTRAP_API_TOKEN。

h. AI 与特定任务 (AI & Specialized Tasks)

1. Sequential Thinking (54)

• 功能: 引导 LLM 进行更结构化、逐步的思考和问题分解。

• 场景: 处理复杂任务时，强制 AI 先规划步骤再执行，提高成功率和逻辑性。

• 配置提示 (mcp.json):

• JSON

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
      "transport": "stdio"
    }
  }
}

• 环境变量: 通常不需要。

1. OpenAPI (48)

• 功能: 让 AI 能够理解并调用符合 OpenAPI (Swagger) 规范定义的 API。

• 场景: 集成内部或第三方的 REST API，让 AI 可以像调用函数一样调用它们。

• 配置提示 (mcp.json): 假设存在 npx 包：

• JSON

{
  "mcpServers": {
    "openapi-mcp": {
      "command": "npx",
      "args": ["-y", "openapi-mcp-server", "--spec", "/path/to/openapi.yaml"], // 提供 OpenAPI 规范文件路径或 URL"env": {
        // 可能需要 API Key 或认证信息用于调用目标 API"TARGET_API_KEY": "secret"
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 可能需要目标 API 的认证信息。

i. MCP 服务器聚合器/管理器 (Aggregators/Managers)

1. MCP Router (136)

• 功能: 一个本地应用 (Windows/MacOS)，可以管理多个 MCP 服务器，提供统一接口、日志记录和访问控制。支持连接 Zapier, Smithery 等注册中心的服务器。

• 场景: 当使用大量 MCP 服务器时，简化管理和配置，增加安全性和可观察性。

• 配置提示 (mcp.json): 需要先安装并运行 MCP Router 应用，然后在 Cursor 中配置连接到它。

• JSON

{
  "mcpServers": {
    "mcp-router": {
      "command": "npx",
      "args": ["-y", "mcpr-cli", "connect"],
      "env": {
        "MCPR_TOKEN": "YOUR_MCP_ROUTER_ISSUED_TOKEN" // 需要在 MCP Router 应用中获取 Token
      },
      "transport": "stdio"
    }
  }
}

• 环境变量: 需要 MCPR_TOKEN。

1. Smithery CLI (104)

• 功能: Smithery 是一个 MCP 服务器托管和发现平台。其 CLI 工具可以方便地安装和配置托管在 Smithery 上的 MCP 服务器到本地客户端 (如 Cursor)。

• 场景: 快速添加和配置来自 Smithery 平台的 MCP 服务器，通常会自动处理 mcp.json 的修改。

• 配置提示: 通常不直接在 mcp.json 中配置 Smithery CLI 本身，而是使用 CLI 命令来安装其他服务器，例如：npx -y @smithery/cli@latest install neon --client cursor。CLI 会自动修改 Cursor 的 mcp.json 文件。

• 环境变量: 安装具体服务器时可能需要提供 API Key 等信息。

[表格：MCP 服务器展示摘要 (中文表头：服务器名称, 分类, 核心功能, 配置要点, 链接)]

(表格内容根据上面 30 个示例进行填充)

3. 寻找更多 MCP 服务器

MCP 生态正在快速发展，除了上面列出的，还有很多其他的服务器。去哪里找呢？

• 官方/核心仓库:

• modelcontextprotocol/servers: Anthropic 官方维护的参考服务器实现 (54)。

• modelcontextprotocol GitHub 组织下的其他 SDK 仓库 (Python, TypeScript, Java 等) 可能包含示例 (147)。

• 社区 Awesome Lists: 这些是 GitHub 上由社区维护的 MCP 服务器列表，非常全面：

• appcypher/awesome-mcp-servers (55)

• punkpeye/awesome-mcp-servers (137)

• TensorBlock/awesome-mcp-servers (121)

• wong2/awesome-mcp-servers (91)

• apappascs/mcp-servers-hub (149)

• 专门的 MCP 目录/平台:

• cursor.directory/mcp: Cursor 官方社区维护的目录 (57)。

• mcpservers.org: 一个独立的 MCP 服务器目录网站 (101)。

• smithery.ai: 一个提供 MCP 服务器托管和安装服务的平台 (138)。

• mcphub.ai: 一个搜索 MCP 服务器的平台 (143)。

• 论坛和社区:

• Cursor 官方论坛: https://forum.cursor.com/ (搜索 MCP 相关帖子) (150)。

• Reddit: r/cursor, r/ClaudeAI, r/mcpserver 等子版块 (89)。

这个生态系统的快速发展既是好事（选择多），也带来了挑战（发现和选择困难）。利用好这些聚合资源，可以帮你找到满足特定需求的 MCP 服务器。

五、竞品对比分析：Cursor 在 AI 编辑器江湖中的位置

Cursor 不是一个人在战斗。市面上还有不少其他的 AI 编程助手或 AI 编辑器。了解它们的异同，能帮你更好地判断 Cursor 是否适合你，以及它的独特价值在哪里。

[注意：以下对比基于截至 2025 年初的信息，技术发展很快，具体功能和定价可能有变动。]

1. Cursor vs. GitHub Copilot

这是最常被拿来比较的一对。

• 定位与集成:

• Cursor: 一个独立的 AI-First IDE，是 VS Code 的一个深度定制分支 (fork) (4)。AI 功能是其核心，深度整合。

• Copilot: 主要是一个编辑器插件/扩展，深度集成在 VS Code、Visual Studio、JetBrains IDEs、Neovim 等主流编辑器中 (5)。

• 核心功能:

• 代码补全: 两者都提供智能的代码补全 (ghost text)。Cursor 的补全 (有时称 Supercomplete 或 Tab) 号称更懂整个项目上下文，尤其擅长多文件场景和自动导入 (5)。Copilot 的补全也非常强大，尤其擅长预测下一行或常用模式 (5)。

• 聊天 (Chat): 两者都有聊天界面。Cursor 的聊天可以方便地 @ 文件/符号，甚至嵌入图片 (7)。Copilot Chat 集成在 IDE、GitHub.com、移动端，企业版还能连接内部知识库 (10)。

• 代码生成/编辑: Cursor 的 ⌘K 和 Composer/Agent 模式擅长根据自然语言进行行内编辑或大范围修改/生成 (7)。Copilot 也有类似功能，如 Copilot Chat 生成代码块，以及较新的 Agent Mode 和 Edit Mode (主要在 VS Code 中) 用于跨文件修改 (8)。

• Agent 能力: Cursor 的 Agent 模式是其早期核心卖点，能执行复杂任务、调用 MCP 工具、运行终端命令 (7)。Copilot 的 Agent 模式也在逐步推出和完善，更侧重于与 GitHub Actions 等生态集成 (10)。

• 上下文理解: Cursor 通过代码索引、Rules、MCP 等方式，强调对整个项目的深度理解 (5)。Copilot 也在不断改进上下文理解能力，但传统上更侧重当前文件和有限窗口 (5)。

• 调试: Cursor 提供 "Debug with AI" 功能尝试辅助调试 (4)。Copilot 的调试辅助相对较弱 (6)。

• AI 模型:

• Cursor: 用户可以选择多种模型，包括最新的 Claude 3.7、GPT-4o 等，甚至可以自带 API Key (5)。

• Copilot: 主要使用 OpenAI 的模型 (Codex/GPT)，模型选择对用户不透明，由 GitHub/Microsoft 管理 (5)。

• 性能与速度: Copilot 通常被认为作为插件更轻量，补全响应快 (5)。Cursor 功能更强，资源消耗可能稍高，但复杂任务生成速度可能因模型选择而更快 (5)。

• 定价:

• Cursor: 有免费额度，Pro 版 $20/月 (有 Fast Request 限制，约 500 次)，超出或使用 MAX 模型需额外付费 (10)。

• Copilot: 个人版 $10/月，商业版 $19/用户/月，提供企业版。价格相对固定和便宜 (5)。

• 结论:

• 选 Cursor: 如果你需要一个深度集成的 AI IDE，看重对整个项目的理解能力，需要灵活选择最新 AI 模型，并且愿意通过 Rules 和 MCP 进行深度定制，不介意稍高的价格和可能的学习曲线。

• 选 Copilot: 如果你习惯于现有的 IDE (特别是 VS Code)，需要一个无缝集成、性价比高、性能稳定的 AI 助手，主要用于代码补全和基础聊天辅助。

2. Cursor vs. Windsurf (Codeium)

Windsurf 是 Codeium 公司推出的独立 AI IDE，同样基于 VS Code fork，是 Cursor 的直接竞争对手。

• 定位与集成: 两者都是独立的 AI-First IDE，基于 VS Code fork (8)。Codeium (Windsurf 的母公司) 也提供编辑器插件 (157)。

• UI/UX: Cursor 功能按钮多，界面可能显得“拥挤” (4)。Windsurf 追求极简设计，界面更干净，对新手可能更友好 (155)。

• AI 交互哲学:

• Cursor: 像个工具箱，提供多种 AI 功能（补全、聊天、编辑、Agent、Rules、MCP），需要用户主动调用和配置 (155)。上下文管理需要用户通过 @ 等方式显式提供 (155)。

• Windsurf: 更强调其 Agentic AI "Cascade"，号称能自动理解代码库，主动分析并进行多步骤操作，交互更像“伙伴” (156)。上下文管理更自动化 (159)。

• 核心功能:

• 代码补全: Cursor 有 Tab Supercomplete。Windsurf 也有 Supercomplete，提供 diff 预览 (8)。

• Agent/Composer: Cursor 有 Agent 模式和 Composer。Windsurf 有 Cascade，区分 Write (写代码) 和 Chat (聊天) 模式，强调工作流 (8)。

• 上下文/规则: Cursor 有强大的 Rules 系统进行定制 (20)。Windsurf 号称自动理解上下文，规则定制能力相对较弱，但有用户反馈其对规则的遵守度可能更好 (160)。

• 终端集成: 两者都有。Windsurf 的终端集成被一些用户认为更直观 (159)。

• 预览: Windsurf 提供 AI 修改的实时预览，Cursor 则需要接受更改后才能看到效果 (158)。

• 性能与成本: Windsurf 号称更快、更轻量 (158)。但在 API 调用成本上，有用户反馈 Windsurf 的 Cascade 可能比 Cursor 消耗更多 token/credits (160)。

• 定价: Windsurf 定价策略近期有调整 (162)。目前 Pro 版 $15/月，提供 500 User Prompt credits 和 1500 Flow Action credits (旧版是 Flex credits) (162)。Cursor Pro 版 $20/月，提供 500 Fast Requests (10)。Windsurf 的定价体系更复杂（区分 User Prompt 和 Flow Action credits），但基础价格更低 (155)。Windsurf 的免费版对其自研的 Cascade Base 模型是无限使用的 (164)。

• 结论:

• 选 Cursor: 如果你需要更强大的功能集、更精细的上下文控制 (通过 Rules)、灵活的模型选择，并且不介意稍复杂的界面和更高的基础价格。

• 选 Windsurf: 如果你喜欢简洁的界面、更自动化的 Agentic 工作流、更低的入门价格，并且能接受其独特的 credit 定价模型。对新手可能更友好。

3. Cursor vs. Cline

Cline 是一个开源核心的 AI 编程助手，通常作为 VS Code 插件使用，以其深度思考和 MCP 集成为特点。

• 定位与集成: Cursor 是独立 IDE (4)。Cline 主要是 VS Code 插件，也有 CLI (9)。有意思的是，一些用户会在 Cursor IDE 内部使用 Cline 插件，取长补短 (4)。

• AI 交互哲学: Cursor 追求快速响应和直接的代码修改 (166)。Cline 则强调“思考过程”，会与开发者进行更深入的对话，解释步骤，像一个真正的结对编程伙伴 (166)。

• 核心功能:

• Agentic 能力: 两者都有。Cursor 的 Agent 更集成在 IDE 体验中。Cline 的 Agentic 能力非常强，尤其擅长结合 MCP 调用外部工具完成复杂任务 (166)。

• MCP 支持: 两者都支持 MCP。Cline 对 MCP 的支持似乎更早、更核心，社区生态也更活跃 (55)。

• 上下文与记忆: Cline 有“记忆库”(Memory Bank) 的概念，结合 MCP 可以实现更持久的上下文记忆 (169)。Cursor 主要依赖索引和 Rules。

• 代码编辑: Cursor 的行内编辑 (⌘K) 和 Tab 补全很方便。Cline 更侧重于通过 Agent 进行大块代码的生成和重构，轻量编辑能力相对较弱 (169)。

• AI 模型与成本: Cursor 提供内置模型选择，价格固定 (11)。Cline 采用 BYOK (Bring Your Own Key) 模式，用户需要自己提供 OpenAI, Anthropic, Google 等模型的 API Key，按实际 Token 使用量付费 (166)。这意味着 Cline 可以使用任何最新的模型，但成本可能非常高，尤其对于复杂任务，一晚上花费几十美元是可能的 (169)。

• 结论:

• 选 Cursor: 如果你需要一个功能全面、价格可预测的 AI IDE，并且其内置模型和 Rules 系统能满足需求。

• 选 Cline: 如果你需要极致的模型灵活性（使用最新、最强或特定模型），深度依赖 MCP 生态，追求最高质量的 Agentic 协作（不惜成本），并且习惯在 VS Code 环境下工作。

4. Cursor vs. Codeium (插件)

Codeium 除了 Windsurf IDE，其核心能力也以插件形式提供，支持多种 IDE。

• 定位与集成: Cursor 是独立 IDE (4)。Codeium 是多 IDE 插件 (VS Code, JetBrains 等) (157)。

• 核心功能: Cursor 功能更全面（Agent, Rules, MCP 等）(7)。Codeium 插件的核心是代码补全和聊天 (157)。Codeium 的补全速度和质量评价很高，尤其在企业版中支持基于私有代码库的个性化模型 (157)。

• 上下文理解: Cursor 依赖索引和 Rules (7)。Codeium 也声称有上下文感知能力，企业版可以针对性训练 (157)。

• 定价: Cursor Pro $20/月 (153)。Codeium 插件有非常慷慨的免费个人版，Teams 版 $12/用户/月，企业版提供自托管和 VPC 部署选项 (154)。

• 安全性: 两者都强调隐私。Codeium 企业版提供自托管等选项，对数据安全要求高的企业吸引力较大 (157)。Cursor 也有 Privacy Mode 和 SOC 2 认证 (20)。

• 结论:

• 选 Cursor: 如果你需要一个集成的 AI IDE 体验，包含 Agent、Rules、MCP 等高级功能。

• 选 Codeium (插件): 如果你只想在现有 IDE 中获得高质量的代码补全和基础聊天功能，并且看重其免费版或企业级的定制和安全选项。

5. Cursor vs. Augment Code

Augment 是一个较新的竞争者，也提供 IDE 插件。

• 定位与集成: Cursor 是独立 IDE (4)。Augment 是 IDE 插件 (支持 VS Code 等) (170)。

• 核心卖点: Augment 强调其基于整个项目上下文的、极其快速和准确的代码补全 (171)。它声称能自动理解整个项目，无需用户手动添加上下文 (171)。

• 功能对比: Cursor 功能更广（Agent, Rules, MCP, Debugging）(4)。Augment 更聚焦于代码补全和聊天，利用其上下文理解能力 (170)。

• 性能: Augment 号称其补全速度比 Copilot 快 2-3 倍 (171)。

• 安全性: Augment 特别强调其安全设计，如默认安全、租户隔离、持有证明 (Proof-of-Possession) 授权、SOC 2 Type II 认证 (171)。

• 定价: Augment 定价较高，为 $60/开发者/月 (172)。远高于 Cursor 的 $20/月 Pro 版。

• 结论:

• 选 Cursor: 如果你需要更全面的 AI 功能集 (Agent, Rules, MCP) 和更低的价格。

• 选 Augment: 如果你的核心需求是极致的代码补全速度和基于全项目上下文的准确性，并且重视其宣称的安全特性，愿意为此支付高昂的费用（可能更适合企业客户）。

6. 总结对比

(161)

这个对比能看出来，AI 编程工具市场已经不是一家独大的局面了 (161)。Cursor 凭借其 AI-First 的理念和 Rules/MCP 的定制化能力，占据了一个独特的生态位。但它也面临着来自各方面的竞争，用户需要根据自己的具体需求、预算和技术偏好来做选择。

六、总结与展望

好了，关于 Cursor 的 Rules 和 MCP，以及它在整个 AI 编程助手领域的定位，咱们聊得差不多了。最后总结几句，再展望一下未来。

Cursor 的独特价值：规则 (Rules) 与 MCP 的力量

• 核心优势回顾：Cursor 不仅仅是个带 AI 功能的编辑器，它是一个以 AI 为核心构建的开发环境。它的优势在于深度集成、对整个代码库的理解能力（通过索引），以及最重要的——通过 Rules 系统和 MCP 协议实现的高度可定制化和可扩展性。

• Rules 的价值：Rules 让 AI 不再是“一问一答”的通用模型，而是变成了理解你项目规范、遵循你团队约定的“定制化助手”。这大大提高了 AI 输出的可用性，减少了人工修改的成本。

• MCP 的价值：MCP 则打破了 AI 的“次元壁”，让它能够与外部世界互动——访问数据库、调用 API、操作文件系统、执行命令…… 这使得 AI 能够完成过去无法想象的复杂任务，真正成为开发流程中的“智能体”(Agent)。

• 最新模型支持：Cursor 持续跟进最新的 AI 模型，如 Claude 3.7 Sonnet (包括高上下文、高工具调用限制的 MAX 版本) (11)，确保用户能用上最前沿的技术。

量体裁衣：Cursor 最适合谁？

Cursor 可能特别适合以下类型的开发者或团队：

• 追求极致效率的 Power User：愿意投入时间学习和配置 Rules、MCP，以换取 AI 更精准、更强大的辅助。

• 希望规范团队工作流的团队：可以通过共享的项目规则 (Project Rules) 来统一代码风格、强制最佳实践、固化特定工作流程（尽管共享机制目前还需完善 (20)）。

• 处理大型、复杂项目的开发者：Cursor 对整个代码库的理解能力，以及 Agent 模式处理多文件任务的能力，在这种场景下优势明显。

• 探索 Agentic AI 前沿应用的开发者：对利用 MCP 连接外部工具，让 AI 自动完成更复杂任务感兴趣的探索者。

当然，也要看到它的潜在不足：

• 成本：Pro 版 $20/月的基础费用，加上 Fast Request 的限制，以及使用 MAX 模型或大量 MCP 调用可能产生的额外费用，对个人或预算有限的团队来说可能偏高 (178)。

• 学习曲线：要充分发挥 Rules 和 MCP 的威力，需要一定的学习和配置成本。

• 稳定性与 UI：作为快速迭代的产品，可能会遇到一些 Bug 或 UI 不够简洁的问题 (4)。

AI 编程助手的未来：路在何方？

AI 编程助手领域正在飞速发展，未来可能会看到以下趋势：

• 更深的 IDE 集成: AI 不再是简单的插件，而是与 IDE 的核心功能（调试、重构、版本控制、项目管理）更紧密地结合。

• 更强的 Agentic 能力: AI 将能更自主地理解复杂需求、规划任务、执行多步骤操作、并从错误中学习和恢复。

• 标准化工具交互: 像 MCP 这样的开放标准可能会得到更广泛的应用，使得 AI 能够轻松地与各种开发工具和服务交互，形成更开放的生态 (45)。

• 多模态交互: AI 不仅能理解代码和文本，还能理解图表、UI 设计稿、甚至语音指令 (50)。

• 个性化与自适应: AI 助手能更好地学习每个开发者或团队的编码风格、偏好和项目特定知识，提供更个性化的服务。

• 安全与隐私: 随着 AI 更多地参与到开发流程中，如何确保代码安全、防止敏感数据泄露将成为越来越重要的问题 (81)。

在这个浪潮中，Cursor 凭借其对 AI 的深度整合，特别是 Rules 和 MCP 这两大支柱，无疑走在了 AI-First IDE 探索的前列。它为开发者提供了一个高度可定制、可扩展的平台，让我们有机会塑造 AI，让它真正成为符合我们需求的编程伙伴。当然，它也面临激烈的竞争和自身的挑战。未来如何，我们拭目以待。

希望这篇深度解析能帮助你更好地理解和使用 Cursor。用好它，也许真的能让你的编码效率提升一个档次。我是老金，咱们下次再聊！