在与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的重写。
最后，编辑器专门用于跨文件重构。这是我使用最少的功能，但提供了更好的
