上下文管理
Cursor 好不好用，很多时候不是取决于模型多强，而是取决于你给它的上下文到底对不对。
这件事听起来很普通，但它几乎决定了使用体验。上下文给对了，Cursor 像是在项目里真的看懂了你的意图；上下文给错了，它就会开始一本正经地改不该改的地方，或者给出很像答案、但跟你手头问题不够贴的建议。
1. 为什么上下文决定体验上限
很多人第一次用 Cursor，会自然觉得“让它看到的越多越好”。结果通常是：
- 它读了一大堆文件，但重点没抓住
- 它知道项目里有很多东西，却不知道当前任务最关键的约束
- 它引用了相关信息，但不是你真正想让它看的那部分
所以我更建议把上下文管理理解成“给它看什么最有用”，而不是“给它看得越多越强”。
2. @Files 和 @Folders 什么时候用
当你需要它理解一个完整文件，或者大致知道某个目录里有哪些内容时，@Files & Folders 很有用。
- 引用文件：适合让它完整理解某个模块
- 引用文件夹：适合让它先建立结构认知
也可以直接把侧边栏文件拖进对话框，速度更快。
但我自己的习惯是：文件夹级上下文只用在“先理解结构”阶段，不用在“开始精确改动”阶段。因为一旦进入真实修改，范围太大反而会让输出变松。
3. @Code 往往比整文件更值钱
@Code 的价值在于，它把问题压到局部。
如果你现在就是在处理一个函数、一段副作用逻辑、一个 hook 的行为，那直接贴整文件其实经常是噪音。@Code 更适合：
- 解释某段实现
- 讨论一个局部 bug
- 改一段明确范围的代码
我会把它看成“把注意力聚焦”的工具，而不是单纯的引用方式。
4. @Docs 什么时候真正有用
@Docs 最适合用在这些场景：
- 你正在接一个不熟的库
- 当前项目依赖某个文档驱动的外部系统
- 你想减少模型乱编 API 的概率
用法本身不复杂：
- 在对话框输入
@Docs - 选择已有文档
- 或选择 Add new doc，粘贴文档 URL
新增文档后，Cursor 会抓取站点和子页面内容。你可以在 Cursor Settings > Indexing & Docs 里管理。
如果是经常会查的文档，我建议固定接进去。因为“反复让模型猜 API”几乎是最浪费时间的体验之一。
5. 上下文最常见的几个误区
把整个仓库一股脑塞进去
这通常不是最优解。它会让模型知道很多背景，但不一定知道你当前在处理什么。
历史对话太长还继续追问
对话越长，越容易混进已经过期的前提。尤其当你已经从 A 任务切到 B 任务时，老上下文反而会变成干扰。
问题很具体，但上下文很泛
例如你想修一个 hook 的副作用 bug，却只给了整个 src/ 目录。这种情况下，模型很难稳定命中真正关键的代码。
6. 一个更稳的上下文策略
我平时更推荐这种层次：
- 先给结构上下文：让它知道项目大概长什么样
- 再给任务上下文：告诉它这次具体要解决什么
- 最后给局部代码：让它把注意力落在真正相关的片段
这样比“一次丢所有东西”通常更稳。
7. 什么时候该新开对话
一个很简单的判断标准是：
如果你已经开始换问题、换文件、换目标，那通常就该新开对话了。
常见触发点包括：
- 已经从“理解项目”切到“开始改代码”
- 已经从“实现功能”切到“调性能”
- 已经从“前端问题”切到“后端接口问题”
对话切干净，Cursor 的表现通常会更稳定。
8. 上下文管理为什么也影响索引内容质量
如果你用 Cursor 来产出网站内容、文档或 wiki，好的上下文管理其实也会间接影响 Google 可索引质量。
因为内容之所以会变空、跑偏、重复，很多时候不是模型不会写，而是它没有拿到对的材料。上下文给得越准，最终写出来的页面越容易围绕一个清晰主题展开，而不是东拼西凑。
下一步
如果你只想先做一件最能提升体验的事，我会选这个：别急着加更多上下文，先学会删掉无关上下文。
