想请教一下各位大佬 cursor 的使用教程和 .cursorrules 的编写

在使用 cursor 写项目的时候,有没有什么技巧,可以让它更完美地达到自己想要的效果。我目前的做法就是描述的详细一些,例如写一个页面时,描述好头部和左右等布局;除了提问时描述的详细还有什么办法可以更好的使用 cursor 吗?
还有想问一下 .cursorrules 的编写方式,之前在站内看到有一个大佬上传的项目,才知道有这个文件,请问这个主要是干嘛的呢?是否类似于提示词一类的。


目前我对 .cursorrules 的理解就是,让 cursor 更好的熟悉项目结构和编程时的一些前置条件,因为我有使用站内大佬的 cursor 池,所以常常会更换账号,想问一下这些有没有什么使用的技巧,谢谢各位大佬:saluting_face:

11 Likes

帮顶,等大佬们指点

2 Likes

配置 rules(.cursorrules) – Cursor 使用文档

PatrickJS/awesome-cursorrules: :page_facing_up: A curated list of awesome .cursorrules files

可以看看这个?

11 Likes

感谢帮顶

谢谢大佬,如果使用中文对话,这些 rules 也可以直接用嘛,还是需要转换成中文

可以使用,你可以在rule中增加一条,始终用中文进行回复

1 Like

新版本建议用project rules 更准确一点,但是不好配置

1 Like

ursor应该升级最新0.46版本吗?

好的,感谢大佬

佬 这个 project rules 有相关的教程吗

Cursor – Rules for AI
这个官方文档

1 Like

好,感谢佬

我还在用 0.45.11

其实,你可以让cursor来生成自己的.cursorrules :dog:

1 Like

还能这么玩?直接和他说让他生成嘛,还是需要加一些,诸如读取整个项目目录的前缀条件

对的,开启agent,他能自己生成,但是你得把你需要的描述清楚,一般包含,项目模块结构和功能,用到的技术,参考网页或者网址–这个可以不要,有时候解析的很cao蛋,至于具体模块的内容,你可以使用composer指定进行详细的改动,如:你向他提问,你让它扮演某个角色(这个我经常用,有时候会有奇效,我经常让他扮演专业的网页UI设计师去帮我画页面),当你没灵感的时候,你就让他结合项目去提问你

官方的规则文档

ProjectRule应该跟着项目走,没有很高的通用性,你可以看一下我使用的全局规则

3 Likes

有个网站的可以参考,内容挺多的

2 Likes

分析个转载的Cursor项目开发推荐工作流,在cursor论坛上看到的(地址):

Cursor 最佳实践使用流程:产品需求文档(PRD)和请求意见稿(RFC)方法

  1. 创建产品需求文档(PRD)

    首先,创建一个清晰的产品需求文档,其中概述:

    • 您的应用程序的功能
    • 所需的技术
    • 设计模式
    • 技术规范
  2. 建立 Cursor 规则

    创建一组规则,让 Cursor 在处理您的代码时遵循:

    • 编码标准
    • 文件/文件夹结构约定
    • 命名约定
    • 架构原则
  3. 创建功能文档

    将您的应用程序分解为独立的功能,并为每个功能提供明确的规范。

  4. 为各个功能生成请求意见稿(RFC)

    对于您要实现的每个功能或更改,创建一个请求意见稿(RFC)文档,其中包括:

    • 技术设计
    • 所需的端点/函数
    • 数据模型
    • 数据库模式更改
    • 安全注意事项
    • 依赖项
  5. 一次实现一个功能

    不要让 Cursor 一次性理解和修改您的整个代码库,而是让它一次只实现或修改一个特定的请求意见稿(RFC)。

为什么这种方法更有效

该脚本的关键见解是,通过将您的项目分解为更小的、文档完善的块,您可以为 Cursor 提供更清晰的上下文,防止它在整个代码库的复杂性中迷失方向。每个请求意见稿(RFC)都为特定任务提供了重点指导,而无需 Cursor 一次性理解整个系统。

示例提示模式

基于此请求意见稿(RFC)文档:

[在此处插入您的请求意见稿(RFC)详细信息]

请在我的代码库中实现/修改以下特定功能:

[准确描述需要更改的内容]

以下是相关文件:

[仅包含此特定更改所需的代码文件]

这种方法在明确的边界内指导 Cursor 的工作,显著降低了它产生幻觉或对您的代码进行不必要更改的可能性。

英文原版

Using PRD and RFC Approach with Cursor

The approach demonstrated in the Turkish YouTube transcript is quite powerful for working with large codebases. Here’s how you can implement it:

1. Create a PRD Document

Start by creating a clear product requirements document that outlines:

  • What your application does
  • Required technologies
  • Design patterns
  • Technical specifications

2. Establish Cursor Rules

Create a set of rules for Cursor to follow when working with your code:

  • Coding standards
  • File/folder structure conventions
  • Naming conventions
  • Architecture principles

3. Create a Features Document

Break down your application into discrete features with clear specifications for each.

4. Generate RFCs for Individual Features

For each feature or change you want to implement, create an RFC document that includes:

  • Technical design
  • Required endpoints/functions
  • Data models
  • Database schema changes
  • Security considerations
  • Dependencies

5. Implementation One at a Time

Instead of asking Cursor to understand and modify your entire codebase at once, ask it to implement or modify just one specific RFC at a time.

Why This Works Better

The key insight from the transcript is that by breaking down your project into smaller, well-documented chunks, you give Cursor a clearer context that prevents it from getting lost in the complexity of your entire codebase. Each RFC provides focused guidance for a specific task without requiring Cursor to understand the entire system at once.

Example Prompt Pattern

Based on this RFC document:
[Insert your RFC details here]

Please implement/modify the following specific feature in my codebase:
[Describe exactly what needs to be changed]

Here are the relevant files:
[Include only the necessary code files for this specific change]

This approach guides Cursor’s work within clear boundaries, significantly reducing the chance of it hallucinating or making unwanted changes to your code.

5 Likes

了解,感谢大佬