Cursor AI 编程最佳实践方案
1. 引言
1.1. Cursor AI 简介
Cursor AI 是一款面向开发者的智能编程助手，集成了代码生成、自动补全、代码重构、文档检索、代码搜索、终端命令执行等多种 AI 能力，极大提升开发效率和代码质量。其核心基于大语言模型（如 GPT、Claude、Gemini 等），结合代码库理解、上下文感知和多工具协作，能够辅助开发者完成从需求分析、代码编写、重构、测试到文档生成的全流程工作。
Cursor AI 支持多种主流开发语言和框架，适配前端、后端、全栈、测试、运维等多种开发场景。通过与 IDE 深度集成，开发者可以在本地环境中无缝调用 AI 能力，提升开发体验。
1.2. 编写目的
尽管 Cursor AI 功能强大，但许多开发者在使用时存在认知盲区与操作误区。部分开发者因缺乏科学的环境配置方法，导致工具性能受限；还有些开发者因未掌握规则设定技巧，难以让 AI 生成贴合项目需求的代码。本方案旨在系统梳理 Cursor AI 的使用方法与实践技巧，从前期准备、规则设定、多模型协同到版本控制等全流程，提供可落地的解决方案，帮助开发者突破使用瓶颈，充分释放 Cursor AI 在项目开发中的潜力，实现高效、规范、智能化的编程工作流。
1.3. 适用范围
本方案主要面向公司前端、后端、全栈开发人员，作为日常开发、协作、文档管理等场景下的 Cursor AI 使用规范和参考指南。
2. 前期准备
2.1. 需求与原型文档管理
项目的需求文件、原型设计文件建议直接放在项目目录（如 docs、design 等文件夹），便于随时通过 @Files、@Folders 等方式引用给 Cursor，提升 AI 对业务需求的理解能力。
如不希望这些文档影响代码分析，可通过 .cursorignore 文件将其排除，兼顾开发与文档管理。
也可将需求、原型等文档放在在线文档平台，通过 Cursor 的 @Doc 功能直接引用在线文档内容，便于团队协作和 AI 调用。
2.2. cursorrules 定义
合理使用全局 Cursor Rules 和局部 Cursor Rules，可以大幅度限制 AI 幻觉和 AI 自由度，输出更符合要求的内容。
全局 Cursor Rules：在公司 / 团队级别统一配置，约束所有项目的基础规范，如注释风格、变量命名、异常处理、日志规范等。
局部 Cursor Rules：针对具体项目或模块，补充业务特有规则，如包结构、数据库访问方式、接口风格、第三方库使用约定等。
建议将 cursorrules 文件纳入版本控制，团队成员协同维护。
对于微服务项目，建议每个服务单独配置 cursorrule，细化各自的业务和技术规范，同时团队层面也应有全局 cursorrule，实现局部与全局规范结合，提升规范落地效果。
2.2.1. 前端 cursorrule 示例
# @datatag-front 项目的 Cursor AI 规则 ## 核心原则 - **遵守 Vue.js 官方风格指南**: 这是最重要的总纲，AI应优先参考并遵循 [Vue.js 风格指南](https://v2.cn.vuejs.org/v2/style-guide/) (特别是优先级A和B的规则)。 - **Element UI 组件库**: 正确使用 Element UI 组件，遵循其文档和最佳实践。 - **代码可读性与可维护性**: 生成的代码应易于理解、修改和扩展。 - **一致性**: 在整个项目中保持编码风格和模式的一致性。 ## Vue.js 特定规范 (@2.6.12) ### 组件 - **组件名**: - 始终使用多词组件名，例如 `UserProfile` 或 `user-profile`。 - 单文件组件 (`.vue`) 文件名：推荐 PascalCase (如 `UserProfile.vue`) 或 kebab-case (如 `user-profile.vue`)，并保持项目内一致。 - 在 JavaScript/JSX 中引入和注册组件时使用 PascalCase (如 `import UserProfile from './UserProfile.vue';`)。 - 在模板中使用组件时，推荐 PascalCase (如 `<UserProfile />`)，但在 DOM 模板中必须使用 kebab-case (如 `<user-profile></user-profile>`)。 - **Prop 定义**: - Prop 声明时使用 camelCase (如 `greetingText`)。 - 在模板中使用 Prop 时使用 kebab-case (如 `greeting-text="Hello"`)。 - Prop 定义应尽可能详细，至少包含 `type`。推荐包含 `required`、`default` 和 `validator` (如果适用)。 - **`v-for`**: 始终为 `v-for` 指令提供 `key`。 - **`v-if` 与 `v-for`**: 避免在同一个元素上同时使用 `v-if` 和 `v-for`。优先使用计算属性过滤列表，或将 `v-if`移至父元素。 - **组件数据 `data`**: 必须是一个返回对象的函数。 - **组件样式**: - 默认情况下，组件的 `<style>` 标签应使用 `scoped` 属性，以避免全局样式污染。 - 对于可复用的基础组件或UI库组件，可以考虑使用基于 class 的策略 (如 BEM) 代替 `scoped`，以便于样式覆盖。 - **单文件组件结构**: - `.vue` 文件内顶级标签顺序推荐：`<template>`, `<script>`, `<style>` 或者 `<script>`, `<template>`, `<style>`。保持项目内一致，但 `<style>` 通常放在最后。 - **组件选项顺序**: 遵循 Vue.js 风格指南推荐的选项顺序 (如 `name`, `components`, `props`, `data`, `computed`, `watch`, `methods`, 生命周期钩子等)。 - **模板中表达式**: 保持模板中的表达式简洁。复杂逻辑应移至计算属性或方法中。 - **自闭合组件**: 没有内容的组件在 `.vue` 文件模板和 JSX 中应自闭合 (如 `<MyComponent />`)，但在 DOM 模板中不能自闭合。 - **基础组件命名**: 应用特定的基础组件（展示型、无状态）建议使用统一前缀，如 `Base` (例如 `BaseButton.vue`, `BaseModal.vue`)。 - **单例组件命名**: 只应存在单个活跃实例的组件，建议使用 `The` 前缀 (例如 `TheHeader.vue`, `TheSidebar.vue`)。 ### Vuex (@3.6.0) - **模块化**: 对于中大型应用，使用 Vuex 模块 (Modules) 来组织 store。 - **State**: State 应该是唯一的真相来源，只能通过 Mutations 修改。 - **Getters**: 用于从 store 中的 state 派生出一些状态，类似计算属性。 - **Mutations**: - 必须是同步函数。 - 命名：使用大写常量形式 (例如 `SET_USER`)。 - **Actions**: - 用于提交 Mutations，可以包含异步操作。 - 命名：通常使用 camelCase (例如 `fetchUserData`)。 - Actions 可以 `dispatch` 其他 actions。 - **辅助函数**: 善用 `mapState`, `mapGetters`, `mapMutations`, `mapActions` 辅助函数简化组件中的代码。 ### Vue Router (@3.4.9) - **路由定义**: - 路由配置应清晰、有组织，可以按功能模块划分。 - 路由命名：使用 PascalCase (例如 `UserProfile`) 或 kebab-case (例如 `user-profile`)，并与组件名保持一定关联性。 - **导航**: 优先使用声明式导航 `<router-link :to="{ name: 'RouteName' }">`。编程式导航使用 `this.$router.push()` 或 `this.$router.replace()`。 - **路由参数**: 清晰定义和使用路由参数。 - **路由守卫**: 合理使用全局守卫、路由独享守卫和组件内守卫处理导航逻辑。 ### Element UI (@2.14.1) - **组件使用**: 遵循 Element UI 文档，正确使用其提供的组件和API。 - **按需引入**: 如果项目配置了按需引入，确保AI生成的代码也遵循此方式，避免引入整个库。 - **自定义主题**: 如果项目有自定义主题，AI生成的相关样式代码应考虑到主题的变量和风格。 - **表单验证**: 使用 Element UI 表单组件时，充分利用其提供的验证规则。 ### JavaScript (ES6+) 编码规范 - **变量声明**: 优先使用 `const`，其次 `let`，避免使用 `var`。 - **箭头函数**: 适时使用箭头函数，特别是在回调函数和保持 `this` 指向时。 - **模块**: 使用 ES6 模块 (`import`/`export`)。 - `import` 语句通常放在文件顶部。 - 导出：根据需要使用命名导出或默认导出。 - **解构赋值**: 善用对象和数组的解构赋值，使代码更简洁。 - **模板字符串**: 优先使用模板字符串进行字符串拼接和多行字符串。 - **Promise 和 Async/Await**: 对于异步操作，优先使用 `Promise` 和 `async/await`。 - **注释**: - 对复杂逻辑、重要函数或模块提供清晰的注释。 - JSDoc风格的注释用于函数和方法，说明参数、返回值和用途。 - **代码格式**: - **缩进**: 使用 4 个空格 (参考项目已有的 `.editorconfig` 或 `.eslintrc.js` 配置)。 - **分号**: 根据项目 ESLint 配置决定是否使用分号 (通常推荐使用)。 - **逗号**: 对象或数组最后一个元素后的拖尾逗号，根据项目配置。 - **行长度**: 建议不超过 120 字符。 - **命名规范**: - 变量和函数名：lowerCamelCase (例如 `userName`, `calculatePrice`)。 - 类名和构造函数：UpperCamelCase (例如 `UserService`, `DataProcessor`)。 - 常量：ALL_CAPS_WITH_UNDERSCORES (例如 `MAX_USERS`)。 ### CSS / SCSS 规范 (如果项目中使用 SCSS) - **命名约定**: - 推荐使用 BEM (Block Element Modifier) 命名约定 (例如 `.card__title--large`) 或项目中已统一的其他约定。 - 避免使用 ID 选择器进行样式化，优先使用 class 选择器。 - **样式作用域**: 见 Vue.js 组件样式部分。 - **属性顺序**: 推荐将相关的属性声明组织在一起 (例如：定位 -> 盒模型 -> 字体 -> 颜色 -> 其他)。 - **简写属性**: 合理使用 CSS 简写属性 (例如 `margin`, `padding`, `font`)。 - **嵌套 (SCSS)**: 避免过深的嵌套 (一般不超过3-4层)，以保持选择器的低特异性和可读性。 - **变量 (SCSS)**: 使用 SCSS 变量定义颜色、字体、间距等可复用值。 - **Mixins (SCSS)**: 对可复用的样式片段使用 mixins。 ### 通用前端最佳实践 - **文件与目录结构**: - 遵循 Vue CLI 生成的默认结构 (`src/assets`, `src/components`, `src/views`, `src/router`, `src/store` 等)。 - 组件按功能或特性组织，可以考虑创建子目录，但避免层级过深。 - 工具函数、常量等可以分别组织在 `src/utils`, `src/constants` 等目录。 - **错误处理**: - 对 API 请求进行错误处理 (例如使用 `axios` 的拦截器或 `.catch()`)。 - 在适当时机向用户展示友好的错误信息。 - **代码复用**: - 提取可复用的组件和逻辑到独立的模块或服务中。 - 避免不必要的代码重复。 - **性能**: - 关注组件的渲染性能，避免不必要的重新渲染。 - 合理使用计算属性和 `watch`。 - 对于大型列表，考虑虚拟滚动或分页。 - 图片资源优化。 - **可访问性 (a11y)**: 尽可能遵循 Web 内容可访问性指南 (WCAG)，例如为表单元素提供标签，为图片提供 `alt` 文本等。 ### AI 交互指南 - **遵循上述所有规则**: 在生成新代码、修改现有代码或提供建议时，AI 必须严格遵守本文档中的规范。 - **理解上下文**: AI 应理解当前文件、组件以及整个项目的上下文。 - **Vue 生态系统**: 正确使用 Vue Router, Vuex 和 Element UI 的 API 和模式。 - **代码生成**: - 生成的代码应直接可用，包含必要的导入和依赖。 - 优先生成单文件组件 (`.vue`)。 - 确保组件的 props, data, methods, computed properties, lifecycle hooks 等组织清晰。 - **代码解释**: 当被问及代码时，能够结合这些规范进行解释。 - **重构建议**: 提出的重构建议应以提高代码质量、可读性、可维护性和遵循规范为目标。 - **提问**: 如果指令不明确或与规范冲突，AI应主动提问以澄清。 - **中文优先**: 与用户主要使用中文交流，代码中的注释也推荐使用中文（除非项目有特定英文注释要求）。2.2.2. 后端 cursorrule 示例
--- description: globs: alwaysApply: false --- # @datatag 项目的 Cursor AI 规则 (基于阿里巴巴 Java 编码规范) ## 通用 Java 开发规范 - **命名规范：** - 类名：UpperCamelCase (例如：`UserService`, `OrderController`)。 - 方法名：lowerCamelCase (例如：`getUserById`, `calculateTotalPrice`)。 - 常量名：ALL_CAPS_WITH_UNDERSCORES (例如：`MAX_RETRY_COUNT`)。 - 变量名：lowerCamelCase。 - 包名：all_lowercase_with_dots (例如：`com.example.project.service`)。 - **注释规范：** - 为所有公共类和方法编写 Javadoc。 - 解释复杂逻辑或非显而易见的代码段。 - 避免仅仅复述代码的冗余注释。 - **代码格式：** - 使用 4 个空格进行缩进（不要使用制表符）。 - 限制行长度为 120 个字符。 - 确保一致的大括号风格 (例如：K&R 风格)。 - **异常处理：** - 捕获异常时要具体。除非绝对必要，否则避免捕获通用的 `Exception` 或 `Throwable`。 - 记录异常时提供足够的上下文信息。 - 不要忽略异常（避免空的 catch 块）。 - 在 `finally` 块中清理资源，或使用 try-with-resources 语句。 - **并发处理：** - 处理共享可变状态时，注意线程安全。 - 在需要时使用适当的同步机制（如 `synchronized`, `Lock`,并发集合）。 - 避免使用 `Thread.sleep()` 进行轮询或等待；应使用恰当的 wait/notify 或更高级别的并发工具。 - **面向对象编程：** - 遵循 SOLID 原则。 - 在适当情况下，优先使用组合而非继承。 - 封装内部状态。 - **魔法数字：** - 避免使用魔法数字；使用命名常量代替。 - **Null 值检查：** - 勤勉地执行 Null 检查，特别是对于方法参数和外部调用的返回值。 - 当值的缺失是正常情况时，考虑使用 `Optional` 作为返回类型。 - 禁止为集合或数组返回 `null`；应返回空集合/数组。 - **Equals 和 HashCode：** - 如果对象要在基于哈希的集合中使用，务必一致地覆盖 `equals()` 和 `hashCode()`。 - **日志记录：** - 使用标准日志框架 (例如 SLF4J 配合 Logback 或 Log4j2)。 - 使用适当的日志级别 (DEBUG, INFO, WARN, ERROR)。 - 不要记录敏感信息。 ## Spring Boot 特定规范 (@2.3.12.RELEASE) - **组件扫描：** - 如果关注性能，优先使用显式的组件扫描路径，而不是默认的广泛扫描。 - **配置：** - 使用 `@ConfigurationProperties` 实现类型安全的配置。 - 使用 `application.properties` 或 `application.yml` 进行外部化配置。 - **依赖注入：** - 对于强制依赖项，优先使用构造函数注入。 - 谨慎使用 `@Autowired`，并清晰记录其用途。 - **REST 控制器：** - 使用特定的 HTTP 方法 (`@GetMapping`, `@PostMapping` 等)。 - 返回恰当的 HTTP 状态码。 - 清晰定义请求和响应的 DTO。 - 使用 `@RestControllerAdvice` 进行全局异常处理。 - **服务层：** - 业务逻辑应位于服务类中。 - 使用 `@Service` 注解。 - 保持服务专注和内聚。 ## MyBatis 特定规范 - **Mapper 接口：** - 定义 Mapper 接口以确保类型安全。 - 对于简单查询使用注解 (`@Select`, `@Insert` 等)，复杂查询使用 XML。 - **XML Mapper 文件：** - 逻辑地组织 XML Mapper 文件。 - 使用 `<sql>`片段实现可复用的 SQL 代码段。 - 避免使用 `select *`；明确列出所有列。 - 谨慎使用动态 SQL 以防止 SQL 注入 (参数使用 `#{}`)。 - **结果映射 (Result Maps)：** - 对于数据库列和 Java 对象属性之间的复杂映射，使用 `<resultMap>`。 - **事务管理：** - 在服务层使用 Spring 的声明式事务管理 (`@Transactional`) 来管理事务。 ## MySQL 特定规范 - **数据库表结构设计：** - 选择合适的数据类型。 - 定义主键和外键。 - 明智地使用索引以优化查询性能。避免过度索引。 - **查询语句：** - 编写高效的 SQL 查询。对复杂查询使用 `EXPLAIN` 分析查询计划。 - 避免 N+1 查询问题；使用 JOIN 或批量获取。 ## 数据序列化 (Fastjson) - **安全：** - 注意 Fastjson 的安全漏洞。保持库版本更新。 - 如果可能，启用 `SafeMode`。 - 除非严格需要并完全理解其影响，否则指定 `autoTypeSupport = false`。 - **日期格式化：** - 使用 `@JSONField(format = "yyyy-MM-dd HH:mm:ss")` 进行一致的日期格式化。 ## Lombok 使用规范 - **代码清晰度：** - 明智地使用 Lombok 注解 (`@Data`, `@Getter`, `@Setter`, `@NoArgsConstructor`, `@AllArgsConstructor`, `@Builder`, `@Slf4j`) 以减少样板代码。 - 确保生成的代码易于理解，并且不会掩盖重要逻辑。 - 注意 `@Data` 等注解的潜在影响 (例如：自动生成 `equals`, `hashCode`, `toString`)。 ## 阿里巴巴规范通用最佳实践 (摘要) - **可读性：** 代码应易于阅读和理解。 - **可维护性：** 代码应易于修改和扩展。 - **可测试性：** 代码设计应便于单元测试。 - **安全性：** 注意常见的安全漏洞 (SQL 注入, XSS, CSRF 等) 并采取措施加以防范。 - **性能：** 编写高效的代码，并注意资源使用。 - **简洁性：** 优先选择简单的解决方案而非复杂的 (KISS 原则)。 - **避免使用已废弃的 API。** - **正确处理资源关闭。** ## AI 交互指南 - 在生成新代码或修改现有代码时，遵守上述规则。 - 优先考虑代码的清晰性、可维护性以及对阿里巴巴 Java 编码规范的遵守。 - 对于新功能，考虑 `@datatag` 项目中现有的模式和约定。 - 如果不确定某个特定规则或最佳实践，请求澄清或参考阿里巴巴 Java 编码规范文档。 - 在建议数据库表结构更改或复杂查询时，解释其原因和潜在的性能影响。 - 确保所有新的公共 API (类、方法) 都用 Javadoc 进行文档化。 ## 项目结构 datatag/ ├── data │ ├── system.db # 数据库文件 ├── src/main/java/com/rzdata/system/ │ ├── SystemApplication.java # 主启动类（已添加@MapperScan） │ ├── constant/ # 系统常量类（新增） │ ├── entity/ # 实体类（使用Lombok注解） │ ├── mapper/ # 数据访问层（详细注释） │ ├── service/ # 服务接口（详细注释） │ │ └── impl/ # 服务实现（异常处理+日志） │ └── controller/ # 控制器 ├── src/main/resources/ │ ├── application.properties # MyBatis-Plus配置 │ └── schema.sql # 数据库初始化脚本 └── pom.xml # Maven依赖3. Cursor 使用技巧
3.1. 任务拆解
在使用 Cursor 前，先将需求或功能点拆解为若干小任务（如接口设计、单个业务逻辑实现、单元测试编写等），每次只让 AI 处理一个具体问题。
推荐在 Notepad 或任务清单中列出所有子任务，逐步推进，避免 AI 一次性生成过多、过杂的内容。
复杂需求可先让 Cursor 协助梳理功能模块，再逐步细化到每个模块的实现细节。
3.2. 避免与处理 AI 幻觉
AI 幻觉（生成错误或虚构内容）常见于需求描述不清、上下文不足或指令过于宽泛时。实用建议如下：
- 复述指令：让 Cursor 先用自己的话复述你的需求，确认理解无误后再让其生成代码。
- 缩小需求范围：每次只提一个具体问题，避免 “帮我写一个完整的 XX 系统” 这类大而泛的指令。
- 拆解需求：将复杂需求分解为多步，逐步推进，每步都进行结果校验。
- 逻辑引导：给出明确的输入输出、边界条件、示例代码或伪代码，帮助 AI 聚焦正确方向。
- 结果校验：AI 生成后，务必人工 Review，重点关注业务逻辑、边界处理、异常分支等。
- 上下文补充：善用 @Files、@Code、@Notepads 等引用相关上下文，提升 AI 准确率。
3.3. 模式选择
- Agent 模式：适合需求不明确、需要 AI 自主探索、批量重构、自动化脚本等场景。典型用法：让 AI 分析代码库、批量生成接口、自动修复 Bug 等。
- Ask 模式：适合只读查询、代码理解、文档检索、历史变更追溯等场景。典型用法：快速定位某个类 / 方法的用途、查找接口文档、分析历史提交等。
- Manual 模式：适合已知具体修改点、需要精确控制变更范围的场景。典型用法：只修改某个文件的某几行、批量替换变量名、精细化重构等。
建议根据任务类型灵活切换模式，提升效率和可控性。
3.4. 模型选择
- claude-4：适合复杂推理、长文本、全局性重构等高阶需求，但高峰期响应较慢。
- claude-3.7.sonnet、gemini-2.5-pro：适合明确、结构化的功能开发，响应速度快，适合日常开发主力模型。
- gpt-o3：适合头脑风暴、需求模糊、需要 AI 主动补全思路的场景。
实践建议：如遇响应慢或结果不理想，可尝试切换模型，多轮对比选择最佳输出。
3.5. 精细的版本控制
每完成一个小功能或修复一个 Bug，建议立即提交代码，保持提交粒度细化，便于回滚和追溯。AI 生成代码后，务必 Review 并本地测试通过再提交。如发现 AI 误改无关代码，可通过 Git diff 快速定位并回退。建议在分支上开发，合并前充分测试，避免 AI 误操作影响主干。
4. Cursor 功能技巧
4.1. New Chat（新建对话）
场景适用
- 每个功能模块、开发阶段（如前端、后端、测试、DevOps）建议单独新建对话，避免上下文混杂，便于任务聚焦和历史追溯。
- 需求、开发、测试等不同阶段分开新建对话，有助于管理上下文，减少 AI 误解。
- 处理紧急 Bug、临时脚本、调研等临时性任务时，也建议新建独立对话，便于后续归档和复盘。
命名对话
对话命名建议采用 “功能 / 模块名 + 任务类型” 格式，如 “用户管理 - API 设计”、“标签计算 - 单元测试” 等，便于后续检索和团队协作。
对于长期维护的模块，可按 “模块名 - 日期 - 任务” 命名，方便版本管理。
4.2. @符号
- @Files：引用项目中特定文件，适合让 AI 分析、修改、补全指定文件内容。
- @Folders：引用整个文件夹，适合让 AI 了解模块结构、批量处理文件。
- @Code：引用代码库中的特定代码片段或符号，便于精准定位和分析。
- @Docs：访问项目文档、接口说明、设计规范等，提升 AI 回答的准确性。
- @Notepads：引用记事本内容，适合复用需求拆解、会议纪要、开发计划等上下文。
- @Cursor Rules：让 AI 严格遵循项目规则，减少风格不统一和幻觉。
- @Past Chats：将之前聊天的摘要版本作为上下文。
- @Web：引用外部网络资源、官方文档、第三方库说明等，辅助 AI 查找最新资料。
建议在每次提问前，结合 @符号补充足够上下文，提升 AI 理解和输出质量。
4.3. Tab（代码补全）
利用 Tab 键接受 AI 建议，快速补全函数、变量、注释等，提升编码效率。
在输入函数签名、注释、循环等常用结构时，AI 会自动预测后续代码，建议多尝试 Tab 键获取最佳补全。
对于重复性高、模板化的代码（如 DTO、VO、接口定义等），AI 补全尤为高效。
补全后务必 Review，防止 AI 引入不符合业务逻辑的内容。
4.4. Notepad
Notepad 适合记录需求拆解、开发计划、会议纪要、常用指令等，便于多轮对话中反复引用。
可将 Notepad 作为 “任务清单”，每完成一项任务及时勾选或归档，提升开发流程的可追溯性。
团队协作时，可共享 Notepad 内容，统一上下文，减少沟通成本。
4.5. Cursor Ignore
通过 .cursorignore 文件排除无关文件或目录（如日志、构建产物、node_modules、target、.git 等），提升 Cursor 分析速度和准确性。
建议每个项目初始化时由 AI 自动生成 .cursorignore，再根据实际情况手动补充。
对于大型项目或多模块仓库，建议细化排除规则，避免无关内容干扰 AI 判断。
.cursorignore 文件应纳入版本控制，团队成员保持一致。
5. 常用快捷键
- Tab：接受代码补全建议
- Ctrl + L：打开 Cursor 的 chat 窗口
- Ctrl + Shift + P：打开命令面板
- Ctrl + Shift + L：将选择的代码添加到聊天
- Ctrl + Enter：接受所有更改
- Ctrl + Backspace：拒绝所有更改
- Ctrl + K：针对部分代码以内联的形式进行交互式问答和修改
6. 接手新项目的 Cursor 初始化流程
6.1. 检索项目并生成 .cursorignore
首次打开项目后，建议让 Cursor 自动扫描项目结构，生成初始 .cursorignore 文件。
排除 node_modules、target、.git、日志、构建产物等无关目录和文件，减少 AI 分析干扰。
检查并手动补充特殊目录（如临时文件、第三方依赖、测试数据等），确保只保留核心业务代码和配置。
.cursorignore 文件建议纳入版本控制，团队成员保持一致。
6.2. 重新索引代码库
在 Cursor 设置中，进入 Feature 菜单，选择 Codebase Indexing，点击 Resync Index，强制重新索引项目。
索引完成后，AI 对代码结构、依赖关系、模块划分的理解会更准确，提升后续问答和代码生成质量。
若项目结构有较大调整（如重构、合并分支），建议再次 Resync Index。
6.3. 录入项目文档
将需求文档、接口文档、设计说明、数据库文档等关键资料通过 @Docs 功能录入，便于 AI 引用。
支持上传 PDF、Markdown、Word 等多种格式，建议统一整理到 docs 或 design 目录下。
录入后可通过 @Docs 快速检索和引用，提升 AI 回答的准确性和上下文丰富度。
6.4. 配置 cursorrules
在项目根目录创建 cursorrules 文件，结合公司 / 团队规范和项目实际，细化规则内容。
可让 Cursor 分析项目结构和代码风格，自动生成初始 cursorrules，再根据实际需求补充和调整。
规则内容建议涵盖命名规范、注释要求、异常处理、日志、依赖注入、数据库操作等。
cursorrules 文件建议纳入版本控制，团队成员协同维护。
6.5. 处理需求与调试
新需求到来时，优先在 Ask 模式梳理需求，创建 Notepad 记录任务拆解和开发计划。
在 Agent 模式下逐步生成代码，每完成一个小任务及时 Review 和测试。
若提交引入 Bug，可在 Ask 模式下结合 @Git、@Files 等工具，指定上次正常提交，让 Cursor 分析问题并给出修复建议。
重要变更建议在分支上开发，合并前充分测试，确保主干稳定。
- 副业接单
自有成熟开发团队，项目自研不外包。承接 Java 全栈、小程序、APP、AI 智能体、爬虫脚本各类软件开发。全程闲鱼担保，交付完整源码，长沙可面谈，无套路，售后稳妥省心。
闲鱼 ID：程序员鱼鱼呀
