在与AI和AI编程特别相关的论坛中，我经常看到经验丰富的软件开发者的共同疑问：是否有人从像Cursor这样的工具中获得价值，订阅价格是否值得？
几个月来，我一直使用Cursor作为个人和工作项目的日常开发工具，有一些观察可以分享关于这是否是一个“必需”的工具，或者只是一个短暂的流行趋势，以及一些快速获取最大效益的策略，这些可能有助于您如果想要试用它。有些人可能已经尝试过Cursor并觉得不尽如人意，也许以下一些建议可以激发您再次尝试的兴趣。
我不是由Cursor赞助的，也不是产品评论者。我不推崇也不贬低这个产品，而是分享自己的使用经验。
我是谁，这篇文章的读者是谁？
我已经编写了36年的代码，涉及多种语言，但专业上专注于以C为主的计算机游戏引擎和Go/Python/JS Web开发。我期望读者具有类似的熟练度，能够在大型代码库中高效地编写和调试代码等。对于初学者，如果他们希望通过AI学习编程概念或编写远超其水平的代码，我会有非常不同的建议！
对我来说，AI副驾的吸引力在于它可以处理样板和重复的任务，让我能够专注于任何特定问题的有趣逻辑。我也不是很感兴趣于自动生成大量代码；我对“编写的代码行数”作为一种效率指标持高度怀疑态度。我更愿意少花时间编写相同数量的代码，多花时间思考边缘情况、可维护性等问题。
Cursor是什么？
Cursor1 是 Visual Studio Code (VS Code) 的一个分支，集成了大型语言模型 (LLM) 驱动的功能到核心用户界面中。这是一个专有产品，提供免费层和订阅选项；然而，定价表没有涵盖订阅者福利的具体内容及其与其他竞品的比较。我将在下面讨论功能时基于自己的理解进行澄清，但简单的总结如下：
- Tab 完成：这是一组专有的微调模型，可以在编辑器中提供代码完成，同时导航到下一个推荐操作，所有操作都通过Tab键触发。仅对订阅者可用。
- 行内编辑：这是一个聊天界面，用于通过简单的差异视图对选定代码进行编辑，使用的基础模型如GPT或Claude。对免费和付费用户均可用。
- 聊天侧边栏：这也是一个聊天界面，用于在侧边栏视图中进行较大编辑，允许更多空间进行长时间讨论、多文件代码示例建议等，使用的基础模型如GPT或Claude。对免费和付费用户均可用。
- 编辑器：这是另一个专门用于跨代码库大型重构的聊天界面，生成多个文件的差异，可以逐页查看并批准，使用的基础模型如GPT或Claude。对免费和付费用户均可用。
Tab 补全
虽然其他LLM驱动的编程工具侧重于聊天体验，但在我的使用过程中，Cursor的Tab完成功能最自然地融入了我的日常编码实践中，并节省了最多的时间。显然，这一特性背后投入了大量的思考和技术研究，因此它不仅能够为一行、几行或整个函数建议完成，还可以建议下一次编辑应跳转到的行。这意味着您可以部分完成一项更改，然后通过反复按Tab键自动完成整个文件中的相关更改。
一种使用方法是将其作为超级增强版的代码重构工具。例如，假设我有一个代码块，变量名采用 under_score 格式，我想将其转换为 camelCase。只需重命名一个变量的一个实例，然后依次按下Tab键更新所有需要更改的行，包括其他相关变量。许多繁琐且容易出错的任务可以通过这种方式自动化，而无需编写脚本来实现。
有时，Tab补全会独立发现错误并提出修复建议。很多时候，当我在Python或Go中添加依赖项时，它会建议导入。如果我在字符串中加上引号，它会适当地转义内容。与其他工具一样，它可以根据函数签名和可选文档字符串编写整个函数。
总的来说，这个工具感觉像是在读取我的想法，猜测我的下一步行动，使我能够少思考代码，多思考正在构建的架构。
还值得一提的是：补全是 异常快的，我从未因等待建议而感到延迟。建议基本上在我停止输入后立即出现。等待时间过长肯定会使我放弃使用。
那么，我对Tab补全的不满有哪些？一个是小烦恼：有时我没有及时看到建议而继续输入，补全消失了。一旦消失，似乎没有方法让其重新出现，所以我必须输入其他内容并希望再次出现。
另一个问题是完全相反的情况：有时补全是完全错误的，我故意拒绝它。随后，但非常罕见地，我会接受一个完全不同的补全，而之前被拒绝的建议也会悄悄地应用。这已经导致了一些难以追踪的错误，因为我不知道错误逻辑已被接受。不过，我还没有发现这种情况频繁到足以抵消Tab完成带来的生产力提升，但它确实有所减损。
行内编辑、聊天侧边栏和编辑器
据我所知，这些功能在与基础模型交互时非常相似——我几乎 exclusively 使用 Claude 3.5 Sonnet——不同之处在于用户界面。
行内编辑可以通过选择一些代码并按下Ctrl-K/Cmd-K调用。我输入所需的更改，文件中会显示一个不错的差异视图，我可以接受或拒绝。我主要用它来实现函数内的代码片段或进行细微的重构。
一个很好的例子是，如果我有一个遍历某些任务的循环，并希望将其并行化。
聊天侧边栏通过Ctrl+L/Cmd+L打开，提供了更多的空间用于多轮对话。尽管我对迄今为止测试的所有LLM模型的一个小烦恼是它们 总是 先返回代码，而不是在有任何歧义时请求澄清。建议的代码有一个应用按钮，会在当前选中的文件中创建差异。这对于单个文件内的大型重构或根据当前打开的文件创建新文件非常有用。如果其他文件相关，可以手动添加到上下文中，但Cursor会根据查询和后台生成的索引尝试猜测相关文件。
这里是一个示例，将应用程序的数据库API创建为REST API以访问它，并包括参数验证和正确的HTTP状态码，然后 编写一个客户端库来访问该REST API。
另一个示例，我使用聊天侧边栏将客户端库从Python转换为Go。注意松散类型的Python是如何转换为定义良好的结构类型和惯用的Go，包括错误处理！这根本不是1:1的重写。
最后，编辑器专门用于跨文件重构。这是我使用最少的功能，但提供了更好的用户体验，可以逐个审查多个文件的差异。
.cursorrules 文件
直到我在（在我看来过于简略）文档中发现这一功能之前，我都没有意识到它的存在。各种聊天模式始终包括位于工作区根目录下的 .cursorrules 文件的内容，以提供额外的上下文。我一直在尝试使用这一功能告知LLM仓库的编码标准、常用包和其他文档。
这一功能可能有助于解决我在使用Cursor时观察到的一个主要障碍：除非在您正在编辑的同文件中已经存在，否则它不会遵循编码风格和模式。例如，在Khan Academy，我们使用一个专有库2 用于在Go中传递函数之间的上下文。这用于日志记录、HTTP请求等，因此LLM需要能够使用它。这在过去一直很困难，但或许一个编写良好的 .cursorrules 是一个好的第一步。
当前的一个限制是每个工作区只有一个这样的文件，因此像我们这样的包含多种语言代码的单存储库（monorepo）将比拥有少量且样式非常一致的代码的小存储库更难以设置。
文档还建议 .cursorrules 文件仅用于聊天模式，而不是标签补全。但是，我已经尝试在工作区中以固定标签的形式打开该文件，并确认至少可以通过这种方式将其包含在标签补全的上下文中。
我的工作流程的变化
像 Cursor 这样的工具最令人兴奋的地方不在于我可以更快地编写代码，因为老实说，实际编写代码并不是瓶颈；实际上，我经常不得不放慢速度，以免过于关注代码而忽视了需要解决的高层次问题。真正的价值在于改变 我如何编码。
尽管这项技术还处于早期阶段，但这是我发现我的工作方式发生变化以及我希望在不久的将来看到的变化：
- 我 非常 不太可能去寻找新的库或框架。不，我不是要去编写自己的加密库，但对于小工具来说，让 LLM 为我量身定制地编写它们要比引入一个通用库容易得多。这些库通常一开始是小巧轻便的，但由于它们是开放的并被许多人使用，因此会积累我不需要的功能和冗余。
许多这些库的存在只是为了减少样板代码，当与我自己编写和维护样板代码的时间平衡时，这似乎是一个必要的权衡，但现在我可以由 LLM 帮我完成这一点，这种权衡显得不那么值得了。而且成本可能是巨大的：你试过在项目写完一年或更长时间后让它运行起来吗？你还不如从头开始。 - 我对坚持 DRY（不要重复自己）原则的担忧也减少了。过早定义抽象可能会在后期产生大量的技术债务，因此能够创建大量代码但不试图将其拉入函数或类的能力给了我更多的灵活性，我知道如果以后需要提取共享逻辑，LLM 也可以帮助我。
- 我更愿意使用我不太熟悉的语言或框架。例如，我在 R 语言上已经摸爬滚打了多年，尤其是在数据可视化方面。然而，坦白说，我在这方面很菜。我对
dplyr没有深入了解，而且看起来总有十几种不同的方法可以完成同样的任务。现在我只需要描述我想要的可视化，就能得到正确的数据操作和ggplot可视化。以前需要花费一个小时或更长时间的任务现在只需要五分钟，所以我更不可能放弃转而在 Python 中完成。
也许有一天我甚至会用 Rust 写点东西。也许。 - 我发现自己会在将小组件集成到更大的代码库之前快速迭代这些组件。这部分是为了克服在处理较大代码库时 LLM 的局限性，但也开辟了我之前未曾考虑过的工作方式。正如上面的例子，我可以在 Python 这样的动态类型语言中原型化一些逻辑，解决技术细节，然后立即将其转换为类型良好的 Go 语言以集成到 Web 应用程序中。我可以自动让 LLM 生成测试数据，或者为我生成一个后端模拟前端编写。为什么在证明一个想法时还要承担在一个成熟代码库中工作的负担？
总结
无论几年后我是否仍在使用 Cursor 或者转向了其他工具，我无法准确预测。但可以肯定的是，在撰写本文时，Cursor 是 LLM 编码助手潜力的最佳示例，如果你想探索这类工具可能带来的价值，我建议你试用一下。
