VkingAICursor Rules 搞定后，我的代码质量终于不靠玄学了
分享如何用 Cursor Rules 让 AI 助手真正遵循项目规范，解决代码风格精神分裂问题
# Cursor Rules 搞定后，我的代码质量终于不靠玄学了
上周 Code Review，同事问我："你这项目结构怎么这么规整，每个文件的注释风格都一样？" 我笑了笑，说这是 Cursor Rules 的功劳。他一脸茫然，大概是觉得我在说某种玄学。
其实三个月前，我的代码风格可以用"精神分裂"来形容——今天用 camelCase，明天变成 snake_case；这个文件有详细注释，下个文件全是魔法数字。AI 助手帮倒忙的情况更是数不胜数，明明我在写 Node.js，它非要给我建议 Django 的目录结构。
直到我认真配了一套 .cursorrules。
先说说这玩意儿是什么
Cursor Rules 本质上是一个项目级的"人设文件"。你告诉 AI 这个项目的技术栈、代码规范、业务背景，它就会在这个框架下给你干活。听起来很简单，但效果出乎意料的好。
配置文件放在项目根目录，叫 .cursorrules。格式随意，但我推荐用 Markdown，可读性更好。
# 项目背景
这是一个跨境电商的订单管理系统，面向东南亚市场。
技术栈
代码规范
业务重点
这个文件会自动被 Cursor 加载，AI 在这个项目里的所有回答都会遵循这些约定。
我踩过的坑
坑一：Rules 太抽象，AI 理解不了
一开始我写的 Rules 很"程序员风格"：
结果 AI 给的建议依然不靠谱。原因很简单：这些话太抽象了，没有具体的指导意义。
后来我改成具体的指令：
效果立竿见影。AI 开始给出符合预期的代码建议，而不是正确的废话。
坑二：忘记更新 Rules
项目迭代几个月后，技术栈有调整——我们从 AWS SQS 换成了 RabbitMQ。但我忘了更新 .cursorrules，结果 AI 一直在建议用 SQS 的代码模式。
解决方法是把这个文件纳入 Code Review 流程。技术栈有变化，先更新 Rules，再写代码。
坑三：Rules 和 ESLint/Prettier 打架
这是个真实案例。我的 .cursorrules 里写着"每个函数必须有 JSDoc 注释"，但 ESLint 配置里没这个规则。结果 AI 生成的代码有注释，但同事提交的代码没有，Code Review 时经常为此争论。
最后我把 ESLint 配置和 Cursor Rules 同步了——Rules 里写的规范，ESLint 里必须能检查。AI 和人类用同一套标准，才不会精神分裂。
进阶用法：分层 Rules
项目大了之后，单一的 .cursorrules 可能不够用。比如我们的前端和后端在同一个仓库，但规范完全不同。
做法是创建多级 Rules：
项目根目录/.cursorrules # 通用规则（Git 规范、文档风格）
backend/.cursorrules # 后端专用（NestJS、PostgreSQL）
frontend/.cursorrules # 前端专用（React、Tailwind）
Cursor 会自动合并这些规则，层级越深优先级越高。
一个真实案例
上个月我们重构订单状态机。旧代码是一个 500 行的 switch-case，改一个状态要改七八个地方。我用 Cursor Rules 告诉 AI：
# 订单状态机重构
当前状态机代码在 src/order/status.machine.ts，需要拆分成状态模式。
目标：
2. 状态转换逻辑集中在一个配置对象里
3. 保留现有的所有测试用例
约束：
然后打开 Cursor 的 Composer，选中旧代码，让它重构。生成的代码结构清晰，测试也通过了。真正花时间的不是写代码，而是把需求翻译成 AI 能理解的指令。
值不值得搞？
如果你是一个人写代码，收益有限——你自己的规范你自己清楚。但如果是团队协作，尤其是团队里有新人，Cursor Rules 可以大幅降低沟通成本。
我现在入职新同事，第一件事就是让他读项目的 .cursorrules。十五分钟了解项目规范，比看一百行代码注释效率高多了。
当然，Rules 不是万能的。AI 有时候还是会犯蠢，尤其是遇到边界情况。但至少，它不会再给我建议用错误的变量命名风格了。
这就够了。