设置光标规则，让 AI 不再破坏您的代码库风格

我使用 Cursor 的第一个月，每个代理编辑都有效，但仍然感觉不对劲——我的存储库使用空格的选项卡、命名代码库中的默认导出、以我们 CI 拒绝的风格编写的测试。修复并没有更好的提示。这是规则文件，设置正确。

光标从存储库中的 .cursor/rules 读取规则。从一个项目级规则文件开始，涵盖不可协商的事项：包管理器、导入顺序、命名约定以及代码库使用的与常见默认值不同的两到三种模式。将其控制在 50 行左右——无人维护的规则文件会成为模型学会忽略的噪音。

被低估的功能是每个目录的规则。我们的组件目录有一个规则：仅功能组件，内联键入的道具，无默认导出。我们的服务器目录还有另一个：没有客户端导入，每个处理程序都会验证输入。这种分割对输出质量的影响比我在全局文件中编写的任何内容都要多，因为模型只能看到适用于它所接触的文件的规则。

三个规则是通过纯粹的重复而赢得一席之地的。第一：“编辑后，运行现有的 lint 命令并修复您引入的所有错误。”第二：“匹配您正在编辑的文件的导入样式，而不是您喜欢的样式。”第三：“如果更改需要新的依赖项，请停下来询问而不是安装。”最后一个是在我在 diff 中发现五个需要一个的新软件包之后出现的。

我停止做的事情：在每条聊天消息中重复样式说明。制定规则后，我的提示会描述意图 - 构建什么，避免什么 - 并且规则文件处理房屋风格。提示变得更短，输出变得更加一致，这就是整个游戏。

维护习惯之一：当座席重复犯同样的错误时，添加一条规则，而不是在聊天中责骂它。聊天更正会随着对话而消失；规则文件复合。我的规则文件每周增加大约两行，每行背后都有一个错误修复。

常见问题：

问：规则文件会减慢光标速度吗？

答：不明显。它们会与您的提示一起注入到上下文中。真正的成本是臃肿的规则文件分散了注意力，这就是为什么我限制我的规则并删除代码库已经超出的规则。

问：规则是否应该提交给回购协议？

答：是的，如果您希望整个团队受益 - 将它们视为 linter 配置。将个人偏好保留在用户级规则而不是项目文件中。

问：规则与仅编写良好的系统提示有何不同？

答：规则自动应用于其范围内的每个请求，跨会话生存，并使用代码进行版本控制。你头脑中的系统提示除了你自己之外没有任何人受益，并且每次你开始新的聊天时都会消失。