评测人工智能代码生成器

来源：InfoWorld 作者：Andrew C. Oliver

最新的 ChatGPT、Claude、Gemini 以及 o 系列模型各有优缺点，因此混合使用这些模型是很有必要的。以下是一份测试报告。
如今，每位开发者都曾将代码粘贴到 ChatGPT 中，或者使用过 GitHub Copilot 来自动补全函数。如果这就是你对人工智能的全部了解，那么你很容易得出这样的结论：使用大语言模型（LLMs）进行编码还未达到理想状态。但在实际应用中，模型的质量和专业性发展迅速，就连你八周前的使用体验也已经过时了。OpenAI、Anthropic 和谷歌今年春天都推出了重大升级，OpenAI 还悄然推出了旨在推理的 “o 系列” 模型。
以下是对五款主流模型在日常生产使用中的实地报告。把它当作一个快照，而不是绝对正确的结论 —— 当你读到这份报告时，可能一次版本发布就又会改变这些模型的排名。

OpenAI GPT-4.1：用户界面方面的助手，但不是我的主要编码工具

OpenAI 的 GPT-4.1 取代了现已停用的 GPT-4.5 预览版，提供了更便宜、延迟更低的 128k 标记上下文，并且在根据图像生成规格代码方面表现更佳。在搭建新代码框架以及将截图转换为代码方面，它依然可靠。但当任务是在成熟的代码库中进行修复时，它就难以跟踪长依赖链和单元测试中的边缘情况。
适用场景：设计系统模型、API 文档草稿、将用户界面设计转换为组件框架。
不适用场景：在完成初始代码框架搭建之后。

Anthropic Claude 3.7 Sonnet：可靠的主力模型

Anthropic 最新的 Sonnet 模型仍然是我首选的模型。它在成本和延迟之间达到了最佳平衡，能在 128k 的窗口中保留全局项目上下文，并且很少出现虚构库名的情况。在处理棘手的错误时，它有时会通过在测试代码中添加它所谓的 “特殊情况处理” 来 “取巧”（注意类似 if (id===’TEST_CASE_1 data’) 风格的补丁）。Sonnet 还有为了 “提高速度” 而禁用 ESLint 或 TypeScript 检查的习惯，所以要保持代码检查器处于开启状态。
优势领域：迭代式的功能开发、涉及 5 到 50 个文件的重构、对构建管道进行推理。
劣势领域：与视觉相关的任何内容、CSS 微调、单元测试模拟。
小贴士：在你的代码中搜索 “特殊情况处理” 字符串。

Google Gemini 2.5 Pro-Exp：存在身份问题的用户界面专家

谷歌的 Gemini 2.5 版本提供了 100 万标记的上下文（承诺将达到 200 万），并且目前在许多地方可以免费使用（我调用 API 时还未被收费）。它在用户界面相关的工作中表现出色，是我使用过的代码生成速度最快的模型。问题在于：如果你的代码库使用的 API 在模型训练后发生了变化，Gemini 可能会质疑你所面对的 “过时” 现实 —— 有时甚至会给你的现实加上引号。它还曾声称日志中的某些内容是不可能出现的，因为这些内容发生在 “未来”。
适用场景：仪表盘、设计系统优化、可访问性改进、快速生成概念验证用户界面。
注意事项：自信但错误的 API 调用以及虚构的库。仔细检查它引用的所有库版本。

OpenAI o3：高端问题解决者，相应地价格也高

OpenAI 的 o3（这个命名仍然让那些期望是 “GPT” 的人感到困惑）是一个研究级别的推理引擎。它可以链式调用工具并撰写分析报告，并且能够仔细检查包含 300 个测试的 Jest 套件。它还设置了访问限制（我必须出示护照才能获得使用权限），运行速度慢，而且成本高昂。除非你有像 FAANG（即脸书、亚马逊、苹果、奈飞和谷歌）规模的预算，或者自己无法解决某个错误，否则 o3 是一种奢侈品，而不是日常使用的工具。

OpenAI o4-mini：调试器的手术刀

4 月的惊喜之作是 o4-mini：一个经过压缩的 o 系列变体，针对紧密的推理循环进行了优化。在实际应用中，它的速度比 o3 快 3 到 4 倍，通过 OpenAI API 使用时仍然很昂贵，但在几个集成开发环境（IDE）中可以 “免费” 进行节流使用。当 Claude 在模拟依赖方面停滞不前时，o4-mini 会重新组织测试框架并解决错误。它的输出简洁明了，这对于 OpenAI 的模型来说有点意外。
适用场景：复杂的泛型、依赖注入的边缘情况、让其他模型束手无策的模拟策略。
不太适合的场景：批量代码生成或长篇解释。你得到的将是简洁的补丁，而不是长篇大论。

多模型工作流程：实用的操作指南

使用 GPT-4.1 在 ChatGPT 中探索用户界面的创意。上传你的幻灯片，并要求它生成模型。提醒你的代码生成器，DALL-E 在处理文字时会有一些奇怪的表现。
在思考模式下使用 Claude 创建你的初始规格。让另一个大语言模型对其进行评估。要求它给出一个分步的实施计划。有时我会问 o4-mini，在一个干净的上下文中，这个规格是否足以让一个大语言模型遵循。
使用 Gemini 2.5 搭建代码框架。上传草图，生成 React 或 Flutter 的框架以及整体结构。
使用 Claude 3.7 充实逻辑内容。导入框架，让 Sonnet 填充控制器逻辑并进行测试。
使用 o4-mini 调试或完成 Claude 遗漏的部分。让它重新设计模拟或类型框架，直到测试通过。
这种 “接力赛” 能让每个模型都发挥其专长，最大限度地减少标记消耗，并且让你在不超出免费使用限制的情况下利用免费层级的功能。

最终的疑虑

使用大语言模型进行编码仍然需要人工审查。这四个模型偶尔会出现以下情况：

1. 只是绕过失败路径，而不是解决根本原因。
2. 过于积极地安装传递依赖项（检查你的 package.json）。
3. “暂时” 禁用类型检查或 ESLint 防护。
   自动化合约测试、增量式代码检查以及提交代码时的差异审查仍然是必不可少的。把这些模型当作记忆力超强的实习生。它们是出色的模式匹配者，但在责任担当方面表现糟糕。（作者注：具有讽刺意味的是，当我让 o3 校对时，它添加了这部分内容，但我非常喜欢，所以保留了下来。）

总结

如果你在 2024 年试用了 GitHub Copilot 并放弃了人工智能编码，那就更新你的工具库吧。Anthropic 的 Claude 3.7 Sonnet 在日常使用中可靠性高，谷歌的 Gemini 2.5 在前端人机工程学方面表现出色，而 OpenAI 的 o4-mini 是目前最好的纯调试工具 —— 前提是你能负担得起标记费用，或者你有足够的耐心。混合搭配使用这些模型。当需要真正的 “大脑” 时，你随时可以介入。