Gemini Spark下放至Pro用户首测

背景

随着大型语言模型（LLM）在创意写作和编程辅助等场景中的普及，用户对模型的连续执行能力、上下文长度、生成速度以及交互体验提出了更高要求。Google 旗下的 Gemini 系列模型近期推出了多个变体，其中“Gemini Spark”和“Antigravity”（注：均为社区对 Gemini 不同模型或功能的俗称）成为用户对比的焦点。Gemini Spark 被下放至 Pro 用户首测，但实际体验引发了广泛争议。本文作者在 LINUX DO 论坛分享了其使用 Spark 和 Antigravity 完成小说写作任务的详细对比，揭示了模型在稳定性、上下文利用、文件操作和用户交互方面的显著差异。

核心内容

作者首先指出，Gemini Spark 的初步体验“非常差”，尤其在写小说案例中，每写 10 个章节左右就会因安全限制而中断，需要用户回复“继续”才能推进，这令作者感到烦躁。Spark 的工作机制是分轮次执行：每一轮完成后，它会自我派发一个定时任务（约 1 分钟后），由下一轮自身继续，周而复始直到任务完成。然而，最大的问题是 Spark 会中途停止——当需要生成超过 10 个文件时，它不会主动请示下一步行动，而是要求用户手动回复“继续”。相比之下，竞品 Antigravity 和 Hermes 只要不是 API 错误，通常不会停止，即使烧完额度也会继续运行。

在速度方面，Spark 使用的 3.5 Flash 模型生成速度高达 600–900 tok/s，明显快于 Antigravity 的 280 tok/s。但鉴于 Spark 频繁要求用户手动确认，速度优势被抵消，作者更偏好 Antigravity 的“一次性完成”模式。

此外，Spark 无法编辑本地文件，这带来了大量问题。当作者要求修改某个 Markdown 文件时，Spark 的做法是直接读取文件内容，然后重新生成并输出，而非直接编辑原文件。这种“吃进去再背出来”的方式效率低下。同时，Spark 模式下缺少 Canva 的补救选项。

在上下文长度方面，Spark 拥有完整的 1M 上下文，能够完整吃下自己的中间产物（如每个章节的伏笔、前因后果等），而 Antigravity 的上下文似乎只有 256K 到 500K 左右（可能更少）。但 Antigravity 会派发子代理（subagent）来弥补这一缺陷。

作者将相同的提示词分别发送给 Spark 和 Antigravity，发现两者生成的小说存在类似的毛病：

• 心理活动描写用词高度模板化，换个名字几乎可套用到任何武侠人物上，第二篇后期尤其明显，例如“轰！陆无回的脑海中仿佛有一道惊雷炸响”。
• 章节结尾频繁出现目的明显的钩子，读几章后基本可以预判结尾句式。

作者认为，对 3.5 Flash 模型要求更高文笔不太现实，仍需要人工介入才能发挥文笔。结果本身的参考价值不大，但都能完整完成任务。最有参考价值的是模型本身——那个持续跳票且“美美隐身”的 3.5 Pro 何时到来，作者表示不知道。

在结论上，作者认为 Antigravity 和 Spark 在结果上并无明显差别，也没有谁更突出。Spark 仅有电脑网页版可用，无法在手机上发起任务，因此不如直接使用 Antigravity 下达任务。没有获得 Spark 资格的 Pro 用户也不会有太大损失。

作者还分享了自己获得 Spark 资格的经验：使用的 Google 账号是 2014 年购买的，经历过 Pixel 被甩下车并再次验证家庭组。在 4 至 7 月期间，Antigravity 的 Gemini 池子额度几乎用尽，且经常使用 Gemini 网页版上传 YouTube 知识影片讨论细节，以及登入 Chrome 侧边栏频繁提问，可能被判断为高价值用户。此外，作者长期使用的 IP 魔法固定在西雅图，很少变动。

关键要点

• Spark 的核心问题：分轮次执行但会中途停止，要求用户手动回复“继续”，无法自动完成长任务。
• 速度对比：Spark 的 3.5 Flash 速度（600–900 tok/s）远快于 Antigravity（280 tok/s），但频繁中断抵消了速度优势。
• 文件操作缺陷：Spark 无法直接编辑本地文件，只能读取后重新生成，且缺少 Canva 补救选项。
• 上下文长度差异：Spark 拥有完整 1M 上下文，能保留所有中间产物；Antigravity 上下文较小（256K–500K），但通过子代理补偿。
• 生成结果质量：二者在小说写作中均存在模板化心理描写和可预测的章节结尾钩子，文笔仍需人工介入。
• 可用性：Spark 仅限电脑网页版，不支持手机端；Antigravity 更灵活，可随时下达任务。
• 资格获取经验：作者推测高频使用、长期固定 IP（西雅图）以及账号历史可能有助于获得 Spark 资格。
• 模型展望：用户更期待持续跳票的 3.5 Pro 模型，而非当前体验欠佳的 Spark。

意义与影响

该评测揭示了当前大型语言模型在“连续任务执行”这一关键场景中的设计缺陷。Spark 虽然引入了分轮次自我调度机制，但对用户交互的过度依赖（如要求手动确认“继续”）严重破坏了自动化体验，这与用户对“一次触发、完整输出”的期望背道而驰。相反，Antigravity 通过子代理和一次性完成机制，在任务连续性上更胜一筹。这一对比表明，模型设计不仅要考虑生成质量和速度，更需关注任务编排的鲁棒性和用户交互的顺畅性。

此外，文件操作能力的缺失（无法直接编辑本地文件）暴露了 Spark 在工具集成上的短板，这限制了其在真实工作流（如文档协作、代码修改）中的应用价值。上下文长度与子代理的权衡也值得关注：更大的上下文窗口固然能保留更多细节，但若缺乏有效的分解机制（如子代理），反而可能因中断或效率问题拖累体验。

对于社区而言，此次评测提供了一个真实的用户体验样本，帮助其他用户在 Spark 和 Antigravity 之间做出选择，并促使模型开发者重新审视功能优先级。作者对 3.5 Pro 的期待也反映了用户对更高性能模型（尤其是文笔和稳定性）的持续渴望。最后，资格获取的玄学因素（如 IP 固定、高频使用）提醒用户，平台对测试资格的分配可能并非完全随机，活跃度与地理一致性可能成为隐性门槛。