最近公司在尝试用AI工具来提升研发效率和质量，所以为开发同学采购了Cursor来试用。
这两天我高强度的使用Cursor进行工作，震惊于其Agent模式的工作效率和效果之余，我开始考虑Cursor这种AI工具对于程序员这个职业的影响到底是怎样的。
很不幸，我对结果很悲观：AI程序员将来必然会替代人类程序员，并且这个将来不会太久。
有多久？
我个人预估，最多3～5年，所有人类程序员的工作，大部份都将会由AI完成，并且完成得更快更好。
为什么呢？
我之前说过，ChatGPT自2022年底发布至今也才不过2年半，你可敢想象再给AI3到5年的时间会发生什么？
当然，既然提到了3～5年，就代表Cursor目前还不能完全替代程序员，我来具体解释一下。
首先，Cursor目前最适合的使用场景是在没有历史包袱的前提下，开始全新的项目。
举例来说，我让Cursor新写一个《飞机大战》的游戏，他会很流畅的写出来；但是如果我让他在现有的项目中，添加或修改一个功能，他会改的一团糟。
原因很简单，大模型是没有记忆的。
我们在跟大模型聊天时，之所以会觉得大模型好像记得我们之前聊过什么，是因为每次向大模型发出新消息时，大模型的开发人员“取巧”的将我们与大模型的历史聊天内容，都重新作为上下文发送给大模型。
然而大模型的上下文是有容量限制的。
当一个项目的代码几百万、几千万行时，你不能指望每条消息都带上整个项目库的代码。
起码，现在Cursor还没有做到。
但是我相信，这个问题迟早会被解决，并且一定会被解决。
只是，还需要时间。
其次，当我们让Cursor帮我们实现需求时，他有很大概率没办法一次成功。
比如出现编译错误、运行时错误等等异常情况。
虽然Cursor当前已经有了分析错误，并尝试解决的能力，并且很大概率确实能够自己解决，但是有时候他会走到错误的方向上。
比如，我遇到过，Cursor发现TypeScript类型检查编译不过，尝试多次修改无果后，就去把强类型检查改为弱类型检查，就这样骗过了编译器。
但这绝对不是我想要的，我希望其编写的代码是安全、健壮的，而不是跟某些差劲的人类程序员一样：“代码和人，有一个能跑就行。”
这里就涉及一个只有人类程序员能解决的问题，即帮助Cursor解决问题。
在这一点上，Cursor目前解决不了，非程序员也解决不了，只有人类程序员能搞定。
当然，这一点未来Cursor越来越先进时，也一定能追上。
第三，对于需求的详细描述。
我发现很多人，包括我自己，都把Cursor当做一个许愿机。
幻想的是，我告诉Cursor一个目标，之后Cursor就能帮我完成的很好。
但这样是不行的，起码现在的Cursor是不行的。
Cursor现在还不是许愿机，而更像是很聪明但偶尔抽风的人类程序员。
你需要详细跟他描述你的产品需求，以及技术要求。
产品需求很好理解，比如你想做个电商平台APP，你不能只是告诉他Cursor说，“帮我抄个淘宝”。
起码现在的Cursor还做不到。
起码你得告诉他一些明确的规则，比如一个大球吃小球的游戏：
- 实现一个大球吃小球的游戏。
- 竖屏，适合手机游玩，同时也支持在PC上用键盘游玩。
- 地图上分布各个小圆点，通过吃掉这些小圆点来变大，也可以吃掉比自己小的圆球来变大。
- 比自己大的敌球也可以吃掉自己。
- 敌球之间也会互相吃。
- 地图搞得非常大，比屏幕大很多。
- 摄像机跟随主角移动，但是不要太敏感，要有一定的死区，超过死区后，摄像机才开始移动。
- 屏幕不要超过地图边缘，不要留下黑边。
技术要求，则是另一个只有人类程序员才能胜任的工作了。
即，你希望Cursor用什么编程语言、什么框架、什么中间件、什么通信协议，与哪些现有服务合作等。
为什么？
因为很长一段时间内，AI程序员与人类程序员将会是共创的关系。
如果AI写出来的代码，人类程序员无法理解、修改、调试，与现有的功能无法很好的配合，那这样的代码就是无意义的。
还是以大球吃小球游戏举例：
- 使用Typescript语言，Phaser框架。
- 通过npm在当前目录下安装Phaser框架，并引入其TS定义文件。
- 所有内容，尽量使用代码实现，不要引入对于prefab、scene之类的依赖。
- 代码都写在主脚本文件里，不要拆分文件。
- 使用面向对象的方式实现。
- 游戏中的图像都使用多边形代替即可，用不用的颜色和形状区分即可，不要去网络上下载。
- 暂时不需要音频，不要去网络上下载。
- 一次性做完，不要总是让我接管。
这三点，就是我为什么认为Cursor给了程序员最后一次机会。
不是给测试、运维，不是给产品经理，也不是给老板，而仅仅是给程序员。
撑死就3～5年的时间，这是我们程序员最后的机会了。
加油吧！程序员们！
注：以上的大球吃小球的提示词是可以实际生成游戏的，大家可以试试，效果如下：
评论
暂无评论