我让 Opus 4.6 和 Codex 5.2 构建同样的东西，结果让我惊讶。
Source: Dev.to
大多数人现在都在使用 Opus 4.6 和 Codex 5.2
在它们发布后稍稍超过 24 小时，我终于能够亲自进行测试。难道我即将需要改变我的工作流程吗？
我之前为自己的 Discord 服务器构建了一个应用程序，用于为 RAG 系统摄取内容，同时通过自动分配角色来帮助进行 moderation。这是一个有趣的副项目。
在我重新投入使用这些新模型并开始玩耍之前，我想先测试一下，看看应该使用哪一个。我选择了一个 可视化我的数据 的测试，所以我们可以把它视为 前端为主、仅有少量逻辑实现的项目。我稍后会为 后端 类别的其他项目进行单独测试。
在本次测试中，我测量 两个主要指标：速度 和 准确性。让我们开始吧。
设置测试
-
连接 – 对于两个模型，我都确保它们能够连接到我的 Xano.com 工作区并读取数据。（还有关于 MCP 的其他讨论，但模型就是通过这种方式与平台通信的。）
-
环境 –
- 我使用 Cursor 来测试 Codex。
- 我使用 Claude (Claude 3 Opus 4.6) 来测试 Opus。
（关键是，这些是不同的环境，幕后处理方式也足够不同，可能会导致结果偏差，但我将在未来进行其他测试。）
-
提示 – 两个模型收到了相同的提示：
请从 Xano（MCP）中的工作区 11 获取数据；我希望你创建一个所有数据相互关联的可视化表示。为此，我想让你展示一个等距视图，显示表、数据和函数之间的所有关系；这包括中间件、认证系统、任务以及其他任何内容。请遍历整个应用程序，评估所有函数、表、端点、任务等，以创建一张地图。
- 扫描必要的 .XS 文件。使用 MCP 来协助应用流程和数据存储。
- 创建一个包含 CSS 和 JS 的 HTML 页面，以等距视图展示应用的全景，并提供一种可视化方式来显示所有内容是如何相互连接的。它应略带视频游戏风格，但强调可读性和可访问性。
- 为了提升可读性：查询所有数据，并将其持久化为本地文件。
你的提示可能会有所不同，这将 100 % 影响本实验的结果。不过，我想测试模型从我提供的信息中进行推断的能力。
我们冲向赛场！
在两者都按下 Enter 键后，我看到 Codex 迅速完成任务，而 Claude 则时不时卡住几分钟。决策过程的差异并不大，但它们执行的速度明显不同。
- Codex 用时 5 分钟 55 秒 完成。
- Claude (Opus 4.6) 在 8 分钟 左右时才结束。
开发速度冠军： Codex
期待的输出
Opus 4.6
我先查看了 Opus 4.6 的输出。虽然并不令人惊讶，但当我打开页面时它正常工作、可访问，并且与我脑中构想的视觉模型相匹配。
- 自动缩放、拖拽、点击节点、点击空白 → 侧边栏打开并显示连通性信息。
- 虽然没有被震撼到，但我完全预料到 Opus 4.6 能做到出色。标准得以保持。
Codex 5.2
空白构建
这不在预料之中。我只听说过 Codex 的好评，所以看到什么也没有加载感到失望。
我不一定要怪 Codex，但在给定任务的约束下，它的表现超出了预期，假设它应该从服务器端提供内容。因为我想保持本地运行，我把错误代码复制到 Cursor 中，像个合格的 vibe‑coder 那样处理，然后刷新页面。
修复后的构建
可视化效果笨拙，我几乎不明白自己在看什么。整个用户体验需要额外的提示才能让它变得可用。
开发准确性获胜者： Opus
摘要
最终，我对结果并不太失望：Claude 一直给人一种表现稍微……的感觉
原文在此截断；其余摘要可稍后补充。
更适合我在 前端 上
考虑到环境差异，Codex 仍然渴望在 CLI 中进行实地测试，以配合一些正式的后端开发。
但我惊讶吗？是的。 我真的期待两者之间会有相似的结果。
看起来在可预见的时间内，我不需要大幅更改我的工作流，因为 Claude 确实擅长读懂暗示、推断用户意图并交付成果。
但这也引发了关于模型人格以及哪种更适合你的构建风格的讨论：interpretive vs. executional（解释型 vs. 执行型）。
基于此以及我的构建风格，我在本次测试中将 Opus 4.6 as the winner 评为胜者。Codex 速度快，但准确性和结果仍是决定性因素。
如果你想让我特别测试什么，留下评论吧。更多测试即将推出！