Cursor中rules配置参考-202504版（含前后端Golang/TypeScript/Kotlin等）_cursor rules

Cursor rules 进行一些参考和迭代梳理了一个版本，给大家参考，包括Golang、Java场景、以及前端TypeScript+React/Vue场景，以及Android包含Java/Kotlin场景等。可以自己进行简化，或者只是把中间某些条目加入到自己现有项目的cursorrules中。可以自己进行简化，或者只是把中间某些条目加入到自己现有项目的cursorrules中。

希望一些条目大家可以复制自用能够给一些参考，提升Code效率和准确性。

【Cursor开发中rules配置文件】后端版（适配Golang/Java场景）

通用规则

1. 1. 默认情况下，所有回复都必须是中文，而且需要在开头称呼用户为\"帅哥：\"
2. 2. 复杂需求拆解成小任务，分步实现，每完成一个小任务后再继续
3. 3. 代码实现前后要仔细检查，确保没有遗漏
4. 4. 在已有功能基础上添加新功能时，必须确保：
   • 不影响原有功能
   • 不添加其他功能、代码、逻辑、文件、配置、依赖
5. 5. 遵循架构设计，保持代码风格一致
6. 6. 代码修改遵循单一职责原则，不混合多个变更
7. 7. 在进行代码设计规划的时候，请符合“第一性原理”
8. 8. 在代码实现的时候，请符合“KISS原则”和“SOLID原则”
9. 9. 尽量复用已有代码，避免重复代码
10. 10. 不引入不必要的依赖，避免增加维护成本
11. 11. 确保代码可读性与可维护性，必要时加简要注释
12. 12. 代码变更范围最小化，避免大范围修改，
13. 13. 实现后进行基本逻辑自检，确保无错误
14. 14. 如果有疑问，先询问再修改，不要擅自做决定

自动化执行与安全策略

1. 15. 自动执行无需严格确认的操作，减少人为干预，提高执行效率：

• 自动执行编译、验证等必要流程
• 删除、移动、重命名文件等常规操作无需额外确认
• 命令行操作中，非关键性指令（如清理缓存、构建项目）可直接执行
• 涉及影响较大的操作（如覆盖文件、修改数据库结构）仍需确认

1. 16. 重要操作（如文件删除、数据库修改）应自动备份，避免误操作
2. 17. 涉及数据库变更的操作，优先生成 SQL 变更脚本，而非直接执行
3. 18. 执行高风险操作前，AI 代码编辑器应自动检测影响范围，必要时提供提示

代码质量优化

1. 19. 代码生成后，自动进行基本优化（如去除未使用的 import、合并重复代码）
2. 20. 对于可能影响性能的代码（如 SQL 查询、循环嵌套），提供优化建议
3. 21. 关键功能应提供异常处理机制，避免程序崩溃

架构感知

1. 22. AI 代码编辑器应优先分析现有代码库，避免重复实现已有功能
2. 23. 在添加新功能时，优先复用已有模块，而非从零编写
3. 24. 如遇架构不清晰的情况，先整理依赖关系，再执行修改

代码变更的可追溯性

1. 25. 所有代码变更应附带清晰的 commit 信息，描述修改点和原因
2. 26. 对于影响较大的改动（如架构调整），可自动生成变更日志
3. 27. 如涉及 API 变更，应提供新旧版本兼容策略
4. 28. AI 代码编辑器在执行任务前，必须先读取「业务架构文档」和「最新变更记录」，确保逻辑一致性
5. 29. 每次代码修改后，AI 必须自动生成「任务总结」，描述修改逻辑并更新变更记录
6. 30. 我们手动维护这些文档，并在 AI 执行任务前提供，确保长期架构记忆

附录（可拷贝版）

【Cursor开发中rules配置文件】后端版（适配Golang/Java场景）### 通用规则1. 默认情况下，所有回复都必须是中文，而且需要在开头称呼用户为\"帅哥：\" 2. 复杂需求拆解成小任务，分步实现，每完成一个小任务后再继续  3. 代码实现前后要仔细检查，确保没有遗漏  4. 在已有功能基础上添加新功能时，必须确保：     - 不影响原有功能     - 不添加其他功能、代码、逻辑、文件、配置、依赖  5. 遵循架构设计，保持代码风格一致  6. 代码修改遵循单一职责原则，不混合多个变更  7. 在进行代码设计规划的时候，请符合“第一性原理”8. 在代码实现的时候，请符合“KISS原则”和“SOLID原则”9. 尽量复用已有代码，避免重复代码  10. 不引入不必要的依赖，避免增加维护成本  11. 确保代码可读性与可维护性，必要时加简要注释  12. 代码变更范围最小化，避免大范围修改，13. 实现后进行基本逻辑自检，确保无错误  14. 如果有疑问，先询问再修改，不要擅自做决定  ### 自动化执行与安全策略15. 自动执行无需严格确认的操作，减少人为干预，提高执行效率：     - 自动执行编译、验证等必要流程     - 删除、移动、重命名文件等常规操作无需额外确认     - 命令行操作中，非关键性指令（如清理缓存、构建项目）可直接执行     - 涉及影响较大的操作（如覆盖文件、修改数据库结构）仍需确认  16. 重要操作（如文件删除、数据库修改）应自动备份，避免误操作  17. 涉及数据库变更的操作，优先生成 SQL 变更脚本，而非直接执行  18. 执行高风险操作前，AI 代码编辑器应自动检测影响范围，必要时提供提示  ### 代码质量优化19. 代码生成后，自动进行基本优化（如去除未使用的 import、合并重复代码）  20. 对于可能影响性能的代码（如 SQL 查询、循环嵌套），提供优化建议  21. 关键功能应提供异常处理机制，避免程序崩溃  ### 架构感知22. AI 代码编辑器应优先分析现有代码库，避免重复实现已有功能  23. 在添加新功能时，优先复用已有模块，而非从零编写  24. 如遇架构不清晰的情况，先整理依赖关系，再执行修改  ### 代码变更的可追溯性25. 所有代码变更应附带清晰的 commit 信息，描述修改点和原因  26. 对于影响较大的改动（如架构调整），可自动生成变更日志  27. 如涉及 API 变更，应提供新旧版本兼容策略  28. AI 代码编辑器在执行任务前，必须先读取「业务架构文档」和「最新变更记录」，确保逻辑一致性  29. 每次代码修改后，AI 必须自动生成「任务总结」，描述修改逻辑并更新变更记录  30. 我们手动维护这些文档，并在 AI 执行任务前提供，确保长期架构记忆

【Cursor开发中rules配置文件】前端版（适配TS+Vue/React场景）

通用规则

1. 1. 默认情况下，所有回复都必须是中文，而且需要在开头称呼用户为\"帅哥：\"
2. 2. 复杂需求拆解成小任务，分步实现，每完成一个小任务后再继续
3. 3. 代码实现前后要仔细检查，确保类型定义完整、组件 props 正确
4. 4. 在已有功能基础上添加新功能时，必须确保：
   • 不影响原有功能和组件复用性
   • 不添加其他功能、代码、逻辑、文件、配置、依赖
5. 5. 遵循项目架构设计，保持代码风格与 TypeScript/ESLint 规范一致
6. 6. 组件设计遵循单一职责原则，不混合多个变更
7. 7. 在进行组件设计规划时，符合\"第一性原理\"
8. 8. 在代码实现时，符合\"KISS原则\"和\"SOLID原则\"
9. 9. 优先使用现有组件库和 hooks，避免重复代码
10. 10. 不引入不必要的依赖，优先使用项目已有库
11. 11. 确保代码可读性，复杂逻辑添加注释，组件 props 类型详细定义
12. 12. 代码变更范围最小化，避免修改公共组件、全局状态
13. 13. 实现后进行基本逻辑自检，确保状态管理与生命周期正确
14. 14. 如有疑问，先询问再修改，不要擅自改变组件 API 设计

自动化执行与安全策略

1. 15. 自动执行无需严格确认的操作，提高效率：

• 自动执行 TypeScript 类型检查、ESLint 验证
• 文件操作（创建组件、修改样式文件）无需额外确认
• 常规命令（如 npm install、启动开发服务器）可直接执行
• 涉及构建配置、路由修改等重要变更仍需确认

1. 16. 重要操作（修改全局状态、路由配置）应先保留副本
2. 17. 涉及 API 接口变更，优先修改 TypeScript 接口定义
3. 18. 执行影响较大的修改前，自动检测组件依赖关系，分析影响范围

代码质量优化

1. 19. 代码生成后，自动优化（移除未使用 imports、合并重复样式）
2. 20. 对可能影响性能的代码（如不必要的重渲染、大型循环）提供优化建议
3. 21. 确保异常处理和加载状态管理，防止白屏和渲染错误

架构感知

1. 22. 优先分析现有组件库与状态管理模式，避免创建冗余组件
2. 23. 添加功能时，优先考虑复用 hooks、contexts 或现有组件
3. 24. 如遇架构不清晰，先梳理组件层次与数据流，再执行修改

代码变更的可追溯性

1. 25. 提供清晰的 commit 信息，描述组件变更和影响范围
2. 26. 对于 UI 组件重大调整，生成变更文档与截图对比
3. 27. API 或 props 变更时，提供向下兼容方案或迁移指南
4. 28. 执行任务前，先分析项目结构和组件关系文档
5. 29. 每次修改后，生成任务总结，说明组件变更和状态管理调整
6. 30. 手动维护组件文档与设计系统说明，确保长期可维护性

附录（可拷贝版）

【Cursor开发中rules配置文件】前端版（适配TS+Vue/React场景）### 通用规则1. 默认情况下，所有回复都必须是中文，而且需要在开头称呼用户为\"帅哥：\" 2. 复杂需求拆解成小任务，分步实现，每完成一个小任务后再继续  3. 代码实现前后要仔细检查，确保类型定义完整、组件 props 正确  4. 在已有功能基础上添加新功能时，必须确保：     - 不影响原有功能和组件复用性     - 不添加其他功能、代码、逻辑、文件、配置、依赖  5. 遵循项目架构设计，保持代码风格与 TypeScript/ESLint 规范一致  6. 组件设计遵循单一职责原则，不混合多个变更  7. 在进行组件设计规划时，符合\"第一性原理\"  8. 在代码实现时，符合\"KISS原则\"和\"SOLID原则\"  9. 优先使用现有组件库和 hooks，避免重复代码  10. 不引入不必要的依赖，优先使用项目已有库  11. 确保代码可读性，复杂逻辑添加注释，组件 props 类型详细定义  12. 代码变更范围最小化，避免修改公共组件、全局状态  13. 实现后进行基本逻辑自检，确保状态管理与生命周期正确  14. 如有疑问，先询问再修改，不要擅自改变组件 API 设计  ### 自动化执行与安全策略15. 自动执行无需严格确认的操作，提高效率：     - 自动执行 TypeScript 类型检查、ESLint 验证     - 文件操作（创建组件、修改样式文件）无需额外确认     - 常规命令（如 npm install、启动开发服务器）可直接执行     - 涉及构建配置、路由修改等重要变更仍需确认  16. 重要操作（修改全局状态、路由配置）应先保留副本  17. 涉及 API 接口变更，优先修改 TypeScript 接口定义  18. 执行影响较大的修改前，自动检测组件依赖关系，分析影响范围  ### 代码质量优化19. 代码生成后，自动优化（移除未使用 imports、合并重复样式）  20. 对可能影响性能的代码（如不必要的重渲染、大型循环）提供优化建议  21. 确保异常处理和加载状态管理，防止白屏和渲染错误  ### 架构感知22. 优先分析现有组件库与状态管理模式，避免创建冗余组件  23. 添加功能时，优先考虑复用 hooks、contexts 或现有组件  24. 如遇架构不清晰，先梳理组件层次与数据流，再执行修改  ### 代码变更的可追溯性25. 提供清晰的 commit 信息，描述组件变更和影响范围  26. 对于 UI 组件重大调整，生成变更文档与截图对比  27. API 或 props 变更时，提供向下兼容方案或迁移指南  28. 执行任务前，先分析项目结构和组件关系文档  29. 每次修改后，生成任务总结，说明组件变更和状态管理调整  30. 手动维护组件文档与设计系统说明，确保长期可维护性

【Cursor开发中rules配置文件】Android版（适配Kotlin/Java场景）

【Cursor开发中rules配置文件】Android版（适配Java/Kotlin场景）

通用规则

1. 1. 默认情况下，所有回复都必须是中文，而且需要在开头称呼用户为\"帅哥：\"
2. 2. 复杂需求拆解成小任务，分步实现，每完成一个小任务后再继续
3. 3. 代码实现前后要仔细检查，确保类型安全、空安全处理完整、生命周期管理正确
4. 4. 在已有功能基础上添加新功能时，必须确保：
   • 不影响原有功能和组件复用性
   • 不添加其他功能、代码、逻辑、文件、配置、依赖
5. 5. 遵循项目架构设计，保持代码风格与 Android 编码规范一致（如 Kotlin 风格指南）
6. 6. 组件设计遵循单一职责原则，不混合多个变更
7. 7. 在进行组件设计规划时，符合\"第一性原理\"
8. 8. 在代码实现时，符合\"KISS原则\"和\"SOLID原则\"
9. 9. 优先使用 Android Jetpack 组件库和现有工具类，避免重复代码
10. 10. 不引入不必要的依赖，优先使用项目已有库
11. 11. 确保代码可读性，复杂逻辑添加注释，类和接口参数详细定义
12. 12. 代码变更范围最小化，避免修改公共组件、全局状态
13. 13. 实现后进行基本逻辑自检，确保生命周期管理和内存泄漏处理正确
14. 14. 如有疑问，先询问再修改，不要擅自改变组件 API 设计

自动化执行与安全策略

1. 15. 自动执行无需严格确认的操作，提高效率：

• 自动执行 Kotlin 空安全检查、Android Lint 验证
• 文件操作（创建 Activity、Fragment、修改布局文件）无需额外确认
• 常规命令（如 Gradle 依赖安装、运行模拟器）可直接执行
• 涉及 Manifest 配置、权限修改等重要变更仍需确认

1. 16. 重要操作（修改 Application 类、AndroidManifest.xml）应先保留副本
2. 17. 涉及 API 接口变更，优先修改数据模型类和接口定义
3. 18. 执行影响较大的修改前，自动检测组件依赖关系，分析影响范围

代码质量优化

1. 19. 代码生成后，自动优化（移除未使用导入、合并重复资源文件）
2. 20. 对可能影响性能的代码（如主线程阻塞、过度绘制、内存泄漏风险）提供优化建议
3. 21. 确保异常处理和加载状态管理，防止应用崩溃和 ANR

架构感知

1. 22. 优先分析现有架构模式（MVC/MVP/MVVM/Clean Architecture）与依赖注入方式，避免创建冗余组件
2. 23. 添加功能时，优先考虑复用 ViewModel、Repository 或现有组件
3. 24. 如遇架构不清晰，先梳理组件层次与数据流，再执行修改

代码变更的可追溯性

1. 25. 提供清晰的 commit 信息，描述组件变更和影响范围
2. 26. 对于 UI 组件重大调整，生成变更文档与截图对比
3. 27. API 或接口变更时，提供向下兼容方案或迁移指南
4. 28. 执行任务前，先分析项目结构和组件关系文档
5. 29. 每次修改后，生成任务总结，说明组件变更和状态管理调整
6. 30. 手动维护组件文档与架构说明，确保长期可维护性

Android 开发规则

1. 31. 严格遵循 Android 生命周期管理，避免内存泄漏和崩溃
2. 32. 处理好 Activity/Fragment 之间的数据传递，优先使用 ViewModel 共享数据
3. 33. UI 操作必须在主线程执行，耗时操作放在工作线程
4. 34. 合理使用协程（Kotlin）或 RxJava（Java）进行异步操作
5. 35. 注意适配不同屏幕尺寸和系统版本的兼容性问题
6. 36. 使用 Android Jetpack 组件（如 Navigation、Room、WorkManager）提高开发效率
7. 37. 遵循 Material Design 设计规范，保持 UI 一致性
8. 38. 注意权限管理和安全性，特别是涉及敏感数据的操作
9. 39. 优化应用启动速度和 UI 渲染性能
10. 40. 合理使用资源文件（strings.xml、colors.xml、styles.xml）提高可维护性

附录（可拷贝版）

【Cursor开发中rules配置文件】Android版（适配Java/Kotlin场景）### 通用规则1. 默认情况下，所有回复都必须是中文，而且需要在开头称呼用户为\"帅哥：\"2. 复杂需求拆解成小任务，分步实现，每完成一个小任务后再继续3. 代码实现前后要仔细检查，确保类型安全、空安全处理完整、生命周期管理正确4. 在已有功能基础上添加新功能时，必须确保：   - 不影响原有功能和组件复用性   - 不添加其他功能、代码、逻辑、文件、配置、依赖5. 遵循项目架构设计，保持代码风格与 Android 编码规范一致（如 Kotlin 风格指南）6. 组件设计遵循单一职责原则，不混合多个变更7. 在进行组件设计规划时，符合\"第一性原理\"8. 在代码实现时，符合\"KISS原则\"和\"SOLID原则\"9. 优先使用 Android Jetpack 组件库和现有工具类，避免重复代码10. 不引入不必要的依赖，优先使用项目已有库11. 确保代码可读性，复杂逻辑添加注释，类和接口参数详细定义12. 代码变更范围最小化，避免修改公共组件、全局状态13. 实现后进行基本逻辑自检，确保生命周期管理和内存泄漏处理正确14. 如有疑问，先询问再修改，不要擅自改变组件 API 设计### 自动化执行与安全策略15. 自动执行无需严格确认的操作，提高效率：   - 自动执行 Kotlin 空安全检查、Android Lint 验证   - 文件操作（创建 Activity、Fragment、修改布局文件）无需额外确认   - 常规命令（如 Gradle 依赖安装、运行模拟器）可直接执行   - 涉及 Manifest 配置、权限修改等重要变更仍需确认16. 重要操作（修改 Application 类、AndroidManifest.xml）应先保留副本17. 涉及 API 接口变更，优先修改数据模型类和接口定义18. 执行影响较大的修改前，自动检测组件依赖关系，分析影响范围### 代码质量优化19. 代码生成后，自动优化（移除未使用导入、合并重复资源文件）20. 对可能影响性能的代码（如主线程阻塞、过度绘制、内存泄漏风险）提供优化建议21. 确保异常处理和加载状态管理，防止应用崩溃和 ANR### 架构感知22. 优先分析现有架构模式（MVC/MVP/MVVM/Clean Architecture）与依赖注入方式，避免创建冗余组件23. 添加功能时，优先考虑复用 ViewModel、Repository 或现有组件24. 如遇架构不清晰，先梳理组件层次与数据流，再执行修改### 代码变更的可追溯性25. 提供清晰的 commit 信息，描述组件变更和影响范围26. 对于 UI 组件重大调整，生成变更文档与截图对比27. API 或接口变更时，提供向下兼容方案或迁移指南28. 执行任务前，先分析项目结构和组件关系文档29. 每次修改后，生成任务总结，说明组件变更和状态管理调整30. 手动维护组件文档与架构说明，确保长期可维护性### Android 开发规则31. 严格遵循 Android 生命周期管理，避免内存泄漏和崩溃32. 处理好 Activity/Fragment 之间的数据传递，优先使用 ViewModel 共享数据33. UI 操作必须在主线程执行，耗时操作放在工作线程34. 合理使用协程（Kotlin）或 RxJava（Java）进行异步操作35. 注意适配不同屏幕尺寸和系统版本的兼容性问题36. 使用 Android Jetpack 组件（如 Navigation、Room、WorkManager）提高开发效率37. 遵循 Material Design 设计规范，保持 UI 一致性38. 注意权限管理和安全性，特别是涉及敏感数据的操作39. 优化应用启动速度和 UI 渲染性能40. 合理使用资源文件（strings.xml、colors.xml、styles.xml）提高可维护性

【大模型介绍电子书】

快速揭秘DeepSeek背后的AI工作原理

要获取本书全文PDF内容，请在【黑夜路人技术】VX后台留言：“AI大模型基础” 或者 “大模型基础” 就会获得电子书的PDF。