Introduction

Hi, I’m Hui Ge, an independent developer dedicated to using AI technology for side projects. As a heavy user of Cursor, I can confidently say that modern development is centered around Cursor programming.

After completing several projects with Cursor, I’ve summarized some insights and experiences to share with everyone, hoping to provide new perspectives.

Rules

In Cursor, Rules refer to the custom configurations or behavioral rules of the code editor, typically used to control code style, formatting, static analysis, or constraints during AI code generation. Specifically, Rules can involve code formatting guidelines, constraints for AI-generated code, and project-specific standards.

Currently, all large models have a context length limitation, especially in multi-turn dialogue scenarios. For the same functionality, Cursor may provide different implementation solutions. Therefore, I believe that the inability to ensure code consistency in our project development is unacceptable.

How to Create Rules from Scratch

If the project is starting from scratch, let Cursor (using claude-3.7-sonnet-thinking) help generate an initial Rules file.

A simple prompt is sufficient: “I want to develop a backend project with a separated frontend and backend using Java. Please help me generate a Rules file in Markdown format for Cursor that allows our backend project to follow modern standards and processes as completely as possible.”

The result generated 12 major rules that are generally usable. If you have a programming background, it’s best to supplement it with your familiar tech stack for easier future maintenance.

com.company.project
    ├── config        # Configuration classes
    ├── controller    # Controllers
    ├── service       # Service interfaces
    │   └── impl      # Service implementations
    ├── repository    # Data access interfaces
    │   └── impl      # Data access implementations (if needed)
    ├── model         # Data models
    │   ├── entity    # Database entities
    │   ├── dto       # Data transfer objects
    │   ├── vo        # View objects
    │   └── enums     # Enum types
    ├── util          # Utility classes
    ├── exception     # Custom exceptions
    ├── constant      # Constant definitions
    └── aspect        # Aspect classes

How to Maintain Rules

Next, we let Cursor initialize the project based on the above Rules. We ask it to generate an accessible demo application. After testing the demo functionality, we can formally start developing project features.

Then, we let Cursor implement the first module of the project. The functionality doesn’t need to be overly complex, but the process should be complete. Once the implementation is done, we ask Cursor to reflect and provide optimization suggestions, considering code standards and implementation processes, to enhance our first module’s code.

After completing the first feature, we let Cursor iteratively update our Rules file content: “Based on the currently implemented xx feature module, summarize the code standards and implementation processes, and add them to our xxx Rules file as constraints for future module implementations.”

Thus, subsequent features can be developed based on this Rules file, ensuring consistency across all code.

Overall, we should leverage Cursor’s capabilities to help maintain the content of the Rules file.

Frontend and Backend Development Process

Currently, a common practice for projects is to separate the frontend and backend. Finding ways for Cursor to efficiently assist us in implementing frontend and backend functionalities is another headache. After trying various methods, I’ve summarized a workable approach.

Open both the frontend and backend projects in the same workspace for easier interaction during development.

For feature development, we first let Cursor implement the complete frontend functionality, but for the API calls, we require the use of mock data. This allows us to focus on developing and debugging the frontend functionality.

Once the page functionality is complete, we can focus on backend development. First, we utilize the mock data structure from the frontend project to generate our backend data models, directly recommending the use of MySQL MCP to help manage database creation. Using these model data, we can implement some template management functionalities on the backend.

Finally, we add the API call files involved in the frontend project to the context, along with the directory of our backend API entry points. Then we let Cursor implement the backend API development based on the frontend API calls, modifying or adding backend functionalities to complete the integration of our frontend and backend projects.

Conclusion

In summary, we can start with general rules to guide the beginning of our project. As the project iterates and upgrades, we should spend more time maintaining the Rules, making them specific to our current project.

The significance of tools lies in liberating our creativity. We hope that as the Rules improve, the need for manual modifications during subsequent feature development will decrease. This way, we can focus more on thinking and innovation.