一、基础相关信息
1.1 Token 与字符估算换算
- 按 1 个英文单词 ≈ 1.3 个 token 计算: 120,000 tokens÷1.3 tokens/单词≈92,307个英文单词
- 按 1 个 token ≈ 0.75 个英文单词计算: 120,000 tokens×0.75单词/token=90,000个英文单词
- 按 1 个中文字符 ≈ 1.5 个 token 计算: 120,000 tokens÷1.5 tokens/字符=80,000个中文字符
- 按 1 个中文字符 ≈ 2 个 token 计算: 120,000 tokens÷2 tokens/字符=60,000个中文字符
1.2 计费标准
1.2.1 计费方式
- Normal:每个模型/消息的请求数(日常编码)
- Max:每 1M 令牌的请求数 (最适合复杂推理、难题和代理任务)
1.2.2 Cursor 价格
- 请求表示发送到模型的单个消息,包括您的消息、代码库中的任何相关上下文以及模型的响应,1 个请求为 0.04 USD。
- 付费用户每个月有500正常请求 (现在好像没有了,后台不显示消耗次数和500次了),用完正常请求时,免费请求会自动激活,免费请求响应慢,且不支持Max模式。
- 普通用户月付 20 美元,年付平均每月 16 美元。
- 请求计数介绍:docs.cursor.com/models#norm...
1.3 热门模型上线文大小
上下文处理大小,代表在AI保证正确记忆的状态下,你能完成多少信息沟通。超过上下文,沟通对话会记忆丢失,失真。

1.4 不同大小上下文能处理的事情
Tokens | 规模 | 真实示例 | 适合什么 |
---|---|---|---|
10k | 小 | 单个实用程序库 | 像 Underscore.js 这样的工具,或者一些 React 组件 |
60k | 中 | 实用程序集合 | 大多数中型库,如 Lodash |
120k | 大 | 完整的库 | 完整的实用程序库或大型框架的核心部分 |
200k | 特大 | Web 框架 | 像 Express 这样的完整框架,或像 Tokio 这样的运行时库 |
1M | 大规模 | 框架核心 | Django 等主要框架的核心(无测试) |
1.5 快捷键
二、Tab 使用
免费用户每月会收到 2000 条建议 (配额在每个计费周期自动刷新),Pro 和 Business 计划会收到无限的建议
2.1 基础功能使用
- Tab 键接受建议
- Esc 键拒绝建议
- 逐字部分接受建议,请按
Ctrl/⌘ →
,要拒绝后续内容,手动输入或使用 Esc - 打开或关闭,右下角状态栏上的"光标选项卡"图标
2.2 高级功能
速览中的 Tab 键,当函数getQuery新增一个参数时,使用转到实现(函数调用位置),此时使用Tab可以一次性改动所有


三、聊天对话(核心)
能力
- 了解代码
- 编辑代码
- 运行命令
- 自动化工作流程
模式
- Agent
- Ask
- Manual
- Thinking (选模型实现,带有脑子图标)
3.1 基本使用
⌘+L
(Mac) orCtrl+L
(Windows/Linux) 打开聊天对话。- 一次运行多个对话,只需按
⌘+T
(Mac) 或Ctrl+T
(Windows/Linux) 创建一个新选项卡。与聊天历史记录不同,选项卡可以并行执行,并且不依赖于之前的请求,同时确保多个选项卡不会尝试一次更改相同的文件 。让一个对话只处理一个核心事情,是避免上下文混乱的重要手段。不要在一次对话问跨域过大的事情。

command + .
查看快速修复建议中是否建议导入 - 如果没有,则语言服务器不工作
- 本次对话改动撤回 Restore checkpoint(在你发现此次代码被错误的接受后,可以反悔到这里)

- 代码审查,检查本次代码改动情况

- 管理长时间的对话,对于扩展对话,Cursor 使用较小的模型总结早期的消息,以保持速度和相关性,而不会丢失上下文。当接近上下文窗口限制时,Chat 建议参考当前对话开始新的对话(此时最好开启新对话,不然可能变智障)

- Duplicating Chats 复制聊天,以分支对话并探索替代方法,同时保留原始线程 (在一个聊天里面探索多个分支容易出现上下文混乱)

- Exporting Chats导出聊天,方便团队分享和讨论提示词和功能

- 选中代码添加到上下文 (很适合改局部代码功能)

3.2 Agent
- Agent Mode 代理模式,自主 AI 编码代理,使用完整的工具独立探索、规划和执行复杂的代码库更改
- Ask mode Ask 模式,Ask 模式允许您通过 AI 搜索和查询来探索和了解代码库,而无需进行更改
- Manual Mode 手动模式,使用明确的文件目标进行精确的代码更改 - 具有用户控制工具的集中编辑模式
- Custom Modes 自定义模式,使用定制的工具和提示创建自定义光标模式,为特定工作流程提供个性化 AI 帮助
论坛自定义模式推荐:playbooks.com/modes
自定义模式解决场景
基于自定义模式,可以使用模型定制多个角色/功能型配置,类似于通用能力封装。例如:
- 基于claude 定义编码角色,制定编码相关的配置和提示规则
- 基于gmini定义产品角色,制定需求分析和文档总结归纳
- 基于 gpt 定义文档整理,编写文档和输出要求

基于模型的特性,进行规则定制,自定义模式是cursor通用的,可以在任何项目中选择自己定义的模式
rule当然也可以定义用户纬度,但是更多适合项目rule
二者相比,自定义模式可定制范围更广泛,可以定义tools的使用(比如:pm角色一般不需要编码,可以避免让AI调用编码能力),同时也支持提示词设置
3.3 内联聊天
- 内联编辑
Cmd/Ctrl+K
允许您直接在编辑器窗口中生成新代码或编辑现有代码 - 终端也可以使用
Cmd K
,通过提示栏界面生成和运行命令 Ctrl/Cmd K
出现的栏称为"Prompt Bar"。工作原理类似于用于聊天的 AI 输入框,您可以在其中正常键入,或使用@

3.4 模型选择
带脑子图标的是思考模式,不带脑子的是常规模式

思维模式(Thinking models) 这些模型可以推断您的意图、提前计划,并且通常无需分步指导即可做出决策,当您探索想法、广泛重构或希望模型更独立地运行时,请使用这些选项。
- 非常适合您希望模型与任务一起运行时
- 不需要提示,但有时更固执己见
- 可以进行比您预期的更大的更改
Examples: 例子
claude-4-sonnet
gemini-2.5-pro
o3
专为复杂、模糊的问题而设计。速度较慢且资源密集,因此更适合偶尔使用 (专为复杂推理而设计)
非思考模型(Non-thinking models) 这些模型等待明确的指令。它们不会推断或猜测,当您想直接引导输出时,它们是理想的选择。当您需要严格控制、需要一致的行为或正在处理定义明确的任务时,请使用这些 API。
- 非常适合精确、受控的更改
- 需要更多提示,但行为更可预测
- 更易于指导、修改和微调
Examples: 例子:
claude-4-sonnet
gpt-4.1
四、上下文
4.1 上下文特点
- 所有模型都有一个有限的上下文窗口(例如 128k 个令牌),当上下文即将被填满时,Cursor 会自动总结对话,以确保模型有足够的空间来响应
- 尽量保留尽可能多重要信息,但必须省略一些内容
- 您可能会看到模型似乎忘记了之前的一些信息
4.2 如何规避问题
- 如果您正在处理新任务,请开始新对话
- 使用具有较大上下文窗口的模型
- 附加更少的文件,并让Agent决定是否需要读取更多文件
- 切换到 MAX 模式,该模式通常具有更大的上下文窗口
- 当系统推荐你开始新对话时,你可以在新开的对话中,引入上次对话内容来保证思路串联上
- 最好的方式是基于文档约束和任务拆分,进行子模块化设计,将大功能拆分多个小功能逐步实现。
五、符号使用
5.1 @符号
- @Files - 引用项目中的特定文件
- @Folders - 引用整个文件夹以获得更广泛的上下文
- @Code - 引用代码库中的特定代码片段或符号
- @Docs - 访问文档和指南
- @Git - 访问 git 历史记录和更改
- @Notepads - 访问记事本
- @Past 聊天 - 使用汇总的 Composer 会话,这个必须用,这是上下文超长后,开心新的对话必须要用的。
- @Cursor 规则 - 使用光标规则
- @Web - 参考外部 Web 资源和文档
- @Link (粘贴) - 创建指向特定代码或文档的链接
- @Recent 更改 - 创建指向特定代码或文档的链接
- @Lint 错误 - 引用 lint 错误(仅限 Chat)
- @Definitions - 查找符号定义(仅限 Cmd K)
5.2 #符号
- "#" 文件 - 将文件添加到上下文中而不引用
5.3 /符号
- / 命令 - 将打开的文件和活动文件添加到上下文中,可以用来初始化历史项目的rule
六、.cursorignore 忽略文件
- 安全原因,您可能仍希望限制对某些文件的访问,例如包含 API 密钥、数据库凭据和其他密钥的文件
- 在一个 monorepo 或非常大的代码库中工作,其中很大一部分与你正在开发的代码无关,你可以考虑将 Cursor 配置为忽略应用程序的这些部分
七、MCP
Model Context Protocol 模型上下文协议 (MCP) 是一种开放协议,它标准化了应用程序向 LLM 提供上下文和工具的方式。将 MCP 视为 Cursor 的插件系统 - 它允许您通过标准化接口将代理连接到各种数据源和工具,从而扩展代理的功能。
7.1 MCP推荐
cursor官方:
MCP官方:github.com/modelcontex...
pulemcp:www.pulsemcp.com/
glama:glama.ai/mcp/servers
smithery:smithery.ai/
awesome:github.com/punkpeye/aw...
linuxdo:linux.do/t/topic/499...
必备推荐
- context7 获取各类工具的官方的最新文档,保证代码编写稳定性。
- figma figma的官方mcp服务,写UI好用。
- github git官方的mcp服务。
7.1.1 通过设置安装mcp是电脑全局安装


7.1.2 通过.cursor/mcp.json 安装是项目安装(推荐)
arduino
// 项目级别
project/.cursor/mcp.json
// 电脑全局
~/.cursor/mcp.json
7.1.3 图片处理
当使用某些 MCP 服务器时,Cursor 可能会运行返回图像的工具,要允许 Chat 正确查看和使用其回复中的图像,您可以确保将服务器配置为以正确的格式返回图像。
php
const RED_CIRCLE_BASE64 = "/9j/4AAQSkZJRgABAgEASABIAAD/2w..."
server.tool("generate_image", async (params) => {
return {
content: [
{
type: "image",
data: RED_CIRCLE_BASE64,
mimeType: "image/jpeg",
},
],
};
});
7.2 如何使用
- 只需要在聊天中说:"使用xxx" 例如 "使用 context7"
- 当 Agent 想要使用 MCP 工具时,它将显示一条消息,请求您的批准

八、进阶使用
使用好rule和自定义模式,才是真正的算是开始了AI编程,真正意义上可以进行大型项目设计或者历史项目改造
我相信很多人对于AI编程,还是保留下面这些观点中的某一些,但我认为这些说法,本质上是没真正的深入使用
- AI 编程能处理一些小项目大项目不太行
- 写一些工具方法,功能函数等还行,写业务不太行
- 适合写新项目,不适合写老项目
- 能提升效率,但也不是爆发性的提升
8.1 rule设置
8.1.1 rule资源
8.1.2 rule 如何使用
rule 分为用户纬度 和项目纬度

用户纬度你可以在任何项目使用,项目纬度在 .cursor/rules
下新建xxx.mdc文件,rule生效时机,always,auto Attached,Agent Requested, Manual,根据rule的实际情况设置(项目基础 rule 可以always一直生效,其他的按需);

8.1.3 如何写符合要求的高质量rule
这个是重点,而且没有唯一的标准,没有绝对的对与错的概念 ,好与坏边界模糊,有点像是薛定谔的rule
它的核心点就是 提示词工程 ,你所写的自然语言 rule,能不能更好的被AI理解,就代表rule的好坏,调试迭代就是不断修改提示词,调试没有明确的对与错的日志让你分析。如果你的rule被AI很好的理解了,那给你完成的功能就非常好,反之很差。
尽管如此,但是从提示词工程 和自然语言表达 角度来说,还是有一些规范和格式可以遵循。始终谨记,自然语言表达的越好越有逻辑性,AI理解的越正确,越准确,最终给你的答案越符合预期
ini
角色定义
您是一名经验丰富 Web 前端开发人员,有超过10年的开发经验,精通,TypeScript、Vue.js等前端技术,并深入了解这些技术的最佳实践和性能优化技术。
任务/目标
您的职责是按照约定的代码规范,根据开发者的要求,进行项目开发。
条件约束(要求)
始终使用最优方案解决开发中的问题。
严格遵守项目结构和代码规范,禁止自我发散。
当你没有答案或是有无法确定时,明确说明,不要编造。
在被要求[更新]或[输出] 文档时,可分为[精简]-[一般]-[详细],默认为[一般]模式。
项目结构
放项目的目录结构树即可
开发规范
新文件使用驼峰命名
始终使用 Vue Composition API 脚本设置样式
编写简洁、可维护、技术上准确的 TypeScript 代码并附带相关示例
使用rem布局,视觉1:1映射到代码中
输出要求(文档)
输出文档始终使用markdown格式
示例样本
### 标题2
内容内容内容内容内容内容内容内容
### 标题2
内容内容内容内容内容内容内容内容
模式说明
[精简] 只阐述核心关键点,不做实际代码演示说明。
[一般] 在阐述关键点的同时,适当应用简化的伪代码。不做实际代码演示说明。
[详细] 在阐述关键点的同时,应用实际代码演示说明。
上面这是一个简单demo,我给设置成always,代表每次开启的AI对话,总是被执行,这只是其中的rule之一。实际开发你还需要一些基础rule来避免AI的问题,需要关于文档规范的rule等等,一个实际项目一般要包含很多个rule。
为什么设定角色?
提示词工程 - 方向性刺激:使模型推理结构清晰度提升62%,减少平庸方案产出率达81%,专业术语使用率提升47%;
为什么需要目标?
提升AI对任务的理解,更好的处理任务,提升任务结果的准确性
为什么条件约束?
约束AI回答,减少AI问题,降低AI幻觉。比如我对AI生成/更新文档的要求,设定了三个模式,当我说使用精简模式时,文档更新不会做任何代码编写,而是纯文本。
为什么项目结构,开发规范?
让AI始终理解项目的结构和开发规范,知道按照什么规范,更新项目和编写代码。
为什么输出格式?
让AI按照要求输出符合格式和要求的内容。
为社么提供示例?
提示词工程 - 少量样本提示: 仅需3个优质样本,准确率可提升 35%+(Google AI, 2023)
8.1.4 项目rule
回到上面我们对AI的评价,不能做大项目,不能做历史项目,迭代适合写工具不适合写业务
不能做大项目
我用rule规则和约束,基于Monorepo模式,设计AI玩法sdk,开发时间不到4天,三个大模块。
前期文档准备
- 前期文档:调研设计文档和方案编写
- 前期文档:需求功能细化,任务拆分
- 前期文档:rule规则设计编写
实际开发功能
- 三方Bos接入-上传封装-任务封装 SKD封装
- image-editor 基于fabric的图片编辑器封装
- example 使用demo的封装

个人开发流程
- 第一步:明确需求,结构化markdown,落地需求文档,根据需求大小拆分功能文档
- 第二步:设置rule,这一步对于第一次接触rule的用户来说不太友好,我个人也是边学边写,建议参考上面社区,找到适合自己的,而且这是一个迭代过程。
- 第三步:让AI阅读理解需求,根据需求给出设计文档和设计思路,独立产出设计文档
- 第四步:人工审核设计文档和设计思路,是否符合需求和个人预期,并对文档进行整改更新
- 第五步:让AI根据一定的要求或思路拆分任务,生成任务文档,这里可以特别强调"保证人可以理解的前提下,尽可能生成AI理解的提示词",逐步实现功能(为什么拆分,因为上下文有限,大项目是无法在有限的上下文内一次完成)
- 第六步:根据任务文档,进行代码实现,此时要有结构化流程,保证先
建立地基,做好钢结构,浇筑承重体,最后才是完善细节
,这样生成才能规范,我举例:
ruby
=> 先按照项目设计模块,生成目录结构(比如monoropo下有三个模块)
=> 在实现模块核心类和方法的伪代码结构(比如每个模块类,对外暴露哪些API或方法,让AI先完成类和方法的声明,不用进行具体实现)这里主要有两个原因,一是实现太多怕超过上下文限制,二是更具备条理性和可移植性,当存在类和方法伪代码时,你可以根据实际情况随意补充片段代码,甚至使用其他AI工具也行,因为你的框架结构是固定的。
=> 然后是要求AI每实现一个功能快进行总结回顾,并对下一个模块设计实现进行简单说明,由人工确认是否进行(这一步的目的也有2个:一是AI的自我反思,审查自己功能实现情况。二是在开发下一个功能时,我们可以先审查它实现思路是否符合要求,由人工确认我们可以纠正一些AI不必要的想法)
=> 完成模块,类和伪代码实现,我们让AI按照模块的目录结构,生成一份必要文档,让AI沉淀功能实现(此时可以让它生AI能更好理解的提示结构,有文档方便后续迭代开发,AI实际开发中,也是功能和文档同步更新,不然其他人接手,没有文档开发会出现偏差)
=> 当你开发很久后,发现达到了AI上下文上限,你可以新开聊天,引用上次聊天(可以保证新的聊天串联上任务,也可以饮用之前总结的文档)
-
第七步:开发完,让AI进行系统总结,查漏补缺完善功能细节。
-
第八步:系统性的对文档审查一遍,让AI针对文档进行理解,对其进行文档理解进行开发效果测试性验证。举例:
上下文引入项目结构和功能模块关键性文档,先让AI说明对项目结构和项目设计思路的理解,然后在让其给出新增或者修改模块的开发思路,人工审核其理解是否符合要求,如果不符合要求,根据其理解偏差适当修改更新文档。
不能做历史项目
首先我们,直接使用生成rule功能,将整个项目结构生成AI可理解rule规则,rule本身也是markdown格式,可以提取出来,放到项目文档目录下。

其次,需要我们审查修改,将其作为项目基础文档,有了项目文档基础,对于AI来说就完全理解了项目,此时和新项目对于AI来说是一样。
这里重点是这些文档可能需要你实际开发中,逐渐迭代文档内容,自动生成偏向于结构文档,缺少业务表述和边界case情况。

适合写工具不适合写业务
这个评价的核心原因就是没有让AI没有理解任务需求。也就是说关于项目的文档总结的不到位。(这一步可以让AI逐步完成,人工审核。AI根据项目文件命名,注释,函数命名等基本上是能够总结出项目的业务核心,可用性还是非常高的)
另外一个原因是,没有使用figma的mcp服务或者图片识别能力,不知道如何让AI基于设计稿写页面。
建议接入figma的mcp服务,粗估能减少40%-70%的工作量(看UI设计的figma规范情况,如果结构合理,效果也会很好)
8.2 自定义模式
论坛自定义模式:playbooks.com/modes
自定义模式和rule玩法基本一致,重点在于你可以更广泛的定制工具调用,避免不必要的工具使用和执行。
我们看下面在cursor比较受欢迎的一个自定义模式,Search模式它只给了codebase和Read file两工具权限,Edit 没有给删除权限。然后自定义介绍,给了深度的提示词设定(基本和rule一致,告诉AI应该是一个什么角色,有什么任务和要求)

九、几个典型开发问题
9.1 AI过度设计
AI设计会考虑的更全面,更丰富,其实有些东西不是很必要
- 国际化,日志上报,监控上报,报警等 AI会过度设计导致代码体积过大,其实根据实际需求,有些不是很必要
rule 提示词要求
shell
## 必要询问
所有国际化能力设计,都要询问是否需要。
所有单元测试、测试相关能力设计,都要询问是否需要。
所有监控、日志、报警设计,都要询问是否需要。
9.2 Agent 不听话上来就写代码
一种方式是,对话时明确要求其不要产出代码 ,先说明设计思路。一种方式是,在rule里配置规则 。我这里采用rule模式,通过条件约束 + 适当自由度
的方式。 一种方式是,自定义模式,控制AI对工具调用的能力,比如定一个文档管理员,禁止其代码输出能力。 还可使用ask模式,不使用agent模式
- 明确要求拆分任务设计,要先总结不要直接实现代码,由人工确认。
- 进行必要回验证,这个是让其适当回顾,当其实现功能时,它会总结说明思路
- 灵活判断,释放自由度,让AI自由评估复杂度,这是辅助上面一条的规则。
rule 提示词要求
shell
## 动态回顾
对于任何要拆分任务,逐步实现的能力,在进行代码编写前,简要概括总结实现内容,由人工确认是否进行下一步开发。
单次设计,功能复杂时,进行必要回验,简要概括总结。
灵活判断复杂度,自由评估。
9.3 不必要的文档跟新和输出
rule 提示词要求
css
在被要求[更新]或[输出] 文档时,可分为[精简]-[一般]-[详细],默认为[一般]模式。
在 "非明确要求创建新文档" 情况下,每次创建文档都优先询问是否新建文档。
创建新文档务必遵守 [双目录同步结构设计],项目在 `packages`下,文档在 `design`下。
可以自由评估文档拆分粒度,不必过于细化,推荐功能模块纬度拆解。
文档更新时,重在更新不是全覆盖。【重点:对于AI可理解提示词,保持增量更新,补充版本号】。
文档更新时,自检提示词,并合理评估优化。
9.4 编码过度包装
- try catch 过多,try catch 嵌套
- console 不必要打印内容
javascript
只在明确要求使用【try catch】时,才对编码增加相关逻辑。
只在明确要求使用【console】时,或者存在try catch 时,才进行console输出。
// 还有一些其他编码要求,根据自身设定 ......