Cursor使用心得：从学习到开发

记录一下近期使用Cursor的一些心得体会，以及一些对AI Coding的思考🤔

从 9 月份开始使用Cursor作为我的主力编辑器辅助我的学习与开发，到现在也已经用了近两月的时间。在此期间其可能是我的“学习导师”，也可能是我的“开发助手”。为了方便管理在Wiki上的学习笔记，我在近期开发的一个MkDocs插件也借助了Cursor的力量。

然而，在使用Cursor的过程中也暴露了不少问题，无论是在学习过程中还是开发任务上。

订阅的初衷¶

我订阅Cursor的最初目的是为了辅助我的学习。

在参与了8月份上海的Cursor Meetup之后，我对Cursor的期待有了一些变化——或许其可以不只是一个简单的开发工具。

从开发角度来看，我需要一个能够辅助我完成开发任务的工具，比如代码补全、代码生成、代码重构等AI Agent工具；从学习角度而言，我也需要一个能随时为我答疑解惑的“学习导师”。在这样的需求下，我转而选择了Cursor作为我的主力编辑器，并订阅了它的Pro版本。

一些问题与思考¶

Cursor的强大毋庸置疑，网上的解读也很多，这里就不再赘述了，下面主要分享一下我在使用Cursor过程中遇到的一些问题以及我的思考。

辅助学习¶

在使用Cursor进行辅助学习时，我主要使用的是它的Agent对话（懒得切Ask模式）。

使用过程中，可以使用Cursor Rules作为提示词约束大模型的行为

关于Cursor Rules，可参考网络上的模板进行编写，这里推荐一个仓库:

• wonderful-prompts

如果是针对生产环境，则有专门的Cursor Rule模板:

• awesome-cursorrules

此外，可以使用Cursor Memories来记录一些上下文信息，方便在后续的对话中快速检索。不过记忆功能本质上也是一种规则¹。

截至我写这篇博客时，我还没有开始尝试这个功能，但是这个功能是真的有用。

此外，在利用对话进行信息检索时，AI给出的网页链接、参考信息有概率是“虚空”的或者过时的，这个问题的原因就是众所周知的幻觉，也有一部分原因是训练数据的时效性。

这个问题在我记笔记时的tab补全时尤为明显（写代码时会好点），因此在学习过程中幻想只使用tab补全和Agent对话就能学好是不太现实的（其开发方面也是如此）。

辅助开发¶

好了，正片开始

说到开发，相比较前面的辅助学习第一反应或许会觉得Cursor就“专业对口”了，事实也确实如此。。。吗？

从8月下旬开始，我决定开发一个MkDocs插件方便我的笔记管理，同时学习一些Python包管理的相关知识与开源项目的运作。

近四个月的mkdocs使用经历以及一些可参考的项目让我对这个插件的架构设计有了一些眉目，加上有Cursor这个“神器”加持，我便“稀里糊涂”地开始了这个插件的开发。

在开发之初，我对Cursor抱有过大的期望，以至于我直接把一个原型mkdocs hook丢给它，在对话框添加了一点象征性的约束提示词就开始让它写代码了；这还不是最难绷的，最搞笑的是我当初连一个mkdocs插件是如何运作的都没有一个明确的概念，mkdocs的官方文档也是一点没看，更不用说应该如何优雅地使用mkdocs原生的api接口了。以及，当时我甚至不知道作为一个插件，在打包前需要在项目配置中引入entry-points，结果自然是不用多说，v0.0.1在打包后甚至无法被正确加载，我为此还将插件的仓库转为私有一段时间（实在是太丢人了）。

开学后，在忙完转专业的行政流程后，我开始重新审视这个插件的开发。期间，我开始慢慢静下心来研究插件的架构并采用逐步引入功能与特性的方式进行开发。

静下心了，但是不多，不过还是取得了一点进展，最起码插件能用了——然而是Cursor给的抛瓦：除了核心架构的设计是我自己完成的，从底层代码到单元测试，甚至readme都是Cursor帮我写的。此时我还没意识到问题的严重性，每次遇到问题就直接描述然后让Cursor解决，自己就在一旁玩手机，code review也只是走个过场，殊不知自己已经逐步失去了对项目的控制（其实还是有点感觉的，只是因为懒所以睁一只眼闭一只眼）。

随着插件的迭代，问题开始变得越来越棘手，来到版本v2.1.5，插件的代码量已经到了12000行左右。在写这篇博客的前一周的某个晚上，出现了一个不经意但有点影响使用体验的Bug——一个涉及笔记文档元数据模型的调用问题，会导致远程部署后的展示出的笔记时间戳与本地测试的展示不一致，然而在排查问题时，我发现备用站点的结果与本地测试和主站点的展示结果也不一致——事实上，这个问题已经持续了好几个版本了，但我始终没有重视。这一次，我准备“尝试”彻底修复一下这个问题，于是开始给Cursor喂提示词，希望它能够帮我找到问题所在。

然而，Debug持续了一个晚上，期间还迭代了一个版本，Cursor始终没有抓住问题的关键，这时我才真正意识到，想要彻底解决问题，就不得不自己上手了。

历经了五天人工的彻底重构，插件的代码量“难以置信”地从12000行减少到了不到3000行，同时极大地简化了架构，移除了一些不必要的特性²。

从程序的角度来看，根本原因其实很简单: Cursor在编写代码时，完全没有考虑mkdocs本身的生态，对其本身的api接口一无所知，完全按照自己的理解来编写代码。作为一个插件项目，脱离其辅助对象的生态进行设计与开发是大忌。

在重构的过程中，我这次是真的静下心来研究mkdocs的插件生态，不再追求直接利用ai进行快速修复与迭代，而是在自己理解了接口与特性的设计原理后，自行编写函数逻辑，在测试可用性时才引入Cursor进行辅助Debug与改进。同时，这次我不再盲目接受Cursor的代码，而是一行一行进行审查，理解其为什么要这么写，这么写会不会有问题后，才决定是否保留。

研究插件生态时，我除了mkdocs的官方文档，我还参考了其他大佬开发的插件，拜读过mkdocs的源码。事实证明，最后一个是最有用的，想要学习一个框架的生态，读文档可能是最快的，但是最好的方式还是阅读其源码。

总结¶

在现阶段，AI虽然强大，但其定位仍然只是一个高效的工具。既然是一个工具，那么就不可能替代使用工具的主体。

作为一名合格的AI乃至工具的使用者，首先就应该明确工具客体的定位，以及如何合理利用工具来完成任务。同时，基于AI的特殊性，在使用其完成工作时，必须具备自行检索信息与判断真伪的能力。

作为人类，我们最擅长的就是制造和使用工具。在享受AI带来的便利的同时，我们更应该思考如何更好地利用AI来完成任务与创造价值，而不是被AI所束缚。