嗨，我是辉哥，一个致力于使用AI技术搞副业的超级个体

作为一个独立开发者，我一直以来都是Cursor 的重度使用者，毫不夸张的说，现在的开发方式就是面向 Cursor 编程

在我借助 Cursor开发完成十几个项目后，也总结了一些使用心得，在这里也分享给大家，希望能带来一些新的思路

Rules 规则

首在 Cursor 中，Rules（规则）是指代码编辑器的自定义配置或行为规则，通常用于控制代码风格、格式化、静态分析或 AI 生成代码时的约束条件。具体来说，Rules 可以涉及代码格式化规则、AI 生成代码的约束、项目特定的规范

现阶段不管是什么大模型都会有一个上下文长度的限制，特别是对于我们这种多轮对话的场景，对于同一个功能，Cursor 给出的实现可能就会是不同的方案。所以，对于我们的项目开发，无法保证代码的一致性我认为是不可接受的

如何从零创建一个 Rules

如果项目是从0到1，那么请让 Cursor（使用
claude-3.7-sonnet-thinking）帮我们生成一个初版的 Rules

不需要太复杂的提示词：我现在想开发一个前后端分离的后端项目，请使用 java 语言，项目从零开始开发，请帮我生成一个 Cursor 中的 Rules 规则文件（markdown 格式），能够让我们的后端项目按照现代化规范流程进行功能实现，请尽可能的完整

结果生成了12个大的规则，基本可用，如果你有编程基础，最好将自己熟悉的技术栈补充进去，便于后续维护

  com.company.project
    ├── config        # 配置类
    ├── controller    # 控制器
    ├── service       # 服务接口
    │   └── impl      # 服务实现
    ├── repository    # 数据访问接口
    │   └── impl      # 数据访问实现（如需）
    ├── model         # 数据模型
    │   ├── entity    # 数据库实体
    │   ├── dto       # 数据传输对象
    │   ├── vo        # 视图对象
    │   └── enums     # 枚举类型
    ├── util          # 工具类
    ├── exception     # 自定义异常
    ├── constant      # 常量定义
    └── aspect        # 切面类

如何维护 Rules

现在，我们让 Cursor 根据上述的 Rules 规则，来完成项目的初始化搭建，让其帮我们生成一个可以访问的 demo 应用。测试 demo 功能可用后正式开始项目功能的开发

随后，我们让 Cursor实现项目的第一个模块，功能不用太复杂，但是涉及的流程完整即可。在功能实现完成后，让 Cursor 进行反思和思考，让其给出优化和建议，可以从代码规范和实现流程方面考虑，让其优化我们的第一个模块代码

等第一个功能完成后，让 Cursor 迭代更新我们的 Rules 文件内容：请基于当前实现好的 xx 功能模块，进行代码规范和实现流程的总结，补充到我们的 xxx 规则文件中，作为后续其他模块实现的规范约束

至此，后续我们其他模块功能的开发，都可以基于这一份 Rules 规则文件来实现，让我们所以代码保持一致

总的来说，我们应该善于让 Cursor自身的能力帮我们来维护 Rules 文件的内容

前后端开发的流程

现在一个项目通过前后端分离是比较通用的做法，那么如何让 Cursor 高效的帮我们实现前后端项目的功能，也是另一个头疼的问题，在我尝试很多方法后，总结出了一套可行的方法

在一个 workspace 中同时打开我们的前后端两个项目，便于后续需要的交互开发

然后对于功能的开发，我们先让 Cursor 帮我们实现完整的前端功能，但是对于接口的调用部分，我们要求使用 mock 数据返回，这样我们可以专注于前端功能页面的开发与调试

等到页面功能完成后，我们可以专注于后端的开发。首先利用前端项目中 mock 的数据结构，生成我们后端数据的模型，直接推荐使用 mysql mcp 自动帮我们管理数据库的创建。然后利用这些模型数据，我们可以实现后端的一些模板管理功能

最后，将前端项目中涉及到的一些 api 调用文件添加到上下文中，然后将我们后端的接口入口目录也添加到上下文。然后让 Cursor 依据前端的接口调用，实现与后端接口的对接开发，修改或者新增后端的接口功能，这样就能完成我们前后端项目的联动开发

总结

总的来说，我们可以先使用比较通用的规则来约束我们项目的开始。随着项目的迭代升级，应该花更多的时间来维护这个 Rules 规则，让其成为适用于我们当前项目的特定规则。

工具的意义在于解放我们的创造力。我们希望实现的效果应该是，随着 Rules 的完善，对于项目后续的功能开发，需要我们人工参与修改的次数应该越来越低。这样，我们才能有更多的精力专注于思考与创新