大家都在说cursor好用，但是实际上在生产场景下闭眼滥用cursor会产生一些问题：
1. 用cursor帮忙写代码并不意味着你可以偷懒不看文档，一直让cursor写代码然后告诉它遇到了什么报错让它继续修改，可能会出现一个下午反复修改一个函数还改不对的死循环中…
2. 用cursor写完的代码实际上自己还是需要能理解写出了什么东西，不然和搜索引擎时代初级工程师从网上随便搜一段代码塞到自己工程里没什么两样——你不知道这段代码是不是完全符合自己的业务需求，也不知道会不会在自己的业务场景下它藏了什么bug
3. 生产环境下往往具有复杂的多文件工程结构，而cursor对单个文件的上下文能比较好的理解，在多文件工程下表现的就不是这么好。这会产生什么问题呢？我们的实习生用cursor把所有的代码都写在了一个文件里…而且对于相同的功能用了两个不同的库…就像三四个不同的人轮番写一段代码一般，我在code review的时候大为震惊。
以下是一些cursor非常好用的场景：
1. 快速出一个功能单一的、代码量不大的脚本
2. 快速搭一个toy demo
3. 本身具有非常强的工程经验（比如在下😎），cursor可以让我不用管细节语法，换语言的速度变得更快了
4. 用ai prompt自己，让自己非常快的知道大概的框架和思路，以此为线索进一步研究(去看文档和补相关的知识)
cursor很快会变得更好：
当它作为IDE变的像jetbrains一样强大的时候，它的能力会再上一个台阶。(这意味着它对整个工程和里面的每一个symbol都理解了)
cursor有一定风险才能变得更好的地方：
对各个library保持最新的理解(嗯，它了解的library肯定是旧的version，有多旧取决于训练语料)；理解没这么主流的或者新出的library
1. 用cursor帮忙写代码并不意味着你可以偷懒不看文档，一直让cursor写代码然后告诉它遇到了什么报错让它继续修改，可能会出现一个下午反复修改一个函数还改不对的死循环中…
2. 用cursor写完的代码实际上自己还是需要能理解写出了什么东西，不然和搜索引擎时代初级工程师从网上随便搜一段代码塞到自己工程里没什么两样——你不知道这段代码是不是完全符合自己的业务需求，也不知道会不会在自己的业务场景下它藏了什么bug
3. 生产环境下往往具有复杂的多文件工程结构，而cursor对单个文件的上下文能比较好的理解，在多文件工程下表现的就不是这么好。这会产生什么问题呢？我们的实习生用cursor把所有的代码都写在了一个文件里…而且对于相同的功能用了两个不同的库…就像三四个不同的人轮番写一段代码一般，我在code review的时候大为震惊。
以下是一些cursor非常好用的场景：
1. 快速出一个功能单一的、代码量不大的脚本
2. 快速搭一个toy demo
3. 本身具有非常强的工程经验（比如在下😎），cursor可以让我不用管细节语法，换语言的速度变得更快了
4. 用ai prompt自己，让自己非常快的知道大概的框架和思路，以此为线索进一步研究(去看文档和补相关的知识)
cursor很快会变得更好：
当它作为IDE变的像jetbrains一样强大的时候，它的能力会再上一个台阶。(这意味着它对整个工程和里面的每一个symbol都理解了)
cursor有一定风险才能变得更好的地方：
对各个library保持最新的理解(嗯，它了解的library肯定是旧的version，有多旧取决于训练语料)；理解没这么主流的或者新出的library
