Gemini 4 Argon 编程测试：3 道题与 18 项检查

做 Gemini 4 Argon 编程测试，先把需求写清楚，再运行它返回的代码。本页准备了三道 JavaScript 题：合并区间、保留最新记录、修复时长解析器。每题配有六项自动测试，检查示例答案之外的边界情况。

这是可自行运行的测试包，不是 Argon 的实测成绩报告。 提示词和检查由 TryCarbon AI 编写。我们用参考实现和故意写错的代码验证过测试脚本，但这不等于测量了 Argon 的表现。你可以用同一套题，分别记录模型首次回答和修改后的结果。

下载编程测试包，然后打开 Argon 聊天。下载免费；发送聊天请求需要登录并购买积分。套餐见定价页。

这套题能测什么

Google 在 Argon 官方模型文档中介绍了它面向复杂软件工程的用途。具体代码能否满足你的要求，仍要逐项检查。

这三道小题检查需求遵守、边界处理和原始数据保护，不测试整个代码仓库的理解能力、前端设计、大规模迁移或自动操作终端。即使通过全部 18 项，也只能说明代码通过了这些检查，不能据此认定它可以安全维护生产项目。

本站聊天以文本形式返回代码，不执行代码，也不接受仓库上传。你需要在自己的开发环境中运行测试。模型开放情况可读 Argon 与 Carbon 对比；本文不声称完成了 Carbon 编程实测。

开始前的准备

解压下载文件，可以看到 prompts.txt、待填写的 solution.mjs、coding.test.mjs、空白 scorecard.csv、说明和 MIT 许可证。使用 Node.js 22 或更新版本，不需要安装 npm 依赖。

每道题新开一段对话，选择 Argon，并关闭联网搜索。这些题不依赖实时信息。记录日期、界面显示的模型和你调整过的设置；请求修复前，先保留完整的第一次回答。若要与其他模型比较，使用相同提示词、测试文件和尝试次数。

运行前先阅读生成的代码。不熟悉的代码应放在没有凭证、私人文件和网络访问权限的临时隔离环境中检查。Node 测试运行器会执行 JavaScript，本身不是安全沙箱。下面的题目只需要纯函数，不需要访问文件或网络。

下载包中的提示词为英文。下面给出等义中文版本；比较不同模型时，应固定使用同一种语言和同一份文字。

第一题：合并区间，不能改动输入

日程时间段、数值区间都可能需要合并。这里容易漏掉的要求是：返回值正确还不够，调用方传入的数组也不能被悄悄排序或修改。

编写 ES 模块，导出 mergeRanges(ranges)。
输入为 [start, end] 数对组成的数组，数值必须有限且 start <= end。
返回按起点排序的新数对，合并重叠或首尾接触的区间。
空数组返回 []。不能修改输入数组或其中的数对。
输入不是数组、数对格式错误、数值不是有限数字，或 start > end 时，
抛出 TypeError。不能使用第三方包、文件系统、网络或顶层副作用。
用一个 JavaScript 代码块返回完整函数，随后简述复杂度。

输入 [[5, 8], [1, 3], [3, 5]]，预期输出为 [[1, 8]]。端点接触也要合并，这是题目明确规定的行为。测试还覆盖嵌套区间、重复区间、负数、小数和长度为零的区间。

检查脚本会传入冻结的数组和数对，并确认返回的是新的数对。如果代码直接对输入调用 sort()，普通示例可能通过，冻结输入时就会出问题。复杂度解释也要与代码对上：如果先对任意输入排序，就不能忽略排序这一步的开销。

第二题：每个 ID 只保留最新记录

这道题接近日常处理事件快照的场景。只说“去重”会留下不少歧义：哪个版本应该保留？结果顺序由什么决定？

编写 ES 模块，导出 latestById(records)。
每条记录都有字符串 id、非负安全整数 timestamp，以及任意其他字段。
每个 id 只保留 timestamp 最大的记录；时间相同时，保留最后出现的记录。
结果中各 id 的顺序，按它们在输入中首次出现的顺序排列。
空输入返回 []。不能修改输入数组和记录，允许返回原记录的引用。
输入保证符合上述格式，无需额外校验。把 "__proto__" 和 "constructor"
视为普通 id。不能使用第三方包、文件系统、网络或顶层副作用。
返回完整函数，并解释时间相同的处理方式。

如果 b 比 a 先出现，结果里的 ID 顺序仍应是 b、a，即使后面又来了一条更新的 b。时间戳优先于出现位置；只有时间戳相同，才由最后出现者胜出。

检查包含空字符串、看起来像数字的 ID，以及特殊对象属性名，避免实现意外依赖普通对象的属性行为。不要只检查 ID：胜出记录的其他字段也应该完整保留。

手动核对一次时间戳相同的记录

下面是本站编写的输入案例，不是 Argon 的回答，也不改变原来的 18 项测试数量。

const records = [
  { id: 'b', timestamp: 8, label: 'first b' },
  { id: 'a', timestamp: 10, label: 'new a' },
  { id: 'b', timestamp: 8, label: 'tie wins' },
  { id: 'a', timestamp: 7, label: 'later but older' },
];
// Expected:
// [
//   { id: 'b', timestamp: 8, label: 'tie wins' },
//   { id: 'a', timestamp: 10, label: 'new a' },
// ]

这里有三个独立条件。ID 首次出现的顺序是 b、a，因此输出仍按这个顺序。两条 b 的时间戳都是 8，同时间戳取最后出现的记录，所以保留 tie wins。最后一条 a 虽然位置更靠后，但时间戳 7 小于 10，因此保留 new a。

只保留最后一条记录的写法会选错 a；只在时间戳严格增大时替换的写法会选错 b；按时间戳给最终结果重新排序，又会破坏首次出现顺序。核对时也要看 label，不能只断言输出的 ID 正确。

可以把这个数组和对 latestById 的调用放在单独的 .mjs 文件里，与 solution.mjs 放在同一目录，然后用 Node 运行。预期的 ID 与 label 对应为 [['b', 'tie wins'], ['a', 'new a']]。将这项额外检查单独记录，不要混进原来每题六项的分数。示例只帮助理解要求，不代表模型通过了测试，也不要求再次付费提问。

第三题：修复时长解析器

这题直接提供有缺陷的代码，要求修复，而不是只解释哪里可能有问题。

修复以下函数，并从 ES 模块导出 parseDuration(text)。
只接受恰好五个 ASCII 字符的 HH:MM：小时 00 至 23，分钟 00 至 59。
返回总分钟数。其他所有输入返回 null，包括非字符串、空白、单字符小时、
尾部多余字符，以及末尾换行。不能使用第三方包、文件系统、网络或顶层副作用。
返回完整替换函数，并解释原实现的问题。

function parseDuration(text) {
  const [hours, minutes] = text.split(":").map(Number);
  return hours * 60 + minutes;
}

09:05 应返回 545；9:05、24:00 和末尾带换行的 09:05 都应返回 null。传入 null 也不能让函数崩溃。这是一道约定小时上限为 23 的格式解析题，不处理时区或日历。

原函数会接受超出约定的输入，也会在某些非字符串输入上抛异常。这些是我们故意放入题目的缺陷，不是已经观察到的 Argon 错误。修复应保留正确输入的行为，同时拒绝所有不符合格式的输入。

为什么要单独测末尾换行

这个任务要求原始输入恰好有五个字符。先调用 trim() 会改变验收条件：本应无效的 "09:05\n" 被改成了 "09:05"。检查类型和长度前，先保留原输入。

JavaScript 的多行标志也值得单独核对。在 Node.js 里运行：

const withNewline = '09:05\n';
console.log(/^\d{2}:\d{2}$/.test(withNewline)); // false
console.log(/^\d{2}:\d{2}$/m.test(withNewline)); // true

m 标志让边界断言也匹配行边界，MDN 的边界断言说明解释了这一区别。完整字符串的格式校验不应悄悄变成逐行搜索。格式正确也不代表小时和分钟范围正确，24:00 仍应失败。

一起核对 09:05、末尾带换行的版本、24:00 和非字符串。把所有输入都拒绝不能算修好；先去掉换行再解析则会藏起这个错误。这些是已独立执行的 JavaScript 示例，不是 Argon 的生成结果或成绩。对比首次回答与修复时，保留测试包的原断言。

怎样运行并记录第一次结果

把模型返回的对应函数放进 solution.mjs，保留三个具名导出。文件内只保存 JavaScript，不要把 Markdown 代码围栏或解释文字一起粘进去。还没填完所有函数时，可以先单独运行一题：

node --test --test-name-pattern="ranges:" coding.test.mjs

另外两题的筛选词分别是 records: 和 duration:。三个函数全部填好后，运行：

node --test coding.test.mjs

输出和名称筛选用法可查 Node 官方测试文档。全部成功时应有 18 项通过、没有失败。下载包里的初始函数是占位符，未经替换时会故意让全部测试失败，它们不是模型答案。

在记录表里填入每题首次通过的数量，满分为六项。某一项可能检查多个无效输入，因此不能把“18 项测试”说成完整覆盖所有输入。保留终端输出和原始回答，区分语法错误与结果不符。如果代码一直不结束，停止进程并记录，不要把这次尝试从结果里删掉。

测试失败后，怎样追问才有用

在原对话中提供失败项名称、输入、预期值和实际结果：

第一版在这个用例失败：
输入：[粘贴输入]
预期：[粘贴预期结果]
实际：[粘贴实际结果或错误]
请解释原因，并返回最小且完整的修正。
保持原需求，不要修改测试。

修好后重新跑该题全部六项，防止修复一个边界又破坏另一个。把修改次数另记一栏，不要用修复后的通过结果覆盖首次失败。每次追问都是新的聊天请求，可能消耗积分。

比较模型时，报告相同题目下的结果、设置和修复次数即可。三道短函数不足以选出通用的“最强编程模型”。用于真实项目时，还要补充业务用例、检查依赖，并在目标环境验证。

可以先把第一题粘贴到 Argon 聊天。账户准备见首次使用指南；需要保存原代码和修复过程时，按历史记录与导出指南保留对话，之后才能准确比较。