测试Gemini 3 Pro、Claude Sonnet 4.5与GPT 5.1 Codex完成代码修复任务的结果对比。

嗯，这是个有趣的实验。我用我的测试框架对 Gemini 3 Pro、Claude Sonnet 4.5 和 GPT 5.1 Codex 进行了一项真实世界任务的测试。完全相同的输入（系统提示、工具、已有的会话状态）。相同的思考设置。以下是发现。

问题：我的编码 Agent 框架的 TUI 渲染器会输出模型产生的思考轨迹。它能将 Markdown 渲染到终端。思考轨迹以斜体显示，颜色为暗灰色。如果模型的思考轨迹中包含内联代码块（如下截图所示），那么代码块后面文本的颜色不会重置为暗灰色。

问题位于两个文件中，合计约 700 行代码。解决方案是在 Markdown 渲染器中重置内联代码块后的颜色 ANSI 码为默认颜色。一个能工作的修复方案完整变更集约 50-70 行代码。所以这并不是一个需要大量代码库搜索的复杂任务。

Sonnet 和 GPT 5.1 Codex 都能找到合理的解决方案。它们都迅速定位到了相关文件。它们在 API 选择上有所不同，但差异不大。我更喜欢 Codex 的方法。

Gemini 3 Pro 则表现挣扎。它充分利用了思考 token 预算，但原地打转。它会重新读取已经在上下文中的源文件，而没有做任何修改。而且显然它不如 Sonnet 和 Codex 熟悉 TUI Markdown 渲染器中使用的 chalk 和 marked 的 API。

所有这些因素导致了一个无法工作的解决方案。我实际让 Gemini 尝试了两次，从会话的同一位置开始。结果相同。

然后我给了它提示并试图引导它，但它再次跑偏。

因此，对于我的特定用例，在我的特定编码 Agent 框架中，Gemini 3 Pro 的表现并不比 Sonnet 或 GPT 5.1 Codex 好，这与 Gemini 今天在其模型卡中的基准测试结果相反。

这并不意味着它对你不适用。但对我来说，如果它连 Sonnet 和 GPT 5.1 Codex 都能轻松完成的任务都失败，那我觉得没必要再花时间了。成本方面也不是优势，因为我没有看到 Google 提供任何类似 Claude Max 或 GPT Pro 的产品。所以更没动力在 Gemini 上花时间让它工作了。

你的情况可能不同，这只是单个样本。自己去试试吧。如果你不信任我的描述，以上所有内容都在下面的直播视频中有完整记录。代码全部在 GitHub 上：
https://github.com/badlogic/pi-mo
no/tree/main/packages/coding-agent