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