23 · 上下文管理

理解 Cursor 的”大脑”如何运转——上下文窗口、@ 引用机制、索引系统、以及如何避免 AI”记不住”或”搞混了”。

01 为什么上下文管理如此重要

Cursor 的 AI 之所以强大，不是因为模型本身比别的平台”更聪明”——而是因为它能看到你的整个项目上下文。它知道你打开了什么文件、你的项目结构长什么样、你最近改了哪些代码、你的编码风格是什么。

但这种”看到”是有容量上限的。AI 模型不像人类可以无限记忆，它的”工作记忆”受限于上下文窗口——一个固定大小的 token 缓冲区。超过这个容量，最早的信息就会被”挤出去”。

你很可能遇到过这些情况：

• AI 开始”忘记”你十分钟前在聊天里说过的话
• AI 在生成代码时偏离了你的项目风格
• 你的对话越来越慢，每次都像在”重新思考”
• 你 @ 了一个文件，但 AI 似乎没有真的”理解”它的内容

这些问题的根源往往不是 AI 不够好——而是上下文管理出了问题。

把 Cursor 想象成一个白板：你和 AI 的所有对话、打开的文件、索引的代码，都在同一块白板上。白板空间有限——写满之后，最早写上去的内容就会被擦掉。上下文管理的艺术，就是知道什么时候该擦、什么时候不该擦、以及怎么让最重要的内容始终留在白板上。

02 Cursor 的上下文窗口有多大

不同模型有不同的上下文窗口大小：

看起来很大对不对？但请注意：上下文窗口不是你一个人用的。每轮对话你输入的消息、AI 返回的代码、你 @ 引用的文件内容、项目索引信息——所有这些都在争抢这 200K 的空间。

实际的消耗情况

一个真实的场景：

你会发现，一个活跃的对话 session 很快就用掉了大半窗口。这还不是问题——问题在于，如果旧对话积累的”噪音”太多，AI 真正能用来”思考”的有效空间就变窄了。

心智模型：上下文窗口像一个行李箱。你的任务是决定”带什么出门”。带少了，AI 信息不足；带多了，寸步难行。

03 @ 符号系统：精确控制上下文的”手术刀”

Cursor 最强大的上下文控制机制就是它的 @ 系统。在 Chat、Composer 或 Inline Edit 中输入 @，会弹出一个引用菜单，让你精确指定 AI 应该”看”什么。

@ 的类型

什么时候 @，什么时候不 @

这是一个新手和老手的分水岭：

该 @ 的场景：

• 要改某个具体文件 → @文件名
• 要理解某个函数的实现 → @#函数名
• 要引用项目规范 → @Notepad（用 Notepads 提前写好）

不该 @ 的场景：

• 刚在当前编辑器中打开的文件（Cursor 已经能看到了）
• 聊一些宽泛的技术问题（不需要上下文）
• 引用你已经粘贴到对话框中的代码

实战：@ 的正确用法

错误示范：

用户：帮我优化这段代码
（没有 @ 任何文件，AI 只能猜你在说哪段代码）

正确示范：

用户：@src/utils/auth.ts 帮我优化 authUser 函数，@#getUserRole 这个函数也需要一起调整
（AI 精确知道要看哪两个文件，以及重点关注哪个函数）

一个关键认知

@ 不是越多越好。 每一次 @ 都会消耗上下文窗口的空间。如果你一次性 @ 了 10 个文件，AI 的”有效注意力”会被稀释——它要花更多 token 去理解这些文件的基本结构，留给真正”思考如何改代码”的空间就少了。

法则：只 @ 需要 AI 立即理解的内容。那些只是”备查”的文件，等 AI 问你要时再给。

04 .cursorignore：控制哪些文件进入索引

不是项目里的所有文件都需要被 AI 索引。node_modules、dist、build、锁文件、日志文件——这些东西被索引只是浪费上下文空间。

.cursorignore 就是用来告诉 Cursor：“这些文件，别看了。“

格式和用法

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

node_modules/
.next/
dist/
build/
*.log
*.lock
.git/
__pycache__/
*.pyc
.env
.env.local
coverage/

.cursorignore vs .gitignore

为什么要用 .cursorignore

没有 .cursorignore 的后果：

1. 索引列表里塞满了无关文件 — AI 看到的文件树里全是 node_modules 下的十万个文件，真正重要的源码反而不突出
2. 误索引二进制/大文件 — .pkl、.bin、图片文件等被读入浪费 token
3. AI 响应变慢 — 每次索引耗时更长

一个实际的例子

# .cursorignore
node_modules/
.next/
dist/
*.min.*
*.map
package-lock.json
yarn.lock
pnpm-lock.yaml
.git/
coverage/

加上之后，Cursor 的索引范围会大幅缩小，AI 看到的都是”有意义”的代码文件。

什么时候更新 .cursorignore

• 添加了新的构建工具（产生了新的输出目录）
• 项目规模膨胀，索引变慢
• AI 开始引用不应引用的文件（比如引用了 dist/ 下的编译产物）

05 索引系统：Cursor 如何”理解”你的项目

上下文管理不只靠 @ 引用。Cursor 还有一个全自动的后台索引系统，持续扫描你的项目并建立索引。

索引了什么

Cursor 的索引不是简单的”文件名列表”。它包括：

• 文件路径树 — 项目结构全貌
• 符号索引 — 所有函数、类、接口、变量的定义位置
• 类型信息 — TypeScript 类型推导结果（如果是 JS/TS 项目）
• 导入关系 — 模块间的依赖关系图
• 最近修改的文件 — 你最近改动过的代码

索引如何影响 AI 质量

当你没有用 @ 引用文件时，AI 依赖的就是索引数据。比如你问：

“这个项目的认证逻辑在哪里？”

如果索引做得不好，AI 可能回答 “我不确定”；如果索引做得好，AI 会直接告诉你 “在 src/services/auth.ts 的 authenticateUser 函数中”。

索引的代价

索引不是免费的：

索引最佳实践

1. 先用 .cursorignore 缩小索引范围 — 不需要索引的目录配好
2. 关注索引状态 — 注意 Cursor 底部的索引进度条，卡住时可能是某个大文件导致的
3. 在规则中引导索引方向 — 通过 Rules（/12）告诉 Cursor 哪些目录才是”核心代码”
4. 重启索引 — 如果觉得索引状态异常（比如 AI 找不到明显存在的文件），可以 Cmd+Shift+P → Developer: Reload Window 重建索引

06 对话会话的生命周期管理

每次你在 Cursor 中开始一个新 Chat 或 Composer，就是一个会话。会话的管理方式直接影响上下文质量。

会话的”寿命”

一个会话能持续多久？答案是：看你怎么用。

上下文漂移

这是最常见的会话问题。当你和 AI 聊了 30 轮之后，AI 可能会出现：

• 反复问你应该已经说过的前提
• 生成的代码风格和初始几轮不一致
• 开始”忘记”某些关键的架构约束
• 对新的请求反应变慢

这些信号告诉你：上下文窗口的”好内容”被旧对话挤出去了。

会话管理的黄金法则

一个会话 = 一个任务。

这个法则虽然简单，但我见过太多人违反它：

• 在改登录模块的会话里，顺便问了一个数据库设计问题
• 在修 Bug 的会话里，让 AI 顺便加个新功能
• 在一个 Composer 里，让 AI 做完 A 再做 B 然后改 C

每多一个不同的任务，旧任务的信息就多一分被覆盖的风险。

实用策略

1. 任务粒度：一个会话只做”一件事”。这件事可以是”修改登录页面的表单验证”，但不能是”修改登录页面 + 添加仪表盘图表 + 重构用户管理模块”
2. 高频重启：与其依赖一个会的记忆力，不如重新开始并给出清晰的上下文。新建会话的成本为零。
3. 工作笔记：把核心项目规范、架构决策写在 Notepads 中，每次新会话用 @Notepad 引用——这样你就不会在新会话中丢失关键背景。

07 上下文膨胀的迹象与应对

上下文膨胀（Context Bloat）是会话老化的自然结果。你需要学会识别它的信号。

识别信号

修复措施

初级修复：

• 关闭当前 Chat/Composer，重新打开一个新的
• 在新会话中@必要的文件和 Notepad
• 用一句简短的话概括之前讨论的背景

中级修复：

• 检查 .cursorignore，排除不必要的文件
• 精简 Notepads 内容，去掉过时的约定
• 用 Rules 替代对话中的重复指令（一次配置，永久生效）

高级修复：

• 重构项目结构，让核心代码更集中
• 建立模块化 Notepads 体系（不用一个 Notepad 包含所有内容）
• 为不同类型的任务创建不同的自定义 Composer 模板

预防胜于治疗

❌ 坏习惯                          ✅ 好习惯
──────────────────────────────────────────────
一个会话用一天                      按任务拆分会话
从来不关旧会话                      频繁新建会话
对话里反复说项目规范                用 Notepads 固化规范
@ 很多无关文件                      只 @ 关键文件
没有 .cursorignore                 配置完善的 .cursorignore

08 什么时候应开始新会话

这是实践中最重要的判断之一。以下情况强烈建议开启新会话：

1. 任务已完成 — 这个功能写完了，下一个功能是新的。关掉，重开。
2. 任务范围改变 — 原计划改 Bug，现在变成了加功能。说明原会话的上下文已经不适合了。
3. AI 开始”糊涂” — 它忘记了你 5 分钟前说过的话，或者重复问同一个问题。不是 AI 变笨了，是窗口满了。
4. 超过 20 轮对话 — 这是一个经验阈值。大多数高质量对话在 15-20 轮后开始衰减。
5. 切换了代码库区域 — 从修改前端组件切换到修改后端 API 逻辑。这两个区域的上下文几乎没有重叠，新会话更高效。
6. 经历了显著的架构讨论 — 如果你和 AI 刚深入讨论了一个架构决策，这个讨论可能已经消耗了大量上下文。在新会话中开始编码，然后用 @Notepad 引用决策结论。

一个简单的判断框架

问自己：如果我现在关掉这个会话重新开始，我需要给新会话多少"背景说明"？

- 很少（一两个 @ 就够了）→ 立即建立新会话
- 中等（两三个 Notepad 引用可以覆盖）→ 考虑新建
- 很多（需要复杂的解释）→ 继续使用当前会话，但考虑精简上下文

09 最佳实践清单

下面是本文所有建议的汇总清单，可以贴在项目文档中做参考：

配置层面

• 在项目根目录创建 .cursorignore，排除 node_modules/、dist/、构建产物
• 配置 .cursorrules 或 Rules，让 AI 知道项目的基本约定
• 创建几个核心 Notepads（项目架构、编码规范、API 设计），新会话引用

会话层面

• 坚持”一个会话一个任务”
• 超过 20 轮考虑新建会话
• 任务完成立即关会话，不清除”以备后用”
• 只 @ 必要文件，不盲目 @

监控层面

• 注意 AI 回答是否变慢（窗口快满了）
• 注意 AI 是否开始”忘记”（窗口可能已满）
• 注意对话历史长度（太长的历史本身就有问题）

索引层面

• 首次打开大项目时等待索引完成
• 定期更新 .cursorignore 以适应项目变化
• 如果 AI 找不到明显存在的文件，考虑重建索引

10 总结

上下文管理是 Cursor 使用中最容易被低估的技能——因为它看不见摸不着。但理解了它的机制，你就能从”偶尔感觉 AI 不好用”进阶到”总是感觉 AI 很懂你”。

四个核心思维：

1. 上下文窗口是有限资源 — 每一轮对话、每一个 @ 引用都在消耗它。精打细算，而不是”越多越好”。
2. @ 系统是你的手术刀 — 精确告诉 AI 该看什么、不该看什么。用好 @ 比写长提示词更有用。
3. .cursorignore 是防火墙 — 阻挡无用信息进入索引，让 AI 的关注范围聚焦在真正的源码上。
4. 会话是消耗品 — 不要舍不得关。新建一个会话的成本几乎为零，但在一个臃肿的会话中挣扎的成本很高。

一句话总结：上下文管理，本质上是对 AI 注意力的管理。你能控制 AI “看到”什么，你就控制了它”想”什么。

下一篇：17 并行 Agent —— 同时跑多个 Agent，用 git worktree 隔离环境，把上下文管理的原则应用到多 Agent 协作中。