Cursor 实战万字经验分享，与 AI 编码的深度思考零 ❀ 引在使用 cursor 编程的过程中，我知道大家偶尔会

零 ❀ 引

在使用 cursor 编程的过程中，我知道大家偶尔会有如下感受：

我只是单纯想和 cursor 聊天聊问题，为什么 cursor 莫名其妙非要去改我的代码？
我 prompt 里都说了只改 A 功能，怎么除了 A 还偷偷把我的 B 功能也顺带改了
一个功能聊到后面，怎么感觉 cursor 理解越来越笨了，一个功能来来回回死活改不好，还不如我自己动手快，犹豫后续还用不用 AI 写代码。
一口气生成整个需求代码了打补丁快？还是边写代码写提问快？
project rule 和 user rule 什么区别？project rule 拆多大的粒度更合适？后更新的 cursor memories 和前面又有什么区别？
pro agent 不限额度，我们的 biz 到底限制额度没？
....

其实除了大家，我自己在很长一段时间也有类似的疑问，对 cursor 的看法也发生过多次改变；而在最近的三个月，我也一直尝试要求自己不要手写任何代码，尽可能全部靠 cursor agent 生成，这个过程中我也做了多次 rule 和开发习惯的调整与对比测试，于是也有了一些心得和感悟，今天讲给大家听。

壹 ❀ 前置概念

在聊具体问题之前，让我们先建立几个 cursor 中比较重要的概念，这也利于后续大家理解和接受本次的观点。

1.1 cursor 提问的 token 计算

我们知道不同 model 都有不同大小的上下文，上下文越大的模型自然能接受更大的提问信息，那么在 cursor 中我们的任意一次聊天，大致会产生如下的 token 计算：

初始 Token 组成：

初始输入 = 用户问题 + Rules + 对话历史

用户问题 : 我们输入的文字 + 主动添加的上下文（图片、项目目录、文件）。

Rules：project rule + user rule + memories

对话历史：对话产生的历史。

工具调用后的 Token 累积：

cursor 接收用户信息后开始调用 tools 获取更为详细的信息，并为问题回答做准备：

总 Token = 初始输入 + 所有工具调用结果

额外的信息：什么是工具调用？比如我们问代码问题，cursor 经常会出现触发 codebase_search（项目代码查询）就是一次工具调用，而我们安装的 MCP 其实都内置了多个工具，可以在设置里查看 MCP 点击展开查看内置的 tools。

下图就是 cursor 对话中对于工具的调用：

cursor 模型分为 normal 和 max 两种，normal model 一次 request 最多调用 25 次 tools，用完就要消耗下一个 request 额度，max 模型每次 request 有 200 次 tools 调用且拥有更大的更大的上下文，对于编程这种需要人为精确干预的任务，我不推荐使用 max， max 更适合全程自动化的任务，比如 cursor background agent。

那么到这，我们能有一个基本的结论，在不超出模型上下文的情况下，我们对于问题描述越清晰，AI 对于问题的处理就会越准确；反之上下文中掺杂过多臃肿的无用信息，这会影响 AI 的判断与回答的质量。

因此，我们如果要提升 cursor 对于问题的理解，方向自然聚焦在 rule 优化、用户问题表达和对话历史几个方向，具体怎么做后面再谈。

1.2 关于 project rule

rule 是一种供持久且可重用的上下文定义，project rule 顾名思义属于专为项目配置专属 rule， project rule 跟着项目走，如果你换了一个新项目之前的 project rule 会丢失，需要再次为当前项目新建 project rule。

在 cursor 0.49 版本后，支持在 chat 时输入 /Generate Cursor Rules 由 cursor 自动为当前项目生成 rule，或者直接复用社区中一些比较优秀的 rule 模版，再针对项目情况做二次修改，比如：

project rule 支持四种生效规则：

规则	描述
`Always`	Always included in the model context 始终包含在模型上下文中
`Auto Attached`	Included when files matching a glob pattern are referenced 当引用匹配 glob 模式时包含
`Agent Requested`	Rule is available to the AI, which decides whether to include it. Must provide a description 规则对 AI 可用，AI 决定是否包含，必须提供描述
`Manual`	Only included when explicitly mentioned using `@ruleName` 仅当使用 `@ruleName` 明确提及时包含

同样的，我们先掌握这个信息，具体优化后面再聊。

1.3 关于 user rule

user rule 也是一种用于持续化重用的规则，与 project rule 不同的是此 rule 跟随用户 cursor 账号，如果你配置过一次，后续无论你打开什么项目，用户 rule 都会存在和生效。

另外需要注意的是 user rule 修改做不到实时更新，做简单的测试是定义后直接问 cursor 当前 cursor rule 是什么，如果大家希望 user rule 立马投入使用，最好的办法是在对话中直接输入新版 user rule 将记忆注入进去。

1.4 关于 memories

cursor 1.0 更新了全新的 rule 分类 memories，不过如果需要使用这项能力，需要用户关闭隐私模式，或者将隐私模式调整为这个选项，目前我们 biz 版本已经让叶子调整了团队规则，所以后续新的 cursor feature 大多数大家都可以直接体验。

与 project rule 类似，memories 也是跟着项目走，但两者的本质区别在于：

Project rules = "我希望你这样做"（主动设置的规则）
Memories = "我记得你喜欢这样"（从交互中学到的偏好）

cursor 会在日常聊天中自动学习和理解我们的项目预期，你可以主动要求记录 memories，或者在被我们严厉批评时，它也会自主记忆。

主动创建记忆：

cursor 的反省与学习：

1.5 关于套餐和计费

cursor 在本月调整了订阅策略，pro 不再限制 model 调用次数，但限制了问答速率，比如一个小时内你最多问答多少次，速率达到就会进入几小时 CD 阶段，只能使用免费模型；

大家一定会好奇我们 biz 版本是否是无限，这点我麻烦叶子跟 cursor 官方确认了这一点，结合 cursor 官方的定价说明，其实我们现在还是每月固定 500 次高级模型 request，无限免费模型调用，且大家也能使用 max 模型，但 max 会消耗大家的 reques 次数，按 tools 次数粗略估算，一次 max 请求可能等于 8 次 normal 问答，消耗会非常恐怖。

贰 ❀ 如何让 cursor 听懂人话？

回到分享引言部分的问题，大家使用 cursor 大多数都希望 cursor 真的像一个 AI 伙伴，它能听懂我在说什么，知道我当下要什么，并为我提供最好的问答体验，我们应该如何改善这一点呢？接下来我们从几个方面解决。

2.1 简化和拆解 project rule，要求越多等于越没有要求

我先贴一个官方的最佳实践要求，然后结合 notta web 的项目规则来聊聊我们如何做的更好。

我对于 project rule 有两个非常明确要求，最基本应该包含你当前项目的技术栈使用，以及对应依赖版本；除此之外应该包含社区编码明确要求的规范，因为不同公司开发规范不同，cursor 没办法自然理解你的编码风格。

还记得前面我们聊到因为 token 有限，每次问答尽可能清晰定义，明确要求，以 notta 项目当前的 project rule 我们可以做如下优化：

project rule 需要明确生效的范围，不要一股脑设置 Always

我们目前 notta 5个子项目的 rule type 都设置为了 always，事实上 always 会默认将这些规则添加到每次问答的上下文中，很致命的一点是，我明明在聊 notta web 的需求，cursor 会把 showcase web、插件好几个不相关的上下文也默认带进来，这些会严重浪费 token 数量增加无效信息。

我更推荐使用 Auto Attached 并使用 glob 去明确匹配目录，比如：

或者使用 Manual 模式，在聊天时主动把要匹配的 project rule 添加到上下文中。

内容应该精简，不要重复描述，可以添加代码描述，但并推荐加入大量的代码示例，非常浪费上下文

还是以 notta web 为例，可以看到对于项目技术依赖出现了多次描述

其实这里完全可以做一个合并，而且在 notta web 里还出现了对于插件的说明，其实这就是重复且无效的上下文。

其次，虽然官方提到必要的时候提供例子或参考文件，但不推荐在 rule 写大量的示例代码，除非这个例子非常典型、重要或者适应性非常广，我个人更习惯具体问题分析时提供具体的参考以强化 cursor 理解，那么此时 rule 里的示例本质上就是多余的。

不要添加假大空的规则，如果你觉得某些规则确实偶尔需要，拆解成单独的rule设置为 Manual，具体问题具体引入

还是 notta web 的例子，如下就是假大空的要求：

我觉得一个规则好不好，最简单的例子就是把规则代入到自己的日常开发，你知道怎么做到怎么写代码让 LCP ，FID 更好吗？实话实说我真不知道，太宽泛了；

实不相瞒，这几句废话规则就是第一版 rule 我加进来的（ = =。），而且事实证明这小半年我没看到 cursor 在编码上有任何以上要求的体现，甚至在 react 组件时还会给我写出无限渲染的组件，不是 cursor 不想做，是当下真的做不到，冷门且重要的规则单独拆出来，具体问题具体要求！

以现在服务端不同服务有不同的项目，就非常为这些单独的服务都配置独立的 project rule，notta 的项目规则接下来我们也会重新做一次优化。

总结：

2.2 增加过程决策，而非放任 AI 编码

老实说，我之前过度追求提前写好方案，然后迫不及待让 AI 一口气帮我完成整个需求，我觉得这太炫酷了，我只需要扮演 prompt 输入、代码审核和测试的角色做就好了，但事实上需求实际表现让我很失望，我发现生成的代码质量很差，除了目录和框架搭建能用，具体组件的代码非常糟糕。

即便我在 project rule 、user rule，memories 都增加了必要编码的规则，但遗憾的是它就是会出现幻觉和失忆，我突然意识到在 AI 编程上我有一个很严重的错误，在当下过分依赖和相信它的自动化编程，这个过程中我缺少了一个非常重要的环节 -- 决策。

我举一个实际的例子，大家有没有遇到过 cursor 明明代码都写好了，但 cursor 好像突然又意识到了什么，然后立刻对之前实现的代码开始“优化”，这种 AI 的反悔本质上是 AI 遇到了一个决策点，但我们做不到暂停只能任由 AI 替我们决策，于是我们得到了一份薛定谔的代码，在代码 review 之前它可好可坏。

为了避免此类问题的发生，我在 user rule 增加了一个规则，凡是在方案、编码过程遇到任何争议或不确定，必须在第一时间主动告知我由我做决策。

我提供了部分更新 rule 后 cursor 的表现截图：

体验一下好起来了，通过这种互动我能时不时加入更多明确的要求和预期，帮助 cursor 不断完善和理解当下的诉求，代码可用度得到了明显改善。

总结：

2.3 采用渐进式开发，而不是大需求一口气梭哈

说在前面，我不推荐大家输出完方案后让 cursor 一口气基于方案完成需求（非常小的需求除外），需求越大代码质量越烂，这一点我基于不同规模的需求做了多次实验，这个结论我可以百分百确定的同步给大家。

为此，我的改变是在方案阶段我会明确要求 cursor 在双方都没问题之前不要输出任何方案，而确定方案后要按步骤依赖关系将需求拆解为 N 个步骤，通过步骤拆解以及决策的 rule 限制，我能在开发阶段的每个环节及时补充上下文。

因为步骤拆解加干预，这个开发过程理想但不完美的 0 - 100，变成了 0 - 10 - 50 - 70 - 100，看起来后者更麻烦和更慢，但实际体感上快了不少。

总结来说，关于渐进性开发，有如下几个优势：

任务粒度越小，AI 完成度越高
一口气完成需求往往带来很多 bug 和不正确的代码，AI 特别容易基于错误堆错误（将错误的代码作为上下文继续制造错误），导致怎么改改不对的烦躁情况，小范围利于人为监管和把控。
分步骤代码量便于做 code review，一次改一大片很难去理解（有同学出现了 AI 代码漏审的情况）

总结：

2.4 明确要求每次改动基于最小范围修改原则，并提供尽可能清晰的上下文

我举一个实际的例子，我在做 notta 设置 automation 时，希望 cursor 基于新接口数据帮我调整业务逻辑，但我并未要求最小范围这一点，也没提供具体的目录信息，在 AI 完成工作后，我发现因为 AI agent 模块也有自动化的需求，于是 AI 出于“好意”把一个相距十万八千里的目录也给我修改了。

而明确要求最小范围改动原则的好处是，我要什么你给什么，不要画蛇添足，除非我明确要求重构或者优化，一定按我的要求指哪打哪。

关于提供明确的上下文这一点，直接给给大家举一个更实际例子，AI 终端 warp 对于我命令的执行对比：

基于全局目录，要求 wrap 帮我构建 notta 插件 uat 包，纯查找耗时 30 多秒（经历了查找、尝试多次摸索）。

明确指定 notta 插件目录，同样的话术，AI 查找只用了 5 秒。

我们很容易陷入一个误区，我之前总觉得 AI 就是自动化高科技的代表，给它一个命令后坐着喝喝茶享受 AI 帮我干活的等待时间，但等待除了不够高效之外，因为目的的不明确，AI 很容易基于它自己的理解做出与我们预期违背的事情。

能直接给目录范围限制，就不要说帮我修改自动化里的什么逻辑，能给 prosemirror 目录就不要说帮我查看编辑器里的需求，cursor 甚至都不知道我们表达的编辑器是不是 prosemirror，AI 只是一个基于概率学的问答机器，所做的一切只是为了让正确的概率变得更高而已。

总结：

2.5 相同需求一个窗口，不同需求不同窗口

有一个非常重要的前提，cursor 每个聊天的窗口上下文不共享；

不知道大家有没有这种感受，我在一个新窗口刚开始跟 AI 对需求时它非常清晰，可随着聊的越来越久，cursor 特别容易对细节失忆或者出现幻觉，这个原因是这个窗口的上下文越来越大（回顾下我们开头的 token 计算原则），导致你原本的问题在上下文中不断被稀释，AI 逐渐失忆和不清晰了。

针对这种情况，有两种办法解决。

如果你希望继续讨论这个需求，再次重申你的方案和 rule，更新上下文，强化窗口中 AI 对于需求的记忆。

如果是额外的话题或者需求，直接新开一个窗口，一切从零开始会获得更好的体验。

总结：

2.6 小错误修，大错回滚，不要错误上堆错误

AI 编程过程中，如果是比较小且你能掌控的错误，你可以考虑基于问题让 AI 二次修复；但一旦 AI 输出跟你理解偏差较大，直接让 AI 回滚后基于现状重新调整 prompt 和更新上下文，能重构就重构，不要舍不得那点 request 和代码，比起浪费的时间这些都不值一提。

举一个贪吃蛇实现的例子，cursor 基于错误的实现作为上下文，陷入了自我纠错的死循环（我知道 cursor 很急，但我比 cursor 还急）

总结：

OK，那么到这里，我们讨论了 cursor 编码的一些细节，通过上文的总结，这里分享下我自己的 user rule:

1. 如果我要求先讨论方案时不要着急修改代码，直到方案确定才可以修改代码。
2. 方案讨论需要在我们双方都没疑问的情况下才可以输出具体方案文档。
3. 方案评估请主动思考需求边界，合理质疑当下方案的完善性，方案需包含：重要逻辑的实现思路、需求按技术实现的依赖关系拆解并排序，便于后续渐进式开发、输出修改或新增文件的路径、输出测试要点利于需求完成后的自动化测试。
4. 方案讨论或代码编写时，如果遇到了争议或不确定性请主动告知我，请牢记让我决策而不是默认采用一种方案实现，重点强调。
5. 开发项目必须严格按步骤执行，每次只专注当前讨论的步骤，要求：不允许跨步骤实现功能或"顺便"完成其他步骤任务、实现前必须先确认技术方案和实现细节、每个步骤完成后必须明确汇报，等待 Review 确认后才能进入下一步。
6. 与第五点类似，任何代码修改请始终遵守最小改动原则，除非我主动要求优化或者重构。
7. 代码实现请先思考哪些业务可以参考或复用，尽可能参考现有业务的实现风格，如果你不明确可让我为你提供，避免重复造轮子。
8. 在 bug 修复时如果超过 2 次修复失败，请主动添加关键日志后再进行尝试修复，在我反馈修复后主动清除之前的日志信息。

叁 ❀ 用 MCP 武装你的 cursor（偏前端）

OK，我们聊完 cursor 对话的细节，接下来花 10 分钟分享我目前在开发中高频使用的 MCP，这个偏前端，我们快速过一下。

3.1 review gate v2

一个能让 request 从 500 次变成大约 2500 次的 MCP，原理是拦截每一次 request 后反复消耗 tools 调用，除非达到 25 次调用号才消耗下一次 request 额度，实测有效，比如到今天为止我的高频对话也就用了。

除了省次数之外，它还有两个我额外喜欢的优点：

当 cursor 遇到决策点时会暂停对话主动唤醒 review chat，便于我提供额外信息后继续对话，非常适合渐进式开发的节奏。
对话信息分离，我的消息在额外对话框，而cursor 回答在右侧，感官上会更清晰

关于 review gate v2 安装说明可见额外的文档：集成 Review-Gate MCP，让 cursor request 增长到 2500 次

3.2 Stagewise

一个能打通 Chrome 和 cursor 的 mcp，我们只需要选择页面元素后提问，Stagewise 能将对应组件的信息同步到 cursor，帮助我们快速建立问答上下文，省去自己找文件的时间，实现指哪打哪。

另外，在 cursor 1.0 版本之后，由于 cursor 安全策略，Stagewise 发送消息到 cursor 后无法做到自动提问和执行，需要用户点击一次 send 按钮，此问题已给 stagewise 提 issue，问题跟踪可见：bug: Stagewise messages to Cursor don't auto-execute - manual send button click required each time.

我对它最大的感受是，在帮助修复词汇表优化需求时，有多个逻辑 bug 我都直接通过 Stagewise 选择对应组件，输入荣慧的 bug 描述，实现 bug 自动修复，对于不复杂的 bug 非常实用。（荣慧可以作证！！）

3.3 Playwright

Stagewise 只能帮我们获取页面元素信息，但做不到获取控制台和接口信息，而 Playwright 正好是一个能直接获取控制台接口信息、接口信息、具备页面视觉且能做自动化测试的 MCP 工具。

它的集成非常简单，在 MCP 配置中添加如下配置即可，然后重启 MCP：

"playwright": {
  "command": "npx",
  "args": [
    "@playwright/mcp@latest",
    "--browser",
    "chrome",
    "--image-responses",
    "auto"
  ],
  "env": {
    "DEBUG": "pw:*"
  }
},

我最终添加这个 MCP 其实只是为了更快获取控制台信息，而不需要我截图或者复制控制台信息到 cursor，但让我意外的是，一旦基于 playwight 启动项目，目前问题解决过程中，cursor 会自动基于此 MCP 完成自动化测试 -- 信息获取 -- 再次测试的过程，我甚至不需要干预，也就是 cursor 已经在全自动实现需求 - 测试 - 修复 bug ，非常惊艳。

playwright 魅力时刻：

AI 自己添加调试日志，自己进行测试以及查看日志：

修复 bug 成功自动移除调试日志代码：

再次测试，并输出问题报告：

前端还是吃的太好了。

另外，bug AI 修复如果超过 2 次修复失败，建议让 AI 补充日志后再修复，修复率可以达到 7 层左右，这点非常实用。

当然，实际开发中为了追求效率，我还是推荐使用 Playwright 获取信息，开发阶段不要太依赖它的自动化测试，因为对比我人为测试就是没我快，如果大家时间充裕，当然也可以喝喝咖啡看它操作，这里给大家做个简答的演示。

那么有了 playwright 还需要 stagewise 吗？答案是需要，因为 playwight 比较依赖自然语言对于界面的描述，对于复杂交互，我还是推荐 stagewise 直接点击具体元素后提问，快速建议对话上下文，两者强强联合。

肆 ❀ 一个实际的开发例子

聊完工具，给大家简单演示下我是如何使用如上的问答技巧，以及 mcp 工具开发一个需求。

我现有的需求开发流程为：准备给 AI 阅读的需求文档 → 与 AI 讨论方案设计(含争议确认) → AI 输出方案文档 → 严格按步骤实现 → 分步骤 Review 确认 → 完成开发自动化测试验收，输出测试和需求完成度报告（自动化有一定局限性，请根据实际情况使用）。

初次对话：

方案的多次讨论：

分步骤渐进式开发：

分步骤的自动化测试

输出最终测试报告，更新方案

这个需求原本的规模在 M，考虑到界面交互、逻辑对接、接口联调等等，保守估计需要 2 天左右的投入，那么利用 AI 开发完这个需求，实际投入不到 1 天，这就是 AI 编码的魅力。

伍 ❀ 本期分享主题

打破 AI 编程的第四面墙：AI 时代下的决策者。

AI 会不会取代我？我其实认真思考过这个问题，在去年 AI 自动编码逐渐兴起时，我内心本能的也有过一点点抵触，忘记了之前谁分享过 Twitter 上一个人对于 AI 的观点，与此人感受相同的是，我的抵触在于不愿意承认 AI 的出现让自己这么多年的努力价值清零，初级开发或者非开发人员用好 AI 也能写出非常漂亮产品。

vibe coding 现在非常火，甚至出现了不少的一人公司的个人创业者，AI 帮助这些人把想法变成现实，且随着模型不断迭代，我相信未来一定会出现有自然语言标准的编程语言，开发者与非开发者之间的能力边界也注定会不断缩小，那么回到当下我的价值在哪？

在这几个月的 cursor 编程摸索中，我始终想了解 cursor（AI）的上限在哪，在大量的基于 AI 做需求做问答后我也逐渐清晰，人类与动物的区别是人类会使用工具，我与 AI 的区别是基于 AI 上下文的限制，在特定场景下我能利用经验帮助 AI 做出正确的决策；还记得去年满华对于 AI 的原理分享，AI 问答的输出本质上是一门概率学，而我们知道怎么让成功的概率变得更大。

AI 不会淘汰每一个人，但 AI 必然会淘汰高替性岗位下下不会使用 AI 的人。

岩哥之前在 general 分享过一个 YouTube OPENAI 联合创始和对于 AI时代下软件变化的演讲视频（大家如果觉得太长可以直接看荣慧总结的记录）

然后荣慧就立马截图 Q 我， echo 你快看看，这里圈出来的观点说的就是你，不要对全自动的 AI 过度兴奋！！

虽然我在武汉办公室天天 “cursor 好牛啊”，“发现一个 AI 工具好牛啊” 每天都迫不及待给大家分享新成果念个不停，但澄清下我其实也过了对 AI 编程自动化兴奋的阶段，本次分享的主题也是给 AI 增加决策。