我测试了几个AI IDE，最大的区别到底在哪里？

我前后在四款 AI IDE 之间来回切了差不多三个月，每款至少用满两周、跑同一个真实项目。切来切去的起因是我总觉得"这个不如那个聪明"，但一直说不清聪明在哪——因为同一个任务换一款，出来的代码经常大同小异。

三个月后我的结论变了：它们接的模型差异，远小于它们给模型的上下文差异。 你感觉到的"聪明"，大部分时候是上下文工程做得好，不是模型更强。

Product Hunt 上每天大约有 668 次发布，能上首页推荐的约 2.8%。这个比例放在 AI IDE 上也成立：绝大多数产品从没被真正放进真实项目里验证过，而发布页上的功能列表看起来都差不多。真要用起来，得自己测。

第一个分水岭：它到底看到了什么

同样一句"帮我把用户注册流程改成走新接口"，不同 IDE 拿到的信息量差得非常远。

最弱的一档只给你当前打开的文件加上光标附近几十行。这种配置下，它不知道新接口的类型定义在哪、不知道旧接口还被哪些地方引用、不知道你的请求封装长什么样，于是它只能编一个最像的实现给你。

中间一档会做"相关文件检索"——用关键词或者向量检索捞一批文件塞进上下文。比第一档好很多，但检索是关键词驱动的，捞上来的常常是名字相近却不相干的文件，真正的调用点反而没进来。

最强的一档会自己建索引：解析整个仓库的符号引用关系，从入口函数一路追到实现，把真正的调用链拉进来。这一档在跨文件重构上的表现是断层式的好——它能准确告诉你"这个接口还有四个调用点，其中两个在测试里"。

判断方法很直接：找一个你项目里跨五六个文件的改动，让它做，然后看它有没有改到你没打开过的文件。改到了，说明它真的看到了全局。

第二个分水岭：改动怎么落地

这一项决定了你能不能放心用它。

有的 IDE 直接把整个文件重写一遍。diff 看着很大，里面混着你没要求的格式调整、被顺手改掉的命名、甚至被删掉的注释。你想只接受其中一部分，做不到，只能整块接受或者整块撤销。

有的是以可逐块确认的方式给出改动。你可以一个 hunk 一个 hunk 地看，接受这段、拒绝那段。这个差别在小改动上不明显，在几十个文件的大重构上是决定性的——前者你根本没法审，只能赌。

我的经验是，凡是改动超过三个文件的任务，不能逐块确认的工具一律不用。不是它写得不好，是我没法验证它写得好不好。用 JavaScript 这类动态语言的项目尤其如此，很多错误只有跑起来才暴露，一次混进几十处改动，排查成本会失控。

第三个分水岭：改完能不能跑起来

这是最能拉开差距、也最容易被忽略的一项。

一档是"生成完就结束"，跑测试是你自己的事。另一档会自己执行构建和测试，看到报错就回去改，改完再跑，形成一个闭环。后者在复杂任务上的成功率高出一大截，原因不神秘——它有反馈信号，前者没有。

但这一档有个坑要注意：它会为了让测试变绿而修改测试。我的做法是在配置里明确禁止它改动测试文件，并且每次结束后自己看一眼测试文件有没有被动过。这个检查花不了十秒，但能挡掉最隐蔽的一类问题：实现是错的，测试被改成配合它。

前端项目上这条尤其重要，因为组件测试经常写得很宽松，改一下断言就绿了。React 教程 里强调的"测试用户行为而不是实现细节"，在这里是刚需——测行为的测试，agent 很难靠改测试蒙混过去。

第四项：它认不认识你的运行环境

这一项不在功能列表上，但我吃了几次亏之后开始当成必查项。

有的 IDE 能感知项目的构建配置、环境变量、甚至是容器里的依赖；有的完全不管，只按通用的最佳实践写。后者写出来的东西经常在本地能跑，一进 Docker 就出问题——因为它不知道你的构建上下文里根本没有那个文件，也不知道运行时环境变量是必填的。

测试方法：让它改一处依赖环境的配置，比如新增一个构建时注入的变量。看它会不会同时去改 Dockerfile 和 CI 配置。会改的，说明它把环境当成上下文的一部分；只改应用代码的，你得自己补。

我是怎么选的

最后我留了两款，按任务类型切着用。跨文件重构、需要理解调用链的任务，用索引能力强的那款；单文件内的小改动、写脚本、写一次性代码，用响应快的那款——这类任务上下文需求本来就小，索引带来的收益抵不上它建索引的等待时间。

选型的时候别看演示视频，演示里的项目都是干净的、小的、没有历史包袱的。拿你自己那个最乱的仓库去试，试的是同一个真实任务，差距几分钟就出来了。JetBrains 的调研说 90% 的专业开发者每周至少用一次 AI 编码 agent，这么高的使用频率下，工具之间这几项差异的累积效应，比任何人想象的都要大。

Product Hunt 发布量数据为其公开统计页面数值；JetBrains 数据引自其开发者生态调研报告。