最近 Cursor 很火，火到我身边的程序员们已经不聊河北彩花，LOL，黑猴等，而是在各种场合讨论这个 Cursor 的辅助编程能力。各类内容平台也在以惊人的速度，迭代出了许多相关教学视频：
我试用了一段时间，第一感觉确实很惊艳，能帮我解决很多基础问题，实打实地提升开发效率，印象比较深的，包括：
Codebase Indexing、 @symbol等功能带来的更强的上下文索引能力，而这极大提升最终 LLM 生成的代码效果；Cursor Composer 功能提供了一个注意力非常聚焦的编程面板，相比于过往 GPT 等产品的即聊即抛的模式，更容易做好跨文件的编辑开发，而这更符合专业开发者的模块化编程习惯。
但是，我觉得，至少在当下阶段，这类产品的定位只能是“辅助编程”，虽然能极大提升效率，但还只是编程活动中的辅助客体，俗称打下手；程序员本体 —— 人类智能依然是主体地位，有点类似于掌柜的吧。
下面我列举几个点，分析 Cursor 能做好的任务，做不好的任务，以及更重要的，作为个体，应该如何适应这个 AI 快速发展的时代。
Cursor 的本质
毫无疑问，Cursor 能解决非常多基础问题，包括我自己也已经习惯了使用 Cursor 替代 VS Code 完成日常工作。它很好用，但并不神秘，本质上就是在传统 IDE 基础上，搭配足够好的交互与足够好的 LLM，从而超越传统 IDE。交互方面，它在 VS Code 基础上，补充提供了：
更适配 LLM 场景的上下文引用能力(即 @codebase/@files等 symbol 指令)；适合复杂编程的 Composer 面板，可以在此与 LLM 保持一个较长时间的回话，并且支持多文件编辑，可以在这里持续沟通，持续生成代码，完成复杂任务； 提供了几乎毫无门槛的代码自动补全能力，并且支持多行编辑，这在一些场景，如修改变量名时，非常好用； 甚至还贴心的支持在 Terminal 中唤醒 LLM 交交互面板，实现命令生成、命令行错误处理等能力。
这些交互上的创新，从技术角度看并不特别复杂(甚至有不少瑕疵)，但从产品角度看，确实做到了即贴合开发者习惯，又能为 LLM 提供更多上下文信息，进而提升模型效果。非常值得称道的一点是，这些交互与传统 IDE 的交互逻辑非常契合，对专业程序员而言不需要过多学习，很快就能上手应用，几乎能做到无缝接入。
在交互之外，Cursor 并没有过多投入精力开发自己的大模型(算是一种克制)，而是提供了比较流程的模型切换功能，用户可以在配置面板上按自己的意愿在各种上下文中切换主流 LLM：
我认为这是一种非常聪明的产品决策，既规避了将有限资源投入到前途未卜的大模型研发中 —— 从而可以聚焦打磨产品本身的体验；又给予用户充分的自由度，延续自己的喜好。虽然让渡了一部分商业利益，但使用者的接受度更高，进而更容易获得种子用户的信任，也就更容易在当下的市场中脱颖而出。
而作为一个普通开发者，我认为我们并不需要过度“神话”这个软件，还是那句话：本质上就是在传统 IDE 基础上，搭配足够好的交互与足够好的 LLM，因此完全把它看做增强版的 VS Code —— VS Code 能做到的事情它同样都能做到，只是在此基础上叠加了许多浑然天成的 LLM 交互能力，即使不做任何配置，也能通过 Auto Completion 等能力获得极大增强的编程体验与效率提升，即使为此需要每月支付 $20，我认为也是非常值得的。
Cursor 的适用场景
从我的使用经验看，我觉得 Cursor 非常适合下面这几类编程场景。
问答
首先是最基础的问答场景，我相信绝大部分程序员应该都做不到无所不知，开发过程中总会需要查找各类资料，在过去我不得不使用 Google/百度之类的搜索引擎查找相关文章，之后自己仔细阅读多篇文章后，总结找到解决方案。
LLM 支持联网功能后，我开始尝试使用 Claude、ChatGPT、Perplexity 等平台咨询技术问题，这些工具都能够根据我所提的问题自动提炼关键字、联网搜索，以及 —— 最重要的，它们能够总结分析搜索结果，之后直接返回一个相对简洁的答案，理想情况下，我已经不再需要在紧张的工作过程花时间阅读仔细阅读、理解这些文章，能更好地保持心流状态。
但是，这类平台给出的答案置信率并不是很高，主要原因在于我很难在一个简单的对话框中给出足够详细的上下文信息 —— 总不能把整个仓库的代码都粘贴进去吧？而 Cursor 提供的诸多上下文符号(@xxx)引用能力就很好地弥补了这一点，例如可以使用 @Codebase 符号索引整个仓库(前提是打开 Code Indexing 配置)，要求 LLM 给出分析结果：
这种极强的上下文索引能力，其底层本质上就是将整个仓库 Embedding 成向量数据库，之后提供给 LLM 消费，从而超越了常规的公共知识领域问答模型，而具备极强的私域知识理解能力，单纯使用 GPT、Claude、Doubao 等模型是非常难以实现这一点的。
更进一步的，基于这些特性，Cursor 还能非常高效地帮我分析总结各类项目的底层原理：
这是一个非常非常有用的特性，过往我在接手一个旧项目，或者学习一些开源项目的时候，不得不逐行主句地理解整个项目的代码，而现在我可以跳过许多细节，让 Cursor 帮我更快地理解仓库代码。
生成单测
这个很强，一方面能够增量生成，一方面你可以不断要求它提升覆盖率，生成更多单测用例
很多 LLM 工具、平台都能生成单测，但 Cursor 表现的会更好一些。相对而言，GPT 等工具的交互形式过于简单，只能一段一段将代码复制粘贴进对话框请求生成单测，这会导致两个问题：一是上下文缺失，难以正确推断下游模块的实现细节，进而影响生成效果；二是很难实现增量更新，例如你已经为你的代码模块生成过一份单测代码，但后续迭代维护导致单测过时后，很难借助 GPT 针对发生变化的这部分代码调整单测。
而 Cursor 显然已经解决了这些问题。如前文所言，Cursor 可以向量化整个代码仓库，因此它有能力自由索引仓库内的所有文件，在生成单测代码时，可以同时将目标模块以及模块对应的上下游模块代码同时提供给 LLM，上下文信息越充分其势必生成的结果会更精确一些。
举个具体例子，我在使用 GPT 等工具生成单测时，由于缺少 Vitest 相关语料，无论怎么调整 Prompt，大多数时候都会返回基于 Jest 的测试代码，而我更喜欢用 Vitest，所以每次都需要把代码复制出来，一通调整后才能放入仓库内运行；而在使用 Cursor 时，只要使用适当的 Prompt，多数时候都能返回基于 Vitest 的结果，调整成本要小的多，例如我常用的 Prompt：
其次，经常编写单测的同学应该都有一个感受，就是为某个模块从零到一编写单测并不特别困难，麻烦的是后续的调整维护，因为你必须深入理解增量代码对旧逻辑的影响，并据此调整存量单测。在过去使用 GPT 等工具时，面对这种增量场景通常只能把修改后的代码全量粘贴入对话框，重新生成全量单测代码，但这会导致过往对存量单测做的细微调整全部失效，需要重复这部分调整工作。
而使用 Cursor 后，问题被优化了许多，我们可以使用 Cursor 专门针对变更内容生成单测，例如下面的 Prompt：
另外一个更实用的技巧是，Cursor 也支持通过 @ 符号引用某个 Git Commit，因此也可以针对某个 Commit 生成单测，例如下面的 Prompt：
不过实测下来，增量生成的单测质量相对全量生成还是会差一些，容易丢失上下文，或者添加多余的单测，因此还是有一些调试成本的，不过还是比使用 GPT 高效许多。
语言切换
在日常开发中，偶尔需要针对存量代码做一些语言切换微调，例如将老项目的 Javascript 改写为 Typescript，只需使用简单的 Prompt：改写为 Typescript，即可实现：
在上面的实例中，Cursor 根据函数体提炼出正确的参数类型，并且正确推断出该函数的返回类型，虽称不上完美，但相比手工操作已经提效了许多，并且即使转换结果又问题，也能通过 tsc 工具快速识别，因此非常建议面对类似场景的同学，优先使用 Cursor 实现代码转换。
甚至，Cursor 还可以丝滑实现跨语言的转换，例如从 Javascript 改写为 Rust：
需要注意的是，这种场景下通常只是完成语法上的简单转换，底层调用的各类基础接口还是需要手工调整，才能正确运行。
PS：还有另外两种非常实用的场景：基于 JSON 生成类型描述、基于 JSON-Schema 生成类型描述，实测都很准确。
实现 V0 版本
Cursor 的 Composer 面板非常适合用于实现功能的 V0 版本，例如：
虽然从专业程序员视角看，生成的结果可能比较粗糙，无法作为最终版本提交 —— 甚至有时候跑都跑不起来，但相对而言已经节省了许多初始化项目、创建文件、编写脚手架代码等方面的时间。接下来，只需基于 V0 版本，按照个人的思维习惯不断微调代码，通常也就能完成一个完整功能的开发。
另外，体感上 Cursor 具有极强的学习能力，使用过程中似乎会不断观察你的编码习惯，后续生成的代码会越来越趋近你的编码风格，代码调整成本也会越来越低。
补充一个点：前期编写 Prompt 虽然也需要花费一些时间，但这个过程本身也是在滤清自己的思路，对流程、设计、约束等想得更清楚一些而不是一上来就开始编码，这样反而更容易做对。
解决中等复杂度问题
Cursor 底层是非常典型的 Agent 架构，它并不是简单调用 LLM 之后直接应用结果，在 Composer、Inline Prompt 等功能中会根据你给出的指令，做出基本的任务分析、拆分子任务、规划等动作，之后结合丰富的上下文数据执行多类子任务，合并产出最终结果。
这种执行方式虽然有可能放大 LLM 随机性带来的不确定性，但也使得 Cursor 初步具备结构化思维模型，已经有能力将一个复杂问题拆解为若干小问题，逐步求解，足以解决中等复杂度的综合问题，日常画个页面，做个 CLI 工具，搭个工程脚手架，写个常规算法等都不在话下，具体效果大家可以到各大自媒体平台自行搜索，有太多人正在吹爆这个软件，我就不啰嗦了。
值得一提的是，即使执行这么多任务，Cursor 的性能依然非常可观，特别是 Tab Completion ，我个人体感感觉基本可以在秒级内猜测出结果，并且准确率很高，相比市面上其他产品要好出非常多。
不过，即便如此，Cursor 依然很难直接解决复杂问题，例如开发一个成熟的商城小程序、做一个点餐系统等，有几个方面的因素：
自然语言表达力不足，很难在有限的 Prompt 描述清楚所有需求细节； LLM 单次交互生成的 Token 数是有限的，多数时候无法满足复杂需求所需的代码量；
不过，Cursor 针对这种场景提供了一种非常不错的解决方案 —— Composer，这个功能相对复杂，简言之，你可以人为地将复杂任务拆解为若干小任务，之后在 Composer 面板中分多次发出指令，Cursor 会据此逐次生成多份文件，且文件之间关联度较高，会互相引用消费，非常适合用于复杂功能开发。
Cursor 的短处
客观的说，LLM 确实非常强大，给各类内容生产行业带来了巨大想象空间，甚至称之为新的技术奇点也不为过。不过，它还不足以完全代替人类，其底层实现逻辑已经决定了它的能力极限只能达到或稍微超越人类总公开信息的平均水平。
Cursor 也一样，它能极大提升代码开发效率，但也存在许多缺陷与短板，当下不可能丝滑代替人类开发有复杂度的生产系统。虽然它确实能给出许多惊喜，但 LLM 推理过程的随机性决定了它无法 100% 满足功能、性能、可维护性、技术品味、向前向后兼容性等诸多工程需求，我认为它始终都只是一个“辅助编程”工具，人类智能才是编码过程的主体。
随机性
LLM 很强大，但它的本质其实就是概率计算 —— 根据上下文与模型本身的参数猜测下一个最可能“正确”的答案，既然是“猜测”就不可能做到像逻辑运算般严谨一致，上下文与 Prompt 的些微变化都可能引发蝴蝶效应导致完全不同的结果。虽然模型还在迭代发展，未来必然越来越稳定，执行越来越快，上下文也越来越长，但这种根子里的随机性我认为是不可能消失的，而随机意味着风险。
实现斐波那契数列
实现，斐波那契数列
仅仅在 Prompt 中加了一个“，”，生成结果就会发生很大变化
虽然人类智能也有极高的随机性，但一个很大的区别在于，大部分活生生的人类都具备较强的自省与逻辑推导能力，有能力自行检阅发现潜在问题，因而随机性带来的风险相对可控 —— 过往几十年的软件工程可都是人类智能发展起来的。而 LLM 并不具备这种自省纠偏能力，最终只能保证某种概率水平上的准确性，很难保证下次还能得到准确答案。并且，与文章、图像等内容生产领域不同，软件项目的容错率非常低，任何一个细小错误都可能导致应用整体崩溃，或出现预料之外的细微错误。
这种随机性导致的结果就是，虽然 LLM 能够以极快的速度批量生成相对“合格”的代码，但在严谨的商业环境中，工程师们还是需要花费许多时间调试 LLM 生成的代码，确保与系统其他部件能兼容执行，并且多数时候，还需要对代码的多处细节做出微调，确保符合功能需求；需要花费时间理解这些代码，Review 生成结果是否符合整体架构约束、风格约束等，确保长期可维护性，等等。总之，至少目前阶段还是需要大量人力介入监督，使用各类技术、非技术类方式方法保障代码质量。
缺乏领域知识
网络上有许多鼓吹关于 Cursor 的文章、视频，在他们的表达中似乎 Cursor 已经超越、替代人类，能够像魔法一样完成复杂应用的开发，可以做到《一行代码不写，让 AI 帮我打工》。但我实际体验这几个月下来，感觉距离这个状态还是比较远的，一是 LLM 缺乏领域知识，很难解决特定领域里的具体问题；二是 LLM 并不具备结构化逻辑思维能力，无法将一个复杂任务拆解为若干子任务，逐步地、更稳健地解决问题。
在我的使用过程中，有一个很强烈的感觉：即使我遵循 Prompt 工程的各类建议，花费许多时间精心编写，多数时候也很难仅仅使用自然语言精确描述需求(我们更习惯使用代码实现)，进而 LLM 很难生成真正符合预期的代码。这本质上是语言本身的表达力问题，在商业环境中，即使是同一团队内部，相同领域背景下的产品与研发在沟通需求时也需要精心准备许多说明文档，拉会沟通多次，从多个角度反复才能对齐需求细节，何况与并不太理解领域特定知识细节的大模型？说的更直观点，LLM 很可能并不认识业务领域内特定代词的具体含义，也没有掌握某些特定历史上下文信息，结果可能就是鸡同鸭讲，对开发者而言很难在有限的 Prompt 表达清楚所有上下文，对 LLM 而言有太多信息黑洞，两边无法完全对齐，也就无法顺利完成业务需求开发。
举个具体例子：“当用户未通过 OAuth 登录时，若点击注册按钮，则弹框展示用户说明书，并发送行为埋点到 B 平台”，这里面 OAuth、注册、弹框、埋点等都属于开放知识，LLM 有相关语料知识的情况下都能理解的不错，但：
“用户说明书”具体是什么？ “B 平台”是啥？具体如何上报埋点？ 埋点的内容应该包含什么？ 等等。
都属于特定团队领域内的私域知识，包含了太多细节，除非你能通过 RAG、Fine-Tune 等方式补齐这部分信息，否则 LLM 无法理解任务的具体实现方法，最终大概率也就生成类似下面这样这种无法直接使用的结果：
不具备创造性
LLM 还有一个比较大的问题：缺乏创造性，这一点应该比较容易理解，从原理上讲，LLM 就是大量收集公开资料，之后借助深度学习技术，尤其是神经网络中的 Transformer 架构，来捕捉语言中的复杂模式和语义关系，进而训练出一套尽可能准确理解与生成自然语言的模型。
通俗地讲，LLM 就像一个具有超高性能与智慧度的知识检索工具，并且出厂时默认就自带了海量互联网公开资料，结果就是，当你提问的问题有对应的资料解释时，它能非常好地生成答案，但超出其检索范围时，表现就会差很多，甚至出现所谓的“幻觉”。
当然，这一问题目前已经有一个成熟的解决方案：Retrieval-Augmented Generation，可以简单理解为通过向量数据库给 LLM 外挂更多知识，LLM 在执行时会同时检索这些知识，从中推算出更接近特定领域的答案，这就使得 LLM 能够被应用在各类具体业务领域中，适用性增强了许多。
但面对一些更深层次的问题，即使应用了 RAG 架构恐怕也很难解决，例如某些不甚知名框架，网络上并没有太多相关讨论资料，并且你也无法提供相关知识时，LLM 就很难给出比较准确的答案，这是因为 LLM 本质上只是在做数学意义上的概率推算，但不具备复杂逻辑推导能力，无法基于新的语料推演出新的知识，缺乏人类智能的创造力。
举个更具体的例子，当你编程过程遇到一些具体的 Bug，如果是前人研究过的点，并且在互联网上详细解释了问题的原因与解决方案，那么 LLM 会表现的很好，直接给出最终答案；如果是框架的问题，但缺乏相关资料的，LLM 大概率无法给出解决方案，需要你深挖框架细节，自己找到答案；而如果是具体业务系统代码本身的问题，LLM 基本是力不从心的，无法给出有价值的答案。因此，面对复杂而具体的问题时，依然还是需要人类智能出场。
最佳实践
频繁提交代码
切记，LLM 始终是随机的，无法保证下次执行结果的正确性，在使用过程务必养成习惯频繁提交代码，方便出现问题时随时回滚。我个人的操作习惯大致是：
使用 Cursor 各类面板生成代码后，先做一遍简单的代码 Review，修改变量名、循环结构等基础问题； 在软件上下文中集成调试，初步验证正确性后立即提交代码； 审阅代码设计，重点关注：函数输入输出结构、模块导入导出内容、逻辑与循环分支处理等等，在这个节点通常会持续让 LLM 按我的想法优化代码，或者自己上手做些小修改，迭代多次持续提交代码，这个过程通常耗时最多； 代码初步稳定后，继续让 LLM 帮我生成单测代码，这个阶段通常需要迭代多次，提交多次，直至单测通过，覆盖率达标为止； 功能代码、测试代码均准备就绪后，提交 PR 准备合码；
这个过程中，每次调用 LLM 都可能得到不符合预期的结果，但只要基本达标我都会立即 Commit，后续遇到问题随时 Revert 即可，虽然这会产生大量 Commit History ，但合码前使用 Rebase 等操作调整历史记录即可。
重视 Code Review
其次，建议将更多时间精力放在 Code Review 上，因为 Cursor 生成的代码可能是局部最优，但可能因为缺失相对抽象的全局架构信息，而并不能做到全局最优，例如重复编写组件，或破坏某些约定俗成的架构规则等，日积月累同类代码可能最终导致可维护性、可读性都逐步劣化到无法继续迭代的程度(公正点说，人类智能也会导致这类问题)。
因此非常建议重视建立严谨的 Code Review 文化，理想情况应该是由 Cursor 生成尽可能多的代码，尽可能代替人类完成编码工作，再由人类智能负责验证、审查这些代码的合理性，保证结果正确且长期可维护。
更好的工程化体系
如前所述，Cursor，或者说 LLM 生成的结果是随机的，无法保证每次都得到正确的结果，每次变更都有可能影响存量代码的稳定性，如果这些变更都必须由人类手动验证，那么测试成本会搞起不下，测试环节会成为工程中新的效率卡点。
更好的方式，应该是投入更多精力建设更稳健的工程化体系(这部分需求也可由 Cursor 辅助实现)，使用自动化工具代替人力完成诸多基础质检任务，例如引入 UT/E2E 完成运行质量测试，CI/CD 中加入 TS 类型检查、ESLint 风格检查等保证代码质量，等等。重点在于，使用更高效、成本更低的方式不断验证 AI 产物质量，更敏捷地应对变化，具体策略可参考我之前的文章：
《前端工程化系列一：序言》 《前端工程化系列二：编码提效》
此处不再赘述。
使用 AI 友好的技术栈
在使用 Cursor 或其他同类辅助编程工具时，应尽可能选用各类 AI 友好的技术栈，以前端为例，如：Tailwind 优于原生 CSS/Less 等；Typescript 优于 JavaScript、CoffeeScript 等；React 或 Vue 等 MVVM 框架优于原生 JS + HTML + CSS；GraphQL 优于 Restful 等。
为什么技术栈之间会出现这种差异呢？关键在于 LLM 底层是基于概率推导实现内容生成的，结果好坏取决于模型质量、训练语料、上下文完整度、Prompt 等诸多因素，单就辅助生产代码这一任务而言，LLM 对技术栈的理解越充分必然效果越好；代码结构越聚焦，推导时信息噪音越低，结果也会越好；业务实现中的特化场景越少，通用规则越多，LLM 需要理解的内容越少，效果通常也会越好；等等。
基于这些维度，我个人总结了几类简单规则可用于辅助评估某种技术栈是否更适用于 AIGC 场景，包括：
社区热度：社区越繁荣，意味着使用者越多，相关的技术讨论、技术资料也必然越丰富，LLM 训练或执行时所能索引的信息就越完整，那么也就越容易推导出较好的结果。举个例子，假设你工作中遇到了某个非常具体而棘手的问题，若刚好有人也遇到过，并将该问题形成的底层原因、解决方案整理成文章并发布到互联网上，若 LLM 运行时能检索到该文章，则可以基于文章内容推导给出最终解决方案；若网络上没有这类信息，考虑到 LLM 并不具备复杂逻辑推理能力，那么大概率无法给出有效的解决方案。 结构化：技术栈本身的结构化、模块化水平越强，则其信息表现形式越是聚焦，越容易被 LLM 正确推导。比如，原子 CSS(如 Tailwind) 就是一个很好的例子，原生 CSS 是通过具体的属性的键值对表达页面元素的视觉效果，而原子化 CSS 则是通过原子类名表达某类样式规则集，信息更聚焦更容易被 AI 理解；并且受层叠规则影响，使用原生 CSS 时，元素样式可能受全局、祖先级元素、多种选择器等层级的样式规则影响，这对 LLM 而言意味着具体信息分散在项目的多个角落，需要消费、理解更多上下文才能推导出正确的结果，相对而言原子化 CSS 框架下，大部分样式信息都聚焦在元素对应的 Class 列表上，信息高度聚焦，推理成本更低，结果也会更可靠。 通用规则优于特化设计：技术栈的设计规范越是通用，则越容易被 LLM 理解，也就越是适用于 AIGC 场景。例如，GraphQL 明显优于 Restful，因为 GraphQL 提供了一套用于描述实体 + 实体关联关系的通用语言规则，足够用于表达绝大多数数据存、取、删、改等常规业务操作，因而对 LLM 而言只需理解这套通用语言规则，配合具体业务领域中的实体与实体关系即可基于 GraphQL 灵活编写出各类数据操作逻辑；而 Restfull 规范则更多聚焦在实体上，除几种基础的数据操作外，涉及复杂数据结构场景时，出于实用性、性能等角度考虑，通常不得不特化设计、特化开发，而这些特化处理对 LLM 而言会显得过于具体，相应的上下文复杂度与噪音也会更高，也就更难以推导出正确的答案。 自动化质检：技术栈的质检工具越强大，则能够越早、越全面地发现质量问题，进而更能低效 LLM 随机性带来的质量风险，也就更适用于 AIGC 场景了。例如，Typescript 之于 JavaScript，前者具有更强的类型声明系统，因此在静态代码分析阶段即可找出诸多类型不匹配问题，那么即使 LLM 生成了类型不匹配的代码，也能够在运行代码之前发现问题，纠错成本要低很多。
当然，上述规则仅仅是我的一家之言，随着大模型的迭代发展，具体规则后续必然还会新增或删改，这不重要，重要的是非常建议读者后续在做技术选型时，不要只是基于个人 or 团队喜好做决定，应该更多考虑技术栈对 AI 的适用性，甚至可以以此为首要原则，尽可能选用对 AI 友好的技术与工具，使得 LLM 更好、更准确地辅助完成各类开发任务，充分融入到日常工作中，提升个体与团队的整体效率。
降低预期
对，标题没写错，你需要降低预期！前面也说过几次，LLM 并不是魔法，它有幻觉，有知识漏洞，有随机性，不擅长解决复杂问题，有各种各样的缺点，从我的使用经验来说，多数时候它还远没有达到我预期的状态，需要我参与到各种代码细节中。
例如，生成单测通常都跑不通，需要各种修改微调测试；生成的文档可能也会缺失某些重要内容，需要调整 Prompt 后多次重试，才有可能达到预期效果；生成的代码，即使在 Cursor 各种上下文引用能力的加持下，也经常会在细节处犯错，导致执行失败。以 LLM 的底层实现逻辑来说，这些结果都太正常不过了。
因此，建议降低对 Cursor 或者其他 LLM 工具的预期，它并不是魔法，无法完全代替人类智能，当下你还是需要认真做好导演角色，引导 Cursor 更准确更好地解决你的问题，认真研读理解仓库已有的代码与 LLM 生成的代码。更进一步的说，你自身还是需要有比较强的技术能力，理解各类技术底层细节，才能及时发现、修复问题。某种程度上，Cursor 就像一把刀，它的锋利程度取决于你自身的功力。
写在后面
最后唠叨几句，这几个月试用下来，Cursor 虽称不上完美，但它确实能完成许多基础而重复的任务，让我把注意力更多聚焦在业务、架构等高纬度，而不必过多关注具体细节；能够在我遇到知识盲点的时候提供真正有意义的提示与帮助；能帮我完成许多重复、低级任务。这不是玩具，而是真正提升开发效率的生产力工具，是我用过最好的 AI 辅助编码工具，强烈建议读者也上手试试。
不过，Cursor 始终只是辅助生产工具，人类智能才是本体，工具能让你更快、更强、更好，但重要前提在于“你”，不要本末倒置。后续我计划继续写一篇文章，聊聊我对 AI 的思考，聊聊作为一个程序员，应该如何在这个时代与 AI 友好相处，那些人可能被替代以及如何避免被替代等，
