Cursor VS Trae, 深度对比第二弹

有人喜欢，有人觉得太浅，觉得我选择的理由太过粗暴。

刚好也用了一段时间的 Cursor，就再来对两款工具进行一个更深度的对比。

变量控制

ps: 这个项目大概的功能如下：

首先是 Trae, 通过在引用中增加当前工作区来获取上下文。得到的篇幅比较长，截取部分如下：

Cursor 中，通过 commond + enter 来完成上下文的注入，得到的回答截取部分如下：

粗糙来看，两者的分析都很 AI，确实都非常好的完成了分析理解的任务。

这一点上，可以说是平分秋色吧 (毕竟，他们都夸我了，结构清晰、功能完整哈哈，没说错)。

但是两者都存在一个体验上的优化，就是当我没有按照他们的要求提供上下文时，对于如何补充上下文提示的不够明显：

都给 90 分吧。

程序员最关心的就是代码补全了，这次提供了三个案例，来进行能力的对比：分别是路由猜测，错误处理，和变量替换

这个项目是一个单页路由，让他们猜测下一个路由写什么：

在这一点上，两者很一致，项目本身有首页，登录页，确实下一个可能的路由就是注册页。

在这一次 PK 上，两者也是平手(虽然我的意图不是注册页，登录即注册)。

如下是我原本的代码，非常常见的 Fetch 的代码，当我把鼠标放在图示位置时，我心里想的是帮我多处理几个 code，而不仅仅是 401

如下是两者的输出对比：

右侧是 Trae，可以看到，Trae 帮我处理了 403 之后，剩余情况直接 throw，懂 js 的都知道这里面的门道有多深：我下面的代码不会执行喽。

而反观 Cursor，403， 404， 500，502，503 都帮我列出来了，不过再往后，Cursor 也会陷入死循环，code 不断加 1，而提示信息始终都是重复。

ok，从这一把的 PK 来看，Trae 完败，Cursor 虽然有缺陷，但至少我的代码功能逻辑上不会错误。

代码中，我们修改变量名之后的意图，往往就是修改本文件中的所有相关变量名。对于 react，如果我们修改了一个 state，我们往往还会希望能够修改对应的 setState 名称。

可以看到，Cursor 完全达到了预期，不仅修改了变量名，还修改了 setState 对应的变量名，并提示我下一步该修改哪里，这一点，给 100 分我都嫌少。

反观 Trae，纹丝不动。在这一把上，我甚至觉得 copilot 可能都比它强。

起初我以为是 Trae 对 react 理解不强，换成普通变量，也依旧如此。

这一波，Cursor 完胜。

而 Trae，说这个功能点完全是没有的也不过分。

chat 模式对代码的理解，大差不差，平分秋色。

代码补全上，变量名替换，Cursor 100 分都少了，Trae 这个功能几乎等于没有。

意图猜测上，简单的 Cursor 和 Trae 差不多，复杂点的 Cursor 完胜。

tab 补全这个能力，是我付费 Cursor 的核心原因，它在工作中，实实在在的提高了工作效率。

Trae 在这一点上，并没有下功夫。猜测可能和 Trae 的定位有关，可能第一用户不是程序员，而是更多使用 builder(agent) 能力的人。

从产品维度上来说，Trae 的愿景可能更宏大: 程序员，你别写代码了，产品，设计师，你们快来用我的 builder 吧，大家别看代码，就做你的产品！

而 Cursor 更为专业，来吧，程序员，我真的很懂你的代码！

萝卜白菜，各有所爱吧。

最后，别忘了关注我的公众号：程序员芋仔。持续干货输出。