1. 引言

Cursor 是一款基于 VS Code 深度定制的 AI 原生编辑器，内置了 GPT-4、Claude 等大模型能力，让开发者可以在编辑器中直接与 AI 对话、生成代码、理解项目。然而，很多新手甚至老手在使用过程中都会遇到各种「坑」——比如上下文丢失、代码被意外覆盖、模型理解偏差等。本文将从实际使用经验出发，系统梳理 Cursor 的核心技巧和常见陷阱，帮你真正用好这款工具。

2. 基础操作与核心概念

2.1 三种对话模式

Cursor 提供了三种主要的 AI 交互方式，理解它们的区别是避免踩坑的第一步：

• Chat（Cmd+K/Ctrl+K）：在侧边栏打开对话窗口，适合全局提问、项目理解、代码审查。注意：Chat 默认只看到当前文件内容，不会自动加载整个项目。
• Inline（Cmd+I/Ctrl+I）：在光标处直接弹出编辑框，选中代码后按Cmd+K可让 AI 修改选中区域。这是最常用的局部编辑方式。
• Composer（Cmd+Shift+I/Ctrl+Shift+I）：全屏多文件编辑模式，适合跨文件重构、新建项目。Composer 可以同时修改多个文件，但上下文消耗极大。

2.2 上下文管理（最关键）

Cursor 的 AI 模型有固定的上下文窗口（通常 128K tokens），超出后最早的内容会被「遗忘」。这是大多数问题的根源。

技巧：

• 在 Chat 中手动@引用文件或文件夹，明确告诉 AI 要看哪些代码。
• 使用.cursorrules文件（项目根目录）定义项目规范、技术栈、编码风格，每次对话都会自动加载。
• 长对话中定期开启新对话，避免上下文膨胀导致模型「失忆」。

坑：

• 不要在一个 Chat 里连续问几十个问题，模型会逐渐忘记开头的内容。
• 不要指望 AI 自动理解整个项目结构——它只看到你显式引用的文件。

3. 高效编码技巧

3.1 精准选中，精准修改

Inline 模式下，选中的代码范围决定了 AI 的修改范围。选中一行，AI 只改这一行；选中整个函数，AI 重写整个函数。

技巧：

• 修改 bug 时，只选中出错的几行，不要选整个文件，避免 AI 误改其他逻辑。
• 重构时，选中整个函数或类，让 AI 在保持接口不变的前提下优化内部实现。
• 使用Cmd+Shift+L选中所有相同符号，批量修改。

3.2 用好.cursorrules

在项目根目录创建.cursorrules文件，写入项目信息：

你是一个资深 Python 后端开发者。 项目使用 FastAPI + SQLAlchemy 2.0 + Pydantic v2。 数据库：PostgreSQL 16。 编码规范：遵循 PEP 8，类型注解必须完整。 测试框架：pytest，覆盖率不低于 90%。

每次对话都会自动加载这些规则，AI 的回答会更贴合项目实际。

坑：.cursorrules只对当前项目生效，切换项目后记得重新配置。

3.3 利用 Composer 做跨文件重构

Composer 可以同时看到多个文件并生成跨文件的修改。例如：新增一个 API 接口，需要同时修改路由文件、Service 层、Model 层和测试文件。

技巧：

• 在 Composer 中先@引用所有相关文件，再描述需求。
• 生成后逐文件审查 diff，不要直接 Accept All——Composer 有时会改错文件。
• 复杂重构建议分步进行：先改核心逻辑，再改调用方，最后改测试。

4. 常见坑与避坑指南

4.1 坑一：AI 改错了代码，但已经保存

现象：AI 生成的代码有逻辑错误，你 Accept 后保存了文件，想撤回却发现 Cursor 的 Undo 只能撤回一次。

解决方案：

• 养成习惯：Accept 前先 Review diff（差异对比面板）。
• 使用 Git 做版本管理，每次 AI 修改后Cmd+S前先看一眼 diff。
• 开启 Cursor 的「自动保存到 Git」功能（Settings → Git → Auto Save），每次修改自动生成一个 commit，方便回滚。

4.2 坑二：上下文溢出导致 AI 胡言乱语

现象：对话进行到一半，AI 开始重复之前的回答、忘记你刚说的需求、或者生成完全不相关的代码。

解决方案：

• 每 10-15 轮对话后开启新对话，把关键上下文（项目结构、当前任务）在新对话中重新描述。
• 使用@引用关键文件，而不是依赖对话历史。
• 如果 AI 开始「失忆」，直接说「请忽略之前的对话，重新基于当前文件内容回答」。

4.3 坑三：Inline 模式下误改了大段代码

现象：你只选中了一行，但 AI 把整个函数都重写了，而且改得不对。

原因：AI 认为「选中一行」只是提示，它有权修改更大范围来「让代码更合理」。

解决方案：

• 在 Prompt 中明确加一句：「只修改我选中的部分，不要改动其他代码」。
• 或者用 Chat 模式 + 精确描述，而不是 Inline 模式。
• 修改后立即 Review diff，不对就Cmd+Z撤回。

4.4 坑四：Composer 修改了不该改的文件

现象：你让 Composer 新增一个功能，结果它顺手改了配置文件、README、甚至删除了某些文件。

解决方案：

• 在 Composer 的 Prompt 中明确指定：「只修改我 @ 引用的文件，不要创建或修改其他文件」。
• 每次 Accept 前逐文件检查 diff，特别是非代码文件（如.json、.yaml、README.md）。
• 对于关键配置文件（如settings.py、docker-compose.yml），建议先手动备份。

4.5 坑五：模型选择不当

现象：用 Claude 写代码时逻辑清晰，但用 GPT-4 时经常出错；或者反过来。

建议：

• 写代码、重构、调试：优先用 Claude（Sonnet 或 Opus），代码生成质量更高。
• 写文档、注释、README：GPT-4 更擅长自然语言表达。
• 快速原型、简单脚本：用 Cursor 自带的默认模型即可，速度更快。
• 在 Chat 和 Inline 中可以随时切换模型（右下角模型选择器）。

5. 进阶技巧

5.1 自定义 Prompt 模板

在.cursorrules中定义常用 Prompt 模板，例如：

## 代码审查 当我要求「审查代码」时，请按以下维度检查： 1. 安全性：是否存在 SQL 注入、XSS、敏感信息泄露？ 2. 性能：是否有不必要的循环、重复查询？ 3. 可维护性：命名是否清晰、函数是否过长？ 4. 错误处理：是否有遗漏的异常捕获？

5.2 利用 AI 做代码审查

选中一段代码 →Cmd+K→ 输入「审查这段代码，列出所有潜在问题」。这是 Cursor 最被低估的功能之一。

5.3 批量修改同名变量

Cmd+Shift+L选中所有同名符号 →Cmd+K→ 输入「把变量名oldName改为newName，同时更新所有引用」。比全局搜索替换更智能，因为它理解作用域。

5.4 用 AI 写测试

选中一个函数 →Cmd+K→ 输入「为这个函数写 pytest 单元测试，覆盖正常路径、边界条件和异常情况」。AI 会生成完整的测试代码，你只需要 Review 后 Accept。

6. 总结

Cursor 是一个强大的 AI 编程助手，但它的能力上限取决于你如何使用它。记住几个核心原则：

1. 上下文就是一切：主动管理上下文，不要依赖 AI 的记忆。
2. Review 再 Accept：AI 生成的代码不是最终答案，只是初稿。
3. 分步执行：复杂任务拆成多个小步骤，每一步都确认结果。
4. 善用.cursorrules：让 AI 从一开始就了解你的项目。
5. 版本管理是最后防线：Git 是你的后悔药，养成频繁 commit 的习惯。

希望这份指南能帮你少走弯路，真正把 Cursor 变成你的生产力倍增器。