AI编程专栏(二)- Cursor 深度使用指南

一、基础相关信息

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 快捷键

docs.cursor.com/kbd

二、Tab 使用

免费用户每月会收到 2000 条建议 （配额在每个计费周期自动刷新），Pro 和 Business 计划会收到无限的建议

2.1 基础功能使用

• Tab 键接受建议
• Esc 键拒绝建议
• 逐字部分接受建议，请按 Ctrl/⌘ →，要拒绝后续内容，手动输入或使用 Esc
• 打开或关闭，右下角状态栏上的"光标选项卡"图标

2.2 高级功能

速览中的 Tab 键，当函数getQuery新增一个参数时，使用转到实现（函数调用位置），此时使用Tab可以一次性改动所有

三、聊天对话（核心）

能力

• 了解代码
• 编辑代码
• 运行命令
• 自动化工作流程

模式

• Agent
• Ask
• Manual
• Thinking (选模型实现，带有脑子图标)

3.1 基本使用

• ⌘+L (Mac) or Ctrl+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官方：

• docs.cursor.com/tools
• cursor.directory/

魔塔：www.modelscope.cn/home

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 安装是项目安装（推荐）

// 项目级别
project/.cursor/mcp.json

// 电脑全局
~/.cursor/mcp.json

7.1.3 图片处理

当使用某些 MCP 服务器时，Cursor 可能会运行返回图像的工具，要允许 Chat 正确查看和使用其回复中的图像，您可以确保将服务器配置为以正确的格式返回图像。

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资源

• 官方：cursor.directory/
• 社区：github.com/PatrickJS/a...

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理解的越正确，越准确，最终给你的答案越符合预期

角色定义
  您是一名经验丰富 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理解的提示词"，逐步实现功能（为什么拆分，因为上下文有限，大项目是无法在有限的上下文内一次完成）
• 第六步：根据任务文档，进行代码实现，此时要有结构化流程，保证先建立地基，做好钢结构，浇筑承重体，最后才是完善细节，这样生成才能规范，我举例：

=> 先按照项目设计模块，生成目录结构（比如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 提示词要求

## 必要询问
所有国际化能力设计，都要询问是否需要。
所有单元测试、测试相关能力设计，都要询问是否需要。
所有监控、日志、报警设计，都要询问是否需要。

9.2 Agent 不听话上来就写代码

一种方式是，对话时明确要求其不要产出代码 ，先说明设计思路。一种方式是，在rule里配置规则 。我这里采用rule模式，通过条件约束 + 适当自由度 的方式。 一种方式是，自定义模式，控制AI对工具调用的能力，比如定一个文档管理员，禁止其代码输出能力。 还可使用ask模式，不使用agent模式

• 明确要求拆分任务设计，要先总结不要直接实现代码，由人工确认。
• 进行必要回验证，这个是让其适当回顾，当其实现功能时，它会总结说明思路
• 灵活判断，释放自由度，让AI自由评估复杂度，这是辅助上面一条的规则。

rule 提示词要求

## 动态回顾
对于任何要拆分任务，逐步实现的能力，在进行代码编写前，简要概括总结实现内容，由人工确认是否进行下一步开发。
单次设计，功能复杂时，进行必要回验，简要概括总结。
灵活判断复杂度，自由评估。

9.3 不必要的文档跟新和输出

rule 提示词要求

在被要求[更新]或[输出] 文档时，可分为[精简]-[一般]-[详细]，默认为[一般]模式。
在 "非明确要求创建新文档" 情况下，每次创建文档都优先询问是否新建文档。
创建新文档务必遵守 [双目录同步结构设计]，项目在 `packages`下，文档在 `design`下。
可以自由评估文档拆分粒度，不必过于细化，推荐功能模块纬度拆解。
文档更新时，重在更新不是全覆盖。【重点：对于AI可理解提示词，保持增量更新，补充版本号】。
文档更新时，自检提示词，并合理评估优化。

9.4 编码过度包装

• try catch 过多，try catch 嵌套
• console 不必要打印内容

只在明确要求使用【try catch】时，才对编码增加相关逻辑。
只在明确要求使用【console】时，或者存在try catch 时，才进行console输出。
// 还有一些其他编码要求，根据自身设定 ......