现在有了 Cursor 企业级订阅，当然更愿意使用 Cursor 来编码、写文档，除了这两项外，搜索、问答、思考分析、代码审查、项目代码解读、画图、生图、生视频等，我们都可以使用 Cursor 来完成，也希望就在这个入口里处理所有事情，不用去切换各种入口，还能实现自动智能串联。

当然其他 AI 工具也大多都能做到这些。比如我自己在家里也会用 trae。

Cursor 中构建上下文

Cursor 如此受我们关注，是因为右侧的 chat 窗口，所以我们也从这个窗口聊起。

什么是上下文

什么是上下文，大家都已经很熟悉了，这里简单说下，当我们在 Cursor 中生成编码建议时，上下文指的是提供给大模型的信息，然后大模型依据这些输入信息来预测后续的信息，这些输入的信息是上下文。

两种上下文

1、意图上下文（intent context）

意图上下文是关于我们想要什么，我们希望从大模型中得到什么，比如我们问：“请实现一个登录功能”、“请修复登录过程产生的 bug”、“请将文字颜色更改为红色”，这是规范地在陈述意图。
2、状态上下文（state context）

而状态上下文是关于我们当前的状态，或说当前世界的状态，比如我们经常会将错误信息、控制台输出信息、图片、代码块/文件/目录等提供给 Cursor，这些信息都是与当前状态相关的上下文，这些上下文通常是描述性，描述了当前的状态。

理解这两种上下文有利于我们更好的与大模型对话，通过这两种类型的上下文，描述当前状态和期望未来状态，让 Cursor 能够给出更有用的编码建议，甚至直接生成或修改代码。

上下文不充分的时候，Cursor 会怎么做？

提供给大模型的上下文和我们要问的事项越相关，大模型就越有用。

而如果我们提供的上下文不足，大模型在没有足够相关信息的情况下，去分析解决我们的事项时，会发生什么呢？

通常会使得 Cursor 这么干：

1、模型强行匹配输出，导致幻觉。

特别是非推理模型经常会发生，比如 claude 3.7 sonnet 或 4.0 sonnet。

这种情况需要我们自身对上下文进行补充，比如我们问：“请实现一个登录功能”，但模型没有足够信息，就会强行匹配输出，导致幻觉。
2、Agent 模式下自主收集上下文。

如果使用 Agent 模式，Agent 会尝试搜索 codebase，读取文件以及调用工具自主收集上下文，通过这种策略，Agent 会走的比较远，但其轨迹仍然由上下文决定。

这个过程通常是不可控的，圈定的上下文范围可能多一些我们不想要的，少一些我们需要的，但总体可能不会有太大偏差，这个过程需要消耗较多 token。最终 Agent 能给出大概的解决方案。

如果我们需要更精确的解决方案，就需要我们对上下文进行裁剪补充。

比如 Agent 模式下使用 claude 4.0 sonnet(Thinking)、gemini-2.5-pro 等推理模型。

Cursor 如何让我们上下文更充分

Cursor 是以上下文感知为核心构建的，且期望最大限度地减少用户的干预，即 Cursor 会自动提取 codebase 中与大模型预测相关的部分，比如当前文件、其他语义相关或相似的文件、内容以及会话中的其他信息，并将其作为上下文提供给大模型。

当然目前来说，人为手动的指定任务相关的上下文引导大模型进入一个正确的方向，仍然是一个比较有效的策略。

@符号工具显性指定上下文

@工具	范例	使用场景	缺点
@code	@loadAndApplyRulesTask	我们知道哪个函数、常量或符号与当下需要生成的输出相关	需要大量的代码库知识
@files	@check_rule.md	我们知道该读取或编辑哪个文件，但不知道文件的确切位置	可能包括许多与手头任务无关的上下文，具体取决于文件大小
@folders	@Invoker	文件夹中的所有内容或大多数文件都是相关的	可能包括许多与手头任务无关的上下文
@docs	@s3 @Amazon S3	第三方官方功能、接口等文档，也允许自定义文档，但只能远程访问	可能包括许多与手头任务无关的上下文
@past chats	@Chat Name Generation	应用指定历史会话	不好回溯

注 1：@floders 默认提供目录路径与概述信息。

如果要上下文包含文件夹下全部内容，需要开启配置：Chat > Full floders contents（1.0 以前的旧版可能在 Features 配置下）

配置开启后，@floders 将尝试在上下文包含文件夹的全部内容。如果未开启配置，默认仅提供目录路径和概述，比如目录树结构。
注 2：@code

有人反馈 @code 不好使，可能是官方文档的范例说的比较简单，其实和 files 一样，只要@对应到代码中的函数、常量或符号，即可。
注 3：@docs

要求互联网可访问文档地址，如果是只有内部地址，外网不可访问时，添加的文档将无法访问。可以考虑在本地 @ 或通过 MCP 代理访问。

Rules 规则指定上下文

Rules 是 Cursor 中一个比较强大的功能，我们可以理解为团队、项目、代码库的各方面原则与约定，让 Cursor 在项目范围内有法可依。

一套完善的规则不是一蹴而就的，软件是由程序、数据、文档组成，如果原来有完善的文档，也许可以借用下官方工具生成 rules，反之需要一个团队携手共同逐步完善。

1、官方工具生成 Rules

官方提供了/Generate Cursor Rules 指令生成 rules，如果项目自身具备现代规范，可以使用 cursor 的生成 rule 命令生成规则。

单纯的执行指令，给出的结果并不会是我们想要的，毕竟是让 Cursor 自动收集上下文，很多私域信息或团队项目潜规则，Cursor 是 get 不到的。

参考：Cursor 0.49 更新：规则自动生成，详解&演示
2、配合 AI 手动添加 Rules

一开始可以参考模仿，结合实际团队项目的原则、规范、最佳实践等进行调整，规则也可以根据实际需要，拆分成有明确范围和意义的小规则文件，粒度小了也能更精准描述与控制生效应用范围、应用方式。

参考：
3、范例

Rules 除了公开知识外，也包含团队项目私域内的约定、规范标准、最佳实践等，需要团队成员共同参与，共同维护。项目负责人可以先完成一个项目的所有 rules 配置，然后分享给团队成员，让大家分门别类共同参与维护。

不细讲规则生成，可以参考一些文章，以及一些优秀的项目，比如：

AI personal assistant for email. 这个项目有优秀的 cursor 规则配置，这是一个优秀的规则配置项目，建议大家去观摩学习一下这个前端项目的规则配置，可以为我们的项目提供一些灵感。
- 全面的规则覆盖：
  - 项目概述与技术栈：清晰定义项目目标和使用的技术。
  - 目录结构：让 AI 了解项目文件组织。
  - API & 路由：后端接口规范。
  - 数据处理 & Prisma: ORM 使用和数据操作规则。
  - UI 组件 (Shadcn/ui): 前端组件库的使用规范、安装命令示例。
  - 开发流程 & 工具：测试、日志、工具类等规则。
  - 特定功能模块：如 Gmail API 调用、LLM 测试等。
- 清晰的结构与描述：每个规则文件都有明确的用途说明，易于理解和维护。
- 实用性强：包含了很多实际开发中会遇到的场景，如新组件安装命令、测试最佳实践等。
这是一个项目中最后生成的所有 rules 的使用指南文件，不好贴 markdown 格式内容，截图如下：

Notepads 指定上下文

官方提供的常见使用方式：

动态样板生成（编码范式、特定项目规则、代码统一规范）。
架构文档（设计模式、数据模型文档、架构准则）。
开发指南（编码标准、最佳实践、团队约定）。

具体来说我们可以使用 notepad 来存储：

常见代码模式模板。

可存储特定项目脚手架规则，如一次性完成一个接口从模型、服务、控制器、路由、验证器、输入输出数据结构，甚至文档注解及单测等一次性完成基础搭建。

一些旧项目经过多手开发，风格多，且并未完全按照框架官方的使用方式在框架内实现编码，存在个性化。在未能使用官方脚手架的情况下，可以通过 notepad 自定义脚手架规则。
常用自定义优秀代码片段，方便快速模仿应用代码片段。

项目中我们多少自定义的一些优秀的模块，在 notepad 中分门别类存储这些优秀模块的使用方式，方便主动快速应用。
一些工具模板。

比如批量转换等，这些也适合作为一种工具提示词模板存放在 notepad，方便需要时使用。

有人一直坚持使用 notepad 吗？是否有这方面的优良建议？

MCP 工具获得上下文

这里不详细介绍 MCP，对于有技术背景的人，应该也都需要知道 MCP 的来龙去脉。总之通过 MCP，Cursor 作为客户端可以发现一些资源、工具或服务能力，并自主决策组织编排调用本地或远端的资源、工具或服务，协助完成一件事情。

通过 MCP 获取更多上下文

Cursor 通过 MCP 可以提供执行和拉取外部的更多上下文信息，让 Cursor 更加智能。人拥有的知识广度、深度和视野大多数情况下都是不如优秀的大模型的，所以很多时候大模型的自主决策会做的很好。

我们允许让更优秀的大模型用更多的资源和工具去完成一件事，其成功率更高，质量更好。作为人，人还很重要，人是驱动者，Cursor 需要与人探讨，需要人 review 确认，才能最后定稿执行。

比如：fetch、google doc、github、gitlab、mysql、redis、mongodb、grafana、paypal、s3、jira、linear 等可以获取对应资源或信息作为上下文。当然 MCP 协议除了获取资源外，还可以执行对应的一些操作。
MCP 服务解决了原来哪些无法解决的问题呢？

MCP 解决了：传统自动化在处理非结构化输入、复杂多步骤任务和动态环境适应性方面的核心难题。
什么时候考虑使用 MCP 呢？

当我们面对以下场景时，MCP 就成了理想的选择，因为它解决了传统自动化难以处理的核心难题：
- 1、处理非结构化输入：当任务指令来自自然语言或非结构化文档，格式不固定时。
- 2、执行复杂多步骤任务：当需要根据当下信息，临时编排组合多个工具、服务或 API 才能完成一个复杂目标时。
- 3、适应动态变化的环境：当状态信息及工具集可能随时更新，需要 AI 动态发现并使用新能力时。
为什么不用现有的 HTTP 协议接口

我们可能会有疑惑为什么要用 MCP，直接调用现有的 HTTP 协议接口不可以吗？MCP 的最大用途是：可以标准化可理解地为 LLM 展示本地或云端拥有的资源与能力，客户端可以借助 LLM 以及当下状态信息，自主决策组织编排调用这些资源与能力。

而存量的 HTTP 协议接口目前难以直接做到，缺乏更细的自描述性，需要额外的个性化适配如胶水代码等提供远端资源与能力的展示，且对 LLM 不是很友好。

举个例子：对于一个查询订单状态的 HTTP GET /api/orders/{id} 接口，人可以直接使用，但 LLM"看"不懂。我们需要额外告诉它：“这里有个接口，路径是…，参数是…，可以查订单”。而 MCP 就像是为这个接口提供了一份标准化的"说明书”（Schema），LLM 自己就能阅读这份说明书，并理解如何使用它。
更多参考内部 MCP 相关分享文档。

TODO

运行时上下文

有时候代码是静态的，无法收集到具体的动态的上下文信息，有人就会想让 Agent 编写临时工具，让工具收集更多上下文，或是代码补充运行请求日志、调试日志、sql 日志、错误日志信息，使得大模型可以访问无法静态推断的动态上下文。

核心思想就是：让 Agent 访问实际的运行时的行为信息，而不仅仅是死盯着静态代码。

要点小结

上下文由意图和状态信息组成。
手动@上下文可以精确引导 Cursor。
善于使用 Rules、Notepads、MCP 等工具，让 Cursor 更智能。
提供静态代码外的动态行为信息，让 Cursor 了解到更真实的运行时状态。

Cursor 如何选择模型与自定义模式

有哪些模型，他们有什么不同

选择正确的大模型可以帮助我们更快地分析、决策与行动，并获得更好的结果。

Cursor 目前支持所有顶级大模型，GPT、Claude、Gemini、DeepSeek 等系列大模型，官方也及时更新模型。

Cursor 支持的很多模型，从模型的表现来看，他们会有这些方面的不同：

特性	说明	备注
`自信心`	如 `gemini-2.5-pro` 或 `claude-4-sonnet` 很自信，可以在最少的提示下做出决定。
`好奇心`	如 `o3` 或 `claude-4-opus` 会花时间计划或提出问题，以更深入地理解上下文。
`上下文窗口`	部分模型可以一次处理更多代码，这对于大规模任务非常有用。	截止 202506，通常都是 120k 的上下文窗口，O3 支持 200k，Max 模式最大可以支持到 1M 上下文窗口。详见 changelog 中关于上下文窗口大小对应的代码量规模。
`主动性`	有些模型擅长规划和探索，有些模型擅长快速实施，有些模型可以面向目标很主动，有些模型更倾向于是面向过程，需要我们的引导。

根据主动性，可以将模型分成我们经常说的：推理型模型、非推理型模型 或者 思考型模型、非思考型模型。

模型类型	说明	模型	使用场景
`推理型模型`	可以推断我们的意图、提前计划，并且通常无需分步指导即可做出决策。不需要太多提示，但有时很固执。可以进行比我们预期更大的调整。	如 `gemini-2.5-pro` 或 `claude-4-sonnet Thinking`、`DeepSeek R1`、`o3`等	需要探索想法、广泛调整重构、期望依赖大模型独立完成任务时。
`非推理型模型`	比较’听话’的模型，他们需要等待明确的提示指令，一般不推断或猜测，可以直接给出输出结果。需要更多提示，行为可预测。	如 `gpt-4o`、`claude-4-sonnet`等	适合公开知识问答，也适合于局部严格精确指导、精细微调、处理定义明确的任务时。

对于人来说，当然是希望我们提需求，大模型主动把事情都解决了，解决个 80% 也行，所以可能大部分情况下，不管三七二十一就选择推理型模型，而且必须是编程最好那一拨，比如：Claude-4-sonnet Thinking 或 Gemini 2.5-pro。

一般只有在知道自己要询问公开的知识时，才会换 Ask 模式下的 Auto 模式，让 Cursor 自主选择合适的模型，一般都会比较快速和节约地得到答案。

注：Max 模式下，可以支持更大的上下文窗口，可以支持到 1M 上下文窗口。所有模型调用均按请求计费，Max 模式则采用与 API 类似的 Token 计价。Cursor – Max Mode

如何选择模型

1、提示风格

这里可以把提示风格分为：面向过程和面向目标。

面向过程意味着我们想要掌控一切，有专业的相关知识，给大模型提出明确的提示，让大模型按照我们的意图去执行。理想模型是非推理型模型。

面向目标意味着我们想要大模型帮我们完成任务，我们只提供目标，让大模型自己决定如何完成任务。理想模型是推理型模型。

2、任务类型

任务	推荐模型
定向修改	`claude-4-sonnet`，`gemini-2.5-pro`
代码库导航与搜索	`gemini-2.5-pro`，`claude-4-opus`，`o3`
规划或问题解决	`claude-4-opus`，`gemini-2.5-pro`
复杂 bug 或深度推理	`o3`

注：O3 专为复杂、模糊的问题而设计。它功能强大，但速度较慢且资源密集，因此更适合偶尔使用。

3、选择树

经过上面的梳理，可以通过一棵选择树来选择模型：
4、Auto 自动选择模型

Auto 模式下，Cursor 会从上面选择树中除了 o3 外的模型中，选择一个可靠合适的模型，虽然官方也认为当不确定选择哪个模型的时候，Auto 就是比较可靠的默认值。

大家的默认模型是哪个？

自定义模式

Cursor 默认提供了 Ask、Agent、Manual 三种模式，也允许自定义模式，目前允许添加最多 5 个自定义模式。

Ask 模式：Ask questions about your codebase。
Agent 模式：Plan,search,build anything。官方也推荐使用 Agent 模式。

自定义模式可以自定义哪些内容？

自定义项	说明
模式名称	比如项目知识问答、方案设计、开发编码、代码审查、分析解读等
模型	不同模式可以选择合适的模型
快捷键	自定义快捷键
工具	目前有 Search、Run、Edit、MCP
自动	自动应用、自动执行、自动 fix
额外指令提示词	可以为这个模式额外添加提示词，比如角色、技能、约束设定

自定义模式有什么用呢？

我们做一件事情，往往会经历 PDCA，即 plan、do、check、action 这 4 个步骤，有了 AI，这些步骤并不会减少，但 AI 会加速这些步骤。
- plan 阶段
  
  这个阶段人会结合现状分析问题，并与 AI 一起不断演进解决方案。
  
  希望 AI 结合 codebase 及一些外部上下文信息，给出一个可行的方案，所以允许 AI 有 Search 能力，以及部分 MCP 能力，如果有时需要执行终端指令的话，再给 Run 的能力，不希望 AI 边思考边调整，一来容易导致文件混乱，二来上下文混乱。
  
  这个阶段可能会输出方案文档或一些备忘等。
- do 阶段
  
  经过 AI 和人确认后，进入 do 阶段，这个阶段希望 AI 可以根据 plan 阶段的方案，发挥 AI 最强能力去完成任务。
  
  这个阶段希望 AI 是无所不能的（可能特殊场景需要约束其能力范围），他会拥有大部分的工具能力，包括 Search、Run、Edit、MCP 等，甚至可以执行终端指令。
  
  注：现实中，并不会很顺利，从分而治之的角度看，PDCA 也是可以嵌套的，比如 do 阶段，可能需要多次 plan，然后 do，然后 check，然后 action。
- check 阶段
  
  这个阶段希望 AI 可以进行本次提交或是本分支改动内容进行代码审查，并给出一些优化建议。
  
  如果 check 的内容比较多与复杂，我们需要对 AI 给出的结果进行 review 和进一步补充上下文纠正，最终给出审查结果，也在确认后，在进入 action 完善。
- action 阶段
  
  有时我们比较相信 AI，可以在 check 时一并完成 action。
从这些阶段看，首先 AI 很重要，人也很重要的，其次每个阶段在现实世界中也是属于不同的细分工种，在 Cursor 里对应不同的细分模式，利于精准角色、约束范围工具与能力、提高关注度与准确度。
官方以及推荐的社区自定义模式
- Cursor – Custom Modes - example-modes
- Custom modes for Cursor that fit your own workflow

遗留项目或大型项目的一些建议

1、了解代码细节，不再用传统手动层层点击。

通过 Chat，可直接提问以获取其详细的运行方式。很多遗留代码我们记不住细节，完全可以让 Chat 来帮助我们找到，并梳理清楚。

虽然很简单，但有时还是会惯性的点点点。
2、启用 Include Project Structure 以提高性能。

为了让 Cursor 更深入地了解代码库的结构，务必在 Settings - Chat 开启 Include Project Structure 以提高性能。
3、特定领域业务知识编写文档规则。

从将新协作者引入我们的代码库角度出发，考虑为新协作者提供什么上下文内容及背景知识，才确保他们可以开始有效的协作。

模型也是我们的新协作者，我们需要为他提供特定领域的业务知识。这个也涉及到 Rules，再次强调了 Rules 及文档的重要性。
4、使用 Ask 模式进行规划，使用 Agent 模式实施。

Ask 模式和 Agent 模式虽然可用同一底层大模型（如 Gemini 2.5 Pro），但在 Cursor 中的实现逻辑和体验差异明显。

Ask 模式允许开发者通过提问、搜索和查询来探索代码库。在规划阶段，开发者需要全面了解项目的背景、需求和现有代码的结构。

Ask 模式可以通过搜索代码库、文档和网络资源，快速提供相关信息，帮助开发者构建完整的上下文。Ask 模式只读模式，无风险，逐步细化完善计划。

Agent 模式则像智能开发助手，能理解高层指令，自动分解并多步完成复杂任务，如项目创建、代码重构等，自主性强，能处理项目全局上下文，但响应速度相对较慢。

两者的核心区别在于：Ask 模式强调直接、精确的交互，适合明确需求；Agent 模式强调自动化和多步骤处理，适合复杂开发任务。
5、架构图、流程图、时序图、类图、状态图

体系结构图可帮助我们了解系统的工作原理。我们可以使用它们来探索逻辑、跟踪数据和传达结构，使用图表我们可以更好的理解流程、逻辑和数据。

从详细的低级图表开始，将其汇总到中级视图中，重复直到达到所需的抽象级别。
6、不要害怕将较大的更改分解成较小的块。
7、适当开始新的聊天有助于保持专注、高效，节约成本。
- Ctrl+T 或是 Alt+[点击创建 chat]，可以开始新的聊天 tab 窗口，不会影响旧的聊天窗口。
- 如果想从当前聊天窗口中间的一个对话开个新分支问答，可以用右下角…里的 Duplicate Chat，来复制对话，开启带有上下文的聊天记录的分叉对话。

Cursor 其他功能亮点

最近 3 个月大版本更新内容亮点。

Cursor-2025-上半年大版本更新日志

Cursor-构建高效上下文与模型选择指南

目录

前言

能用 Cursor 做什么