Cursor 实用技巧：规则文件与上下文管理

很多人装了 Cursor 只用来“聊天写代码”，结果 AI 经常忽略项目约定、改错文件、越聊越乱。其实决定效果的关键只有两件事：给 AI 定规矩（规则文件）和喂对信息（上下文管理）。本文围绕这两点展开。

一、Cursor 是什么

Cursor 是一款基于 VS Code 的 AI 代码编辑器。因为底层是 VS Code，所以：

• 界面、快捷键习惯和 VS Code 基本一致；
• 大部分 VS Code 插件可以直接使用；
• 首次启动时可以导入 VS Code 的设置和插件。

在此基础上，它把 AI 深度集成进了编辑器：代码补全、对话、自动修改多个文件、执行终端命令等。

二、三种基本用法：Tab、Chat 与 Agent

Tab 补全

写代码时，Cursor 会以灰色文字给出建议，按 Tab 接受。它不只补全当前行，还会根据你刚做的修改，预测接下来要改的地方。比如你把一个函数参数改了名，它可能会提示你把后面几处用法一起改掉，连续按 Tab 就能跳过去接受。

用好 Tab 的诀窍：先手动改一处，让它学到你的意图，再让它补剩下的。

行内编辑

选中一段代码，用行内编辑快捷键（macOS 上通常是 Cmd+K，Windows/Linux 上是 Ctrl+K）直接输入指令，如“加上错误处理”“改成 async 写法”。适合小范围、目标明确的修改。

Chat 与 Agent

侧边栏的 AI 面板有不同模式，大致分两类：

• 问答类（Ask / Chat）：只回答问题、解释代码、给出建议，不主动改文件。适合理解代码、讨论方案。
• Agent：能自己搜索代码库、修改多个文件、运行终端命令，并根据结果继续调整。适合完成一个完整功能。

Agent 修改的内容会以 diff 形式展示，你可以逐个文件接受或拒绝。

三、用 @ 精确引用上下文

在对话框中输入 @，可以把特定内容加入上下文。常用的有：

一个好的提问示例：

@src/api/user.ts @src/types/user.ts
给 getUser 增加缓存：同一个 id 在 60 秒内重复请求时直接返回缓存结果。
参考 @src/api/product.ts 里已有的缓存写法，保持风格一致。

比起“帮我给用户接口加缓存”，这样写能让 AI 少猜、少搜，结果也更符合项目现有风格。

四、项目规则：让 AI 记住你的约定

每次对话都重复“我们用 TypeScript 严格模式”“组件用函数式写法”很累。规则文件就是解决这个问题的：把约定写一次，AI 在相关场景自动遵守。

规则放在哪里

• 项目规则（推荐）：放在项目的 .cursor/rules/ 目录下，每条规则一个文件（.mdc 格式）。可以提交到 git，团队共享。
• 旧版 .cursorrules：项目根目录下的单个文件。目前仍可能被兼容，但官方已推荐迁移到 .cursor/rules/。
• 用户规则：在 Cursor 设置中填写，对你所有项目生效，适合写个人偏好（比如“用中文回答”）。

规则文件的结构

.mdc 文件由头部元数据和正文组成。头部可以设置：

• description：规则的用途说明，AI 会据此判断是否需要读取；
• globs：文件匹配模式，编辑匹配的文件时自动附加这条规则；
• alwaysApply：设为 true 时，每次对话都会带上。

也可以不自动应用，只在对话中手动 @ 引用某条规则。

一份好规则的示例

文件：.cursor/rules/frontend.mdc

---
description: 前端 React 组件的编写规范
globs: src/components/**/*.tsx
alwaysApply: false
---

# 前端组件规范

## 技术栈
- React 18 + TypeScript（strict 模式）
- 样式使用 Tailwind CSS，不要写单独的 CSS 文件
- 数据请求统一使用 src/lib/request.ts 中封装的函数

## 写法要求
- 只用函数组件和 Hooks，不用 class 组件
- Props 类型用 interface 定义，命名为 XxxProps
- 一个文件只导出一个组件

## 不要做
- 不要引入新的第三方依赖，需要时先提出来
- 不要修改 src/lib/ 下的公共代码，除非我明确要求

## 参考
新组件的写法参考 @src/components/UserCard.tsx

好规则的共同点：

• 具体：写“Props 用 interface 定义”，而不是“代码要规范”；
• 简短：一条规则聚焦一个主题，太长的规则会占用上下文，也更容易被忽略；
• 有反例：明确写“不要做什么”，往往比“要做什么”更有效；
• 有样板：引用一个项目中写得好的文件作参考。

五、上下文管理技巧

1. 新任务开新对话

这是最重要的一条。一个对话里先修 bug、再加功能、又问配置，前面的内容会干扰后面的回答，也会浪费上下文空间。一个任务一个对话，做完就开新的。

2. 精确引用，而不是丢整个仓库

上下文不是越多越好。无关代码越多，AI 越容易抓错重点。优先 @ 具体文件，其次是目录，只有在你确实不知道代码在哪时，才让 Agent 自己在整个代码库里搜索。

3. 先让它出计划

稍复杂的改动，先让它说清楚打算怎么做：

我要给订单模块加一个“部分退款”功能。
先阅读 @src/orders/ 下的代码，然后给出实现计划：
需要改哪些文件、新增哪些函数、数据结构怎么变。
先不要写代码，等我确认。

计划有问题时改几句话就行；代码写错了再改，成本高得多。

4. 对话太长时主动总结

如果一个任务确实需要很长的对话，可以让 AI 总结当前进度、已做的决定和待办事项，然后把这份总结带到新对话里继续。

5. 用 git 做安全网

在让 Agent 做较大改动前先 commit。Cursor 自身也提供了回退到某个对话节点的功能，但 git 更可靠、更可控。

六、常见坑

• 一次要求太多：“把整个项目从 JavaScript 改成 TypeScript”这种任务，拆成按模块逐个进行，每步都验证。
• 不看 diff 就全部接受：Agent 有时会顺手改了你没要求的地方，比如删掉注释、改动不相关的函数。接受前逐个文件看一遍。
• 规则写成长篇文档：几百行的规则反而会被稀释，重点写 AI 最容易犯错的地方。
• 忽略 .cursorignore：大体积的数据文件、构建产物、包含密钥的配置文件，可以通过忽略文件排除在 AI 索引和上下文之外。
• 相信过时的 API：AI 对新发布的库版本不一定熟悉。遇到新库时，用 @Docs 或 @Web 提供最新文档。
• 忘了自己验证：让它写完后运行测试或实际跑一遍，不要只看代码“看起来对”。