Theo 测试 Gemini 4 Argon：设计长处与代码审查疑虑

Gemini 4 Argon 终于来了。从 Gemini 3.1 Pro 到这次发布，我算下来已经间隔了八个月。我提前获得了使用机会，测试了价格、前端设计、一个 3D 游戏和代码审查工作。它有长处，但我在较复杂代码任务中的体验令人失望。

Google 的朋友帮助我提前使用这个模型。Google 作为 YouTube 平台向我支付创作者收入，但没有为这次 Gemini 评测付费。我的判断基于视频中展示的测试和例子；其他人的工作负载和结果可能不同。

Google 将 Argon 定位为处理编码及其他领域复杂多步骤任务的模型。我查看了外部排行榜，但发现其中给另一个模型标注的价格值得怀疑，这降低了我对该比较的信心。基准的成本假设和分数同样重要。

在我展示的 Artificial Analysis 智能指数中，Argon 的结果高于某些模型，低于部分设置下的 Opus 5.5。按每次完成基准任务的成本计算，它没有按 token 单价看起来那么划算。这个指数是一个综合参考，并不能完整衡量编码能力。

Google 的发布材料列出的首发价格是每百万输入 token 2 美元、输出 token 10 美元，缓存读取另有折扣。在我的测试中，token 用量和缓存命中率让实际成本不那么吸引人。我观察到约 70% 至 80% 的缓存命中率，而我的配置中某些替代模型超过 99%。

我无法确定缓存结果来自模型、Antigravity 的报告方式，还是我们在 T3 Code 中的集成。这些只是可能原因，不是诊断结论。我还提到，Google 当时表示首发价格将在 12 月 1 日提高到每百万输入 4 美元、输出 20 美元；这些数字反映的是视频发布时的公告。

Google 引用了内部数据，称智能体代码提交增加、回滚减少，并展示了 Chrome 重构案例。这些是 Google 自己的测量和例子。我更想看看在自己的任务中会发生什么：设计、准确性以及达到有用结果所需的时间都很重要。

一个惊喜是 SkateBench：我用于识别滑板动作名称的私有基准。在我展示的测试中，Argon 在已完成的问题上取得满分，而 Opus 5.5 Max 得分为 79%。早期测试期间 API 出现错误，因此我不得不调整基准以应对不稳定。

模型在这个特定任务中速度快、用量也较省。但在狭窄测试中取得满分，并不能证明它在所有工作中都可靠。声称成功率达到 100%，只有在理解测试任务及其与自身需求的关系后才有意义。

Google 强调了处理文档、视频和音频的多模态能力。过去我发现 Gemini 模型在视觉任务上表现不错，例如给照片中的零件标注名称。本视频重点测试代码，我没有对这些能力做基准测试，因此建议针对相关用途单独测试。

公布的首发价格是暂时的。我不喜欢用户开始构建产品后价格再上涨的方式。不论标价多少，现实中的成本比较都应考虑输出量、缓存行为，以及完成任务所需的尝试次数。

在前端设计方面，我曾用早期 Gemini 模型制作视频审阅产品 Lawn。在这里展示的例子中，我觉得 Argon 生成的主页美观，互动部分也能运行。这是一个积极结果，尽管我会减少页面上的文字。

这些例子使用了 Anthropic 的设计技能。在我的比较中，关闭它会得到更重复的导航和布局；另一个 taste 技能对我来说效果也不如它。这些是主观设计判断，会受提示词和工具影响，不能当成普遍排名。

对于某些营销页面设计，我仍更喜欢 Fable 5.1；处理真实用户体验时，我重视快速迭代。模型生成 token 快，不一定意味着它能迅速解决问题。对我来说，能否与它反复调整，比一次令人印象深刻的初稿更重要。

不同服务商也会给模型提供不同的工具和数据。Gemini 的 YouTube 相关能力对我这样的创作者很有用，包括获取信息和字幕。我在其他 Google 服务集成上的体验没那么好，所以会分别评估具体任务，而不是假定每项集成都一样出色。

我听说 Gemini 在多语言和本地化工作中可能有特殊优势，但我自己的测试没有证实这一点。SkateBench 显示，它确实可能在其他评测没有发现的领域有独特长处。值得寻找这些能力，但不能假设它们能迁移到所有领域。

我的 Fish Slap 测试让不同模型在相同配置下构建同一个 3D 游戏。Argon 的版本实现了完整的五个鱼缸流程，鱼的部分动画也比较合理，但我认为视觉效果和潜艇模型不够出色。更重要的是，第一版存在游戏机制问题。

食物落到鱼缸底部后不会消失，而鱼又无法吃到它。鱼会围着食物聚集，最终饿死；食物数量限制也让我无法简单地继续投喂。我要求模型修复投喂和水面问题并改进画面；下一版看起来更好，也修复了大部分投喂行为。

剩下的一个例子是伤害增强道具：下一波敌人到来之前，它就已经失效。模型实现了一个看似合理的功能，却没有让它与游戏时间安排相协调。我把它称为系统层面判断失败，而不是幻觉：道具确实存在，只是在当前设计中没有用。

我展示的 Artificial Analysis 图表报告，Argon 在一项评测中的幻觉率较低。该评测也考虑答对和拒答，因此错误率低并不等于总分高。我自己的代码工作中出现了许多我判断为错误的说法，这说明结果可能随任务而变化。

我请多个模型审计 TS Rust，也就是我用 Rust 重写的 TypeScript 编译器，验证它们的说法后，再让一个模型评委组给报告打分。在这次测试中，GPT-6.1 Sol 的 38 条核查说法全部正确，平均得分为 8.84。Opus 5.5 得分为 8.78，有一条错误，在展示的比较中耗时更长、成本更高。

Argon 在这次审计中得分为 4.38，耗时约 43 分钟，按测试中的价格假设成本约 3 美元。展示的结果将 36 条核查说法中的 24 条标为错误。这是我的特定代码库、运行环境和评估方法得出的结果，并非所有 Gemini 使用场景的错误率。

在另一次针对 T3 Code 批量更新问题的审计中，Opus 在我的比较里得分最高，但也有一些错误说法。Sol 漏掉了一些严重问题，却在那次测试中没有提出错误说法，而且更快、更便宜。这也是我喜欢同时比较准确性、有用程度、时间和成本的原因。

在我的评分中，Argon 的 Lakebed 审计结果更差：10 分中得到 2.25 分，78 条核查发现中有 56 条被标为错误。在 T3 Code 架构审计中，我报告了 31 条正确、14 条部分正确和 47 条错误发现。如果审查者自信地让团队追查不存在的问题，就可能造成实际损害，因此我会独立核查其发现。

我还觉得它的回复冗长、不易阅读。我的结论很严厉，因为这些结果与我自己反复遇到的挫折一致，但测试仍然是我设计的：项目、提示词、集成方式、评判过程和抽查的说法都会影响结果。

在一个具体编码任务中，我请模型调查 SQLite 连接不稳定。它指出了读连接池和单写入连接的方向，随后我让它实现第一优先级。生成的 PR 耗时约半小时，修改超过一千行，而且检查失败。我关闭了它，没有合并。

我请 Opus 审查这个线程和 PR。它认为，最初的诊断发现了一个真实机制，但证据不足；实现则仍然把阻塞工作留在主线程。它还指出已经有 PR 在处理这个问题。按我的描述，后来一个小得多的改动得到了合并。

另一次长时间运行后，我遇到了网关故障，只能在没有原线程历史的情况下重新开始。我还觉得 Antigravity 集成不够顺手，包括模型和推理强度选项的呈现方式。我无法从一次失败推断所有问题分别由哪个组件造成，但周边工具的可靠性确实会影响用户体验。

我担心账号访问问题，因为我的 Gemini 账号与我依赖的其他 Google 服务相连。我说 Google 承诺过更有限的限制，但我看到的一些报告让我保持谨慎。这是我对风险的判断，并不是说使用这个特定集成必然会导致账号被封。

经过这些测试，我不打算在自己的项目中用 Argon 承担大量代码工作。我仍可能考虑用 Gemini 获取 YouTube 数据，或制作初步前端设计。我希望看到取得更好结果的人的反馈和例子；模型也许有我的测试没有覆盖的有用长处。