你有没有过这样的体验——

月底一看 Cursor 的用量统计。发现额度已经见底，而距离重置还有一周。回想一下好像也没干多少活啊，怎么就用完了？

如果你也有这种感觉。那么问题大概率不出在「用得太多」，而出在「用得不对」。

我用了 Cursor 一年多。从最初的月抛选手到现在的精打细算，踩了不少坑。这篇文章把我积累的实际方法全部分享出来没有废话，只有可操作的策略。

一、上下文控制 — 省 Token 最大的杠杆

说一个反常识的事实：你消耗的 token 里% 不是模型思考用的，而是上下文塞进去的。

什么意思？每次你跟 Cursor 对话，它都会把当前上下文里所有的文件内容、对话历史、规则配置一起喂给模型。这些是你真正的成本大头，

❌ 反例：让 Agent 自由扫描项目

见过最多的场景：打开 Agent。不提具体文件，只说「帮我改一下使用者注册表单的邮箱验证」。

Agent 开始自动分析项目结构——翻遍路由、控制器、模型、组件、样式文件，甚至在 dist/ 和 node_modules 里兜了一圈。为了改一个邮箱验证规则，读了几十个无关文件。

💸 浪费：~ token。而且无关文件会稀释模型的注意力，输出质量反而下降。

正确做法： 用 @ 精准引入表单组件文件，或者把要改的函数直接贴进对话。Agent 就不会漫无目的地扫全项目了。

@file 的正确姿势

@ 的本质是让你的上下文尽可能精简。按理说，说到几个实操经验。

• 能 @ 函数不 @ 文件选中代码后用 Cmd+K上下文天然就是选中部分。
• 能 @ 文件不依赖自动扫描一个文件能说清楚的事，不要让 Agent 满项目乱翻。
• 非要让 Agent 了解项目整体时先用 .cursorignore 把 node_modules。 dist,* .lock,测试快照等大文件排除掉，减少自动扫描噪音。

简单你给模型的材料越精准。它的注意力就越集中，结果越好，消耗越少。

❌ 反例：一个对话用到底

This scenario is all too common—a Chat that starts on Monday and drags on until Friday。accumulating thousands of tokens of history that are no longer relevant.

The cost of asking a simple sorting question in fifth round can be dozens of tokens just because whole conversation history is carried over.

正确做法： 每完成一个独立功能，就果断开新 Chat。只粘贴关键结论作为简短背景，比拖着几十轮历史便宜数倍。按理说，

多根工作区 — 年的新解法

C​ursor 在 2024 年 5 月上线了多根工作区。单个 Agent 会话可以跨多个文件夹工作。如果你经常在前后端仓库之间切换，这个功能能省掉大量「每次重新指定目标文件」的重复上下文开销。

二、Prompt 工程 — 一次问对。减少来回

每多一次来回，就多一次完整上下文传递。Prompt 的主要策略只有一个：

❌ 反例：自然语言啰嗦描述

"请你帮我在使用者管理页面中增加一个搜索功能。这个搜索功能要能支持按照使用者名、邮箱、手机号、注册时间范围来搜索使用者，搜索结果要分页显示，每页 20 条…，"

The natural language description contains a lot of redundancy;model still has to extract actual requirements.

使用者列表搜索-
至于搜索字段，使用者名、邮箱、手机号、注册时间范围
至于分页，20条/页
从排序来看，注册时间 ↓、使用者名 ↑
UI这方面，搜索框 + 搜索按钮 + 重置按钮
状态这方面，loading / 空结果 / 错误
NE

几个实际方法

从技巧一来看，建立个人缩写词典

C​reate a .cursorrules

NE = no explanation,code only
TS = add TypeScript types
ERR = add error handling
SC = single class/file output only