Cursor 使用指南
本文解决“怎么把 Cursor 用顺手”的问题：账号、额度、模型选择、token 控制和提示词写法。把这层跑通后，再看 Cursor 核心概念 理解规则和工作流的边界；如果还想把同一套约定扩展到 Copilot、Claude Code、Codex CLI，就继续看 Beyond Cursor：统一 AI 工具箱；如果关心这些约定最后怎么变成可交付结果，详见 Agent Harness：把 AI 变成可控工作流。
1. 账号获取
Cursor Pro 账号直接在 淘宝购买，备注需要发票，店家通常可提供电子发票（个人/企业均可，建议购买前确认）。
购买后登录 cursor.com 激活，确认 Pro 状态生效后再开始使用。
2. 使用限额配置
登录 Cursor 账号后，进入 Settings > Billing 或 Account，将 Fast Request 上限调整为 Unlimited，避免在高频 使用期间因默认配额触顶而被降速（Slow Queue）。
Unlimited 模式下每20刀左右 cursor 会收费一次，按实际使用量扣除额度。虽然没有单次请求数量限制，但仍需注意整体消耗。
3. 模型使用原则
本团队只使用以下两类模型，不使用其他任何模型（包括 GPT 系列、Gemini、本地模型等）：
| 类型 | 来源 | 说明 |
|---|---|---|
| Composer 模型 | Cursor 套餐内置 | 默认首选，适合日常绝大多数任务 |
| Anthropic 模型 | Claude Sonnet / Opus | 按需切换，仅用于复杂任务 |
统一使用 Anthropic 体系的好处：模型行为一致、调试经验可复用、避免因模型特性差异导致的不可预期输出。
4. 模型选择与 Thinking 模式
4.1 三档模型，按需升级
默认从 Composer 出发，不够用再升级，而非一开始就用最强的。
| 模型 | 定位 | 典型场景 |
|---|---|---|
| Composer 模型（套餐内置） | 默认首选，快且省 | 代码补全、格式整理、简单 bug、文档撰写、样板代码、CRUD |
| Claude Sonnet | 复杂任务 | 多步骤重构、跨模块逻辑分析、需要强代码理解能力的调试 |
| Claude Opus | 高难度任务 | 架构级设计、极复杂多文件重构、Sonnet 多次失败后的兜底 |
升级触发条件：Composer 已尝试 2 次以上仍输出存在明显缺陷，或任务明确涉及架构判断 / 跨模块复杂依赖。
不应升级的情形：任务本身简单只是描述不清（先优化提示词）；觉得 Opus“更好”就默认用（浪费额度）；重复性模板化任务。
4.2 Thinking 模式：同一模型的深度推理档
Anthropic 模型支持开启 Extended Thinking，模型在输出前先完成一段内部推理链，再给出答案。
- 开启后：推理更严谨，能处理多步骤、有歧义或需权衡的问题；但 token 消耗显著增加，响应更慢
- 不开启：直接输出结果，速度快、消耗低
Thinking 不是“更好的模型”，而是用更多 token 换更深的推理。不要无差别开启。
4.3 决策速查表
| 任务类型 | 推荐选择 |
|---|---|
| 日常编码、文档、格式、简单 bug | Composer（非 thinking） |
| 复杂逻辑、多步骤重构、长上下文分析 | Claude Sonnet（非 thinking） |
| 架构设计、高难度 bug、多方案决策 | Claude Sonnet 或 Opus（thinking） |
| 不确定时 | 先 Composer，不满意再逐级升级 |
5. 控制 Token 消耗
5.1 先理解 token 的实际消耗规模
在优化之前，先建立直觉（具体还是和模型选择相关，此处先大致估计）：
| 内容 | 大致 Token 量 |
|---|---|
| 一个 500 行 TypeScript 文件 | ~4,000 token |
| 一段 10 条来回的对话历史 | ~20,000–40,000 token |
| 20 条各 100 行的 Rules | ~2,000 token（每轮都要吃） |
| 模型探索一个大代码库 | 50,000+ token（还没写一行代码） |
模型的上下文窗口（如 200k token）是有限的“工作内存”。塞进去的无关内容越多，模型处理核心问题的能力就越弱——不是慢，而是真的更容易出错。
5.2 精简上下文
- 只
@真正相关的文件或代码块，@folder比逐个附加文件更高效（约省 50% token），但也别直接@整个大目录 - 错误日志只粘贴关键的 3–5 行，不要整段 50 行堆进去
- 对话窗口变长后，New Chat 重开——历史记录堆积消耗惊人，每轮递增
5.3 提示词写法：描述目标，而非步骤
低效的描述方式会浪费来回轮次，每多一轮就多一次 token 消耗。
反例（让模型来猜你想要什么）：
帮我做一个按钮
正例（目标、约束、格式一次说清）：
在 @src/components/Button.tsx 里新增一个按钮组件：
- 继承 shadcn/ui Button 的基础样式
- 支持 sm / md / lg 三种尺寸，默认 md
- 只接受 primary / secondary 两种 variant
- 最多 50 行，用 Tailwind 写样式，不要引入新依赖
- 只输出组件代码，不要解释
差异在于：第二种写法让模型第一次输出就接近可用，而不是在“帮我猜你的意图”上消耗多轮 token。
另一个常见反例（范围不清）：
帮我优化一下这个文件
正例（限定范围，防止“顺手”改你不想动的地方）：
只修改 @auth.ts 里的 validateToken 函数，把它改为支持 JWT RS256 算法。
不要动这个文件里的其他函数，不要修改任何其他文件。
5.4 Agent / Composer 使用注意
- 不要开启过长的 Agent 任务链去处理简单问题——描述越模糊，Agent 探索的范围越大
- 每次 Composer 任务完成后检查实际改动范围，防止模型“顺手”修改非目标文件
- 复杂任务拆成小步骤逐步完成，而非一次性提交大范围修改；模型单次能稳定处理的范围是有限的
5.5 及时清理
- 对话历史过长时及时归档/关闭，上下文窗口越长每轮消耗越高
- Rules 配置精简，只保留真正有效的约束，冗长的 rules 本身也消耗 token
- 不再使用的 MCP Server 及时禁用，它们持续占用上下文空间
6. 常见误区
| 误区 | 正确做法 |
|---|---|
| 使用 GPT / Gemini 等非 Anthropic 模型 | 只用 Composer 模型或 Claude Sonnet / Opus |
| 遇到问题直接切 Opus | 先检查提示词是否清晰，再升级模型 |
| 无差别开启 Thinking 模式 | 仅在复杂推理场景开启，普通任务无需开启 |
@ 整个项目文件夹 | 只 @ 需要的文件或片段 |
| 用一个超长对话完成所有任务 | 按任务拆分，必要时 New Chat |
| 让模型“随便重构一下” | 明确告知范围、目标与约束 |
| 提示词越详细越好 | 详细是对的，但描述目标与约束，而非每一步操作指令 |