Gemini 4 Argon 编程测试：任务设计、评测方法与 API 验证

Gemini 4 Argon 是什么？

Gemini 4 Argon 是本评测协议中使用的模型名称。本文不证明该名称对应的身份、提供方、可用性、文档、价格或 API 访问方式。开始测试前，必须从获得授权的来源确认这些事实。

对开发者来说，问题不只是“模型有多强”，还包括它能否完成明确任务、产出可运行的代码、从失败中恢复，以及延迟和成本是否可接受。这正是本协议关注的内容。

评测方法

公平比较需要为每个模型保持相同的仓库、提示词、工具权限、上下文和验收检查。应在干净工作树中运行每项任务，保存首次响应，记录每次追问，并在模型停止后执行相同的自动化检查。

测试细节	协议
测试日期	2026-11-01，或结果日志显示的日期
环境	Node.js 22、TypeScript、Vitest 和干净的 Git 工作树
任务	五个带明确验收标准的软件工程任务
评估	构建成功、测试结果、正确性、延迟和代码质量
追问	单独记录；评分前不做隐藏的人工修复

五项编程任务

测试 1：构建小型 Web 应用

要求模型构建一个小型 TypeScript 应用，例如待办看板、Markdown 编辑器或 API 面板。应包含有限功能列表、键盘行为、空状态和测试命令，并根据能否启动、满足要求以及首轮实现后的可理解性评分。

测试 2：修复真实缺陷

提供失败测试和相关源文件，但不说明根因。记录模型能否定位正确故障、做出最小安全修改、避免回归，并添加或更新回归测试。

测试 3：实现 API 端点

实现带验证、超时、结构化错误和重试策略的端点。测试格式错误、认证失败、上游超时、限流和重复提交，不能只验证成功路径。

测试 4：重构现有代码

提供一个可运行但重复的模块，要求在不改变行为的情况下重构。比较前后测试套件，检查 diff 大小，并确认公共接口和错误语义保持不变。

测试 5：编写单元测试

要求模型覆盖边界条件，而非只测试成功路径。可包括空输入、错误 JSON、重试、取消、时区和上游响应不完整等情况。优秀结果应暴露假设，而不是只增加行覆盖率。

结果表

此表有意不填入猜测数字。模型可用后，应使用运行 ID、准确模型 ID、时间戳和测试产物替换待验证条目。

任务	结果	耗时	通过测试	备注
小型 Web 应用	待实际运行	未记录	未记录	评分启动和功能完整度
修复缺陷	待实际运行	未记录	未记录	检查根因和回归
API 端点	待实际运行	未记录	未记录	覆盖 401、429、超时和重试
重构	待实际运行	未记录	未记录	比较行为和公共接口
单元测试	待实际运行	未记录	未记录	检查边界覆盖和测试质量

提示词模板

任务提示词应说明成功标准，但不要规定实现方式。比较模型时保持措辞一致：

你正在一个现有的 TypeScript 仓库中工作。

目标：实现要求的变更，并让仓库保持可运行。
约束：
- 编辑前先检查现有代码。
- 除非任务要求，否则保留公共 API。
- 不要修改无关文件。
- 运行现有测试，并在适当时补充回归覆盖。
- 报告修改的文件、运行的命令和剩余不确定性。

任务：
[在此插入任务及验收标准]

最终报告也是评测的一部分。能写代码但无法说明测试内容的模型，在长期代理工作流中更难信任。

如何通过 API 核验 Gemini 4 Argon

先检查实时模型目录和文档。不要从展示名称推断 API 模型 ID。如果控制台确认提供 OpenAI 兼容路由，应使用其中显示的准确 ID：

curl https://api.sublyx.org/v1/chat/completions \
  -H "Authorization: Bearer $SUBLYX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "CONFIRMED_MODEL_ID",
    "messages": [{"role": "user", "content": "Reply with OK."}],
    "max_tokens": 16
  }'

只有从当前模型列表复制后，才能替换 CONFIRMED_MODEL_ID。成功请求应记录模型 ID、请求 ID、时间戳、状态码、延迟和 token 用量。不要把真实 API Key 放入浏览器 bundle、仓库、截图或公开 issue。

关于网关行为、请求路由和失败处理，参见 AI API 聚合网关指南；关于 Gemini CLI 配置注意事项，参见 Gemini CLI API 配置指南。

如何与其他模型比较

只有在准确版本和访问条件均有记录时，才运行 Claude Opus 5.5 或 GPT-6 Astra。保持仓库、提示词、上下文窗口、工具权限、温度或推理设置以及时间限制一致。比较应展示首次成功率和修复轮次，而不只是主观胜负。

生产使用还应比较：

• 构建和测试成功率
• 首 token 和完整响应延迟
• 输入和输出 token 用量
• 失败恢复和重试行为
• diff 大小和可维护性
• 重复运行的一致性

限制与更新规则

这是一个持续更新的评测协议。提供方目录可能因账户、地区或套餐而不同，未经验证的模型名称不能证明模型可用，也不能证明基准有效。

有经核验的运行记录后，应同时更新模型 ID、环境、原始结果、成本、延迟和失败记录。除非底层运行可以根据关联的提示词和仓库状态复现，否则不要把“待验证”替换成分数。

常见问题

Gemini 4 Argon 能通过 Sublyx 使用吗？

本文没有这样声称。这里没有验证它的身份、访问方式或实时结果。发起请求前，请查看当前 Sublyx 模型目录和获得授权的控制台。

“待实际运行”是否意味着模型很差？

不是。这只表示本文尚未记录已验证的运行。把未知结果和测量结果分开，是有用基准的必要条件。

这套测试能用于其他模型吗？

可以。保持仓库、提示词、权限、验收标准和评分规则不变，并在结果旁发布运行元数据。

应该在哪里检查 API 错误？

从准确模型 ID 和认证开始。关于 429 和重试设计，参见 AI API 429 指南；关于当前连接和模型配置，参见 Sublyx 文档。