Theo 在 Gemini 4 Carbon 中找到安全用途，日常编码仍有困扰

Theo 提前获得 Google Gemini 4 Carbon 的访问权限。最初，他认为它相对于 Gemini 4 Argon 的改进没有达到自己的期待，因而感到失望。但进一步测试后，一项安全相关的编码任务给了他意想不到的结果。

他指出，Carbon 发布时曾出现在某个公开模型排名的前列，之后才有更新的竞争模型出现。在他看来，基准分数和图表中选入哪些模型，本身并不能决定某个模型是否适合特定工作。

Google 将 Carbon 描述为适合软件工程、长时间智能体工作、科学推理和网络安全的模型。Theo 说，他最初对安全能力的声明关注不足，尽管模型在某项编码基准上的分数似乎远好于他的实际体验。

他的测试重点是分析现有代码库和审查拟议修改。在一次 Rust 架构审查中，他数出 Carbon 的 79 条说法中有 23 条错误，而 Argon 的 36 条中有 24 条错误。他说，几个竞争模型在同一任务中的错误说法少得多。

在另一项 T3 Code 分析中，他数出 Carbon 的 86 条说法中有 23 条错误，而 Argon 的 92 条中有 47 条。他说，在自己的全部评测中，错误说法占比从 Argon 的 36% 降到 Carbon 的 18%；这在他的测试中是明显进步，但比例仍高到让他不敢不经核对就相信结果。

他还抱怨任务耗时。引用一项第三方测试时，他说 Carbon 在低努力程度下平均约需 22 分钟，在高努力程度下约需 27 分钟；作为比较，Opus 的范围约为 3 至 25 分钟。在他看来，每秒输出多少 token 不能充分反映用户的等待时间。

Theo 读出 API 试用价格：每百万输入 token 2 美元、每百万输出 token 10 美元，缓存读取每百万 token 0.10 美元。他说，列出的价格将在 12 月 1 日翻倍。他质疑两个价位下的性价比，并提醒观众考虑这项计划中的调整。

他说，自己的 API 测试还发现缓存命中不稳定，在 5 秒和 30 秒间隔后都出现过未命中。由于未命中可能增加重复处理上下文的成本，他主张比较完成整个任务的成本，而不是只看公布的 token 价格。

Google 强调知识工作和数据分析能力，也提到与 Artificial Analysis 合作开发的多模态基准。Theo 随后转向界面和编码；他的评价基于自己查看过的例子，而非所有可能的任务。

查看生成的网站设计时，他发现许多页面使用类似布局：居中的两行文字、药丸形元素，以及被截断的产品截图。他看到了部分差异，但认为无论是否使用设计技能，结果都会变得重复。

他把 Google 关于复杂编码工作的声明，与自己难以信任长篇代码分析的体验作比较。他说，自己曾撤回前代 Argon 模型所做的修改，也想知道其他团队如何取得更好的结果。Google 展示的例子还包括 3D 场景。

在一项包含鱼和水的 3D 测试中，第一个结果没有给他留下深刻印象。让模型把画面做得更美观后，水的效果改善了，其他元素却出了问题，因此他让 Carbon 自己修复场景，而不是交给另一个模型纠错。

Theo 说，由于自己拥有提前访问权限，无法可靠测量付费 Gemini 订阅能使用多少 Carbon。他计划在能取得普通用户的用量数据时再比较，同时提到了自己过去对订阅限额的体验。

他概述了 Google 关于网络安全基准、所报告的开源项目发现，以及部分安全评估结果改善的说法。这些内容来自发布说明，与他后来亲自尝试的安全工作不同。

他说，在代码库分析和审查中，Carbon 在某些会话里仍会编造数据库列名、行号和架构细节。即使模型在其他方面表现出优势，这些错误也让他难以信任结果。

Theo 主要通过 T3 Code 使用 Gemini。他说，只有在 Google 允许的情况下，才应通过其他工具使用订阅访问；他还介绍了自己与 DeepMind 团队合作开发连接组件，让工具能够控制获授权的界面。

他遇到的部分幻觉来自旧版集成：它没有向模型发送所需的全部信息，包括行号。他感谢 DeepMind 工程师根据反馈调查并改进连接，同时表示端到端体验对他而言仍然缓慢。

一位独立开发者提交的安全报告改变了他的评估。这名报告者通过 Anthropic 的安全计划审查 T3 Code，发现了两个问题。Theo 说，视频上线时修复已经发布，并请用户更新。

他首先用 Anthropic 的 Mythos 处理报告。其中一个建议要求用户在批准连接前，从另一台机器取得一个代码。Theo 认为这对自己的远程机器工作流程过于繁琐，于是继续与模型讨论替代方案。

他说，经过多轮交流，他们找到一种方案，对通过 T3 Code 可信服务建立的连接和原始链接作不同处理。工作尚未完成时，他又把同一份报告交给 Carbon，比较其回答。

Carbon 对问题的描述让他能够理解，并建议将已知机器的流程与原始 URL 的流程分开。Theo 说，这符合他想要的处理方式，还发现了其他需要注意的问题。他感到意外，因为其他模型要么拒绝处理，要么最初建议了不太方便的设计。

他仍然批评使用 Carbon 所需的时间和多轮往返。他请其他模型审查 Carbon 的工作，提供反馈，并在任务完全结束前停下来录制视频。他认为安全事件响应可能是一种有用的应用，同时指出自己的提前访问状态可能影响体验。

Theo 感谢独立报告者 Brandon 提交了一份清晰、可执行的报告。他说，这名研究人员几乎没有要求回报，并借此强调外部贡献对开源项目安全的价值。

在另一项测试中，他让 Carbon 实现一项有关 Windows 远程更新问题的调查结果。他说，工作进展顺利，也获得其他模型较好的评价，不过这些分数反映的是特定审查，而不是完整评估。

尽管有这些安全工作实例，Theo 仍不会把 Carbon 设为默认编码模型。根据他的体验，Opus 在日常工作中更好用，而 Carbon 可能速度慢、成本高，并容易在较大代码库中出错或编造细节。

不过，他认为 Carbon 在保持任务方向和跟进对话方面比 Argon 有明显进步。他计划继续观察它的反馈长期是否有用，而不是把一次结果当成完整结论。

3D 修复任务大约 25 分钟后终于完成。Theo 发现画面有所变化但仍有缺陷：鱼周围的元素没有出现在他预期的位置。根据这个例子，他会选择其他工具处理类似的 3D 工作。

他的结论是，Carbon 可能适合安全开发，对于已经使用 Gemini 的人而言也是一次改进，但他在大部分编码工作中仍更喜欢其他选择。他希望后续版本能解决自己遇到的问题。