📁 项目地址: https://github.com/YaBoom/ai-coding-benchmark-zyt

说实话，一开始我只是想看个热闹。

2026年2月5号，OpenAI和Anthropic同时发布新模型，像约好了一样。GPT-5.3 Codex 和 Claude Opus 4.6，两大巨头的最强编程模型正面刚。社区瞬间炸锅：“到底哪个更强？”

我看了几篇评测文章，但越看越觉得… 这些测试真的靠谱吗？

为什么是"不靠谱"

先说说我看到的问题。

大部分评测文章都在比什么？SWE-Bench分数、HumanEval通过率、Token生成速度。数据都很漂亮，但我总觉得少了点什么。

真实编程场景根本不是这样。

你写代码的时候，是像做算法题一样一次性写对吗？不是。你会：

• 先写个大概能跑的版本
• 发现边界情况没处理好，修一下
• 觉得命名不够清晰，重构一下
• 突然想起来还有异常没处理，再加个try-catch

这个过程，那些标准Benchmark测不出来。

那就自己动手

所以我决定做个小工具，用自己的方式测试一下。

项目很简单（代码在GitHub，有兴趣可以看看），核心逻辑就是：

1. 定义一系列编程任务（算法题、Bug修复、代码重构）
2. 把同样的任务丢给不同模型
3. 对比它们的输出

// 核心代码大概长这样
const gpt = new GPT53Codex(apiKey);
const claude = new ClaudeOpus46(apiKey);

for (const task of tasks) {
  const gptResult = await gpt.generateCode(task.prompt);
  const claudeResult = await claude.generateCode(task.prompt);
  // 对比分析...
}

说"简单"，其实中间也踩了不少坑。比如最开始我想自动执行生成的代码来验证正确性，但发现安全风险太大——谁知道AI会生成什么鬼东西。后来改成人工评估，虽然麻烦点，但至少保险。

我的测试任务设计

我没有用LeetCode那种标准题目，而是选了三种更贴近实际的场景：

1. 算法题（基础能力）

比如Two Sum、LRU Cache这些经典题。不是为了比谁能做出来（都能做出来），而是看代码风格和边界处理。

2. Bug修复（理解能力）

比如经典的JavaScript异步陷阱：

// 有问题的代码
async function fetchUserData(userIds) {
  const results = [];
  userIds.forEach(async (id) => {
    const user = await fetchUser(id);
    results.push(user);
  });
  return results; // 总是返回空数组
}

看模型能不能理解问题所在，并给出正确的修复方案。

3. 代码重构（组织能力）

比如把回调地狱改成async/await，或者把一团糟的工厂函数改成正经的Class。

这个很有意思，因为"好的重构"没有标准答案，能看出模型的代码品味。

初步观察（样本量小，仅供参考）

说实话，我只跑了一组测试，样本量太小了，不敢说哪个模型"更强"。但有几个有趣的观察：

1. 速度差异明显

GPT-5.3 Codex确实快。同样的任务，Codex的输出时间大概是Opus的60%-70%。但这个优势在复杂任务上会缩小。

2. 代码风格差异

• Codex: 更简洁，喜欢用现代语法，偶尔有点"炫技"
• Opus: 更稳健，注释更详细，考虑边界情况更多

举个例子，同样是实现LRU Cache，Codex直接用Map，代码很简洁；Opus会用Map+双向链表，虽然代码多了点，但解释了为什么这样实现。

3. 错误处理

Opus在这块更保守。比如重构任务，Opus会主动加try-catch，会检查参数合法性。Codex往往先给你一个能跑的版本，防御性代码少一些。

这俩风格像什么？Codex像那种"先做出来再说"的程序员，Opus像"先把边界想清楚"的程序员。没有绝对的好坏，看场景。

4. 解释能力

Opus的解释通常更详细。不只是说"改成这样"，会解释"为什么要这样改"。对于学习来说，这点挺重要的。

我的感受

跑完这组测试，我最大的感受是：这两个模型其实没有绝对的优劣，只有适合不适合。

如果你追求速度，想快速验证一个想法，Codex可能更合适。它的输出快，代码简洁，适合快速迭代。

如果你在做关键模块，需要代码长期维护，Opus的稳健风格可能更好。它的代码考虑得更全面，可读性也更强。

不过这些都是基于很小的样本量，可能有偏差。而且我用的是API调用，和官方宣传的那些"桌面应用"体验可能也不一样。

项目的局限

这个项目有很多问题，得承认：

1. 没有自动执行代码 - 安全考虑，没有真正运行生成的代码验证正确性
2. 评估主观 - 代码质量的判断主要靠我看，不够客观
3. 样本量小 - 就测了十几个任务，统计意义有限
4. Prompt可能有偏 - 我的Prompt设计可能对某个模型更友好

所以这个项目更像是一个"探索"，而不是严谨的Benchmark。

下一步

我打算继续完善这个工具，计划加几个功能：

• 支持批量测试，积累更多数据
• 尝试用LLM自动评估代码质量
• 增加更多类型的任务（比如架构设计、Code Review）
• 支持更多模型（Gemini、Llama这些）

如果你对这个项目感兴趣，欢迎来GitHub看看代码，提Issue或者PR都行。

🔗 GitHub: https://github.com/YaBoom/ai-coding-benchmark-zyt

最后

这次探索让我意识到，AI编程助手的对比远不是几个Benchmark分数能说清楚的。真实的开发场景太复杂了，涉及速度、质量、可维护性、团队协作很多维度。

也许最好的方式是：不要纠结哪个"更强"，而是学会在不同场景下用对的工具。

你最近在用哪个AI编程助手？体验怎么样？有没有遇到什么坑？欢迎分享。