Cursor 按你的编码风格写代码：一套 Rules 搞定

用 Cursor 写过代码的人，大概率都遇到过同一种别扭：

它生成的代码能跑，但处处和你的习惯对不上

——变量命名、函数长度、注释方式、错误处理，全是一副"通用模板"的样子。

这不是孤例。Stack Overflow 2025 年开发者调查显示，84% 的开发者已经在使用 AI 工具。但"用起来"和"用顺手"之间，隔着一道很多人没跨过去的坎：

怎么让 AI 按你的规矩来，而不是你迁就它的默认风格。

问题往往不在模型，而在少给了一份东西：一份"员工手册"。在 Cursor 里，这份手册叫

Rules（规则）

。

先理解原理，才知道规则为什么管用。

大语言模型在两次补全之间，是

不保留记忆的

。上一次纠正它"变量别用拼音"，下一次它照样忘。它不是故意不听，是真的"记不住"。

Rules 的作用，就是在提示层面给 AI 提供一份

持久、可复用的上下文

——规则被触发后，内容会被附加到模型上下文的开头。等于每次生成代码前，先把"家规"念给它听一遍。

没有规则，Cursor 就只能用"最通用的风格"去猜偏好。而通用风格，恰好是最不像"你自己的代码"的那一种。

还有一个常见的误区：把 Rules 当成"一次性配置"，配完就不管了。实际上，Rules 应该跟着项目一起演进——技术栈变了、团队约定改了、踩了新坑，规则都要跟着更新。一份过时的规则，比没有规则更糟，因为它会让 AI 稳定地按错误的方式写。

Cursor 的规则分四种，别混着用。

类型存放位置作用范围适用User RulesCursor Settings所有项目个人习惯、语言偏好Project Rules.cursor/rules/*.mdc当前项目团队共享、可版本控制Team Rules云端（Business/企业版）团队所有成员企业统一标准AGENTS.md项目根目录当前项目简单项目快速上手

优先级从高到低是：User Rules > Project Rules > Team Rules > AGENTS.md。

想让"编码风格"这件事落地，最该用的是

Project Rules

——它按项目存放、能进 Git、团队共享，正是放编码规范的地方。个人习惯放 User Rules，项目规范放 Project Rules，各归其位，别把个人偏好塞进团队规范里。

如果只是想快速起个小项目、不想折腾 .mdc 文件，AGENTS.md 是更轻的选择——它就是个纯 Markdown 文件，不需要 frontmatter，放在项目根目录即可。但它的短板也明显：不能按文件类型过滤，规则一多就容易互相干扰。所以正式一点的团队，还是建议直接上 Project Rules。

新版 Cursor 的项目规则，是 .cursor/rules/ 目录下的 .mdc 文件。每个文件开头是一段 YAML frontmatter，里面三个关键字段：

description：规则的描述，让 AI 判断要不要引用。globs：匹配的文件模式，比如 **/*.ts，只在编辑 TypeScript 文件时生效。alwaysApply：是否始终加载，设成 true 就每次都带进上下文。

对应的，规则有四种激活方式：

Always

：始终生效，适合放核心代码风格。

Auto Attached

：按 globs 匹配文件才触发，适合特定类型的规范。

Agent Requested

：AI 自己判断要不要用，适合参考性内容。

Manual

：对话时用 @规则名 手动调用，最灵活。

想让风格规则稳稳生效，最省心的组合是把核心风格规则设为始终加载，其余按文件类型用 globs 精准匹配。

这样既保证风格不丢，又不会把无关规则塞满上下文。

文件组织上，推荐按功能模块拆分，而不是把什么都塞进一个文件。比如一个 Vue 项目，可以拆成 project-guidelines.mdc（通用规范，始终生效）、vue-components.mdc（组件规范，globs 匹配 .vue 文件）、api-design.mdc（接口规范，匹配 api 目录）。这样每条规则只在相关的时候被加载，AI 的上下文更干净，判断也更准。

一份能落地的编码风格规则，至少覆盖五块：

命名规范

：变量、函数、组件、文件的命名约定。比如"组件用 PascalCase，文件用 kebab-case，变量用有意义的英文单词，禁止拼音"。

结构约束

：函数长度上限、参数数量上限、单一职责。比如"函数参数不超过 5 个，超过就改成对象参数；单个函数不超过 50 行"。

注释风格

：什么该注释、什么不注释、注释用什么语言。规定清楚"为什么"要注释，而不是逐行翻译代码。

错误处理

：异常怎么抛、怎么兜底、日志怎么打。比如"业务异常统一用 AppError 抛出，异步调用必须 try/catch，禁止吞异常"。

语言特性偏好

：比如 Python 强制 type hints、TypeScript 优先用 interface 还是 type。

这些内容，本质是把人自己都未必意识到的"隐性偏好"，翻译成 AI 能执行的"显性规则"。

写的过程，也是在逼着把"总觉得哪里不对"这种感觉，落成一句句能执行的条款。

命名规范是最容易见效的一块，也是最该先写的一块。因为命名的混乱会传染——一个变量名起坏了，后面所有引用它的代码都跟着难读。把命名规则定死，等于从源头掐断了这种混乱的扩散。

规则正文是纯 Markdown，不用花哨，清晰可执行即可。下面是一段 TypeScript 风格规则的样子：

# TypeScript 编码风格规范## 命名- 变量与函数用 camelCase，类与接口用 PascalCase- 组件文件用 PascalCase 命名，如 UserCard.tsx- 禁止拼音命名、禁止无意义的单字母缩写## 结构- 函数参数不超过 5 个，超过时改成对象参数- 单个函数不超过 50 行，超出必须拆分- 每个文件只导出一个组件或一个职责## 错误处理- 业务异常统一用 AppError 抛出- 所有异步调用必须 try/catch，禁止吞异常

注意每一句都"可执行"

——没有"保持代码整洁"这种空话，全是"参数不超过 5 个""函数不超过 50 行"这类能照着做的硬标准。

规则写对了，效果天差地别。五个技巧：

具体可执行，不要模糊

。写"函数参数不超过 5 个"，别写"写出高质量代码"。前者 AI 能照着做，后者等于没说。

用示例，好例子和坏例子都给

。AI 模仿示例的能力，远强于理解抽象规则。

分层拆分

。按"通用规范 / 语言规范 / 框架规范"三层拆，别把所有规则塞进一个文件，按需加载才不会淹没重点。

少即是多

。10 条清晰规则，胜过 100 条模糊建议；整个规则文件控制在 500 行以内。

让工具兜底格式

。缩进、换行、引号这些，交给 EditorConfig 加 Prettier、ESLint 强制执行，Rules 只管"风格和结构"，别去和格式化工具抢活。

还有一条最实用的习惯：

当发现自己总在对话里重复纠正同一件事，就把那件事写成一条规则。

规则就是这样一点点长出来的。

这套方法的价值，会随着时间滚雪球。刚开始规则可能只有三五条，只覆盖最基础的命名和结构；但每纠正一次、每踩一个坑，就往里补一条。三个月后再回头看，这份规则已经成了团队风格的"活文档"，新成员照着它就能写出和老成员一样的代码。

Cursor Rules 的本质，是给 AI 看的一份"项目文档"。新人进项目先看文档，大模型进项目也应该先看规则。

让 Cursor 按自己的编码风格写代码，说穿了就三步：

把隐性偏好写成显性规则，放进 .mdc 文件，用 globs 和 alwaysApply 控制它稳稳生效。

剩下的事，交给格式化工具兜底格式，交给规则管风格和结构。做到这一步，AI 生成的代码才会从"能用"，变成"像你自己写的"。