【AI智能编程】Cursor IDE工具学习

什么是Cursor

Cursor 是一个类 VSCode 的智能编程 IDE，集成了 GPT-4、Claude 3.5 等先进大语言模型（LLM），本质上是一个内置 AI 助手的 VSCode。它不仅支持自然语言编程，还提供从代码编写、调试、重构到部署的智能辅助。你可以像和人交流一样与 AI 协作，大幅提升开发效率和代码质量。

国内 AI 编程 IDE 推荐

• 阿里 Lingma IDE：https://lingma.aliyun.com/
• 字节 Trae：TRAE - The Real AI Engineer

Cursor 的核心特性

• AI 原生设计：从底层架构就融入了 AI 能力，而非后期添加的插件
• 智能代码生成：通过自然语言描述快速生成代码片段
• 上下文感知：深度理解项目结构和代码关系
• 实时协助：在编程过程中提供即时的建议和优化
• 多模型支持：集成了多种先进的大语言模型

Cursor 与传统 IDE 的区别

功能特性	传统 IDE	Cursor
代码补全	基于语法分析和已有代码的静态补全	AI 驱动的智能补全，理解上下文和意图
代码生成	依靠预设模板和代码片段	通过自然语言描述生成完整代码逻辑
问题解决	需要手动查找文档、Stack Overflow 等	内置 AI 助手，即时解答编程问题
代码理解	提供语法高亮和基础结构分析	深度理解代码逻辑，提供详细解释
重构优化	手动操作，依赖开发者经验	AI 智能分析并建议最佳重构方案
学习支持	需要外部资料和文档	内置技术知识，实时学习辅导
错误处理	显示编译错误和基础语法检查	预测潜在问题，提供修复建议和解释

核心差异总结

对比维度	传统 IDE	Cursor
交互方式	基于菜单、快捷键的工具操作	自然语言对话 + 传统操作
学习曲线	需要记忆大量快捷键和功能位置	通过对话快速上手，降低学习门槛
开发效率	依赖开发者经验和熟练度	AI 辅助显著提升编码速度
代码质量	主要依靠开发者技能水平	AI 持续提供最佳实践建议
知识获取	需要主动搜索和学习	被动接收 AI 推荐和解释
问题诊断	基于错误信息手动排查	AI 分析问题根源并提供解决方案
创新能力	受限于开发者知识范围	AI 提供多样化解决思路
适用人群	需要一定编程基础	适合各个水平的开发者

安装Cursor

官网地址： Downloads | Cursor - The AI Code Editor

第一步：选择我同意此协议

第二步：选择需要的附加任务

第三步：选择安装

安装完后选择完成即可

第四步：选择配置

第五步：从 VS Code 中导入配置

若你的电脑中已安装并配置 VS Code ，你可以点击 从 VS Code 导入 按钮。系统将会从对应的 IDE 中获取插件、IDE 设置、快捷键设置等信息并一键导入到 Cursor中，帮助你快速从其他 IDE 切换到 Cursor。

第六步 选择数据偏好

推荐选择右边的隐私模式

第七步 注册或者登录

Cursor基本功能

按下键盘组合键 Ctrl+Shift+X，进入扩展程序页面。在搜索框中输入 “Chinese”，搜索中文语言包。

Cursor初体验

打开 Chat 模式 进入 cursor后，一般默认进入 Chat 模式。若非如此，可以参考以下步骤打开 Chat 模式。

第一种方法 点击右上角的即可进入chat模式

选择模型 Cursor内置了很多LLMs，包括最先进的GPT4s、Claude3.7和openai最新发布的推理模型o1-preview和o1-mini，在右上角的设置中即可打开相应的模型进行辅助编程。平时用的最多的还是Claude3.7和GPT4。

AI功能快捷键 ：Cursor的AI功能是其最大的特色，掌握这些快捷键可以让你的编码效率翻倍：

Cmd/Ctrl + K：打开AI命令面板，可以用自然语言向AI提问或要求它执行特定任务。
Cmd/Ctrl + L：选中代码后使用此快捷键，AI会详细解释代码的功能；同时也可以调出聊天选项卡。
Cmd/Ctrl + /：通过模型切换选择您喜欢的AI模型。

Agent模式

什么是Agent模式

Agent 模式是 Cursor 中的核心能力之一，定位为开发者的智能编程伙伴。它借助深度 AI 集成，能主动理解代码上下文并执行复杂操作，显著提升开发效率。

🔧 核心功能：

• 上下文智能提取：自动分析当前项目的代码结构，理解上下文信息。
• 终端命令执行：无需切换窗口，即可在编辑器中直接运行命令。
• 文件操作支持：轻松进行文件的创建、修改、删除等操作。
• 语义搜索：可通过语义理解快速定位关键代码段。
• 多工具连续调用：Agent 最多可连续调用25 个工具，支持复杂任务自动完成。

Agent 和普通 AI 的区别？

对比项	普通 AI（如 ChatGPT）	Agent 模式
能不能动手？	❌ 只能说	✅ 能执行
能不能读全项目？	❌ 只能读片段	✅ 可以读整个项目上下文
能不能跑命令？	❌ 不行	✅ 可以
能不能自动做一系列任务？	❌ 不行	✅ 连续执行多个任务（最多 25 个）

典型应用场景

✅1. 代码重构 Agent 分析代码上下文，提出结构优化建议并生成重构后的代码。

✅ 2. Bug修复 自动检测、标注错误，提供修复建议并可一键完成修复。

✅ 3. 完整项目生成 例如让 Agent 创建一个 “Todo List Web 应用”，它会：

• 搭建项目结构
• 编写前后端代码
• 自动生成测试代码
• 输出使用说明

Ask模式

什么是Ask

Ask 模式是智能编程工具（如 Cursor）中的重要交互方式之一，专注于代码理解、问题解答与知识补全。与 Agent 模式注重执行不同，Ask 模式提供的是基于上下文的智能问答体验，帮助开发者快速理解代码含义、定位问题、优化设计，从而显著提升编程效率和代码质量。

Ask 模式能做什么

• 理解代码含义
• 定位错误和解释报错
• 性能和结构优化建议
• 学习参考和文档补全

使用方式

✅ 激活方式：

在支持 Ask 模式的 IDE（如 Cursor）中，激活方式通常包括：

• 选中代码后按快捷键（如 Cmd + K / Ctrl + K）
• 右键菜单中选择“Ask about this code”
• 直接输入自然语言问题并指定相关代码块

✅ 问答格式支持：

• 这段代码在做什么？
• 为什么这里会报错？
• 有没有更好的写法？
• 这个变量的类型是什么？
• 这个函数能不能改得更简洁？

与 Agent 模式对比

对比维度	Ask 模式	Agent 模式
核心定位	智能问答/解释	智能执行/操作
工作方式	基于代码上下文的提问和解答	接收指令并调用工具或执行动作
是否修改代码	❌ 不直接修改代码	✅ 可以修改、创建、删除文件
使用频率	高频次	中高频（复杂任务用）

Manual模式

什么是Manual模式

Manual 模式是 Cursor 中最基础、最“听话”的 AI 使用方式，顾名思义，"手动使用"。用户需要主动输入请求（Prompt），AI 根据输入内容来响应操作，不会主动介入你的编程过程。

换句话说，在Manual 模式下，AI 更像一个工具箱里的"智能助手"，不主动打扰，只在你召唤它时才工作。

核心特点

特性	描述
主动触发	必须由用户输入命令或点击 AI 面板按钮触发
响应内容	基于当前输入或代码上下文生成
可控性强	不会自动修改代码，所有建议由你手动选择是否采纳
无打扰	不会在你写代码时跳出来自动提示
支持多种任务	包括改写代码、生成函数、解释报错、翻译注释、生成测试用例等

使用场景

• 需要对 AI 生成内容有充分控制的开发流程
• 开发者习惯逐步交互，细化任务拆分
• 复杂项目中对每一步修改都需确认和审查
• 辅助生成测试、文档等辅助性工作
• 调试、排错时需要精准、可控的辅助

与其他模式对比

模式	是否主动	是否修改代码	用途
Ask 模式	✅ 是	❌ 否	轻量问答、快速交互
Agent 模式	✅ 是	✅ 是	自动理解意图、重构、创建新文件等
Manual 模式	❌ 否	❌ 否	手动触发、自主掌控，适合教学或有经验的开发者

内联智能

什么是内联智能？

内联智能，顾名思义，就是指智能功能直接嵌入在代码编辑器的编辑界面内，与代码内容无缝结合，实时显示和交互，帮助开发者在编写代码的“行内”获得智能辅助。

换句话说，内联智能就是把 AI 的能力“贴近代码”，在开发者写代码时直接在代码旁边、行内或特定位置给出提示、补全、注释、建议等信息，无需跳转窗口或打开其他面板。

内联智能的核心特点

特点	说明
实时性	随代码输入即时触发，反馈快速
上下文感知	基于当前文件乃至整个项目的代码上下文进行智能推断
无缝集成	直接显示在代码编辑区域，不打断开发者思路
交互便捷	支持点击、展开、编辑、采纳建议等交互操作
多功能融合	集成代码补全、错误提示、重构建议、文档注释等多种智能功能

内联智能的具体应用场景

1. 智能代码补全

• 在开发者输入代码时，内联智能能结合上下文和历史记录，推荐最合适的代码片段或函数调用
• 例如输入变量名、函数名时，自动提示匹配项并支持快速选取

2. 代码错误和警告提示

• 直接在代码行内或旁边标注语法错误、潜在逻辑漏洞
• 例如拼写错误、类型不匹配、变量未定义等即时警告

3. 重构建议和代码优化

• 在相关代码处提示重构可能性，比如函数拆分、命名优化、循环简化
• 鼓励代码规范化、模块化，提升可维护性

4. 文档注释生成

• 在函数定义或类上方内联提示缺少注释，提供自动生成选项
• 帮助快速补全符合规范的 API 文档

5. 单元测试建议

• 代码变更时，内联提示可能需要新增或修改的测试用例
• 支持快速跳转生成测试代码模板

内联智能的技术实现要点

技术点	说明
上下文感知语义理解	结合语法树（AST）、类型信息、代码调用关系进行深度语义解析
模型推理与缓存机制	采用大模型推理辅助决策，并缓存历史结果减少延迟
编辑器插件集成	通过 VSCode、IntelliJ 等编辑器扩展实现 UI 层和交互层支持
事件驱动机制	监听代码输入、保存、切换文件等事件触发智能响应
异步反馈与并发处理	保证智能提示不会阻塞编辑体验，异步加载和更新内容

Cursor精准上下文

使用 @Docs：获取权威官方信息

@Docs 功能将 Cursor 直接连接到众多流行工具和框架的官方文档。当您需要以下类型的权威信息时，@Docs 是首选：

• API 参考 ：精确查找函数签名、参数定义、返回值类型等。
• 入门指南 ：快速了解工具的安装、配置和基础使用方法。
• 官方最佳实践 ：获取源头推荐的编码模式和设计原则。
• 框架特定调试 ：参考官方提供的故障排除步骤和常见问题解答。

使用 @Web：探索广泛的社区与网络资源

@Web 功能赋予 Cursor 实时搜索互联网的能力，以获取最新的博客文章、社区讨论和教程。以下场景适合使用 @Web：

• 近期教程与代码示例 ：查找由社区贡献的最新学习资源。
• 技术方案对比 ：阅读分析不同方法或工具优劣的文章。
• 追踪最新动态 ：了解非常近期的技术更新、版本发布或行业公告。
• 获取多方视角 ：参考不同开发者对同一问题的多种解决方案和观点。

@Web 扩展了信息获取的边界，尤其适用于快速变化的技术领域和需要多元视角的场景。

Cursor Rule规则配置

什么是 Cursor Rules

Cursor Rules，中文翻译过来是 Cursor 规则。就是给Cursor制定一系列规则，约束AI生成的代码。

当一条规则被触发后，规则中的内容会被附加到提示词中，为 AI 提供参考，无论是在自动补全、代码生成、重构还是错误修复时都能遵循这些规范。

在 Cursor 当中，支持两种级别的规则：

• 全局规则（User Rules） ：针对所有项目通用的规则
• 项目规则（Project Rules） ：存放于项目目录下的 .cursor/rules 中，只用于约束当前项目。

规则文件的位置和命名规范

Cursor 会自动识别 .cursor/rules/ 路径下的规则文件：

项目根目录/
└── .cursor/
   └── rules/
     └── *.mdc  👈 规则文件（必须使用 .mdc 扩展名）

解释：

• 📁 路径固定：必须为 .cursor/rules/
• 📄 扩展名固定：必须为 .mdc
• ✅文件可以有多个，每个规则建议单独拆分主题编写，如 unocss-guidelines.mdc, project-structure.mdc, naming-conventions.mdc 等

规则文件的作用

• 指明项目所使用的技术栈（Vue 3, Element Plus, Pinia, TypeScript, Vite）
• 明确项目约定（组件/文件命名、CSS 命名、导入顺序）
• 避免误判：减少 Cursor 提供的错误补全或重复实现已有功能
• 提升智能度：帮助 AI 生成符合项目风格、结构规范、命名约定的代码

如何创建 .mdc 规则文件

手动方式

// 创建规则目录
mkdir -p .cursor/rules
// 创建规则文件
touch .cursor/rules/project-guidelines.mdc

说明：文件名可自定义，扩展名必须为 .mdc

使用 Cursor 快速生成 在 Cursor 编辑器中打开 Chat 窗口，输入 / 并选择弹出的 Generate Cursor Rules 选项，即可自动生成 .cursor/rules/ 目录及默认的规则文件。

Cursor 支持四种规则类型

• Always：始终应用规则（想始终生效）
• Auto Attached：当匹配 globs 模式的文件被引用时自动附加规则（想自动触发用）
• Agent Requested：根据 AI 代理的判断决定是否应用规则，需要提供规则说明（想让 AI 自己决定是否用）
• Manual：仅在提示中显式使用 @规则名 时附加规则。（想手动调用规则）

规则文件怎么写？（内容结构推荐）

.mdc 文件本质是 Markdown 文档，但具有特殊结构。以下以开源项目 vue3-element-admin 为例，给出适用于 Vue 3 + TypeScript 项目的推荐规则模板写法：

# 项目基础说明
​
- 本项目基于 Vue 3 + TypeScript + Element Plus + Pinia + Vite 搭建。
- 采用组合式 API（`<script setup lang="ts">`）进行开发。
- 状态管理使用 Pinia，模块化组织。
- 路由使用 Vue Router，采用权限动态路由配置。
- 接口请求统一封装在 `@/utils/request.ts` 中，使用 Axios。
- 表格、表单页面基于 Element Plus 封装通用组件，提高复用性。
​
# 组件和文件命名规范
​
- 组件文件名使用 `PascalCase` 格式，例如：`UserTable.vue`, `LoginForm.vue`
- 公共组件放置在 `src/components/` 下，业务组件可放在 `src/views/模块/components/` 中
- 文件夹名和非组件 `.ts/.scss` 文件使用 `kebab-case` 格式，例如：`user-api.ts`, `login-form.scss`
- 页面文件命名与路由保持一致，使用 `kebab-case`，例如：`user-list.vue`, `role-edit.vue`
​
​
# 样式和 CSS 使用约定
​
- **优先使用原子类：** 使用 UnoCSS 提供的原子类进行布局和样式，例如常见的 flex 布局（`flex justify-center items-center` 等）。样式语义明确，便于维护。
- **常用组合提取为全局快捷方式：** 对于**频繁使用**的原子类组合，应在 `unocss.config.ts` 中通过 `shortcuts` 定义全局组合类。例如：将 `flex justify-center items-center` 定义为 `flex-center`，这样可以在整个项目中复用。组合类命名应简洁且语义化，反映布局或功能意图。
- **非常用组合使用局部类：** 对于特定组件中使用但不常见的、超过3个的原子类组合，应该在组件内使用局部CSS类（使用`<style scoped>`块），避免过多的全局组合污染全局命名空间。
- **避免重复代码：** 不论是通过全局`shortcuts`还是局部CSS类，都应避免在多个地方重复编写相同的原子类列表，保持代码 DRY（Don't Repeat Yourself）原则。
- **样式优先级：** 优先考虑 UnoCSS 解决方案（原子类或组合类），其次才是传统 CSS。当需要使用传统 CSS 时，遵循 BEM 命名规范，即 `block__element--modifier` 格式。
​
# 导入顺序规范（保持统一结构）
​
1. Vue 相关 API（如 `ref`, `computed`, `onMounted`）
2. 第三方库（如 `element-plus`, `axios`）
3. 工具函数（如 `@/utils/*`）
4. 状态管理（如 `@/store/*`）
5. 项目内部组件、模块（如 `@/components`, `@/views`）
6. 样式文件
​
​
# 开发注意事项
​
- 使用 TypeScript，避免使用 `any`；
- 组件职责单一，保持结构清晰；
- 所有组件必须使用组合式 API；
- 适当添加注释，提升 AI 理解。

使用技巧与建议

• 拆分规则主题： 可以为不同模块分别写规则，比如 style-guidelines.mdc、project-structure.mdc、component-conventions.mdc，让 AI 更易查阅上下文。
• 越具体越好： 你越明确规则，Cursor 越能准确给出符合你期望的代码。避免废话和废规则： Focus on 可执行、可操作、可验证的规则。比如“命名要清晰”不如“类名采用 BEM 规范并用小写字母连接”具体有效。
• 随项目迭代更新规则： 规则应当与代码保持同步更新，特别是引入新的库、工具、编码风格变更时。

mdc语法

什么是mdc文件格式

.mdc（Markdown with Configuration）是一种扩展的 Markdown 文件格式，专为 Cursor等智能开发工具设计，用于编写规则、配置、教学任务等内容。

它结合了 Markdown 的可读性与结构化的前置元数据（Frontmatter），使得开发者可以在统一语法中定义：

• 文件适用范围
• 启用方式（自动、手动）
• 配套文件引用
• 规则说明、注释、命令等

文件结构与规范

每个 .mdc 文件由两部分组成：

1. 前置元数据（Frontmatter）：用三横线（---）包裹，定义规则的描述和适用范围。
2. 规则正文：使用Markdown格式编写具体指令

前置元数据（Frontmatter）

使用三横线 --- 包裹，采用 YAML 格式，主要用于声明规则的元信息。

常见字段如下：

字段	说明
description	对规则的简要描述，便于用户理解该规则的意图。
globs	规则应用的文件匹配范围，支持通配符。例如："src/**/*.tsx"。
alwaysApply	是否始终自动应用规则。true 表示无需用户确认，自动生效。
applyMode	（可选）控制应用方式，如 intelligent, manual, specificFiles。

---
description: "在 React 项目中使用 TypeScript 和 Tailwind CSS"
globs:
  - "src/**/*.tsx"
alwaysApply: true
---

正文（Markdown格式）

正文使用标准 Markdown 编写，可以包含标题、列表、代码块、注释、引用文件等。是实际执行规则或说明内容的主体。

常用语法支持：

• ## 标题：用于结构化说明
• - 列表项：用于列出规范细则
• @file：表示要引用的外部文件路径
• @command：表示要执行的指令（例如用于脚手架）

---
description: "在 React 项目中使用 TypeScript 和 Tailwind CSS"
globs:
  - "src/**/*.tsx"
alwaysApply: true
---
​
# 项目基础说明
​
- 本项目基于 Vue 3 + TypeScript + Element Plus + Pinia + Vite 搭建。
- 采用组合式 API（`<script setup lang="ts">`）进行开发。
- 状态管理使用 Pinia，模块化组织。
- 路由使用 Vue Router，采用权限动态路由配置。
- 接口请求统一封装在 `@/utils/request.ts` 中，使用 Axios。
- 表格、表单页面基于 Element Plus 封装通用组件，提高复用性。
​
# 组件和文件命名规范
​
- 组件文件名使用 `PascalCase` 格式，例如：`UserTable.vue`, `LoginForm.vue`
- 公共组件放置在 `src/components/` 下，业务组件可放在 `src/views/模块/components/` 中
- 文件夹名和非组件 `.ts/.scss` 文件使用 `kebab-case` 格式，例如：`user-api.ts`, `login-form.scss`
- 页面文件命名与路由保持一致，使用 `kebab-case`，例如：`user-list.vue`, `role-edit.vue`
​
​
# 样式和 CSS 使用约定
​
- **优先使用原子类：** 使用 UnoCSS 提供的原子类进行布局和样式，例如常见的 flex 布局（`flex justify-center items-center` 等）。样式语义明确，便于维护。
- **常用组合提取为全局快捷方式：** 对于**频繁使用**的原子类组合，应在 `unocss.config.ts` 中通过 `shortcuts` 定义全局组合类。例如：将 `flex justify-center items-center` 定义为 `flex-center`，这样可以在整个项目中复用。组合类命名应简洁且语义化，反映布局或功能意图。
- **非常用组合使用局部类：** 对于特定组件中使用但不常见的、超过3个的原子类组合，应该在组件内使用局部CSS类（使用`<style scoped>`块），避免过多的全局组合污染全局命名空间。
- **避免重复代码：** 不论是通过全局`shortcuts`还是局部CSS类，都应避免在多个地方重复编写相同的原子类列表，保持代码 DRY（Don't Repeat Yourself）原则。
- **样式优先级：** 优先考虑 UnoCSS 解决方案（原子类或组合类），其次才是传统 CSS。当需要使用传统 CSS 时，遵循 BEM 命名规范，即 `block__element--modifier` 格式。
​
# 导入顺序规范（保持统一结构）
​
1. Vue 相关 API（如 `ref`, `computed`, `onMounted`）
2. 第三方库（如 `element-plus`, `axios`）
3. 工具函数（如 `@/utils/*`）
4. 状态管理（如 `@/store/*`）
5. 项目内部组件、模块（如 `@/components`, `@/views`）
6. 样式文件
​
​
# 开发注意事项
​
- 使用 TypeScript，避免使用 `any`；
- 组件职责单一，保持结构清晰；
- 所有组件必须使用组合式 API；
- 适当添加注释，提升 AI 理解。
​

用户Rule规则配置

什么是用户 Rule（规则）？

用户 Rule 是一组配置规则，用于定义系统在执行任务或操作时的行为约束，特别是在 AI 编程、自动化任务、操作代理（Agent）执行环境等场景中，用于控制哪些操作允许、哪些禁止、如何处理异常等。

怎么使用 User Rule？

User rule 是一个全局设置，在 Cursor Settings -> Rules 可以设置。比如，我们可以设置回复的语言和风格：

所有输出和建议必须基于确认无误的信息，严禁臆测或无依据的猜测。
按文件逐一修改，便于审阅和排查问题。
除非明确要求，禁止添加任何第三方或新增依赖，确保项目可控。
仅修改用户明确指定的内容，不影响其他区域或功能。
禁止因排版目的进行无意义的空格、缩进等调整。
修改后仅输出结果代码，不附加修改说明、总结或提示语。
只做指定改动，不增加任何未被请求的功能或逻辑。
不得删除或更改与本次修改无关的代码或功能。
修改前需完整浏览上下文，确保理解整体结构和逻辑。
保持与现有项目的命名规范、代码风格、格式完全一致。
变量命名需语义明确，禁止使用 a、b、c 等无意义命名。
禁止添加日志输出、调试页面、调试语句等调试相关内容。
除非特别要求，否则不得自动生成任何测试代码。
统一使用当前推荐的标准 API，禁止调用已弃用接口。
一律使用 Windows 命令，禁止使用任何 Linux 命令。
所有代码注释必须使用中文，保持语言一致性。