Cursor is getting harder and harder to use! It forces me to write more mdc documents than code
New challenges of Cursor and solutions of .mdc files.
Core content:
1. Problems and challenges caused by the decline of Cursor intelligence
2. Introduction to .mdc files and their role in coding
3. Creation, application and example display of .mdc files
Cursor is becoming more and more difficult to use, especially since version 0.45, its intelligence has visibly declined and it has become more and more Trae-like.
During this period of time, I found that the context of Cursor was getting shorter and shorter, and files were modified randomly from time to time . A simple problem could take a long time to solve, and the solution to the error message was clearly provided but it was not solved.
The most outrageous thing is that I turned on the MCP function, and every time I edited a file, it would call the MPC's write file function. I even removed the configuration file, but it was still calling MCP's rite_file.
Alas, how smart you were before, how stupid you are now!
The funniest thing is that the official itself hasn’t figured out whether it is Edit or Agent , and now they suddenly changed the name and added a Manual function that I don’t know what it is.
I couldn't do anything about it, so I had to create a file locally and teach it how to write it step by step. As a result, there are more .mdc documents than code . It's OK to use it, which can be regarded as a partial relief for the current inaction of Cursor.
Let me briefly introduce this new Cursor-specific .mdc file.
.mdc (Markdown Cursor) file is the Cursor rule file format, which is itself Markdown syntax, but is specifically used to define the behavior, constraints, and context of AI when coding.
You can think of it as a "memo" to your AI assistant, telling it what rules it should follow and what to do in your project.
In addition, the old version of .cursorrules will soon be abandoned, mainly because it is too single. The advantages of the new proprietary .mdc are:
- You can create specialized rule files for different types of files or tasks.
- AI will automatically select applicable rules based on the file you are editing
- Based on Markdown, writing is more natural and smooth
After using the .mdc file, the quality of the code modified by the AI assistant has improved. Everything has been fed to it, and if it can't write anymore, it can only curse . In addition, this document makes it easier for the company's team to collaborate. There is no need to repeatedly tell the AI the same project specifications, and subsequent projects can be easily migrated to it.
It is a perfect match with the most powerful programming model on earth: Google Gemini 2.5 Pro ultra-long context.
Writing this file is actually very simple. A typical .mdc file contains two parts:
- Prefix metadata : Wrapped in three dashes (---), defines the description and scope of application of the rule
- Rule body : Use Markdown format to write specific instructions
When creating and using .mdc files, the main thing to remember is its location:
- Create in the project root directory
.cursor/rules/Folders - Add to
.mdcFiles such asts-rules.mdcAfter saving, Cursor will automatically apply the rules
Take a look at this simple example:
--- description: TypeScript project specification globs: *.ts, *.tsx --- # TypeScript coding standards - Use strict mode (strict: true) - Prefer function components to class components - The code must contain complete type annotations
Here are some examples of my growing .mdc files:
Full-stack TypeScript project architecture and constraints
--- description: Enterprise-level TypeScript full-stack application architecture specification globs: *.ts, *.tsx priority: 10 --- # TypeScript full-stack architecture specification## Core architecture principles - Adopt the **Hexagonal Architecture** design pattern - Isolate domain logic from infrastructure such as framework, UI, and database - Dependencies must point to the core of the domain, and reverse dependencies are prohibited - Interfaces are defined in the domain layer and implemented in the infrastructure layer## Type system specification - The use of the `any` type is prohibited, and `unknown` must be used as the default choice for unknown types - Explicitly annotate all function parameters and return values - For complex objects, use the following pattern to define types: ```typescript // Domain entity basic type type UserProperties = { id: string; email: string; firstName: string; lastName: string; role: UserRole; createdAt: Date; updatedAt: Date; }; // Entity class export class User { private props: UserProperties; private constructor(props: UserProperties) { this.props = props; } // Factory method public static create(props: Omit<UserProperties, 'id' | 'createdAt' | 'updatedAt'>): Result<User> { // Validation logic... return Result.ok(new User({ ...props, id: UUID.generate(), createdAt: new Date(), updatedAt: new Date() })); } // Accessor methods get id(): string { return this.props.id; } get email(): string { return this.props.email; } // ...other accessors }Microservices
### Microservice Architecture Design Specifications--- description: Microservice Architecture Design Specifications and Best Practices globs: *.{ts,js,go,py} priority: 20 --- # Microservice Architecture Design Specifications## Overall architectural principles - Use **Domain-Driven Design (DDD)** thinking to design microservice boundaries - Each microservice should meet the "single responsibility" principle - Inter-service communication gives priority to asynchronous event-driven mode - Follow the API-first design principle, define the interface first and then implement it## Inter-service communication specifications### Synchronous communication - REST API must follow the following specifications: - Use HAL (Hypertext Application Language) to represent resource relationships - Unified error response format: ```json { "error": { "code": "RESOURCE_NOT_FOUND", "message": "The requested resource does not exist", "details": { "resource_id": "12345", "resource_type": "user" }, "trace_id": "abcd1234-5678-efgh-ijkl-mnopqrstuvwx", "timestamp": "2025-03-28T12:34:56Z" } } ``` - API version control strategy: specify the version in the Accept header, for example `Accept: application/vnd.company.api+json;version=1` ### Asynchronous communication - Event structure specification: ```json { "id": "uuid-v4-format", "type": "user.created", "version": "1.0", "source": "user-service", "time": "2025-03-28T12:34:56Z", "dataContentType": "application/json", "data": { // Event specific data}, "correlationId": "related-request-id", "subject": "users" }The above are all based on Cursor 0.45. If you also encounter the behavior of Cursor's intelligence reduction, you might as well write two more lines of planning documents like this, which may improve the situation.
