Cursor使用指南

本章要点

在上一章的第一次实践中，我们安装了Cursor，体验了它的四种模式，写出了第一段AI辅助的代码。那一章像是一次初次见面——你知道了对方叫什么、大概是做什么的，但还没来得及深入了解。这一章，我想带你真正认识Cursor：它是如何理解你的项目的，你能做哪些配置让它更懂你，如何管理对话的上下文，如何在不同场景下选择最合适的模型，以及在让AI接触你的代码时，隐私和安全应该怎么考虑。

从工具到伙伴：Cursor的设计哲学

要真正用好Cursor，先要理解它的设计哲学——因为只有理解了这一点，你才能明白为什么某些功能要这样设计，以及在遇到困惑时该往哪个方向思考。

Cursor最核心的设计理念，是把AI从"功能"变成"环境"。在传统的IDE里，代码编辑是主体，AI只是一个可以调用的附加功能——就像一台电脑上安装了一个计算器应用。而Cursor的思路刚好反过来：AI是整个环境的中枢，代码编辑器是AI工作的舞台。你不需要去"打开AI"，因为AI始终在场。

这种哲学带来了一个深远的影响：Cursor并不满足于只帮你写当前这几行代码，它真正想做到的是理解你的整个项目。它会在你打开项目时默默建立代码索引，理解文件之间的调用关系，记住你的代码风格和命名习惯。当你让它帮你添加一个功能时，它不会凭空生成通用代码，而是尽力遵循你项目里已有的模式和约定。

理解了这一点，你就会明白为什么Cursor不只是一个"更聪明的代码补全工具"，而是一个会随着你的项目积累越来越懂你的伙伴。而接下来要讲的所有功能，本质上都是在回答同一个问题：如何让这个伙伴更懂你？

Rules：让AI记住你的偏好

想象一下，如果你招募了一个聪明的实习生，第一天你需要告诉他各种规范：我们用Python，命名用下划线风格，函数必须有注释，不要用旧版的API。这些事情你说了一遍，他记住了。但三天后来了一个新任务，你又要重新说一遍，因为他"忘了"。

这正是初学者使用Cursor时的常见体验——每次新的对话，AI都不记得你上次强调过什么。不是它不聪明，而是它本来就没有"记忆"。每次对话对AI来说都是一张白纸。

Cursor提供了一个优雅的解决方案：Rules（规则）。它让你可以把这些"背景知识"写成文档，Cursor每次回答都会自动参考这些规则。你说一次，它永远记住。

全局规则与项目规则

Rules分为两个层次。全局规则是你个人的偏好，适用于你在Cursor中打开的所有项目。打开Cursor设置（Cmd+, 或 Ctrl+,），找到"Rules for AI"，在这里写下你希望AI始终遵守的事情，比如"请始终用中文回复我"，或者"在给出代码前先解释你的思路"。这些规则会跟着你走，不管你打开哪个项目。

项目规则则是针对特定项目的约定。在你的项目根目录下创建 .cursor/rules/ 文件夹，在里面放置Markdown格式的规则文件。这些文件可以提交到Git，和代码一起被团队成员共享。

一个典型的项目规则文件可能长这样：

# 项目规则

## 技术栈
这是一个基于 FastAPI 的后端项目，使用 PostgreSQL 数据库和 SQLAlchemy ORM。
所有API路由在 src/routers/ 目录下，数据库模型在 src/models/ 目录下。

## 代码规范
- 使用 Python 3.11+ 的类型注解，所有函数必须有类型提示
- 命名风格：变量和函数用 snake_case，类用 PascalCase
- 每个函数必须有 docstring，描述功能、参数和返回值
- 使用 Pydantic v2 定义请求/响应的数据结构

## 数据库操作
- 所有数据库操作必须通过 Repository 模式进行，不要直接在路由里查询数据库
- 使用 async/await 编写异步代码

## 错误处理
- 使用自定义异常类，不要直接抛出 HTTPException
- 所有异常要有有意义的错误信息和正确的HTTP状态码

有了这份规则文件，当你告诉Cursor"帮我写一个用户注册的API"时，它不会给你一个到处都是同步代码、没有类型注解、直接在路由里操作数据库的通用实现，而是会生成一份符合你项目约定的代码。

规则文件支持精细的控制方式。你可以设置某条规则"始终生效"，也可以设置"仅当处理特定文件类型时生效"——比如一套规则只在处理 .sql 文件时应用，另一套只在处理 .tsx 文件时应用。你还可以让AI自己判断某条规则是否与当前任务相关，只在需要时引入，避免在每次对话中占用太多上下文空间。

社区里有一些很好的规则文件资源，比如 cursor.directory 和 dotcursorrules.com，你可以找到别人为各种技术栈（React、Django、Go、Rust）写好的规则模板，在此基础上修改成适合自己项目的版本，省去从零摸索的时间。

规则的最佳实践

规则文件写得越精准，AI的表现就越好，但也有一些需要注意的地方。

长度要克制。规则文件不是说明书，不是越长越好。每次对话时，规则文件的内容会被加入到上下文中，太长的规则会"稀释"真正有用的信息，甚至超出模型的处理能力。一般来说，一份规则文件保持在500行以内是合理的。

要定期更新。项目在演进，规则文件也应该跟着演进。三个月前你们还在用 Vue 2，现在已经迁移到 Vue 3，但规则文件里还写着旧的API用法，AI就会给你生成"过时的正确代码"。把更新规则文件当成项目迭代的一部分，而不是一次性的配置任务。

写给AI看，也写给人看。规则文件本质上是Markdown文档，写清楚一点，既能让AI更好地理解，也能帮助新加入的团队成员快速了解项目规范。

上下文管理：让AI看到正确的内容

Cursor的Agent能力强大，但有一个根本性的约束：它在每次对话中能"看到"的内容是有限的。这个限制来自大语言模型的上下文窗口——你可以把它想象成AI的"工作记忆"，它能同时处理的信息是有上限的。

如何在有限的上下文空间里放入最有价值的信息，是使用Cursor时一门需要学习的艺术。

@ 符号：主动指定上下文

第一章里我们简单提到了 @ 符号，这里我想更系统地介绍它。在Cursor的对话框里输入 @，会弹出一个选项列表，让你可以精确地引用各种信息来源：

@文件名 是最常用的方式。当你问"帮我给这个函数写测试"时，不要假设AI知道你在说哪个文件——用 @utils.py 里的 parse_config 函数帮我写单元测试，明确指出你想处理哪个文件里的哪个函数。

@Codebase 会让AI在整个代码库中搜索相关内容。当你问"我们项目里有没有处理文件上传的代码？"时，加上 @Codebase 能让AI先搜索，再基于找到的实际代码来回答，而不是给你一个凭空想象的答案。这对于摸清一个不熟悉的项目特别有用。

@Web 让AI在回答前先搜索互联网。当你遇到某个库的最新用法、需要查最新的API文档、或者想了解某个概念的最新进展时，加上 @Web 能确保AI给你的信息是最新的，而不是它训练数据截止时的旧内容。

@Docs 让你可以引用官方文档。你可以先通过设置把常用的文档地址添加进来——比如React官方文档、FastAPI文档、你们内部Wiki的地址——然后在对话中用 @Docs 引用。这比每次让AI去网上搜更精准，因为你指定了它该读哪里。

除了这些，你还可以引用 @Git 来让AI参考最近的提交记录，或者引用 @终端 来让AI看到你刚才运行命令的输出结果。这些都是在帮AI建立"任务现场"——你知道的越多、AI看到的信息越完整，它给出的答案就越准确。

.cursorignore：告诉AI不要看什么

控制上下文，不只是选择"让AI看什么"，还要决定"让AI不看什么"。

在你的项目里可能有大量不应该被AI处理的文件：node_modules/ 里有数十万行第三方代码，dist/ 或 build/ 是编译产物，.env 里有敏感的密钥和配置，某些大型的数据文件或者日志文件也没有让AI读的价值。

你可以在项目根目录创建 .cursorignore 文件，语法和 .gitignore 完全一样：

# 不索引依赖
node_modules/
vendor/
.venv/

# 不索引构建产物
dist/
build/
*.pyc

# 不上传敏感文件
.env
*.key
*.pem
secrets/

# 不索引大型数据文件
data/raw/
*.csv
*.parquet

这个文件有两个好处：一是减少了Cursor建立代码索引时需要处理的文件量，让搜索和理解更快；二是在涉及安全的场景下，防止你不小心把敏感文件的内容发送给AI服务。

管理对话上下文

另一个常被忽视的点是：及时开始新的对话。当你用Agent做了一个任务，再接着做第二个、第三个不相关的任务，对话历史里积累了越来越多与当前任务无关的内容，AI的性能会下降，回答会变得不那么准确。

养成一个习惯：一个任务（或一个主题）用一个会话。当你发现AI的回答开始显得"神游"——回答的是你上几条消息里的问题，或者忘记了你刚才说的事情——这通常是信号，该点击"新对话"重新开始了。

选择合适的模型

Cursor支持多种AI模型，你可以在输入框旁边的模型选择器中切换，也可以按 Cmd+/（Mac）或 Ctrl+/（Windows）快速切换。不同的模型有不同的特点，选对模型能让你获得更好的体验和更低的成本。

Cursor自研模型

Cursor有两类自研模型：Tab补全模型和Composer/Sonnet模型。

Tab补全模型专门为代码补全优化，追求的是极致的低延迟——当你停顿下来，它应该在毫秒级内给出建议，不能打断你的打字节奏。这个模型背后集成了Supermaven技术，它的厉害之处在于"预判"：它不只是补全你正在写的这一行，还能预测你接下来要修改哪里。你刚改了一个变量名，它会建议你更新所有引用；你新增了一个字段，它会建议你在哪些地方使用它。

Cursor还推出了自家的编程专用模型Cursor Composer，主打的就是速度，特别适合需要快速迭代的编程任务。当你面对一个"帮我把这个函数重构一下"这样的明确任务，它的响应速度比同等能力的其他模型快得多。

Claude系列：适合复杂推理

Anthropic的Claude系列在代码生成和解释上有很强的表现，尤其是Claude Sonnet，是当前最受欢迎的编程助手之一。它的特点是：理解复杂需求的能力强，生成的代码注释详细，解释问题时有耐心。

如果你在处理的任务需要复杂的逻辑推理——比如设计一个复杂的系统架构、理解一段晦涩的算法、或者追踪一个涉及多个文件的bug——Claude Sonnet往往会给出更有深度的分析。

Claude Opus是Claude系列中能力最强的，但速度更慢、成本更高。适合真正复杂的任务，比如全面地重构一个模块、理解复杂的多线程问题，或者需要模型进行长链推理的场景。

GPT系列：适合快速响应

OpenAI的GPT系列（包括o系列推理模型）也在Cursor中可用。GPT-4o在速度和能力之间取得了很好的平衡，适合日常的代码生成任务。o3/o4-mini这类推理模型在解决复杂的算法问题和数学逻辑问题上表现突出，但响应更慢。

怎么选？

一个简单的经验是：用Cursor自研模型做代码补全，用Claude Sonnet做Agent任务，遇到真正复杂的推理问题时试试Claude Opus或o3。

当你只是在写代码，不需要对话，让Tab补全模型静静工作就好。当你有一个具体的任务要委托给Agent，比如"帮我写一个功能"或"帮我调试这个bug"，Claude Sonnet是一个很稳健的选择。而当你面对的问题感觉已经超出了普通对话的处理范围——比如分析一个复杂的并发问题或者设计一套精妙的缓存方案——那时值得把模型调到更强力的那一档，哪怕慢一点。

Background Agents：让AI异步工作

如果你用过Cursor一段时间，可能会发现一个不那么顺手的地方：当Agent在处理一个复杂任务时，你需要等着它完成，不能在同一个会话里做其他事情。特别是那些需要五到十分钟才能完成的任务，你只能干等。

Cursor 2.0引入了**Background Agents（后台Agent）**来解决这个问题。按下 Ctrl+E 启动后，你可以把任务交给一个在后台运行的Agent，然后你继续做别的事情。它完成后会通知你，你再回来审查结果。

Background Agent的工作方式有些不同。它不是在你本地机器上运行的，而是在一个隔离的云端Ubuntu环境里工作。这个环境会从你的GitHub仓库克隆代码，Agent在里面修改文件、运行测试，完成后把结果推送到一个新的分支上，你只需要创建一个Pull Request审查它的工作就好。

这种方式有几个显著的优点。首先，它不会影响你的本地工作环境——Agent在云端折腾，你本地的代码不会受到任何影响。其次，因为不需要等待你确认每一步操作，它可以更快地完成任务。第三，你可以同时启动多个Background Agent处理不同的任务，并行推进多个方向。

当然，你需要清楚这个方案的代价：代码会被发送到远程服务器处理，这意味着如果你开启了严格的隐私模式，Background Agent就无法使用。对于含有敏感商业逻辑或安全要求高的项目，你需要权衡一下。

隐私与安全：你的代码去了哪里

当你使用AI编程工具时，一个不可回避的问题是：我的代码发给了谁？会不会被用来训练模型？会不会泄露出去？

这些顾虑是完全合理的，Cursor在这方面提供了几个层次的控制。

三个隐私级别

在Cursor设置（Cursor Settings > General > Privacy Mode）里，你可以选择三个隐私级别：

无隐私保护（默认）：Cursor可以收集你的提示词和代码片段用于产品改进。代码可能被存储和分析。这个设置适合对隐私没有特别要求的个人项目和学习使用。

隐私模式（Privacy Mode）：你的代码不会被用于模型训练，但Cursor可能会存储部分数据来支持某些功能（比如Background Agents需要云端存储代码）。这是大多数专业开发者的推荐选项——兼顾了功能完整性和基本的隐私保护。Cursor与OpenAI和Anthropic都签有零数据保留协议，开启隐私模式后你的代码不会被这些模型供应商保留。

Ghost Mode（最严格的隐私）：开启后，Cursor会在本地拦截并丢弃所有聊天内容、代码片段、Agent操作记录。服务器只接收到最少量的元数据，代码和提示词不会离开你的本地机器。代价是：所有需要云端支持的功能（Background Agents、跨设备同步、内存功能）全部不可用。

可以在 Settings → Advanced → Local / Ghost Mode 中切换到Ghost Mode。对于处理机密代码、财务数据或政府项目的开发者，这是更适合的选项。

用.cursorignore保护敏感文件

除了整体的隐私模式，对于那些你永远不想发送给任何AI服务的文件，可以用前面提到的 .cursorignore 文件把它们排除在外。Cursor会尽力确保这些文件不被包含在任何发送给服务器的请求中。

一个好习惯是：即便你信任Cursor的隐私承诺，也不要把包含密钥、密码、数据库连接字符串的文件暴露给AI。不是不信任Cursor，而是减少不必要的风险。.env 文件永远应该在 .cursorignore 里。

MCP：打通外部世界

我们在第一章里提到，Cursor的Agent可以读文件、写代码、运行命令。但现实的开发任务往往不只是这些——你需要查询数据库、调用内部API、检索文档系统，甚至让AI帮你在Jira上创建任务。

这时候就到了**MCP（Model Context Protocol）**登场的时候。MCP是Anthropic提出的一个开放标准，定义了AI模型如何安全地连接到外部工具和数据源。Cursor从2.0版本开始支持MCP，让你可以把各种外部能力"插入"到Cursor的Agent里。

MCP是什么概念

把MCP想象成一种插件协议。Cursor本身是一个AI编辑器，它原生能做的事情是处理代码文件和运行终端命令。通过MCP，你可以给它"扩展"各种新能力：

• 连接到你的PostgreSQL数据库，让Agent直接执行查询
• 接入GitHub API，让Agent读取Issue、创建PR
• 连接到Slack，让Agent发送通知
• 接入Kubernetes API，让Agent检查pod状态
• 连接到公司内部的知识库，让Agent参考内部文档回答问题

每一个这样的连接，都是通过一个"MCP服务器"实现的。这个服务器可以运行在你的本地机器上（通过标准输入输出通信），也可以运行在远程服务器上（通过HTTP通信）。

配置一个MCP服务器

以连接GitHub为例。在Cursor中，打开设置并找到MCP配置，添加如下配置：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "你的GitHub Token"
      }
    }
  }
}

配置完成后重启Cursor，Agent就获得了访问GitHub的能力。你可以直接用自然语言让它完成GitHub相关的任务：

查看一下我们仓库里最近的10个Issue，把还未分配给任何人的bug类型Issue列出来。

不需要你自己调用API，不需要切换到浏览器，一切都在Cursor的对话窗口里完成。

社区里有越来越多现成的MCP服务器，覆盖了常用的开发工具和服务。Cursor会在你提问时检测哪些MCP工具与当前任务相关，并自动使用它们。你不需要每次手动告诉Agent"去用GitHub工具"，它会自己判断。

MCP是一个相对新的特性，还在快速发展中。随着更多工具接入MCP标准，Cursor的可用能力会越来越强大。这有点像智能手机的应用生态——手机本身的功能是固定的，但通过应用，它的能力可以无限扩展。

把一切整合起来：一个完整的工作流

讲了这么多独立的功能，让我用一个具体的场景把它们串联起来，让你看到这些功能在实际工作中是如何配合运转的。

假设你正在为一个电商项目添加"商品搜索功能"。这是一个需要前后端配合的中等复杂度任务。

你首先进入 Plan模式，用自然语言描述你的需求：

我需要为电商项目添加商品搜索功能。要求：
- 后端：FastAPI路由，支持按商品名称、分类、价格范围过滤
- 数据库：使用现有的PostgreSQL，商品表是 products，字段有 name、category、price、stock
- 前端：一个搜索栏加过滤器，结果分页展示

Cursor会先读取你的项目文件（此时 .cursor/rules/ 里的项目规则会自动应用），理解现有的代码结构，然后生成一个详细的实施计划：要创建哪些文件、要修改哪些文件、大概的实现思路是什么。

你审核这个计划，发现它建议直接在路由里写数据库查询，而你的项目规则里明确规定要用Repository模式。你把这个反馈告诉AI，它修改计划。计划确认后，切换到Agent模式开始执行。

如果任务足够大，你可以考虑启动Background Agent，把这个任务交给它，然后去处理另一个任务。它会在后台工作，完成后创建一个分支，你回来审查代码即可。

整个过程中，你不需要每次都解释项目规范——Rules文件替你说了；你也不需要担心AI看不到相关代码——@Codebase 和代码索引替你处理了。

快捷键速查

功能	Mac	Windows/Linux
打开内联编辑	Cmd+K	Ctrl+K
打开Agent面板	Cmd+L	Ctrl+L
快速切换模式	Cmd+.	Ctrl+.
切换AI模型	Cmd+/	Ctrl+/
启动Background Agent	—	Ctrl+E
接受更改	Cmd+Enter	Ctrl+Enter
拒绝更改	Cmd+Backspace	Ctrl+Backspace

小结

这一章，我们从更系统的视角重新认识了Cursor。

我们了解了Cursor的核心设计哲学：AI不是功能，而是环境。这决定了它和普通AI插件的本质区别——它真正想做到的是理解你的整个项目，成为越来越懂你的伙伴。

我们学习了Rules系统：通过 .cursor/rules/ 文件夹，你可以把项目规范持久化地告诉AI，让它始终遵循你的代码风格和架构约定，不用每次重复说明。这是专业使用Cursor的关键一步。

我们深入探讨了上下文管理：用 @ 符号精确指定AI应该参考哪些内容，用 .cursorignore 告诉AI不要看哪些文件，以及养成及时开始新对话的习惯——这些细节会显著提升AI回答的准确性。

我们梳理了模型选择的逻辑：Tab补全模型负责实时补全，Claude Sonnet适合日常Agent任务，更强力的模型留给真正复杂的推理场景。选择合适的模型，既能获得更好的体验，也能节省成本。

我们了解了Background Agents：让AI异步工作，你不必守着等待，适合处理耗时较长的复杂任务。

我们认真讨论了隐私与安全：三个隐私级别各有适用场景，敏感文件用 .cursorignore 保护，在功能和隐私之间做出适合自己的选择。

最后，我们初步认识了MCP：通过这个协议，Cursor可以连接到各种外部工具，让AI的能力从处理本地代码延伸到整个开发生态系统。

这些功能加在一起，让Cursor不只是一个"能帮你写代码的编辑器"，而是一个可以根据你的项目和习惯深度定制的AI开发伙伴。工具配置得越好，你的开发体验就越顺畅。

练习

配置题：在你的一个实际项目（或者新建一个测试项目）里，为它创建一套 .cursor/rules/ 规则文件。至少包含：项目的技术栈简介、代码命名规范、一条你认为AI经常会违反的约定。创建好之后，试着让AI做一个代码修改，看看它是否遵循了你的规则。

上下文体验题：在一个你不太熟悉的代码库（可以是一个开源项目）里，试着用以下几种方式问同一个问题："这个项目里处理用户认证的代码在哪里？"

• 第一次：直接问，不加任何 @ 引用
• 第二次：加上 @Codebase 后再问

对比两次回答的质量和准确性。你会发现哪种方式更好？

隐私检查题：打开你的一个项目，检查一下有哪些文件包含敏感信息（密钥、密码、私有配置），确保这些文件都在 .cursorignore 里，或者在 .gitignore 里（Cursor也会参考 .gitignore）。然后检查一下Cursor当前的隐私设置是什么级别，是否符合你对这个项目的安全要求。

模型切换题：选一个你觉得比较复杂的编程问题，分别用两个不同的模型提问，比较它们回答的质量、深度和速度。什么时候你会感觉"换一个更强的模型值得"？形成自己的判断标准。