Cursor 是 VS Code 的一个分支，核心卖点是 Tab 补全、Composer 和 Agent 模式这三件事。但多数人只用到第一层——Cmd+L 问一句、粘贴答案。真正把速度拉开差距的，是把规则文件、上下文和模式分工用对。这篇是按上手顺序梳理的实践路线，附带常见误区。

环境与规则文件

装好之后第一件事不是开写，而是在仓库根目录放一个 .cursorrules 文件。它会被注入到每一次 AI 请求里，用来写清技术栈、风格约定和禁区。这比每轮对话重新交代背景靠谱得多：

# .cursorrules
- 技术栈：Next.js 15 App Router，不用 Pages Router
- 风格：TypeScript strict，禁止 any
- 约定：金额字段用分（int），测试文件放源码旁边 *.test.ts
- 禁区：不要绕过 auth 中间件，不要直接改 migrations/

关键习惯是：当 Cursor 反复犯同一个错，不要只改输出，把它写进 .cursorrules。这个文件就是团队的「活规范」，一个人踩的坑能救所有人。规则还分项目级和用户级，团队通用约定放全局规则，仓库特有约定放项目根目录。

三种模式的分工

Cursor 有 Tab、Cmd+K、Composer/Agent 三种交互，用错场景就是白费力气。

Tab 补全是默认常开的行内预测，擅长样板代码——mapper、类型定义、测试用例这类重复活儿，写个函数签名和 JSDoc 注释，Tab 就能填完函数体。它比聊天快，因为你不用组织语言描述。

Cmd+K 是行内编辑，选中一段代码给一句话改局部——加注释、改命名、重构单个函数。Composer（Cmd+I）才是做多文件改动的地方：加一个横跨 API、类型、UI 的功能，或者全仓改名。Agent 模式是 Composer 的加强版，能跑终端命令、装依赖、跑测试、按失败迭代，适合「把这个文件从 JS 迁到 TS」这类端到端的活。

判断标准很简单：一句话能说清、只动一处，用 Tab 或 Cmd+K；动多个文件、有验收标准，用 Composer；需要跑命令、跑测试闭环，才上 Agent。把 Agent 当默认是会慢的——它每一步命令都要审批。

上下文与索引

Cursor 的输出质量取决于喂进去的上下文。用 @ 显式引用，别让它猜：@file 指定文件、@folder 指定目录、@codebase 拉全仓索引、@web 查资料。索引要干净，用 .cursorignore 把 node_modules、构建产物、大文件排除掉，索引干净了检索才准。

模型选择与成本

模型不是越强越好。补全用默认的快速模型；改几行的活用轻量模型；架构决策、长上下文重构才上 Claude Sonnet 或 GPT-5 这类强模型。Cursor 支持自带 key（OpenAI、Anthropic、DeepSeek、本地 Ollama），预算紧的时候可以把常规活切到便宜模型上。

几个常见误区

第一个误区是把 Chat 当主战场。Chat 是「想清楚问题」的地方，不是「干活」的地方；真写代码的是 Tab 和 Composer。整天泡在 Chat 里问一句贴一句，速度和直接生成差一个量级。

第二个误区是让 AI 猜上下文。不写 .cursorrules、不用 @ 引用、不建索引，AI 就只能从当前打开的文件猜你要什么，输出自然飘。上下文喂得越准，返工越少，这笔账是确定的。

第三个误区是「无脑全量接受」。Composer 给的 diff 要逐个文件看，宁可重发一次 prompt，也别接受一个烂 diff 再手动修——修的成本往往比重问高。习惯上，每次 Composer 或 Agent 跑之前先 commit，这是兜底，不是仪式。

第四个误区是一把模型用到底。补全、改几行、架构重构的难度差很多，用同一个模型要么浪费要么不够。按任务切模型，是省成本和提质量的共同解。

团队落地

团队铺开前，让两三个人先跑一个 sprint，量几个数：PR 产出、CI 失败率、评审返工时间，有数据再决定要不要全员上。共享配置靠 git：.cursorrules、MCP 配置都进仓库，个人偏好走本地设置。把 .cursorrules 当活文档维护——谁踩了新坑就补一条，团队的上下文成本才会随使用时间下降，而不是每次都从头教一遍。