Antigravity实测体验：模型翻车与配额焦虑的真实吐槽

一位学生开发者的真实困境

近日，一位学生开发者在Reddit上发布了对Google Antigravity（谷歌新推出的Agent化IDE平台）的深度吐槽帖，引发了大量共鸣。

Google Antigravity平台背景： Google Antigravity是谷歌推出的新一代Agent化集成开发环境（IDE），旨在将AI能力深度整合到开发流程中。所谓'Agent化'，指的是AI不再是简单的代码补全工具，而是具备自主规划、工具调用和多步骤执行能力的智能体。它能理解开发意图、自动拆解任务、调用终端命令、读写文件，甚至进行代码审查。Antigravity集成了Gemini（谷歌自研）和Claude（Anthropic开发）等多个主流大语言模型，允许开发者根据任务特点选择不同模型。这种多模型聚合策略在理论上能兼顾各家所长，但也带来了配额管理、模型切换成本等新问题。

作为一款集成了Gemini与Claude等主流模型的AI编程环境，Antigravity本应是提升生产力的利器，但这位用户的实际体验却充满了挫败感。

这篇看似简单的抱怨帖，实际上折射出当下AI编程工具的两个核心痛点：模型能力与基准分数的错位，以及配额定价对普通用户的不友好。

基准分数高，实际任务却频频翻车

Gemini系列的表现落差

该用户明确指出，Gemini 3.1 Pro的表现"令人失望"，而Gemini 3.7 Flash则"像是在猜答案，缺乏合理的思维链条"，经常"敷衍了事"（half-asses everything）。

最让他困惑的一点是：这些模型在基准测试中拿到了很高的分数，却在最简单的任务上频频失败。 这其实是业界长期存在的争议——基准分数与真实开发场景之间的鸿沟。

基准测试与实际能力的错位现象： AI模型的基准测试（Benchmark）通常采用标准化数据集，如HumanEval（代码生成）、MMLU（多任务语言理解）、GSM8K（数学推理）等。这些测试集题目明确、答案标准，便于量化比较。然而，真实开发场景远比基准复杂：需求往往模糊且多变，代码库存在历史债务和隐含依赖，上下文可能跨越数十个文件。模型在封闭测试集上的高分，可能源于对特定题型的过拟合，或是训练数据中包含了测试集的相似样本（数据泄露问题）。这种'应试能力'无法保证在开放环境中的泛化表现，就像学生能在模拟题中拿高分，却在实际项目中手足无措。业界已有多篇研究指出，基准分数与用户满意度的相关性远低于预期。

不少模型为了在标准化测试集上取得漂亮的数据，会针对特定题型进行优化，但这种优化并不总能迁移到实际的、上下文复杂的编程任务中。当开发者面对的是真实项目里模糊的需求、隐含的约束和多文件依赖时，模型的"应试能力"就显得力不从心。

对Prompt的极端依赖

用户还提到，这些模型"需要极其详细的提示词，不像其他模型那样"，即便他提供了规范的Prompt，输出结果依然"难以信任"，"大多数时候都会把事情搞砸"。

这暴露了当前部分模型在指令理解鲁棒性上的不足。

指令理解鲁棒性的技术解析： 指令理解鲁棒性（Instruction Following Robustness）衡量的是模型在面对不完整、歧义或非标准提示词时的表现稳定性。优秀的AI助手应具备'意图推断'能力——从简短描述中补全合理假设，或通过追问澄清需求。这依赖于模型的上下文学习（In-Context Learning）和指令微调（Instruction Tuning）质量。如果模型过度依赖详细的Few-Shot示例或冗长的Prompt模板，说明其泛化能力不足。这背后可能是训练数据偏向高质量、结构化的输入，导致模型在面对口语化、省略式的真实指令时'水土不服'。理想的鲁棒性需要在多样化、带噪声的指令数据上进行强化训练，并引入反馈机制让模型学会主动澄清。

理想的AI编程助手应该具备一定的意图推断能力，能从简短的描述中补全合理的上下文。如果每次都需要用户手写超长Prompt才能勉强工作，那么工具本身节省的时间反而被写提示词的成本抵消了。

配额焦虑：一条命令烧掉一半额度

Claude模型的高Token消耗

如果说模型能力是"体验问题"，那么配额则是直接的"生存问题"。这位用户描述了一个极端案例：他只是让Antigravity运行一条PowerShell命令，就消耗掉了5小时配额的50%。

这个数字相当惊人。一条简单的系统命令执行，本不应该消耗如此巨量的Token。

Agent模式的Token消耗机制： Agent模式下的AI工作流与传统的单次问答截然不同。执行一条简单命令可能触发复杂的内部循环：首先，Agent读取当前上下文和任务描述（消耗Input Token）；接着，生成执行计划并调用工具（如文件读写、终端执行），每次工具调用的结果都会作为新的上下文被重新输入模型（再次消耗Token）；模型验证结果、判断是否需要纠错或继续下一步；最终生成总结报告（输出Token）。如果Agent陷入'思考-执行-验证'的低效循环，或因错误理解反复重试，Token消耗会指数级增长。Claude等模型的上下文窗口虽大（可达200K Token），但单次调用成本也更高。5小时配额被一条命令消耗50%，可能意味着该操作触发了数十轮内部交互，总Token数达到数万甚至十万级。

这背后可能涉及Agent模式的工作机制——AI在执行任务时会反复读取上下文、规划步骤、调用工具、验证结果，每一轮交互都在消耗Token。当Agent陷入低效循环或过度"思考"时，配额就会被迅速烧光。

Claude模型的成本结构： Claude系列（由Anthropic开发）以其出色的指令遵循和安全性著称，但调用成本也处于行业高位。以Claude 3.5 Sonnet为例，API定价约为每百万Input Token 3美元、Output Token 15美元（实际价格因版本和渠道而异）。在Agent模式下，由于需要反复读取大量上下文，Input Token占比极高。一次看似简单的任务可能涉及读取整个代码库的核心文件（轻松数万Token）、多轮工具调用和结果验证，最终累计消耗可达数十万Token。对于免费用户或学生套餐，配额通常按'小时数'或'请求次数'而非纯Token计费，但底层仍映射到Token消耗。一旦单次任务触发高频交互，配额迅速见底。这也是为何许多AI编程工具对学生用户限制严格——成本压力确实存在。

学生群体的经济压力

用户特别强调了自己的身份："作为一名学生，我没有钱购买Claude套餐或其他任何付费方案。" 他还提到自己安装了名为Ponytail的工具，希望能减少Token消耗，但不确定它到底有没有起作用。

这触及了AI工具普及的核心矛盾。高质量模型（尤其是Claude系列）的调用成本高昂，而免费额度往往在几次实验后就被耗尽。对于学生、独立开发者和初学者而言，这构成了一道实实在在的门槛——他们恰恰是最需要AI辅助学习的群体，却也最难承担持续的订阅费用。

从吐槽中看到的行业信号

AI工具评价需要回归真实场景

这位用户的经历提醒我们，评估一款AI编程工具时，不能只看官方宣传的基准分数和演示视频。真实的开发工作流——包括模型的稳定性、对模糊指令的容错、Token的实际消耗效率——才是决定用户体验的关键。

单一Reddit用户的抱怨当然带有主观色彩，我们也需注意其观察可能受特定项目、网络环境或工具配置影响。但当越来越多用户反映类似问题时，就值得开发商认真对待。

定价模式的可持续性挑战

Antigravity这类聚合多模型的平台，如何设计一个既能覆盖成本、又对普通用户友好的定价与配额机制，是一个长期挑战。过于激进的Token消耗会直接劝退潜在用户，尤其是在竞品众多、切换成本低的当下。

给同类用户的实用建议

对于面临类似困境的学生和预算有限的开发者，这里有几点可以参考的策略：

• 明确任务边界：让Agent执行任务前，尽量拆解成小步骤，避免它在一个复杂任务中反复循环消耗Token。
• 善用免费或低成本模型：对于简单任务，优先使用消耗更低的模型，把Claude等高端模型额度留给真正复杂的场景。
• 监控Token消耗：留意每次操作后的额度变化，找出"吞Token大户"操作并加以规避。
• 关注开源替代方案：本地部署的开源模型虽然能力有上限，但没有配额焦虑，适合日常练习和学习使用。

开源模型的本地部署方案： 开源大语言模型（如Meta的Llama系列、Mistral、DeepSeek-Coder等）允许开发者在本地硬件上部署运行，彻底摆脱配额和网络依赖。本地部署的核心挑战在于硬件要求：7B参数模型需要至少16GB显存（如RTX 4080），13B模型需要24GB以上（如RTX 4090或A5000），更大的模型则需要多卡并行或量化压缩（如4-bit量化可将显存需求减半）。部署工具链已相当成熟，Ollama、LM Studio、vLLM等工具提供一键安装和API服务。虽然开源模型在复杂推理任务上与GPT-4或Claude仍有差距，但在代码补全、文档生成、简单重构等场景中表现已可接受。对于学习阶段的学生，本地模型可无限次试错，积累Prompt工程经验，无需担心'用完配额就卡壳'的焦虑。

结语

这篇来自Reddit的真实吐槽，是AI编程工具走向成熟过程中一个有价值的注脚。技术宣传常常聚焦于"能做什么"，而普通用户的痛点往往在于"稳不稳、贵不贵、好不好用"。对于Antigravity及其背后的团队来说，真正赢得开发者信任的，从来不是基准榜单上的数字，而是在一个又一个真实任务中交付可靠的结果。

核心要点