Cursor 是什么

Cursor 不是"在编辑器旁边加一个聊天框"。官方文档把它定义为 AI editor and coding agent——一边保留日常写代码需要的编辑器、文件树、终端、Git、扩展，另一边把 Agent、Rules、MCP（Model Context Protocol，模型上下文协议）、Skills、CLI、Cloud Agent 和团队治理放进同一条开发闭环里。

换种说法：它不是给现有 IDE（Integrated Development Environment，集成开发环境，如 VS Code / JetBrains 系列）加 AI 插件，而是把整条 coding loop（编程循环：读代码 → 改代码 → 跑命令 → 审 diff → 验证）重排了一遍——原本散落在不同窗口的动作收敛到一个工作面。

理解这一点比记住按钮位置更重要。因为 Cursor 的价值不在于"能不能生成代码"——这一点所有 AI 编程工具都能做到——而在于它能不能围绕真实 codebase 做 plan、edit、run commands、review changes，并把结果交给你验证。

1. 两层身份：编辑器和 Agent

Cursor 的第一层身份仍然是 editor。你会打开 folder、浏览文件、安装 extensions、跑 terminal、看 Git diff、调试应用。对从 VS Code 或 JetBrains 迁移过来的人来说，这一层保证了基本开发工作面不会断。

Cursor 的第二层身份是 coding agent。Agent 可以读取上下文、搜索代码库、提出计划、修改文件、运行 shell commands、使用 browser 验证 UI、调用 MCP servers，甚至把任务切到 Cloud Agent 或 Bugbot 这类云端入口。

flowchart TD
  Cursor["Cursor"] --> Editor["AI Editor"]
  Cursor --> Agent["Coding Agent"]
  Editor --> Local["Files / Terminal / Git / Extensions"]
  Agent --> Context["Codebase Context"]
  Agent --> Plan["Plan Mode / Agent Mode"]
  Agent --> Tools["Tools / MCP / Browser"]
  Agent --> Review["Diff Review / Checkpoints"]
  Review --> Human["Human Approval"]

这就是它和普通 AI 插件的关键区别：插件通常增强某个入口（比如在编辑器里加一个 chat 面板），Cursor 试图重排整个 coding loop——让 Agent 自己读项目、自己跑命令、自己看 diff，把人从信息搬运工变成审阅者。

2. 不要从模型列表开始学

Cursor 支持多种 frontier models，官方模型页也会频繁变化。但教程学习顺序不应该从“哪个模型最强”开始。

更稳的顺序是：

1. 先学 Cursor 如何读取 project context。
2. 再学 Agent 如何把任务拆成 plan、edits、commands 和 verification。
3. 然后学 Rules、MCP、Skills、Subagents、Hooks 如何约束行为。
4. 最后再按任务复杂度选择 model、mode 和 budget。

模型决定能力上限，工作流决定结果能不能上线。只盯模型，很容易把 Cursor 用成一个更贵的聊天框。

3. Cursor 适合解决什么问题

最适合 Cursor 的任务有三个共同点：目标明确、上下文在代码库里、结果可以验证。

典型场景：

• 解释一个陌生项目的入口、模块关系和运行命令。
• 修复一个有日志、复现步骤或测试失败的 bug。
• 给现有功能补 test、补 loading state、补 empty state。
• 在小范围内重构重复逻辑，并跑目标验证。
• 根据项目规范生成新组件、route、API handler 或 docs page。
• 对本地 diff 做 review，找潜在 regression。

不适合直接交给 Cursor 自主执行的任务：

• 生产数据库 migration。
• 支付、认证、权限、账单、删除、密钥轮换。
• 没有 Git、没有测试、没有人工 review 的大范围重构。
• “全面优化一下”“商业级完善一下”但没有拆分边界的模糊任务。

4. 正确的任务闭环

在真实项目里，一个合格的 Cursor loop 应该长这样：

flowchart LR
  A["只读理解"] --> B["定义边界"]
  B --> C["Plan"]
  C --> D["Small Edit"]
  D --> E["Run Check"]
  E --> F["Review Diff"]
  F --> G["Keep / Revert / Iterate"]

每一步都有不同权限：

• 只读理解：Ask 或 Agent 只解释，不修改文件。
• 定义边界：明确目标文件、禁止动作、验证命令。
• Plan：让 Agent 先给方案，复杂任务用 Plan Mode。
• Small Edit：一次只批准能完整审查的改动。
• Run Check：跑 lint、test、build、browser check 或手工验收。
• Review Diff：看真实 diff，不只看 Agent summary。
• 沉淀规则：重复出现的问题写入 Rules、commands 或 team workflow。

5. 一个真实例子

假设项目里登录页提交后没有跳转。不要一上来写“帮我修复登录问题”。更好的写法是：

只读分析登录流程。请先找登录页、表单提交逻辑、认证 API、路由跳转位置和相关测试。
不要修改文件。输出：
1. 可能根因
2. 需要看的文件
3. 最小修复计划
4. 建议验证命令

这条指令把 Cursor 放在“理解现场”的位置。等你确认计划后，再让它只改最小范围，并要求跑目标 test 或 browser 验证。这样 Agent 的能力会变成受控执行，而不是黑箱改动。

6. 学完本章要能做的判断

你应该能回答：

• 这个任务更适合 Ask、Agent、Plan 还是 Debug？
• Cursor 需要哪些 project context？
• 允许它调用 terminal、browser、MCP 吗？
• 结果用什么 evidence 验收？
• 出错后用 checkpoint、Git diff 还是 branch 回退？

通过标准：你能把 Cursor 解释成“editor 工作面 + Agent 执行层 + rules/tools 治理层”，而不是只说“它能写代码”。

官方来源

• Cursor Docs：官方文档首页，覆盖 Agent、Rules、MCP、Skills、CLI、models、Teams 和 Enterprise。
• Cursor Documentation Index：官方文档索引，用于核对 Agent、customizing、cloud agents、CLI、Help Center 等页面。
• Cursor Documentation Markdown：官方定位与能力域。

接下来去哪