Cursor 系列（2）：使用心得
这篇文章主要是分享一些我在Cursor使用过程中总结的一些心得、踩过的坑以及解决办法，能够帮助大家更好的使用Cursor去辅助我们的开发。主要包括使用技巧、Cursor锁区问题、Rules相关以及模型的选择。
使用技巧
使用 @精确到行
用 @ 标记相关文件可以显著提高代码建议的准确性 ，在明确知道需要改动哪行或者改动哪个文件的情况下，最好用@精确到行。在Cursor里操作也挺方便的，直接复制代码到Chat里面，编辑器会自动关联文件。
缩小变更范围，不要试图一次更改太多
在使用 AI 编辑器 coding 过程中，无论是使用哪个AI编辑器，我的建议是一个功能点一个功能点的去做 ，尽量让更改范围小些 。这样不至于让 AI 写的代码变得越来越不可控，以至于到最后我们看不懂也改不动。
更小的更改范围有助于我们更好的阅读 、理解 AI 写的代码，毕竟，人，才是写代码的主体。
让 cursor 复述你的要求
我们表述的语言总是有模糊性的，加上 AI 理解特定信息的局限性，以及 AI 生成内容的一定随机性，有时候我们可能会遇到 AI答非所问 的情况，这个时候先别怪 AI，先去看下自己的提问或描述是否清晰易懂，其实最好的方法就是让 AI 复述 一遍你的需求，从它复述的结果看 AI 是否充分理解了你的要求。
善用图示提问
各个AI的识图其实已经非常强了，如果你的需求是否很难用文字完全描述清楚，可以适当增加一些图示 ，哪怕是一些简单的流程图，都能更好地帮助 cursor 去理解你的意图。
经常创建新的chat
每次完成一个新功能，最好新开一个chat，避免之前的上下文对后面的功能开发造成污染，这也是我之前踩过的一个坑。而且因为新开的chat只包含只包含当前任务相关的上下文，不包含历史无关信息，在按 token 计费模式下，还可以节省费用。
灵活使用Chat的模式
当前版本 cursor（2.2.43版本）的Chat 有 Ask 、Agent、 Plan和Debug四种模式。
这四个模式的定位、行为特点以及典型适用场景如下：
| 模式 | 核心定位 | 行为特点 | 典型适用场景 |
|---|---|---|---|
Ask |
对话 / 思考 / 出方案 | 只聊天和给建议，不主动大改代码 | 问概念、要方案、评审代码、讨论架构和技术选型 |
Agent |
自动改代码 / 执行任务 | 自动读改多文件，真正帮你写和改代码 | 新增功能、重构、批量替换 API/埋点/日志等跨文件修改 |
Plan |
拆解任务 / 生成路线图 | 只给步骤和 TODO，不直接动代码 | 大型功能、复杂重构、技术栈升级前的规划 |
Debug |
定位和修复问题 / 调试辅助 | 围绕报错和异常，找原因给修复方案 | 接口 500、程序报错、测试失败、性能问题等调试场景 |
对我来说，没啥思路时，我会使用Ask跟AI讨论技术方案，有时候也会使用Ask去分析代码。
在自己知道代码咋写的情况下，如果是大需求，我会先使用Ask 模式与 cursor 沟通好需求的背景、目的、实现效果等，或者直接上传 prd，让它生成一个初始的技术方案，再根据自己的业务理解与代码理解去优化这个技术方案，最后拿这个比较成熟的方案使用Agent 模式去执行。当然一些小的简单的需求直接Agent 改就完事了，这样效率更高。
Plan 模式像个大号的Ask模式，我只会在大型功能开发、复杂重构和项目初始化时使用。他会先问你，如果我想把项目的element ui升级下版本，直接问：
它会先问你几个问题：
等你回答完这几个问题后，他会生成一个后缀为.plan的md文档：
在这个md文件的最下面，有一个todo list，如果你认为这个todo list没啥问题，可以点new agent按钮（如下图），它会创建一个agent模式的chat按照这个todoList去执行。如果你觉得这个todo list有点问题，可以直接编辑它，也可以点New Todo按钮去自己增加一项todo。
如果你在你的Chat里面输入的内容，表示这个任务很复杂，Cursor 会自动建议切换到Plan模式。
Debug模式我不是很喜欢用，这里就不展开了，可以看这个。
先检查下accept
Cursor 写完代码后。可以不用那么着急着去点 accept all，因为你也不知道 cursor 每次生成的代码是不是正确的。更好的方法是先去验证下 Cusor 写的代码是否正确，让后再点击 accept all，当然如果你不小心点到了 accept all，也可以 ctrl + z 撤回。
Cursor 锁区问题
在 2025 年的7 月份，Cursor 中断 了中国大陆用户 的多个模型使用权 。我们常使用几个模型比如 Claude 系列、Gemini 系列，在国内都无法使用：
为什么会这样
老实说，这次的锁区事件其实跟 Cursor 关系并不大 ，Cursor 作为一个 AI+IDE 编辑器，他自身其实并不开发模型，它是基于 VSCode 开源代码进行开发，再通过他的网络去调用如：Claude、ChatGPT、Gemini 等等这些模型，去使用的模型的能力。
Cursor 也在他的公告里为自己喊冤：
Some models in
Cursormay be unavailable in certain regions based on the terms and policies set by the model providers. We plan to re‑enable all models in any regions where they are supported. If our model partners allow access to your region, we plan to restore the affected models and update this page.
大概意思就是，这种限制并非 Cursor 故意为之，而是受到上游模型提供商政策变化的影响。类似的情况在 AI 行业并不罕见 ， Anthropic（Claude）、OpenAI（GPT / o-series）、Google（Gemini）等公司都有自己的不支持国家和地区。遗憾的是，中国大陆地区都在这三家公司的封禁名单中... 即使是翻墙也不行
怎么办？
Cursor 官方给了几个方案
- 勾选
Auto选项，每次请求时自动选择可用模型。 - 如果你有能在当地正常使用的
APIkey，可以在Cursor中配置他，这样就可以绕过去限制。 - 申请按比例退款
这三种方案其实都没有真正解决问题。官方相当于直接摆烂了，直接告诉国内用户：我也没办法了，您要不勉强用，要不直接退款吧。
真实情况也是如此------在 Cursor 的锁区事件后，大批量的中国用户放弃 使用 Cursor，转而使用 Trae、Windsurf 等替代品。那段时间我也放弃 Cursor 去试用了下 Trae，但是使用了一段时间后， Trae着实令我有点失望，生成的代码常常驴头不对马嘴，智能这方面远远不如 Cursor，于是我又回到了 Cursor 的怀抱...
锁区的问题还是得解决啊，民间社区中也有人逐渐摸索出了解决方案：
- 修改网络类型 ：
ctrl + shift + j打开控制面板后，点击Network，修改http模式，把默认的HTTP/2修改为HTTP/1.1
- 打在你的代理工具中，将 Tun Mode 打开
我实际测试了下，效果还行，常用的几个模型都能使用，就是链接有时候会中断，应该是我的代理不太稳定的问题。
社区中也有人使用 Proxifier 转发 api2.cursor.sh:443 来实现，这样既可以使用 http2 享受低延迟，也可以用上 claude 等模型，感兴趣的朋友可以查下相关文章去尝试下。
一顿操作下来也是够麻烦，使用体验还没有以前好。这次的锁区事件本质上还是受美国 AI 出口管制以及国家安全相关政策的影响，或者说是受中美技术竞争的影响，也不知道什么时候技术开放化 才能真正到来，让国界不再成为开发者的一个门槛。同时国内的相关公司也得支棱起来啊，让自己的AI 编辑器更好用些。
Rules
想要用好 AI 编辑器，rules 肯定是不能绕过去的，合理的 rules 能够提供明确的结构化指导来约束 AI 的行为，并且有效对抗"AI"幻觉，确保生成的代码符合项目标准。
当前 Cursor 有三种类型规则
- 项目规 则：存储在 .
cursor/rules 中，受版本控制，作用范围限定在你的代码库内 - 用户规则 ：在整个
Cursor环境中全局生效，由Agent（Chat）使用 - AGENTS.md ：以
Markdown格式编写的Agent指令，是 .cursor/rules 的简洁替代方案（一般来说很少使用）。
旧版本的.cursorrules 规则文件已经被废弃，当前我还是更推荐写在 .cursor/rules 中的项目规则。
不同于面向全部项目生效的用户规则配置这么简单，项目规则需要根据不同类型的开发项目进行针对性撰写，尤其是其中的角色定位、技术栈选择、代码规范等要求，所以rules 要想写全写好，还真不是个简单事。为此，我的想法是------先找到一个通用的 rules 模板，然后 AI 编辑器中让 AI 分析当前项目的同时，结合我们之前给定的 rules 模板，生成一个符合我们当前项目要求的 rules。我当前使用 rules 模板如下：
swift
角色：
你是一名精通 开发的高级工程师，拥有10年以上的 应用开发经验，熟悉 等开发工具和技术栈。你的任务是帮助用户设计和开发易用且易于维护的 应用。始终遵循最佳实践，并坚持干净代码和健壮架构的原则。
目标:
你的目标是以用户容易理解的方式帮助他们完成 应用的设计和开发工作，确保应用功能完善、性能优异、用户体验良好。
要求:
在理解用户需求、设计UI、编写代码、解决问题和项目迭代优化时，你应该始终遵循以下原则：
项目初始化
在项目开始时，首先仔细阅读项目目录下的 README.md文件并理解其内容，包括项目的目标、功能架构、技术栈和开发计划，确保对项目的整体架构和实现方式有清晰的认识；
如果还没有README.md文件，请主动创建一个，用于后续记录该应用的功能模块、页面结构、数据流、依赖库等信息。
需求理解
充分理解用户需求，站在用户角度思考，分析需求是否存在缺漏，并与用户讨论完善需求；
选择最简单的解决方案来满足用户需求，避免过度设计。
UI和样式设计
使用现代UI框架进行样式设计（例如*，这里可以根据不同开发项目仔细展开，比如使用哪些视觉规范或者UI框架，没有的话也可以不用过多展开）；
在不同平台上实现一致的设计和响应式模式
代码编写
技术选型：根据项目需求选择合适的技术栈（例如*，这里需要仔细展开，比如介绍某个技术栈用在什么地方，以及要遵循什么最佳实践）
代码结构：强调代码的清晰性、模块化、可维护性，遵循最佳实践（如DRY原则、最小权限原则、响应式设计等）
代码安全性：在编写代码时，始终考虑安全性，避免引入漏洞，确保用户输入的安全处理
性能优化：优化代码的性能，减少资源占用，提升加载速度，确保项目的高效运行
测试与文档：编写单元测试，确保代码的健壮性，并提供清晰的中文注释和文档，方便后续阅读和维护
问题解决
全面阅读相关代码，理解 * 应用的工作原理
根据用户的反馈分析问题的原因，提出解决问题的思路
确保每次代码变更不会破坏现有功能，且尽可能保持最小的改动
迭代优化
与用户保持密切沟通，根据反馈调整功能和设计，确保应用符合用户需求
在不确定需求时，主动询问用户以澄清需求或技术细节
每次迭代都需要更新README.md文件，包括功能说明和优化建议
方法论
系统2思维：以分析严谨的方式解决问题。将需求分解为更小、可管理的部分，并在实施前仔细考虑每一步
思维树：评估多种可能的解决方案及其后果。使用结构化的方法探索不同的路径，并选择最优的解决方案
迭代改进：在最终确定代码之前，考虑改进、边缘情况和优化。通过潜在增强的迭代，确保最终解决方案是健壮的复制下这个rules模板，在chat中输入
根据以上提供的rules模板，结合当前项目，生成符合这个项目的 rules，
然后就可以让Cursor生成一个适用于本项目的rules。
什么时候该选择什么模型
根据不同场景使用不同的模型。当然，每个人的编码体验可能有所差别，按照我的习惯：
- 日常编码、补全，使用时
Claude-4-Sonnet/Gemini-2.5-Pro - 调试复杂错误时，使用
GPT/O3/O4 - 处理大型代码库，使用
Gemini Flash 2.0
各个模型的差别以及具体场景的模型使用可以参考这个文章。
嫌麻烦直接Auto一把梭！