Cursor Rules 实战：把团队编码规范写成 AI 能执行的规则

Cursor 用久之后会遇到一个问题：每次都要重复提醒 AI，“不要改这个公共接口”“日志格式要统一”“内存申请要用项目封装函数”。这些内容如果一直写在聊天里，既浪费时间，也容易漏掉。进阶做法是把长期有效的要求沉淀成 Rules。

Rules 的本质不是“写一堆口号”，而是把项目约束变成 AI 能执行的具体规则。比如普通写法是：“代码要规范”。这对 AI 帮助不大。更好的写法是：“新增 C 文件时，函数名使用模块前缀；错误日志统一使用 APP_LOGE；动态内存申请优先使用项目封装接口；修改公共头文件必须说明兼容风险。”

推荐把规则分成三层：个人偏好、项目规范、特殊模块规范。个人偏好可以放你长期使用的风格，例如回答先给结论、代码要有中文说明。项目规范放编译方式、目录结构、日志宏、内存接口。特殊模块规范只对某些目录生效，例如音频模块、UI 模块、驱动模块各自有不同的限制。

一个适合嵌入式项目的 Rules 示例：

本项目运行在 RTOS 环境，默认不能在中断回调中执行阻塞操作。
修改音频链路时，必须注意栈大小、环形缓冲区、采样率和线程优先级。
涉及 PSRAM/SRAM 的修改，需要说明新增内存占用。
所有新增日志使用项目现有日志宏，不直接 printf。

规则不需要一次写完。最好的方式是：每次发现 Cursor 反复犯同类错误，就把这个错误改写成一条规则。这样 Rules 会越来越贴近项目，而不是变成没人维护的说明文档。

透明说明：本文是个人使用 Cursor 的经验整理。准备试用或升级的朋友，可以使用我的邀请链接：https://cursor.com/referral?code=OX0D4UQFAAHW
根据当前邀请页显示，受邀者首月可享优惠，我也会获得一定使用额度奖励；具体规则以 Cursor 页面实际显示为准。