1. 动手之前：这几项设置不调好，规则写得再好也白搭
很多人装了 Cursor 之后，第一反应是“这不就是个套壳 VSCode 吗”，然后直接开始写代码，写到一半发现补全不像宣传里那么聪明，对话回复还是一股机翻味，又回头吐槽工具不行。我见过太多这种案例了。实际上 Cursor 的核心竞争力，不在默认状态，而在两件事上：一是模型调度和路由，二是你自己写的Rules 规则。这两件事没调好，后面谈“少写一半代码”就是空话。
1.1 中文界面与中文回复：先解决“劝退第一关”
打开 Cursor 第一眼是英文界面，对非英语母语的人来说，确实会有一种隐形门槛。这问题好解决：在扩展市场搜Chinese (Simplified) Language Pack，装完之后按Ctrl+Shift+P打开命令面板，输入Configure Display Language，选zh-cn，重启就变成中文界面了。注意一点，如果哪天升级完界面又变回英文，多半是语言包和版本不配套，去扩展市场重新安装一次即可。
但界面汉化只是表面功夫。更多人真正困扰的是：明明我中文提问，AI 回复却中英混杂，甚至习惯性输出英文注释、英文变量名。这个问题靠界面汉化解不了，必须写进规则里。
我目前的做法是在全局 Rules 的第一行直接写：
始终使用简体中文回复，代码注释和文档也使用中文，除非用户明确要求英文。这句话看着简单，实际效果比你在对话框里每次补一句“请用中文”要稳定得多。因为后者是临时指令，随对话上下文被冲掉；前者是每条消息都会参与模型上下文计算的高优先级指令，不会被覆盖。
1.2 模型选择：Claude、GPT、Grok 与 Claude Code 到底什么关系
热词里有“cursor codex claudecode trae”和“cursor和claudecode是什么关系”，我发现不少人把 Cursor 和 Claude Code 的关系搞混了。
简单说一下：Claude Code 是 Anthropic 官方出的终端编程助手，跑在命令行里；Cursor 是编辑器，通过 API 接入 Anthropic 的 Claude 模型能力。两者底层的模型同源，但产品形态不同——一个在终端里操作，一个在图形界面里和代码库深度集成。你可以理解成同一台发动机，装在了轿跑和越野车上，驱动体验完全不同。
至于模型怎么选，我的经验是分场景：
- Claude 系列（Opus/Sonnet）：适合复杂重构、跨文件改动、逻辑推演。它对上下文的理解更细腻，在长对话里不容易“忘事”。
- GPT 系列：适合技术问答、概念解释、快速生成样板代码。如果你主要是问问题而不是让 AI 大范围改代码，GPT 模型往往性价比更高。
- Grok 模型：目前属于灰度功能，部分账号在模型列表里能看到入口，额度独立计算。我的实测感受是它在代码续写上表现中规中矩，胜在免费额度偶尔会给得大方，适合作为备用额度池。
模型选型会影响你写规则的方式。比如你主力用 Claude 模型，规则里就可以少写“解释你的思路”这类要求，因为 Claude 本身倾向于详细分析；如果你主力用轻量快速模型，规则里就要明确“直接给出代码，不要长篇解释”，否则响应里一半是废话。
1.3 额度管理：免费用户最容易踩的隐形坑
Cursor 免费版并不是“完全免费”，它有额度分层逻辑：基础模型请求基本无限，高级模型请求每月有限次，用完自动降级到慢速/快速模型。很多人遇到“cursor taking longer than expected”或者回复突然变笨，多半就是高级额度耗尽，被降级到了快速模型，而不是软件坏了。
这个状态在设置面板的Account > Quota里能看到消耗。我见过太多人不知道这个入口，以为 Cursor 变卡变蠢了，到处找原因。
额度管理这件事，和规则息息相关：规则写得越精准，你和 AI 之间的无效往返就越少，高级额度的消耗就越慢。比如我下面第 3 章那套规则，最大的作用就是减少“再解释一遍需求”“重写一遍格式”这类重复请求，一次把需求说清楚，一次生成到位，额度自然经用。
2. Rules 文件才是“少写一半代码”的发动机
标题说“这套规则让我少写一半代码”，很多人以为是夸张修辞。实际用下来，规则对编码效率的提升，主要不是帮你打字，而是帮你少走弯路：少写重复代码、少改格式问题、少做无用重构。代码量真的能砍半，前提是规则先立起来。
2.1 两类 Rules 文件的分工
Cursor 的规则体系分两层：
- 全局规则（User Rules）：在
Settings > Rules里配置，对所有项目生效。适合放通用编码习惯、语言偏好、注释风格。 - 项目规则（Project Rules）：放在项目根目录的
.cursor/rules文件夹里，以.mdc文件存在。适合放项目特定的架构约束、目录规范、禁用项、命名约定。
一句话总结分工：全局规则管“你希望 AI 怎么干活”，项目规则管“这个项目允许 AI 怎么干活”。
我见过一些团队把项目规则写进全局规则里，结果换一个技术栈的项目时，AI 还在拿上一套框架的约束去套新项目，输出全是驴唇不对马嘴。正确的做法是：全局规则保持精简，项目规则按仓库维护，随着代码一起走。
项目规则文件还有一个好处——它是团队协作的杠杆。你把.cursor/rules提交到 Git 仓库，新成员 clone 下来，Cursor 自动加载规则，相当于把资深工程师的编码约束直接复制到了每个人本地。这种知识传递效率，远高于口头交代“要注意代码风格”。
2.2 三个写规则最容易犯的错
先说最常见的错误：规则写太长。有人把几十条规范全部堆进 Rules，AI 每次请求都要带着这么长的规则去算上下文，结果有两个，一是上下文被规则挤占，代码相关记忆变短；二是模型注意力被稀释，关键约束反而抓不住。我的经验是全局规则控制在 20 条以内，每条一句话说清楚，最长不超过两行。
第二个错误：规则写太抽象。比如“代码要优雅”“注意性能”“遵循最佳实践”，这种话一点用没有。规则必须具体到能被检查的程度。比如“性能”要求，可以拆成“禁止在循环内重复查询数据库”“循环体内不得进行不必要的对象创建”。AI 是概率推理模型，不是执行命令的程序，你给它的指令越模糊，它越倾向于按默认习惯输出。
第三个错误：规则之间自相矛盾。全局规则说“所有变量使用 camelCase”，项目规则里又说“接口定义使用 snake_case”，AI 遇到冲突时可能随机取一个，输出结果不稳定。解决方法是给规则排优先级，比如在项目规则里显式声明“本项目优先级：项目规则 > 全局规则”。
2.3 底层机制：为什么规则能显著改变输出质量
很多人不理解，为什么同样一个模型，加了规则之后输出质量差距那么大。这要从 Cursor 的实现机制说起：用户的 Rules 会被插入到每次请求的系统提示词（system prompt）中，也就是模型在读取你的对话之前，先读到了这份规则。
模型的输出，本质是对输入上下文的延续。系统提示词中明确写“回答使用中文、代码使用函数式风格、调用数据库必须在事务内”，那模型在一开始就处于“我面对的是一个有明确编码规范的工程师”的状态里，生成时自然会沿着这个方向走。
反过来说，没有 Rules 时，模型就是“裸奔”状态——它不知道你的代码风格偏好，不知道你忌讳什么，默认按训练时的通用模式回答。通用模式没有错误，但远谈不上“贴合你的项目”。规则的本质，就是给模型补上“项目专家知识”，让它从“一个通用程序员”变成“了解你这个项目的专用程序员”。
3. 一套能直接抄的 Rules 模板（含逐条说明）
下面这套是我个人在全局规则里实际在用的版本，不含项目特定内容，你可以直接复制。每条后面我会说明为什么要这么写。
3.1 通用代码生成规则
1. 所有代码必须使用项目现有风格，不主动引入新的代码风格或重新格式化。 2. 函数和变量命名遵循已有代码的命名约定，不混用多种风格。 3. 不得省略 import、require、using 等引用语句，给出完整可运行代码。 4. 代码注释使用中文，说明函数用途、参数含义和边界条件。 5. 生成代码时优先使用标准库或项目已有依赖，不擅自引入新库。 6. 修改现有代码时，只改动必要部分，禁止顺手重构无关代码。第 1、2 条解决的是“AI 写出来的代码和项目风格不一致”的痛点。我见过太多 AI 生成的代码，功能没问题，但文件里一半 tab 缩进、一半空格缩进，变量名有 camelCase 也有 snake_case，看得人血压升高。规则里提前声明风格跟随现状，输出一致性立刻改善。
第 3 条看着基础，实际特别重要。AI 为了看起来简洁，经常省略 import 语句，写一段“示意代码”，但你要的是能直接运行的东西。强制完整引用，能省掉你手动补 import 的时间。
第 5、6 条是克制 AI“自由发挥”的关键。AI 默认倾向于用最新最炫的库，但它不知道项目的技术栈包袱、license 要求、维护成本。规则里写死“优先用已有依赖”，可以挡住大部分不合理的库引入；“禁止顺手重构”，能挡住 AI 在改一个 bug 时顺带把整个函数都重写一遍的冲动性行为。
3.2 项目规范与记忆规则
7. 在开始大范围修改前，先通读项目 README 和 doc 目录，理解项目架构。 8. 回答中引用文件时，必须给出文件路径和关键函数名，不要只给模糊描述。 9. 遇到不确定的业务规则，明确提问而不是假设，禁止编造不存在的行为。 10. 多文件改动时，先列出将要修改的文件清单，确认后再动手。第 7 条针对的是 AI“不看上下文直接答”的通病。项目里有 README、有设计文档，但 AI 提问时经常不主动读，只在给定文件里打转。规则强制它先收集上下文再回答，输出质量提升明显。
第 9、10 条是我最看重的两条。AI 的“自信式胡说”是编码中最大的隐性成本——它不知道业务规则，却编造一个看似合理的行为，你要在代码 review 时才发现，返工成本极高。规则里写明“不确定就提问，不允许假设”，AI 就会在有歧义时先列问题清单，而不是直接生成错误实现。
3.3 负面清单：不许自作主张
11. 禁止删除用户注释掉的代码块。 12. 禁止把现有函数重构为全新实现，即使你认为新实现“更好”。 13. 禁止在没有指明出处的情况下，把第三方开源代码片段复制进项目。 14. 禁止修改配置文件里的非相关项，比如版本号、路径、端口，除非用户明确要求。 15. 禁止生成 TODO 注释来代替实际实现，需要实现的内容必须直接实现。写规则的时候，负面清单比正面要求更有效。为什么？因为模型在训练时学习到的默认行为，就是“主动帮助用户完善代码”。它看到注释掉的代码，倾向于清理；看到不完美的实现，倾向于重构。这些行为在某些场景下是优点，但在你不知道的情况下发生，就是事故。
比如第 14 条，我有一次让 AI 加一个环境变量，它顺手把配置文件里的端口和日志级别都改了，导致测试环境一连串报错。从那之后我彻底理解了：给 AI 的规则，必须像给实习生的岗位红线一样，先说什么不能做，再谈什么应该做。
4. 让 Rules 真正生效的配套操作
规则写好，只是第一步。同样一套规则，在不同人手里效果差距很大，差别就在配套操作上。
4.1 @文件与 Codebase 索引：上下文是规则的上限
Rules 告诉 AI“应该遵守什么”，但没告诉它“项目里有什么”。要让规则真正落地，得让 AI 看到相关文件。在对话中，你可以用@引用具体文件、文件夹、符号，也可以引用全局的@Codebase让 AI 主动检索代码库。
实际操作中，我推荐一个组合策略：大范围改动时先@Codebase建立全局认知，具体修改时@精确引用目标文件。前者给 AI 项目全貌，后者避免它在检索上浪费额度。如果你做的是小改动，直接@文件就够了，多余的全库检索只会拖慢响应。
这里也有一个容易被忽略的坑：.cursor/rules目录里的文件，默认格式是.mdc，它本身可以被对话引用。你可以写一个project-context.mdc，放项目的技术栈、模块划分、关键目录说明，然后在规则第 7 条里要求 AI “先阅读 project-context.mdc 再回答问题”。这样 AI 每次大改前都会自动加载项目导读，效率比手动传文件高得多。
4.2 Composer 的 Plan 模式与 Tab 补全
很多人不知道 Cursor 的对话面板（Composer）有两种模式：Plan 和 Agent。Plan 模式只出方案不动代码，Agent 模式直接改文件。我的做法是：涉及多文件改动时，先 Plan 后 Agent。Plan 模式可以让你在 AI 动手前审查思路，确认方向再放行，这一步能挡住至少一半的错误改动，比事后 review 省力太多。
Tab 补全则是另一个容易被低估的功能。它和 Rules 的关系在于：Tab 补全的生成逻辑同样受项目内已有代码影响，而 Rules 里的风格约束能让补全结果更贴合现有代码习惯。你可以在设置里打开自动补全增强选项，实测下来写重复性代码时，Tab 补全的接受率很高，能有效减少手打。
4.3 十分钟自测：验证规则是否真的在生效
规则写完之后，必须验证，不然你不知道它有没有实际进入模型上下文。
我的自测方法是：从新开一个对话（避免历史上下文干扰），输入下面两句话：
- “用三句话描述一下你看不见但能感受到的东西。”（故意不说明语言偏好，看它是否用中文回答）
- “写一个 Python 快排，不要 import 任何东西，直接给完整代码。”（测试规则第 3 条是否生效）
如果 AI 第一问蹦出英文长回复，第二问给了残缺代码，那大概率是你的规则没被加载，或者被提示词上下文挤占了。这时重新检查规则文件的格式和位置，必要时重启编辑器。
5. 免费额度与模型降级的真实体验
再回来说额度这件事，因为它直接决定规则的“马力”能发挥到什么程度。
5.1 免费额度耗尽前后的体验差在哪
免费额度充足的时候，你用的是高级模型，规则执行度高，多步推理能力强，代码准确率高。额度一旦耗尽，降到快速模型，最明显的感受是：响应变快的代价是智商下降。同一套规则，高级模型能严格遵循，快速模型可能漏掉一两条，尤其在第 3 章那种负面清单里，它偶尔会“违法作业”。
所以我的建议是：免费额度优先给“大改动”用，小补丁、单文件修改尽量用快速模型完成。平时写工具脚本、写 HelloWorld 级别的改动，不碰高级模型；真正要重构模块、跨文件改动时，再切换到高级模型。这样额度消耗慢，体验下限也兜得住。
5.2 模型切换的实用策略
Cursor 的对话面板和 Tab 补全，可以分别配置模型。实际操作中，我通常是：
- Tab 补全：用快速模型，因为补全追求的是低延迟，而不是深度推理。
- Composer 对话：复杂任务用高级模型，简单问答用快速模型。
- 代码审查：用高级模型，因为审查需要全局推理和细节洞察。
这套策略的核心逻辑是“好钢用在刀刃上”：高级模型额度是稀缺资源，不要让它在琐碎任务上烧掉。很多人一天就把高级额度用完，就是因为没区分任务等级，什么问题都丢给最强模型。
5.3 什么时候值得付费用户
我的判断标准很简单：如果你每天要和 Cursor 对话超过两小时，或者从事涉及多文件重构的深度编码工作，订阅是划算的；如果你只是偶尔用 AI 查个 API 写法、写个小函数，免费额度完全够用，没必要花钱。
付费还有个隐藏优势：额度焦虑消除后，你在和 AI 协作时会更敢提要求，更敢让它试错。免费额度下，我经常因为怕消耗而把请求压缩到很简略，结果 AI 理解偏差，反而更费额度。痛快点把需求说清楚，反而省。
6. 从 VSCode 迁移过来的配置细节
最后说点迁移相关的实操细节。Cursor 基于 VSCode 技术栈，但默认配置并不是“一键全搬”，有几个地方值得手动处理。
6.1 键位与设置的平滑迁移
如果你之前在 VSCode 里精心调过键位和配置，没必要在 Cursor 里重新配一遍。Cursor 的登录界面里有导入 VSCode 设置的入口，可以拉取settings.json、keybindings.json和已安装的扩展列表。
我实际迁移时遇到一个坑：部分 VSCode 扩展在 Cursor 里会重复激活，导致命令面板出现双份命令。比如一些格式化扩展、主题扩展。解决方法是迁移完扩展之后，手动禁用那些在 Cursor 里明显功能重复的插件，保留编辑器原生能力即可。
6.2 C/C++ 调试环境的配置思路
热搜词里有“vscode配置c/c++环境”，这个在 Cursor 里逻辑一样，因为 Cursor 复用了 VSCode 的调试架构。C/C++ 调试最简单的一套配置是：安装微软的 C/C++ 扩展，然后确保 system 里装好编译器（Windows 下是 MinGW 或 MSVC，Linux 下是 gcc/g++），接着写一份tasks.json负责编译，一份launch.json负责启动调试。
{ "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "g++", "args": ["-g", "${file}", "-o", "${fileDirname}/${fileBasenameNoExtension}.exe"] } ] }{ "version": "0.2.0", "configurations": [ { "name": "(gdb) 启动", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/${fileBasenameNoExtension}.exe", "preLaunchTask": "build" } ] }配置完这两份文件，按F5就能一键编译并启动调试。新手最常见的问题是program路径配错，或者没装编译器就点了执行，报program does not exist或找不到g++命令，排查时先确认工具链是否就绪。
6.3 遇到“转圈/慢/报错”时的排查次序
开头提到“cursor taking longer than expected”，这几乎是每个用户都会遇到一次的报错。很多人第一反应是网络问题，其实按我这个排查次序走，大多数能解决：
- 先看状态栏模型名字，确认是否被降级到了快速模型。降级后响应变慢是正常现象，等额度刷新或切换模型即可。
- 再关掉当前对话里引用的大文件，尤其是那种几千行的文件，上下文过长会导致请求排队时间变长。
- 最后才是检查网络状态和服务负载，通常换个时间段再试就好。
我自己的体会是，Rules 这套东西不能指望一次成型。我第一次写规则时恨不得面面俱到，结果 AI 因为上下文被规则占满，反而频繁遗漏代码细节。后来把规则压缩到十几条，每条都是踩过坑后提炼出来的硬约束，效果反而好得多。建议你也随用随调，每两周回头看看哪些规则真正减少了你的返工，把没用的删掉，把临时需要固化下来。规则不在多，每条都管用，才叫配置到位。
