Antigravity 2.0新版IDE翻车：Bug频出、体验倒退引发用户众怒

引言：当IDE失去了"IDE"的灵魂

Antigravity 2.0 近日发布了重新设计的 IDE，然而这次更新并未收获预期中的好评。相反，用户反馈几乎一边倒地呈现负面态势——严重的 Bug、糟糕的用户体验、有限的模型支持，以及令人头疼的 Gemini Token 配额消耗问题，让这款新 IDE 陷入了舆论风暴。更耐人寻味的是，有迹象表明 Antigravity 自家的开发者可能并不使用自己的产品进行日常开发工作。

Bug频发：基本功能都不稳定

对于一款 IDE 产品而言，稳定性是最基本的底线要求。然而 Antigravity 2.0 的新版 IDE 在这一点上显然未能达标。大量用户报告了各种影响日常使用的 Bug，从编辑器的基础交互到代码补全功能，问题几乎无处不在。

要理解这一问题的严重性，需要认识到 IDE 在开发者工作流中的核心地位。IDE（集成开发环境）是开发者每天使用 8-12 小时的核心生产力工具，其稳定性要求堪比操作系统级别。业界成熟的 IDE 如 JetBrains 系列、VS Code 等，通常经历数年的迭代打磨才能达到生产级稳定性。VS Code 之所以能在短短几年内占据超过 70% 的市场份额，很大程度上归功于其基于 Electron 框架的稳定架构和微软投入的大量测试资源。对于新兴的 AI IDE 而言，它们不仅需要保证传统 IDE 的编辑、调试、版本控制等基础功能的稳定性，还需要处理 AI 推理请求带来的额外复杂性——网络延迟、模型响应异常、上下文窗口管理等都是新增的故障点。

值得深入探讨的是，传统 IDE 的稳定性建立在确定性的本地计算之上——语法高亮、代码折叠、自动缩进等功能的行为是完全可预测的。但 AI IDE 引入了非确定性的远程推理环节，这从根本上改变了稳定性的工程挑战。每一次 AI 交互都涉及网络 I/O、模型推理延迟（通常在 500ms 到数秒之间）、流式响应的渲染同步等问题。更复杂的是，AI 生成的代码需要实时插入编辑器，这要求编辑器的文本缓冲区管理、撤销/重做栈、语法树增量解析等底层机制都能正确处理"外部注入"的内容变更。许多新兴 AI IDE 在这一层的工程实现上存在明显不足，导致光标跳动、代码闪烁、撤销行为异常等问题频发。这些看似细小的问题，累积起来会严重破坏开发者的"心流"（Flow）状态，从根本上损害生产力。

一款开发工具如果连基本的编码体验都无法保障，那么再炫酷的 AI 功能也只是空中楼阁。用户选择 IDE 的核心诉求是提升开发效率，而频繁的 Bug 不仅没有提升效率，反而增加了额外的心智负担。这种"负优化"的体验让许多早期尝鲜者迅速回退到了旧版本或转向竞品。

用户体验大倒退：重新设计不等于更好设计

除了 Bug 之外，新版 IDE 的用户体验设计也遭到了广泛批评。所谓的"重新设计"并没有带来更直觉化的操作流程，反而在许多地方增加了不必要的复杂性。

模型支持严重不足

在当前 AI 编程工具百花齐放的时代，模型支持的广度和深度是核心竞争力之一。然而 Antigravity 2.0 在模型支持方面表现得相当有限，这直接影响了用户在不同场景下的使用灵活性。

当前 AI 编程工具领域，模型支持的多样性已成为关键差异化因素。主流大语言模型包括 OpenAI 的 GPT-4o/GPT-4.1 系列、Anthropic 的 Claude 3.5/4 系列、Google 的 Gemini 2.5 系列，以及开源阵营的 DeepSeek、Llama 等。不同模型在代码生成、Bug 修复、代码解释等任务上各有优劣——例如 Claude 在长上下文代码理解方面表现突出，GPT-4o 在多语言代码生成上更为均衡。Cursor 等领先产品允许用户根据任务特性自由切换模型，甚至支持用户自带 API Key 接入任意兼容模型，这种灵活性极大地提升了产品的适用范围和用户粘性。当 Cursor、Windsurf 等竞品纷纷支持多种主流大模型时，Antigravity 在模型支持上的短板会被进一步放大。

Gemini Token配额消耗异常

更让用户感到不满的是，新版 IDE 在使用过程中会快速消耗 Gemini 的 Token 配额。这意味着用户不仅要忍受糟糕的体验，还要为这些低质量的交互付出真金白银。

这里需要理解 Token 经济学在 AI 工具中的重要性。Token 是大语言模型计费的基本单位，通常每个英文单词约对应 1-1.5 个 Token，中文每个字约对应 1.5-2 个 Token。在 AI IDE 场景中，每次代码补全或对话交互都需要将当前代码上下文、项目结构、用户指令等信息打包发送给模型，这意味着单次请求可能消耗数千甚至数万个 Token。优化 Token 消耗的常见策略包括：智能上下文裁剪（只发送与当前任务相关的代码片段）、请求去重与缓存（避免对相同代码片段重复请求）、增量式上下文更新（只传输变化部分而非全量上下文），以及合理的请求触发机制（避免每次按键都触发 API 调用）。Gemini 模型虽然在 Google AI Studio 中提供了一定的免费配额，但在高频 IDE 使用场景下，配额消耗速度远超普通聊天场景。

Token 配额消耗异常的背后，往往涉及上下文窗口（Context Window）管理这一核心技术难题。当前主流模型的上下文窗口从 128K 到 1M Token 不等，但一个中等规模的代码仓库可能包含数十万行代码，远超单次请求的上下文容量。因此，AI IDE 需要实现智能的上下文检索机制——通常结合代码索引、向量嵌入（Embedding）和基于 AST（抽象语法树）的依赖分析来选择最相关的代码片段。RAG（检索增强生成）技术在这一场景中被广泛应用：先将代码库分块并生成向量索引，在用户发起请求时检索最相关的代码片段作为上下文。上下文选择的质量直接决定了 AI 响应的准确性和 Token 消耗效率——选择过多不相关的代码会浪费 Token 并可能引入噪声，选择过少则会导致 AI 缺乏必要信息而给出低质量回答。这也是各家 AI IDE 产品差异化的关键技术壁垒。

Token 消耗效率低下的问题暴露出产品在 API 调用优化方面的严重不足——可能存在不必要的重复请求、上下文管理不当等技术问题。从商业模式角度看，AI IDE 赛道面临一个深层矛盾：用户期望以固定月费（通常 $20-40/月）获得无限制的 AI 辅助编程体验，但底层模型的 API 调用成本是按 Token 线性计费的。以 GPT-4o 为例，输入 Token 价格约 $2.5/百万 Token，输出约 $10/百万 Token；Claude 3.5 Sonnet 的价格为输入 $3/百万、输出 $15/百万。一个活跃的开发者每天可能触发数百次 AI 交互，每次消耗数千到数万 Token，月度 API 成本可能轻松超过 $50-100，远高于订阅收入。这迫使 AI IDE 厂商在模型选择、请求频率控制、缓存策略等方面做出艰难的权衡——一些厂商选择在高频低复杂度场景（如代码补全）使用更小更便宜的模型，仅在复杂任务（如多文件重构）时调用旗舰模型，以此控制成本。Antigravity 在 Token 消耗上的失控，可能正是缺乏这种精细化成本管理策略的体现。

"吃自己的狗粮"：开发者信任危机

在所有负面反馈中，最具讽刺意味的发现或许是：有线索表明 Antigravity 自家的开发团队在日常工作中使用的是其他开发工具，而非自己打造的 IDE。

在科技行业，"吃自己的狗粮"（Dogfooding）是一条被广泛认可的产品原则——如果你自己都不愿意使用自己的产品，又怎么能期望用户买单？这一概念源自 1988 年微软经理 Paul Maritz 的一封邮件，他鼓励团队"吃自己的狗粮"来测试 Windows 产品。此后这一理念成为科技行业的金标准实践。微软要求 Office 团队日常使用自家 Office 套件，Google 员工在内部广泛使用 Gmail、Google Docs 等产品的早期版本，苹果工程师在新 iPhone 发布前数月就开始使用原型机。在 IDE 领域，JetBrains 团队使用 IntelliJ IDEA 开发 IntelliJ IDEA 本身，VS Code 团队同样使用 VS Code 进行日常开发。这种实践的价值在于：开发者能以真实用户的视角发现问题，Bug 修复的优先级更贴合实际使用场景，产品决策也更接地气。

这一发现从根本上动摇了用户对产品团队的信任。它传递出一个危险的信号：连最了解这款产品的人都认为它不够好用。当一个产品团队不使用自己的产品时，往往意味着产品与真实需求之间存在严重脱节。

AI IDE赛道的三点启示

这一事件为当前火热的 AI IDE 赛道提供了几点重要启示：

第一，基础体验不能让位于AI功能。 无论 AI 能力多么强大，IDE 的核心价值仍然在于为开发者提供稳定、高效的编码环境。在基础功能尚未打磨成熟的情况下急于推出重大更新，往往适得其反。

第二，Token经济性是AI工具的生命线。 随着 AI 编程工具从免费试用走向付费订阅，用户对 Token 消耗的敏感度会越来越高。如何在保证功能质量的同时优化 API 调用效率，是每个 AI 工具团队必须解决的工程问题。

第三，产品团队必须是自己产品的重度用户。 只有在日常开发中持续使用自己的产品，才能真正理解用户的痛点，才能在第一时间发现并修复问题。

总结

Antigravity 2.0 的这次更新堪称一次典型的产品翻车案例。在 AI 编程工具竞争日趋白热化的当下，这个赛道正经历着爆发式增长——Cursor 基于 VS Code fork 构建，凭借出色的 AI 代码编辑体验在 2024 年迅速崛起，估值突破数十亿美元；Windsurf（原 Codeium 旗下产品）主打深度代码理解和自动化工作流；GitHub Copilot 作为最早的 AI 编程助手，依托 GitHub 生态和微软资源持续迭代；此外还有 Augment Code、Trae（字节跳动旗下）、Zed 等新玩家不断涌入。这个赛道的特殊之处在于：开发者是最挑剔的用户群体，他们对工具的性能、稳定性和效率有极高要求，且迁移成本相对较低——切换一个 IDE 通常只需要几分钟的配置时间，这意味着产品必须持续提供卓越体验才能留住用户。

值得注意的是，开发者工具市场虽然单个工具的迁移成本看似较低，但围绕工具形成的生态系统（插件、配置、工作流集成）会产生显著的锁定效应。VS Code 的成功很大程度上归功于其 Extension Marketplace 中超过 50,000 个扩展，以及与 GitHub、Azure 等微软生态的深度集成。基于 VS Code fork 的 AI IDE（如 Cursor）天然继承了这一生态优势，用户可以无缝迁移现有的扩展和配置。而从零构建的 IDE 则面临"冷启动"问题——即使 AI 功能再强大，缺乏用户熟悉的插件生态和快捷键体系也会成为采用障碍。这也解释了为什么大多数新兴 AI IDE 选择基于 VS Code 或 JetBrains 平台构建，而非完全自研。对于 Antigravity 而言，如果其重新设计的 IDE 在生态兼容性上也存在短板，那么用户流失将更加不可逆。

Antigravity 团队需要迅速回应用户反馈、修复核心问题，并重新审视自己的产品开发流程——否则，在这个快速洗牌的赛道上，用户流失的速度可能远超想象。

核心要点

核心要点