AI编程之Cursor使用技巧及一些思考

很多人说2025年是智能体元年，而在2024年，很多追求高效的程序员已经使用上了Cursor/Windsurf，它似乎让人从几年前的GitHub Copilot又更进一步，我也时常思考未来编程会变成什么样，Cursor以及LLM等对于整个开发流程又会有怎样的影响呢？

前言

本篇文章来源于2024年底在组内的一次技术分享，主题是《Programming with Cursor》。当时以演示为主，由浅入深和大家一起体验了Cursor的强大之处，也分享了一些使用技巧。在整理为博文时，发现其实不少操作视频更有利于理解，所以本文不求文字重现过程，而从另一个角度，谈谈Cursor协作编程的一点思考。

我会简单聊聊它的一些基本操作与设置，但显然手把手教学并不适合于此；然后是一些进阶的玩法，以及如何借助于它重构我们日常的开发流程；最后也扩展聊一点其它AI Code Editor的玩法，以及它们与Cursor的对比。我希望你在阅读本文前最好接触使用过Cursor，或者有其它一些AI辅助代码生成的经验，这会更加有助于理解我说什么。

好的，让我们开始吧。

Cursor的来由

要简单介绍它还不容易，如果你了解传统的Copilot，那么Cursor相比有更强的AI能力，以及更易用的交互。它的理念之一是：

“基于你的光标位置，思考你想做什么？”

我来回翻了下Cursor的BLOG，可以见到他们一直在提升它的上下文感知能力，以及多行、跨文件代码变更等。在比较后面的版本(0.43+)又提升了Agent等能力，进一步提升了AI自动化水平。而Cursor的一个标签挺有意思： Tab, Tab, Tab，这或许意味着它很懂你，你要的只是Tab确认一下，同时它支持多处修改，不断跳转。

Cursor基础交互

之所以能流行，我觉得Cursor把交互做得相当简洁了，主要就四个操作（以MacOS快捷键为例，其它平台自查）：

Tab：确认某一些代码变更或补全。
Cmd+K：在编辑器中对某一段代码进行对话或重写。
Cmd+L：唤出Chat窗口，与Cursor对话。
Cmd+I：唤出Composer，进行更复杂的如从0构建项目，或多文件修改对话。

不知道为啥，我个人觉得在编码中Cmd+K并不是太好用，它直接对代码进行改写，我更喜欢能看对前后Diff对比再采纳。所以个人最常用的可能是Cmd+L和Cmd+I。当然Cmd+K在命令行下挺好用，不必切换到聊天，直接生成命令执行，我印象中早些年有个编辑器叫Wrap，它出师未捷而中道崩殂了吧：）

Cursor更厉害的是它的引用能力。只要以@开头，可以引用不少内容，常见的如文件、目录、代码片段，以及更强大的web页面、外部文档，还有Git仓库中的提交等以及整个代码仓库code base等。这里可以简单聊几个小技巧：

有时候你和它聊一个东西，它显得张冠李戴了，大概率是上下文不够，你可以尝试@引用一些文件，或者对应的结构及函数。会发现它生成的可能更符合你心意了。
基于可以引用Git，它了解你的仓库情况，所以让它生成一些Commit Message也是不错的选择。格式规范，描述清晰，甚至我感觉它比我自己写得还好。
有些外部较新的文档，模型大概是没有学会的，这时@web或一个链接给它就很有帮助了。相信它读文档比你快还准确，唉，一边开心一边忧伤吧。
因为Cursor背后是大模型支撑，所以其上下文有所限制，有时太长你会发现它好像忘记之前的一些内容了，建议适时Cmd+N起一个新的聊天窗口。

Cursor进阶玩法

老实说第一次开启了Agent后的试用，有一些行为让人惊喜连连。这一节我们聊几个进阶玩法，主要涉及agent模式/yolo模式以及定制化.cursorrules文件，背后的工作原理似乎也是显而易见的，但是却有大用处。

Agent模式

Agent模式需要你的版本在0.43+，有些同学说它的Cursor怎么找不到，我这也不是特供版呀：D 你只是没更新而已（不过更新后也有同学反馈之前通过不断Delete Account来获得反复体验权的被拦截了，原因未知）。对于这种迭代更新较快的软件，及时更新能获得更强大的功能。初步的Agent已经能够做一些我们琐碎的事情了，从自动编写代码，到自动修复一些lint错误，以及自动生成单元测试用例和自动生成提交。

惊艳到我的是，我让其重构一段代码，它同时尝试修复相关lint，发现protobuf的proto有修改，自动去编译proto，它先尝试命令make proto，发现报错了。接着分析我的Makefile，察觉到是基于Earthly来构建的，并且发现了make code命令可以生成相关协议，接着自动执行编译与修复工作。一切就绪后，给我生成了一个不错的Commit Message，并自动提交了。这期间我就是看它表演，时而让我确认一下要执行的命令，我面带微笑点确定，又一次有点忧伤。

YOLO模式

在使用Agent模式时，当遇到需要在计算机上执行一些命令时，有时会询问于你，要使用者主动点确定，主要是隐私等考虑。但有时我们想更快捷认为可以授权它去做点事，这便是Yolo功能的出现背景，要使用此功能则需要0.44+的版本。相对开启Agent，Yolo这个相当于一个配置，说是一种模式略显牵强。当前默认是不开启Yolo的，显式的为了安全起见，我们还是可以配置允许它自动执行哪些命令，白名单或黑名单都支持。

在启用YOLO后，Agent模式下工作会更加自动化，多数时候已经可以“围观”机器工作了。这个模式我使用的经验倒不是特别多，有时候似乎有些低效的循环，但未来价值可期。

定制化`.cursorrules`

写文章时再查了一下，前几天更新的0.45版本又一次提升了.cursorrules文件的定制能力，它支持了多仓库级的rules配置，未来研究一下实际效果。我们先说两种使用方式：

全局的Rules For AI。在Cursor的设置中可直接输入，可以配置一些全局规则，比如我就让它回复使用中文，但是代码注释使用英文，效果很明显。
在根目录定义.cursorrules文件，在它上面写上你想告诉Cursor的一些提示词。

网上也能找到一些不错的提示词总结，比如awesome-cursorrules。我试着将仓库特定的规则告诉它，比如代码风格，比如一些工具或编译等，这都有助于我们未来更好的与AI沟通。

这个过程中，其实我们还可以偷懒，甚至.cursorrules也是由AI来写的，它基于README或code base，可以帮我们完成一个初稿，我们自己再补充完善一些，未来这就是喂给AI的一部分提示词了。我在想，若是能够不断编辑完善rules，比如如何写一个测试用例，如何写注释，如何写一个模块，那么真的很可能取得不错效果，这一块我应该未来还会持续有更多实践，特别是工作中会经常和某几个仓库打交道，必然有些成熟的惯例是AI能轻松学去的吧：） Cursor Rules

Cursor的其它实践

单元测试

有一些工作是我们平常自己厌烦的，但是咱们的AI助手可是任劳任怨，比如写更多单测。我们自己写平常会有两大问题，用例想不完全以及偷懒覆盖不足。这种目标性比较确定的事情，在Cursor中是比较容易完成的，当然前提是你的代码比较规范，也有一些可参考的示例。

也有些场景生成的代码不太符合预期，那么如何写出AI友好的用例/代码呢？我看Behavior Driven Development (BDD)挺不错，它强调行为，而不是实现，所以可以更聚焦于功能，而不是实现细节。有这种代码框架后，细节刚好AI可以补全，而咱们只需要关注于功能（即用例）。在Go语言中，可以借助于Ginkgo(https://onsi.github.io/ginkgo/)，它支持BDD框架。你看着感受一下会不会AI友好些：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
var _ = Describe("Books", func() {
  var foxInSocks, lesMis *books.Book

  BeforeEach(func() {
    lesMis = &books.Book{
      Title:  "Les Miserables",
      Author: "Victor Hugo",
      Pages:  2783,
    }

    foxInSocks = &books.Book{
      Title:  "Fox In Socks",
      Author: "Dr. Seuss",
      Pages:  24,
    }
  })

  Describe("Categorizing books", func() {
    Context("with more than 300 pages", func() {
      It("should be a novel", func() {
        Expect(lesMis.Category()).To(Equal(books.CategoryNovel))
      })
    })

    Context("with fewer than 300 pages", func() {
      It("should be a short story", func() {
        Expect(foxInSocks.Category()).To(Equal(books.CategoryShortStory))
      })
    })
  })
})

未来如何在更多场景中使用AI来帮助完善单测是值得探讨的事情，希望有更多实践后能和大家分享更多心得体会。

Code Review

没想到吧，AI除了帮你写代码，当然也能帮你评审代码。随着不停的听着各种AI刷爆排行榜，那么我也期待它们能帮我把控更多的风险。我尝试将工作中的一些比较隐蔽的BUG，通过Cursor来评审，发现它确实能发现一些问题，甚至一些我们组内多人评审都漏掉的问题。我不由得想，如果大家提交代码前，都有一个这么强力的助手帮你先看看本次改动，提供一些参考建议，那么提交的代码质量会更高，也更有信心。

任劳任怨的AI，它不会因为一次修改几百处而眼花缭乱，它只会默默的遵从你的指定帮你检查。所以给CR的提示词也比较关键，这里我们可以看一下网上的一些总结ai prompts for code reviews。不过我感觉不同团队或项目最好有自己定制的CR规则，比如就写在.cursorrules文件中，这样更有针对性。

这里有点小技巧，我们在Cursor中提交代码前，可以@git选择PR (Diff with Main Branch) ，这样Cursor会基于当前的diff来评审，而不是基于整个仓库。模型上我建议你选择更强的模型，比如claude-3.5-sonnet或者o1-mini等。

我最近拿了一个较复杂的提交来让AI进行Code Review，使用claude-3.5-sonnet模型以及4o都没有发现问题，但我切换到o1-mini，它能够发现。我又试了一下国产最近大火的DeekSeek V3，也能够发现问题。给国产模型点个赞！所以作为CR使用，面对复杂的场景我们就别节约这点消耗啦：）

其它AI Code Editor

除了收费的Cursor/Windsurf等，我们还可以有免费的vscode + cline插件来实现比较好的AI辅助编程体验。当然现阶段我推荐你使用Roo Cline插件（好像又改名叫Roo Code了，这是要摆脱Cline身影啦），它在消耗token上更友好，还有更多功能待你发现。结合上面提到咱使用国产的DeeSeek V3，甚至换上又火爆全球的DeepSeek-R1系列模型，价格便宜，性能强大，应该也是不错的。有点遗憾的是这些插件可能因为只是“插件”，各种体验我感觉还是略逊一筹。

另外，发现Cline有个比较有意思的扩展：MCP Servers。基于MCP（model-context-protocol）协议，定义了模型和工具互相交互的一种范式。当前已经有不少支持它的server了，比如和Git/Sqlite等交互，甚至Cloudflare有：

Cloudflare - Deploy, configure & interrogate your resources on the Cloudflare developer platform (e.g. Workers/KV/R2/D1)

还有不少第三方的MCP server，不确定未来是不是能够此标准一统天下，但它是一个不错的思路，也具备一定的想象空间。

后记

因为时间有限，对于Cursor的体验也说不上深入，但似乎能够看到它带来的工作效率的提升。我们常听说，未来淘汰我们的不是AI，而是不会使用AI的一批人，我不确定是不是自媒体卖课时的危言耸听，但也值得提醒我们，如何不那么轻易被替代。做不了10x程序员，咱有机会2x, 3x吗：）

短期内来说，怎么将这种能力融入到日常开发流程中，并且获得货真价实的质量与效率提升，才是更有意义的事情。欢迎大家一起交流探讨一下你们是如何使用的呢？也欢迎指正文章中的错漏之处，共同学习，共同进步。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：

扫码关注公众号

前言