先给大家普及一下背景：我们现在使用的TRAE和CodeBuddy是国内版本，选择的模型是DeepSeek V3.1，其他的设置保持默认。今天我们主要测试的方向是Agent能力和代码补全。项目代码已经准备好，依然是大家耳熟能详的老朋友若依。
开发完成后，我们用Cursor写了一个博客管理模块。
现在这个模块实现了文章管理的所有功能，包括增删改查，都能正常使用。
接下来，我们会把代码复制成三份，分别用这三个IDE打开。等代码索引建立完毕后，我们输入一段提示词，需求其实很简单：在当前的博客管理模块中创建一个文章分类的子模块，同时也给出了数据库字段的建议。
接下来，Agent需要完成后端逻辑、前端页面和数据库脚本的创建。如果在这个过程中出现了意料之外的结果，我会指出它们遇到的一些问题，让它们去进行修改，直到所有功能正常可用为止。现在这三个IDE的工作都已经结束了。
同样的需求、同样的提示词，谁能最快达到预期效果呢？
我这边准备了一个表格，这次我们主要比拼六个方面，我会给每个IDE的表现打分，每项满分五分，我们一起来看看。
首先是需求理解部分，我觉得三个工具的理解都没有问题，因为最终它们都实现了功能，效果也符合预期。这一项我给五分。
接下来是任务驱动开发。Coder会先给你列出一个待办事项清单，而TRAE和CodeBuddy则直接开始动手。代码完成后，三个IDE都会列出完成的工作内容。而Coder在待办清单中也会阶段性更新进展。
这个互动逻辑我觉得很不错，所以我给Coder五分，其他两个四分。
再来看一下多轮交互能力。三个IDE的表现都很不错，因为我们写完代码后，都会遇到一些问题。在与它们沟通时，它们都能结合上下文找到相关代码，最终解决问题。因此这一项我给它们三个都打五分。
然后是跨文件修改。因为我们的需求涵盖了数据库SQL、前端页面和后端Java代码，难度还是有点大的，对吧？
在这方面，表现最好的我认为是TRAE。举个简单的例子：我已经建立了博客管理的菜单，而TRAE通过检索过往SQL得到了这个信息，所以在创建文章分类菜单时，它就自动分配了副菜单ID。
这一点让我非常惊讶。而且，它会把博客分类的代码放到已有的blog模块文件夹中，这体现了代码的一致性。相比之下，Qoder没有考虑到这些，它把category直接放到了system下面。这样的代码提交上去肯定过不了审核。更糟糕的是，它没有考虑已存在的博客管理一级菜单，导致重复创建。在我执行的时候，我还特别指出了这个问题。
然后它才去修改。所以我觉得它整体上还是不如TRAE。而CodeBuddy的代码层级是对的，SQL语句也考虑到了已有的博客管理一级分类，但缺少了一个delete_flag字段，导致后续代码出现了错误。在代码一致性方面，它的表现也不如TRAE和Qoder。
不过在测试功能时，我发现TRAE在页面上没有参考项目的一些写法，比如form缺少ID、权限代码使用错误等。
这两项的评分如下：
– 跨文件修改：Qoder 3分，TRAE 4分，CodeBuddy 4分
– 代码一致性：Qoder 4分，TRAE 4分，CodeBuddy 4分
最后说说实际效率这一轮，三个IDE在测试阶段都或多或少存在一些问题。
不过在我反馈错误信息后，它们能够一次性解决。从整体耗时来看，生成代码加测试阶段耗时最短的是Qoder，接下来是TRAE，最后是CodeBuddy。
我发现TRAE在解决问题时深入源码的风格让我很放心。比如前面提到的form缺少id，正常情况下它可以参考其他模块——这个列表页面的查询表。
但是它是怎么做的？这个问题很轻松就解决了。而TRAE会找到负责这个组件交互的JS源码，反推得出是因为没有给这个form设置id，导致搜索失效。这一点我非常喜欢——虽然有一些小问题，但它在解决问题时能从底层原理入手。
这对我后续与它的协作会有很大帮助。这一轮我给Qoder四分，TRAE四分，CodeBuddy三分。当然，这个阶段的评分也与我反馈问题的难度有关，但我认为这也是效率考核的一部分。因为如果你在前期能避免这些繁琐问题，后期就不需要花很多时间在测试阶段去调整了。不过，这个测试也有一定的运气成分，如果大家感兴趣的话——
可以使用我的提示词在本地测试一下，或许你得到的结果和我视频中的会有所不同。在横向对比的过程中，大家可以通过这种测试方式找到最适合自己的AI工具。
接下来我们再看看代码补全，因为手动编写代码的情况还是比较常见，所以代码补全的流畅性也很重要。我这次准备了一个表格，本轮比拼主要从以下六个方面进行评测。
每个项目也是满分五分。我们逐一来看。首先是重命名操作，比如把变量名surface改成bcs。此时可以看到TRAE能自动感知其他引用位置，按下Tab就会自动跳转并做出修改。这个功能称为Q。而Qoder和CodeBuddy就没有这个功能。
再举个常见的例子：在方法入口添加一个打印日志的逻辑，TRAE会自动跳转到下一个修改点，反应速度非常快。而Qoder虽然也有NES功能（即Next Edit Suggestion），但大家可以看到，在我手动输入第二条时，它才会触发修改点的预判。之后一路Tab就能无脑完成操作。而CodeBuddy完全没有这个功能。所以在第一项重命名和修改点预测的评分上，我给Qoder……
五分，而CodeBuddy给三分，希望CodeBuddy能尽快加入类似Qoder的功能。接下来我们看看多行修改。这次我想实现一个联动删除的功能，也就是删除分类后，下面的文章也会一并删除。首先来看TRAE，我找到了负责删除分类的service方法，在注释中添加了新的描述，它会自动在方法内部生成相应的代码。
我觉得这真是太神奇了。Qoder和CodeBuddy在这一步就不具备这个能力，它们只是在注释层面提供一些文字补全，有时候推荐的内容还会出错。我需要把光标移动到要写文章删除的行号，才能让它们补全相应的代码。目前这三个IDE对于Java代码都不支持自动导包。
我们来到文件头部，自己去引用声明，然后到blogArticleMapper的文件中，当光标定位到文件底部时，可以看到TRAE自动生成了相关代码，包括注释和方法定义都是正确的。特别是这里的参数类型long，显然它有上下文传递的能力。
接下来我们去xml文件编写SQL，光标一放下，它就知道我们要干什么，生成的SQL语句也是正确的。然后我们来到SQL文件，其实是想给blog_article增加一个category字段，对吧？同样的，光标一落下，代码就自动生成，非常流畅。而相比之下，Qoder和CodeBuddy当我们进入blog_article_mapper文件时，代码补全似乎就失效了。它们都需要你先写注释，或者输入一些文字，才能开始反应。而在xml文件也是一样的情况，对吧？它会先给你一些推荐，然后你写了delete定义后，
它才会想起来该干什么。在circle文件中，表现也是如此：你必须先写注释，它才能想起来要做什么。在多行修改方面，我给Qoder和CodeBuddy只能打三分，而TRAE表现得非常出色，所以我给它五分。
在当前文件内的代码补全方面，三个工具的表现都不错，但Qoder和CodeBuddy的智能性略逊：Qoder给四分，CodeBuddy也给四分。整体上看，TRAE表现……
TRAE的表现真是让人刮目相看！
我觉得TRAE真的是优秀到不行，所以我给它打了五分。一换文件，TRAE的表现就能让人眼前一亮，大家应该都能感受到它的连续性和上下文传递能力。就这一点，TRAE绝对值得五分。而Qoder和CodeBuddy这俩就没那么好运了，最多只能给三分，因为它们一换文件就像失忆了一样。至于效率呢，完全是个人的主观感受，所以在我看来，TRAE的五分和CodeBuddy的三分是非常贴切的。
说到Coder，它的得分是四分，因为它能预测下一个修改点，而CodeBuddy就完全没有这功能。就代码补全这一项，TRAE简直是完胜了！从整体来看，这次评测中，Coder在执行效率上表现得相当不错，而CodeBuddy则显得比较平淡，没有特别出色的地方。不过让我感到惊喜的还是TRAE，它在跨文件修改和代码一致性这些考验中，展现了更强的整体理解能力，真是了不起。
在代码补全方面，TRAE的表现简直是全面碾压其他两个工具，特别是在多轮交互、跨文件修改和上下文的连续性上，都给人一种“我懂你”的感觉，写代码合作起来非常流畅。
如果让我最终总结一下，我觉得TRAE是这三款工具中最值得长期使用的。它不仅能完成Agent驱动的任务，还能在日常编程中节省我们不少时间和精力，提高效率。
至于Coder，它可以作为一个不错的补充，因为它的Agent能力还是挺强的。而CodeBuddy呢，目前看来还需要时间来追赶，提升自己的实力。
来源见截图水印
