第02章：Cursor实战——超越代码补全的工作方式

第02章：Cursor实战——超越代码补全的工作方式

第一次打开Cursor的人，很多人的第一反应是：这不就是带AI的VSCode吗？

没错。但"带AI的VSCode"这件事，如果真的用对了，会改变你整个的写代码方式——而不只是让你打字更快。

这章会讲Cursor真正有价值的几个功能，以及你应该如何把它整合进你的日常开发里。

Cursor的核心功能层次

Cursor的功能可以分成三层，价值从低到高：

第一层：代码补全
跟GitHub Copilot差不多，根据上下文预测你要写什么。这是大多数人用到的层次，价值有限。

第二层：Chat（聊代码）
打开侧边的Chat窗口，直接和AI讨论你的代码问题。可以引用当前文件（@文件名）、选中的代码段，或者整个代码库（@codebase）。这是Cursor真正开始有差异化的地方。

第三层：Composer（多文件生成）
这是Cursor Pro最有价值的功能。你描述要做什么，AI可以同时修改多个文件，生成完整的功能模块。不只是帮你写一个函数，而是帮你同时创建模型、路由、测试文件，改配置文件。

大多数人停留在第一层，这章帮你进入第二层和第三层。

功能一：@codebase——让AI理解你的整个项目

这是Cursor让很多人第一次感到震撼的功能。

普通的AI问答是无状态的：你把代码贴进去，问完这次忘了上次。Cursor的@codebase让AI能索引你整个项目的代码，在回答时考虑你所有文件的上下文。

典型使用场景：

场景1：理解陌生代码库

你接手了一个别人写的项目，第一件事：
"@codebase 解释一下这个项目的整体架构，数据流是怎么流的，
主要有哪些模块，它们之间的关系是什么？"

AI会给你一个架构概览，通常比你自己看代码理解得快3-5倍。

场景2：在整个项目里找相关代码

"@codebase 这个项目里，用户权限验证是在哪里处理的？
相关的代码涉及哪些文件？"

你省去了全局搜索+手动跳文件的时间。

场景3：评估影响范围

"@codebase 如果我要修改User模型，增加一个email字段，
会影响哪些地方？给我列一个修改清单。"

这个任务本来需要你花时间全局搜索，AI几秒钟给你答案。

功能二：Chat引用——精准的上下文控制

和AI对话时，上下文控制得越好，回答越准确。Cursor的@引用系统让你能精确控制AI看到什么。

常用引用方式：

  • @文件名 — 引用某个具体文件
  • @代码选择 — 选中一段代码，右键选"Add to Chat"
  • @codebase — 引用整个项目
  • @docs — 引用特定的文档（需要提前配置）
  • @web — 让AI搜索最新信息（适合问某个库的最新API）

实际对话示例：

用户：@auth.py @user.model.py 
我想在用户登录时增加一个"最后登录时间"的记录，
应该改哪里？

Cursor AI：基于你的代码，建议在auth.py的login_user函数里，
在验证通过后，调用user.last_login_at = datetime.now()，
然后db.session.commit()。同时在user.model.py的User类里
增加last_login_at字段：
last_login_at = Column(DateTime, nullable=True)

注意用法：先引用相关文件，再说要做什么——这比直接问"怎么记录登录时间"获得的回答更贴合你的代码。

功能三：Composer——多文件生成

这是Cursor Pro真正的杀手级功能。

一个例子：你要给项目增加一个"用户收藏文章"的功能。你需要：

  1. 数据库模型（Bookmark表）
  2. API路由（/bookmarks的增删查接口）
  3. 测试文件

手写需要30-60分钟。用Composer：

提示词：

给这个Flask项目增加用户收藏文章功能，需要：
1. 在models.py里增加Bookmark模型（user_id, article_id, created_at）
2. 创建新的路由文件bookmarks.py，包含：
   - POST /bookmarks：添加收藏
   - DELETE /bookmarks/<id>：取消收藏
   - GET /bookmarks：获取用户的所有收藏（分页）
3. 在blueprints的__init__.py里注册新路由
4. 创建test_bookmarks.py，覆盖上面三个接口的基本测试

用这个项目现有的代码风格（@models.py @routes/user.py参考）。

Composer会同时修改或创建多个文件，你看着变更的diff，决定接受哪些、拒绝哪些。

重要的使用原则：
Composer不是一键生成，而是一个协作过程。你需要：

  1. 描述清楚（上面的提示词是个好例子）
  2. 审查AI生成的代码（别直接Accept All，检查逻辑）
  3. 发现问题就在Chat里继续调整

功能四：.cursorrules——给AI设定项目规则

这个功能被大多数人忽略，但它是Cursor里对长期使用价值最大的功能之一。

.cursorrules是一个你放在项目根目录的配置文件，里面写的是"AI在这个项目里应该遵守的规则"。你只需要写一次，之后每次和AI的对话都会自动遵守这些规则。

一个实际的.cursorrules例子：

# 项目规则

## 技术栈
- Python 3.12，Flask 3.0，SQLAlchemy 2.0
- 数据库：PostgreSQL
- 测试框架：pytest

## 代码风格
- 使用类型注解（type hints）
- 函数和方法必须有docstring
- 变量名使用snake_case
- 不使用全局变量

## 架构规范
- 路由只做参数校验和调用service，业务逻辑放在services/
- 数据库操作只在repositories/里进行
- 用Flask Blueprint，每个功能模块一个Blueprint

## 错误处理
- API返回统一用{success: bool, data: ..., error: str}格式
- 所有异常必须被捕获，不允许让异常直接暴露给用户

## 安全
- 所有用户输入必须通过marshmallow schema验证
- 敏感操作需要权限检查装饰器@login_required

有了这个文件，你之后再让AI生成代码，它会自动遵守这些规范。你不需要每次都说"记得加类型注解"、“记得写docstring”。

高效使用Cursor的几个原则

原则1：别让AI一次做太多事
Cursor生成300行代码的时候，你也需要审查300行。拆成小任务，每次让AI做一件事，审查更容易，错误更少。

原则2：让AI生成，你来审查
最有价值的模式：你描述需求 → AI生成 → 你审查 → 发现问题 → 你改或者让AI改。你是决策者，AI是执行者。

原则3：失败了就换角度
AI第一次的输出不满意，不要一直问"这不对，重新生成"。给它更多上下文，或者换一种描述方式。

原则4：高复杂度任务先讨论设计
对于复杂功能，先用Chat讨论"应该怎么设计"，确认设计对了，再让Composer生成代码。不要让AI在错误的设计上生成一大堆代码。

一个真实的Cursor工作流

下面是我用Cursor开发一个新功能的完整流程：

步骤1：理解现有代码（5分钟）

@codebase 我要给这个项目加用户通知功能，
现有代码里有没有类似的功能实现可以参考？
订阅/通知相关的代码在哪里？

步骤2：设计讨论（10分钟）

我要实现这样的通知功能：
[描述需求]
基于现有的代码架构，你觉得最合适的实现方式是什么？
列出几个选项，以及每个选项的优缺点。

步骤3：分模块实现（每个模块10-20分钟）

[切换到Composer]
先实现数据库层：
- 创建Notification模型（参考@models/user.py的风格）
- 在@repositories/里创建notification_repository.py
- 增加必要的数据库迁移

步骤4：测试生成

@notification_repository.py @test/test_user.py（参考风格）
给notification_repository.py里的所有公共方法写测试

步骤5：代码审查
最后过一遍所有改动的diff，确认每处改动都是自己理解的。

整个过程，AI承担了大部分的"写"的工作，我承担了"思考"和"决策"。

如果今天只记一件事：Cursor最有价值的用法不是代码补全，而是让AI理解你的整个项目（@codebase）、帮你跨文件生成功能（Composer）——把这两个功能用起来，效率才会有质的提升。