一、常用快捷键:
- ctrl shift p / 命令面板
二、cursor使用原则:
# Cursor官方下场谈Cursor正确用法,以及我的实践解读# 深度解读Cursor首席设计师12条黄金法则,让Cursor写出高质量代码,丝滑到起飞!
“结构和控制是胜利之道(目前如此)。将 Cursor 代理视为一位强大的初级员工——如果你指明方向,它能够快速走得很远。” ------Ryo Lu “AI编程的终极形态,是让人类专注于战略,而AI执行战术。”
1. 在一开始就设定 5-10 条清晰的让 Cursor 了解你的结构和约束。尝试为现有代码库执行/generate rules.
- 使用 project rules,在.cursor目录下维护一组项目rules
- 通用规则,变成语言规则,框架规则
- 全新项目:
- 先创建脚手架,
- 然后创建通用规则,如项目结构,主要模块、目录说明等
- 老项目:采用自动生成rules功能 ; Agent模式下,执行“generate rules”
2. 提示词要具体。详细说明技术栈、行为和约束,可以认为是个需求文档,也是个具体的rules
***例子:
模糊提示: “写一个登录功能。”
精准提示: “用React+TypeScript实现OAuth2.0登录组件,禁止使用任何第三方库,按钮需兼容暗黑模式。”
***在对话上下文中,用自己的专业知识,限定工具的输出。
请帮我开发一个“图片转png”Chrome浏览器插件,这个插件的功能是:
1、开启插件后,用户在浏览器图片鼠标右键后会出现插件入口"下载为png",点击就可以把选中的任意格式的图片下载为png格式的图片;
2、支持下载为png的图片格式包括JPG、JPEG、PNG、BMP、webp、svg;
3、使用OffscreenCanvas避免阻塞主线程;
4、通过Blob URL减少内存占用。
- 每次对话,其实就是个rules,在.cursor目录中项目总体rules规范下的业务规范
- 开发过程中的对话怎么做,参考以下内容:
- ***A) 代码生成(全新生成)
用{编程语言}开发{产品/功能},
要求:
1、{功能要点1}
2、{功能要点2}
3、{功能要点3}
风格:参考{某种设计风格/项目中已有的文件路径}(非必需
我要开发一个{产品主题/名称}的{产品形态},
这个产品的功能是:
1、{功能要点1}
2、{功能要点2}
3、{功能要点3}风格:参考{某种设计风格/项目中已有的文件路径}
我要开发一个{产品主题/名称}的{产品形态},
这个产品的功能是:
1、{功能要点1}
2、{功能要点2}
3、{功能要点3}
风格:参考{某种设计风格/项目中已有的文件路径}
API调用说明:
1、调用{产品}的{功能}API;
2、对应API key:{你的实际API key};
3、API调用示例:------{对应的API调用示例}
- B) 代码生成(新增代码)
基于 @{项目中的具体文件} / 现有代码:{粘贴现有代码}
添加{新功能描述}功能,
需要与现有代码风格保持一致,同时保持其它功能不变。
cursor新版本废弃了 Codebase, 会自动根据上下文搜索全文,也可以增加如下话术: “基于/搜索代码库”
- C) UI调整
我想将{模块A}的UI调整为:
1、{UI调整点1}
2、{UI调整点2}
具体可以参考:{截图}/{mermaid图表}/{代码示例}/{项目中已有的文件路径}
整体功能架构保持不变
- D) 代码理解及注释
解释以下代码的功能和工作原理:
{粘贴需要解释的代码}
主要关注(提醒作用---例如提示是算法解释等):
- {关注点1}
- {关注点2}
项目总体理解
梳理这个项目的所有功能,并详细描述各个功能在页面上的表现,以及各个页面组件的交互逻辑,让一个非技术人员的用户能理解这个项目
- E) 代码重构
@{文件或粘贴需要重构的代码}重构代码,以提高其{性能/可读性/可维护性}:
重点改进:
1. {改进点1}
2. {改进点2}
但保持原有功能架构不变`
- F) 代码调试和修复
{项目内的具体文件/代码片段/终端指令}出现报错,
日志信息:{粘贴日志信息}
请帮我修复这个问题,并指导后续的项目推进步骤
- G) 生成测试用例
请搜索代码库,生成该项目的测试用例,
尽可能详细,让非测试人员也能看懂并执行测试。
3. 按文件逐个工作;在小块、集中的部分生成、测试和审查。
- 项目做好结构拆分,变更,尽量在小范围内进行。
- 文件级别迭代,小步快跑
- 每个文件独立生成、测试、审核,避免全局失控
- 审核代码,测试通过后没问题,及时commit
4. 测试驱动开发(TDD/ATDD),先写测试,锁定它们,然后生成代码,直到所有测试通过
- 测试驱动开发
- 人工编写测试用例(单元,系统测试)
- 让cursor生成代码,直到测试通过
- 如果失败,让AI修改调整
- 下一个功能迭代
- 老代码变更前,可以先生成测试用例,然后再变更代码
- 与.gitignore类似, cursor也可以指定忽略文件/文件夹
- 可以在不同文件夹维护.cursorignore
- 配置Cursor Settings / Features / Hierachical Cursor Ignore
- 可以指定测试用例不能变更,这样重构代码,就可以跑老的测试用例
5. 总是审查 AI 输出,并对任何错误的内容进行硬修复,然后告诉 Cursor 将其作为示例使用。
- 手动修改AI代码后,用@fixed 标记代码,并说明原因,这相当于在训练AI
- 案例:AI生成的API接口漏了鉴权,手动补全后,在代码中增加描述提示:“以后所有接口需包含JWT验证头”。
- 如果生成代码和自己预期不符合,可以考虑用rules进行约束,例如如果有公司的企业代码规范,可以做为一个rules放到.cursor目录下,这样就会按规范生成代码
6. 与规则3类似,缩小范围,使用@file、@folder、@git,将 Cursor 的关注点定位到代码库的正确部分
命令:
@src/components
:限定修改范围;@git#main
:对比分支差异,避免误改。
场景: 修复Bug时,用@file:utils.js
锁定文件,防止AI“顺带”修改无关代码。
7. 将设计文档和检查清单保存在 .cursor/ 中,以便 Agent 能够全面了解下一步要做什么。
- rules 文件是重要的当前项目指南和规格。
- 在`.cursor/docs`存放架构图、接口文档;
- 约定成俗,项目根目录下的README.md也是重要的规则文件
- 更新代码时,同步更新文档,确保文档代码一致
8. 如果代码错误,就自己写。Cursor 从编辑中学习比从解释中学习更快。
- cursor工具在特定问题上写不好,那么需要手动写入代码
- 手动写入代码会让cursor从中学习,并做为范例
9. 使用聊天历史来迭代旧的提示,而不需要从头开始。
- /history 调取历史记录,迭代以前的提示词
- 对高频问题,如代码风格等,保存为模板,rules,
10, 有意选择模型。Gemini 用于精确,Claude 用于广度。
- 不能使用一个模型,模型各有优缺点
- Claude 3.7:深度思考,善于使用工具,比较宽泛, 适合做规划
- Claude 3.5:编码,确定性的编码任务
- Gemini: 高难度,例如算法----该模型,目前是编程最强的(5月9日), claude搞不定,切换到该模型
- 如果调试复杂问题,可以切换到Gemini
11, 在新的或不熟悉的技术栈中,粘贴文档链接。让 Cursor 逐行解释所有错误和修复
- https://context7.com/ 一些公共库的最新文档链接地址,速查手册
- cursor 工具中, 选中代码 @最新库文档, 更新到最新库
- MCP工具, Context7 MCP, 可在对话中直接使用“: 新的 Next.js after() 函数是如何工作的?使用 context7】
- 示例: “@https://xxxx/docs 请解释useEffect依赖项未更新的问题”。
12, 大型项目,随时更新index,并限制上下文,保持敏捷
- 注意,创建索引,需要保证 .cursorignore 设置正确,减少索引量
- 晚上同步代码后,进行索引,以避免高峰期抢占资源
- @scope:core 限定AI仅关注核心模块,避免资源
二、 rules
1. rules概述
为了让cursor更好的利用AI大模型,减少大模型幻觉,cursor工具针对项目可设置很多约束,来让AI输出确定性的结果
- 分类
- Rules for AI : 全局生效
- project rules:当前项目有效
- 本项目下的 .cursor/rules目录
- 可以认为是老的.cursorrules文件的细化(可拆分为多个文件)
- 例如一个项目前后端在一个目录,可分别提供一个java后端rules,前端js的rules
- 规范类型:(每次规则都会有不同级别的上下文,所以需要选择合适的类型)
- Auto Attach类型: 指定特定的文件类型,例如: .py, 该rule自动应用在python文件
- Always: 每次聊天和agent命令,都会用到的规则
- Agent Request:agent自动判断,调用某种类型rules
- Manual: @手动包含在上下文中
- mdc文件,可以引用其他mdc文件: @other.mdc @build.gradle
- .cursorrules: 当前项目有效,文件 .cursorrules。
- 老的模式,以后可以去掉(现在可以勾选,兼容老项目)
- 主要是所有规则在一个文件中,控制不够深入
- rules官方参考资源:
- Awesome CursorRules
- 该项目包含很多语言的实际rules
- 注意该项目rules-new目录包含clencode等通用rules
- java有以下rules:
- java-general-purpose rules
- java语言开发通用规则
- java-springboot-jpa rules
- controller, REPO等spring通用规则
- java-general-purpose rules
- 维护项目rules:
- 项目复杂,可以分多个文件,在.cursor目录下维护rules
- 项目简单,可只维护README.md , 该文件描述整个项目的情况,包括但不限于(功能列表,目录/文件说明,重要流程等,rules的描述)
- 项目可以要求cursor生成README.md(例如提示词: 如没有README.md,则创建该文档。如果有该文档,分析整个项目代码,优化补充该文档)
- rules 编写指南:
![[Pasted image 20250506215225.png]] - 团队/公司规范:针对公司的规范,例如内部库使用规范,代码规范等 - 项目规范: - 领域规范:例如金融,医疗,游戏等特殊领域 - 合规性规范,例如GDPR, HIPAA, PCI DSS等
- 编写指南-通用规范:
- 通用规范及示例
- 常用project rules示例
- 通用规范示例
- 常见语言示例
- 常用project rules示例
- 根据推荐指南,以及前述 各种推荐的rules编写例子。总结出内部的rules
- 通用规范及示例
参考文档 通用规范.txt
[[public/通用规范.txt]] [[租房流程]]
2. 自行编写rules的一种推荐方法
- rules编写大纲
# 1,角色
--- 让AI成为目标工程师,解决特定领域的问题。
# 2,目标
--- 给ai来下达定性目标:可以认为自己是CEO,给AI工程师下达明确的工作任务。
# 3,要求
--- 为了达到目标,给AI工程师拆解需求的具体要求和约束,以下子目录为参考内容(可扩充)
## 3.1 项目初始化
--- ai接手项目前,先要让它看历史文档熟悉项目。(例如指导他阅读readme, UE/UI交互稿等),如果没有,则让AI根据项目进行整理工作,创建一个readmme
## 3.2 需求理解
--- 如果用户无法将需求描述清楚,指示AI进行需求理解,并给出参考方案(产品等)。
## 3.3 UI和样式设计
---- 如果存在交互,可列出UE,UI交互的要求。
## 3.4 代码编写
- 技术选型:
- 要求1
- 要求2
- 代码结构: (强调代码的清晰性、模块化、可维护性,遵循最佳实践,比如其中提到的DRY 原则,全称是Don't Repeat Yourself,就是让cursor避免三种代码重复情况,分别是实现逻辑重复、功能语义重复和代码执行重复。这一点在cursor中经常出现,很容易造成代码冗余和错误。)
- 代码安全性:
- 性能优化:
- 测试与文档:(强调提供清晰的中文注释和文档,如用中文注释清楚哪个模块对应什么效果或能力,方便后续阅读和维护。)
## 3.5 问题解决
--- 问题解决的步骤
## 3.6 迭代优化
--- 每次迭代的要求,例如要求更新readme,确保文档和代码同步。
## 3.7 方法论
- 系统思维:
- 思维树:
- 迭代改进:
- 万能提示词:
- 根据前面的大纲,总结出一个模板
- 使用deeepseek等AI工具,增加限定语,生成一份rules
- 可以在被生成的rules基础上,再丢给cursor,重新生成一份(例如deepseek选择深度思考, cursor,选择Claude-3.5-sonnet(这个模型,比3.7更具广度)
- 万能提示词:请参考下面这份模板,给我写一份用于开发java应用的合格的cursorrules文档,这份模板中的 (X) 是占位符,你需要补充相关的信息和技术栈和其它可能需要的信息,文档以markdown格式输出
- 模板如下:
# 1 角色
你是一名精通(X)开发的高级工程师,拥有10年以上的 应用开发经验,熟悉(X)等开发工具和技术栈。你的任务是帮助用户设计和开发易用且易于维护的应用。始终遵循最佳实践,并坚持干净代码和健壮架构的原则。
# 2 目标
你的目标是以用户容易理解的方式帮助他们完成应用的设计和开发工作,确保应用功能完善、性能优异、用户体验良好。
# 3 要求
在理解用户需求、设计UI、编写代码、解决问题和项目迭代优化时,你应该始终遵循以下原则:
## 3.1 项目初始化
- 在项目开始时,首先仔细阅读项目目录下的README.md文件并理解其内容,包括项目的目标、功能架构、技术栈和开发计划,确保对项目的整体架构和实现方式有清晰的认识;
- 如果还没有README.md文件,请主动创建一个,用于后续记录该应用的功能模块、页面结构、数据流、依赖库等信息。
## 3.2 需求理解
- 充分理解用户需求,站在用户角度思考,分析需求是否存在缺漏,并与用户讨论完善需求;
- 选择最简单的解决方案来满足用户需求,避免过度设计。
## 3.3 UI和样式设计
- 如果项目需要用户交互,则使用现代UI框架进行样式设计(例如 (X),这里可以根据不同开发项目仔细展开,比如使用哪些视觉规范或者UI框架,没有的话也可以不用过多展开);
- 在不同平台上实现一致的设计和响应式模式
## 3.4 代码编写
- 技术选型:根据项目需求选择合适的技术栈(例如(X),这里需要仔细展开,比如介绍某个技术栈用在什么地方,以及要遵循什么最佳实践)
- 代码结构:强调代码的清晰性、模块化、可维护性,遵循最佳实践(如DRY原则、最小权限原则、响应式设计等)
- 代码安全性:在编写代码时,始终考虑安全性,避免引入漏洞,确保用户输入的安全处理
- 性能优化:优化代码的性能,减少资源占用,提升加载速度,确保项目的高效运行
- 测试与文档:编写单元测试,确保代码的健壮性,并提供清晰的中文注释和文档,方便后续阅读和维护
## 3.5 问题解决
- 全面阅读相关代码,理解(X)应用的工作原理
- 根据用户的反馈分析问题的原因,提出解决问题的思路
- 确保每次代码变更不会破坏现有功能,且尽可能保持最小的改动
## 3.6 迭代优化
- 与用户保持密切沟通,根据反馈调整功能和设计,确保应用符合用户需求
- 在不确定需求时,主动询问用户以澄清需求或技术细节
- 每次迭代都需要考虑更新README.md文件,包括功能说明和优化建议,以便文档和代码保持一致
## 3.7 方法论
- 系统思维:以分析严谨的方式解决问题。将需求分解为更小、可管理的部分,并在实施前仔细考虑每一步
- 思维树:评估多种可能的解决方案及其后果。使用结构化的方法探索不同的路径,并选择最优的解决方案
- 迭代改进:在最终确定代码之前,考虑改进、边缘情况和优化。通过潜在增强的迭代,确保最终解决方案是健壮的
代码编写部分, 可使用参考前述的 Awesome CursorRules
cursor插件, cursor rules, 可以自动编写rules
- 也可以对现有老项目在agent模式下,自动生成rules
3. rules案例
- 3.1 案例chrome插件开发:
# 角色
你是一名精通 **Chrome浏览器插件开发** 的高级工程师,拥有10年以上的 **浏览器扩展** 开发经验,熟悉 **JavaScript、HTML、CSS、Chrome Extensions API、Webpack、React** 等开发工具和技术栈。你的任务是帮助用户设计和开发易用且易于维护的 **Chrome浏览器插件**。始终遵循最佳实践,并坚持干净代码和健壮架构的原则。
# 目标
你的目标是以用户容易理解的方式帮助他们完成 **Chrome浏览器插件** 的设计和开发工作,确保应用功能完善、性能优异、用户体验良好。
# 要求
在理解用户需求、设计UI、编写代码、解决问题和项目迭代优化时,你应该始终遵循以下原则:
## 项目初始化
- 在项目开始时,首先仔细阅读项目目录下的 README.md文件并理解其内容,包括项目的目标、功能架构、技术栈和开发计划,确保对项目的整体架构和实现方式有清晰的认识;
- 如果还没有README.md文件,请主动创建一个,用于后续记录该应用的功能模块、页面结构、数据流、依赖库等信息。
## 需求理解
- 充分理解用户需求,站在用户角度思考,分析需求是否存在缺漏,并与用户讨论完善需求;
- 选择最简单的解决方案来满足用户需求,避免过度设计。
## UI和样式设计
- 使用现代UI框架进行样式设计(例如 **React** 或 **Vue.js**,遵循 **Material Design** 或 **Chrome扩展设计规范**);
- 在不同平台上实现一致的设计和响应式模式
## 代码编写
- 技术选型:根据项目需求选择合适的技术栈(例如 **JavaScript** 用于主要开发语言,**HTML** 用于构建页面结构,**CSS** 用于样式设计,**Chrome Extensions API** 用于浏览器扩展功能,**Webpack** 用于模块打包)
- **JavaScript**:用于主要开发语言,遵循面向对象编程原则,确保代码结构清晰。
- **HTML**:用于构建页面结构,遵循语义化标签原则,确保页面结构清晰。
- **CSS**:用于样式设计,遵循模块化样式原则,确保样式易于维护。
- **Chrome Extensions API**:用于浏览器扩展功能,遵循Chrome扩展开发规范,确保功能实现符合浏览器要求。
- **Webpack**:用于模块打包,遵循模块化开发原则,确保代码结构清晰且易于维护。
- 代码结构:强调代码的清晰性、模块化、可维护性,遵循最佳实践(如DRY原则、最小权限原则、响应式设计等)
- 代码安全性:在编写代码时,始终考虑安全性,避免引入漏洞,确保用户输入的安全处理
- 性能优化:优化代码的性能,减少资源占用,提升加载速度,确保项目的高效运行
- 测试与文档:编写单元测试,确保代码的健壮性,并提供清晰的中文注释和文档,方便后续阅读和维护
## 问题解决
- 全面阅读相关代码,理解 **Chrome浏览器插件** 的工作原理
- 根据用户的反馈分析问题的原因,提出解决问题的思路
- 确保每次代码变更不会破坏现有功能,且尽可能保持最小的改动
## 迭代优化
- 与用户保持密切沟通,根据反馈调整功能和设计,确保应用符合用户需求
- 在不确定需求时,主动询问用户以澄清需求或技术细节
- 每次迭代都需要更新README.md文件,包括功能说明和优化建议
## 方法论
- 系统思维:以分析严谨的方式解决问题。将需求分解为更小、可管理的部分,并在实施前仔细考虑每一步
- 思维树:评估多种可能的解决方案及其后果。使用结构化的方法探索不同的路径,并选择最优的解决方案
- 迭代改进:在最终确定代码之前,考虑改进、边缘情况和优化。通过潜在增强的迭代,确保最终解决方案是健壮的
二、对话模式&大模型选择
1. 最新对话模式
- agent: 可以执行命令(为了安全,需要关闭自动执行,即需要人工确认)
- 该模式,可以集成MCP扩展能力
- ASK: 对话模式,不执行
2.
三、MCP扩展能力
四、cursor开发流程(需求产品,测试,开发,测试、迭代)
新老项目,均需先生成index文件再操作
1. 全新项目
- 和cursor对话,提出业务需求,确定技术栈。(要求先别出代码,只讨论技术栈)
- 确定了技术栈,可以指定通用规范,以及技术栈相关的rules(参考上面的rules相关章节)
- 注意rules的几种类型
- Alays,cursor始终调用
- Agent requested,agent调用
- 注意rules的几种类型
2. 老项目
- 2.1 分析现有项目,整理出整个项目的编程语言和框架
- 提示词: 遍历整个项目,分析这个项目使用的编程语言和框架,如果没有README.md,请创建。
- 请分别针对前端,后端生成规则文件 /Generate Cursor Rules
- 提示词: 遍历整个项目,分析这个项目使用的编程语言和框架,如果没有README.md,请创建。
- 2.2 分析出技术栈后,自动生成project rules。
- 自动生成后,可以按上述模板进行检查,并补充
- 创建项目概览规则
- 自动生成后,可以按上述模板进行检查,并补充
创建前端的项目概览规则,包括但不限于 文档目录结构,功能说明等,这里有个范例:将前述”通用规范.txt“内容填入
- ***创建API结构规则***
创建API结构规则
- ***创建服务器和配置规则***
- ***创建代码风格和约定规则***
继续生成服务入口规则文件
- ***创建部署指南***
继续生成服务入口规则文件
- ***创建服务入口文件***
继续生成服务入口规则文件
前述为前端的rules生成规则,可按如下提示,生成发后端的规则文件
按照上述步骤和规则,生成后端的规则文件
但生成的比较简单,还需要按前述方式,重新生成规则文件, 例如:
继续创建后端的api结构规则文件, 请将你生成的api结构规则内容,直接覆盖规则文件
- 使用时,如果时manual类型规则,则可以 @file @代码规则.mdc 来指定规则
3. 开发循环:
- 需求拆分,拆成小功能
- TDD, ATTD循环
- 参考前述测试部分说明
四、功能细分,确保cursor工具正常使用
五、参考:
- cursor教程 | 如何根据不同项目写好一份合格的cursorrules?
- ***# 深度解读Cursor首席设计师12条黄金法则,让Cursor写出高质量代码,丝滑到起飞!
- # Cursor官方下场谈Cursor正确用法,以及我的实践解读
- Project Rules在实际开发中的三种层级&实际应用(附20个常用Rules