嵌入式C开发中Cursor规则引擎的实战配置与AI协同优化

1. 为什么嵌入式C项目需要Cursor规则引擎？

干了这么多年嵌入式开发，我踩过最大的坑不是硬件驱动调不通，也不是内存泄漏查不到，而是团队协作时那五花八门的代码风格。你这边变量名用temp_sensor，他那边用TempSensor，还有人用tempSensor。宏定义更是重灾区，有人用#define MAX_LEN 10，有人用#define MAXLEN 10，还有人干脆不用宏，直接写死数字。等到项目后期要维护或者新人接手时，光是理解这些不一致的命名和写法就得花上好几天，更别提AI助手来帮忙时，它根本搞不清你到底想要什么。

这就是为什么我强烈推荐在嵌入式C项目里用上Cursor的规则引擎。它不是什么高深莫测的黑科技，本质上就是一套能“管住”AI的“家规”。你告诉Cursor：“在我们这个项目里，全局变量必须加g_前缀，函数名全用小写加下划线，HAL层函数必须用hal_开头。”然后Cursor就会记住这些规矩，以后无论你是自己写代码，还是让AI帮你生成、修改代码，它都会自动遵守这些规范。

我刚开始用的时候也觉得多此一举，心想“我自己注意点不就行了？”但实际用下来才发现，真香！特别是当你需要快速生成一大段驱动代码，或者让AI帮你重构一个模块时，有了规则引擎，AI生成的代码直接就是符合项目规范的，省去了大量手动调整格式、统一命名的时间。对于嵌入式这种对代码稳定性、可读性要求极高的领域，从一开始就保持一致性，比后期再来“打补丁”要高效得多。

2. 从零开始：搭建你的第一个嵌入式C规则文件

规则文件的后缀是.mdc，其实就是Markdown格式的文本文件，放在项目根目录的.cursor/rules文件夹里。Cursor会自动识别并应用它们。别被“规则引擎”这个词吓到，它的配置其实非常直观。

我们先从最基础的代码风格规则开始。在你的项目根目录下，创建.cursor/rules文件夹，然后新建一个文件，比如叫01-code-style.mdc。内容可以这样写：

---
description: 嵌入式C项目基础代码风格与命名规范
globs:
  - "**/*.c"
  - "**/*.h"
alwaysApply: true
---

### 嵌入式C项目基础代码风格与命名规范

#### 1. 变量命名
- **局部变量**：使用全小写字母，单词间用下划线分隔。例如：`int sensor_value;`、`uint32_t error_count;`。
- **全局变量**：必须使用`g_`前缀，同样全小写加下划线。例如：`volatile uint32_t g_system_tick;`。这能一眼就看出变量的作用域，避免误用。
- **静态局部变量**：建议使用`s_`前缀，如`static int s_initialized = 0;`。
- **指针变量**：在类型名和`*`号之间加空格，变量名以`_p`结尾以示提醒。例如：`uart_device_t * uart1_p;`。

#### 2. 函数命名
- 所有函数名使用全小写字母和下划线。例如：`void read_temperature(void);`、`int parse_sensor_data(const uint8_t *buffer);`。
- **硬件抽象层函数**：必须以`hal_`开头，后接模块名和操作。例如：`void hal_gpio_set(uint8_t pin);`。
- **驱动层函数**：以`drv_`开头，例如：`int drv_imu_init(void);`。
- **应用层函数**：按模块功能命名，如`app_task_scheduler(void);`。

#### 3. 宏与常量定义
- **宏定义**：全部字母大写，单词间用下划线连接。例如：`#define UART_BUFFER_SIZE 256`。
- **配置宏**：以`CFG_`开头，方便在头文件中统一管理。例如：`#define CFG_DEBUG_ENABLE 1`。
- **枚举常量**：使用`typedef`定义枚举类型，枚举值以类型名前缀开头。例如：
  ```c
  typedef enum {
      SENSOR_STATE_IDLE,
      SENSOR_STATE_READING,
      SENSOR_STATE_ER