Cursor 是一款 AI 编辑器，它可以帮助你快速编写代码。本文将通过 cursor 的编程体验，来记录使用过程中的一些心得体会。
前言
最开始利用 AI 写代码大概都是通过补全插件去实现的，比如 vscode 的 copilot，但是后来发现，这个插件的补全能力还是有限，感觉被局限在单文件上。当然，在函数级别上，这些补全插件还是很有效的，如一些工具函数或者模板代码块。彼时，我对待 AI 写代码的态度还是无所谓的，觉得有点花里胡哨。
在年初的时候，我的 copilot 的免费额度消耗完了，我便开始寻找其他的 AI 写代码的工具。那时，cursor 已经很火爆了，"遥遥领先"。本着白嫖的心态，我便开始利用 cursor 的免费额度体验"AI 编辑器"。
体验
在网上搜索了 cursor 相关的入门视频后，我便开始尝试使用 cursor 写业务代码了。整个 code 过程真的很让我惊艳。之前的体验的代码补全插件，在 cursor 中仿佛成为了无足轻重的能力，基于制定的规则和文档，通过语义明确的对话，cursor 可以对多文件及其内容进行分析，并给出符合预期的代码，以及增删操作，准确率非常之高。尤其是在 CMS 系统中，超过 60%的代码都是模板化的，这意味着 cursor 能够有效减少这 60%的代码量。
细节场景：树选择组件的智能处理
我们经常会遇到树选择的场景，如选择分类、选择部门、选择角色等，这个时候往往需要做树的筛选和 label、value 相关的属性转化。后者可以封装工具函数完成，前者却与业务强依赖，你需要根据不同的上下文你一遍遍做看似"相似"的工作。
以我遇到的实际案例举例：有一对父子组件，B 组件的树选择组件会依赖 A 组件传递的多个属性，需要完成如下的状态变化：1.某些节点的禁用。2.部分层级的节点需要高亮。3.节点内容需要根据不同的上下文做不同的展示。4.某些路径的节点层级需要达到一定深度，否则意味着脏数据。5.当某个节点在某个条件下被命中时，需要向上溯源，找到该节点的父节点，并根据父节点的状态做不同的展示。 如果是我这样一个不太熟练算法的人，大概需要折腾一会，才能完成这个需求。但是在 cursor 中，我只需要描述清楚我的需求，将以上的情况一一罗列出来，cursor 就可以自动完成这个需求，生成对应的函数。其中让我尤为满足的是，它可以通过多个组件文件中已有的代码，自动推论出生成代码中所需要的字段值，意味着我不需要去二次调整函数中出现的诸如 id、value 等字段，不仅提供了普适的算法，还针对当下的场景自动调整了相关代码，很好地接入了业务。
整体场景：CMS 系统的页面生成
在 CMS 系统中，基于其面向的用户群体，不需要很强的定制性，涉及到的页面多是列表页、详情页、编辑页，页面布局和增删查改的操作往往也相对固定。通常情况下，你可以做一些组件封装，但是往往不太推荐，因为如果和业务相结合，你会发现要修改的细节太多了，这样组件暴露出的接口也越来越多，不利于维护。其实更好的还是复制粘贴，然后根据业务需求做细节调整。这个过程是机械的，非常枯燥。同一类型的事情做多了，影响最大的还是心情，因为这个过程你得不到任何进步，也意味着不可能收获任何成就感。
在 cursor 中可以这么做，将模板页面 A 拖入对话框，然后这样描述：请基于页面 A 的操作逻辑和页面结构，生成页面 B 的代码，其中涉及到的接口或者多语言文件在某某目录下（拖入这个文件），请根据实际情况调整。很快啊，页面 B 的代码就出来了，包括样式文件和多语言的修改等。它甚至会按照你的要求，自动拆分组件减少文件代码量，你只需要根据实际情况调整一下，就可以直接使用了。你要做的就是提供精确的语言描述和上下文，剩下的交给 cursor 就好了。
我完全沉浸在 cursor 的强大能力中，三个免费体验额度很快就耗尽了。我想，它是时候成为我的第一款付费的 code 工具了，1400+的年费，也不能阻止我。
搭建博客
通过以上的体验，大概很容易对 cursor 建立第一印象，即可通过精确的语言描述和适当的规则编写，即可生成你想要的代码，感觉像是自然语言编程。这个时候，最重要的往往是你的想法了。说出你的思考，描述你的需求，剩下的交给 cursor 就好了，也就是说，想法很重要。
如果当下没有好的产品想法，那么搭建个人博客是一个不错的选择。在前期构思中，我会将自己经常逛的个人站点，或者一些个人博客，收集成一个个想法，整理成文档。在这个过程当中，你会去挖掘对象里使用的技术栈，如果比较小白也没关系，你可以和 cursor 的 chat 进行对话，从对话中拆解你的需求，并让它整理出一份文档，涉及到的关键字诸如：站点风格、样式、静态站点、技术栈、动画库等等。
我并不是一个小白，所以在一开始我的技术栈就很明确，只有在我对某个技术点模糊不清的时候，我会尝试让 cursor 帮我分析多个选项的优缺点。有必要说的是，我最开始尝试使用 React 技术栈的静态站点生成器，但是起步还是有点慢，在字体、图标等等如何接入的过程当中，走了一些弯路，cursor 的完成度不尽如人意。这个我思考了一下，可能是因为我对其生态不够熟悉，从而导致指令不够精确。出于前期良好的体验，也抱有太大的期待值，稍有不如意，便有挫折的心理体验。之后我果断的切换到熟悉的 vitepress 技术栈，结果很重要，过程在其次。
我通过对话的方式，将我的要求一一拆解后，让 cursor 帮我整理了一份博客的文档，然后自己也通过 rules 的方式，将博客的样式、动画、图标、字体等要求一一罗列，综合上诉内容，让 cursor 帮我生成了一个项目骨架。第一版还是比较简陋的，很多细节都没有打到我想象中的要求，可能是我一次性要求太多了。基于此，我后面在 composer 中，都是针对某一部分进行调整，比如页面头部、内容区域、文章列表，动画效果等。目的越清晰，范围越适中，语义越明确，得到的效果也越好。
过程也不是一帆风顺的，有时候在一个问题上，cursor 的模型会出现“幻读”，问题会被反复改来改去，最终回到原点，这也打破了我“不写一行代码”的美好幻想，最终还是需要我手动排查。所以在当前阶段，所谓的从零开始写一款应用，我觉得还是不太现实的。
总结
cursor 的体验还是很棒的，尤其是在代码生成方面，准确率很高，而且可以基于上下文进行分析，给出更符合预期的代码。但我觉得当前还是比较利好有技术背景的产品经理，就像上文中一再提到的“准确的语言”，准确是指对项目或任务有全面的理解，并能够将理解转化为准确的语言，让 cursor 能够准确理解你的需求。当下包括我在内的很多程序员其实都不具备这个能力，我们面对某个需求，或许能够很快在脑海中给出代码的解决方案，但是如何诉诸于文字，真的很难。我现在之所以坚持使用 cursor ，其实也是在锻炼自己的归纳和总结能力，将有限的精力优先服务于解析需求，而不是代码。Code 不重要，Idea 才重要！