热榜都在说 AI 写代码要取代程序员，我拿 5 个模型实测同一个项目，结果出乎意料

ofox
3 阅读6分钟

今天刷掘金热榜，前几名全在讨论 AI 写代码，有说"三家巨头宣布不写代码了"的，有说"Claude Code 100% 自己写代码"的，还有直接喊"前端将死 Agent 永生"的。

说实话看完挺焦虑的 😅

但焦虑归焦虑，我寻思光看别人吹不如自己动手测。于是花了一下午，拿 5 个主流大模型 写同一个项目——一个带 WebSocket 实时通信的 Todo 应用（前后端都有），看看 2026 年了，AI 写代码到底卷到什么程度。

测试设定

为了公平起见，我给每个模型 完全相同的 prompt：

用 Node.js + Express 写一个 Todo 应用后端，要求：

  1. RESTful API（CRUD）
  2. WebSocket 实现实时同步（多端同时编辑能看到变化）
  3. SQLite 持久化
  4. 前端用原生 HTML/CSS/JS，不用框架
  5. 支持拖拽排序

这个需求不算简单也不算复杂，刚好能测出模型的综合能力：架构理解、代码生成、前后端联调、边界处理。

测试模型：Claude Opus 4.6、GPT-4.5、Gemini 2.5 Pro、GLM-5、DeepSeek V4

先说结论

模型一次跑通代码质量WebSocket拖拽排序总评
Claude Opus 4.6✅⭐⭐⭐⭐⭐完美完美🥇
GPT-4.5✅⭐⭐⭐⭐完美小 bug🥈
Gemini 2.5 Pro❌→✅⭐⭐⭐⭐完美完美🥉
DeepSeek V4❌→✅⭐⭐⭐⭐有坑能用第4
GLM-5❌→✅⭐⭐⭐半残有 bug第5

剧透：没有任何一个模型能完全取代程序员（至少目前），但差距确实在缩小。

详细踩坑记录

Claude Opus 4.6：王者依然是王者

这货就离谱。prompt 丢进去，一次性给我吐出了完整的项目结构：

todo-app/
├── server.js          # Express + WebSocket
├── db.js              # SQLite 封装
├── public/
│   ├── index.html
│   ├── style.css
│   └── app.js         # 前端 + WS 客户端 + 拖拽
└── package.json

直接 npm install && node server.js，一次跑通。WebSocket 多开两个标签页，一边添加 todo 另一边实时出现，丝滑。拖拽排序也没问题，而且它还自动加了乐观更新（先本地更新 UI，再同步到服务端），这个我 prompt 里没提。

说实话有点被惊到。

GPT-4.5：稳但有点粗心

也是一次跑通，代码结构清晰。但拖拽排序有个小问题：拖完之后 order 字段的更新 SQL 写反了，导致拖到第一位的 todo 实际排到了最后。

改了一行代码就好了：

// 原来的（有bug）
await db.run('UPDATE todos SET sort_order = ? WHERE id = ?', [todos.length - index, todo.id]);
// 改成
await db.run('UPDATE todos SET sort_order = ? WHERE id = ?', [index, todo.id]);

其他都没问题。GPT-4.5 的代码风格偏"教科书"，注释详细到有点啰嗦。

Gemini 2.5 Pro：第一次没跑起来，但改了一轮就好了

第一次跑的时候报错，因为它 import 了 better-sqlite3 但 package.json 里写的是 sqlite3。经典"自己跟自己打架"。

改完依赖之后一切正常。WebSocket 部分写得很漂亮，甚至做了断线重连。拖拽排序也 OK。

DeepSeek V4：能用，但 WebSocket 有坑

首先，它把 WebSocket 服务和 HTTP 服务开在了不同端口（一个 3000 一个 8080），前端连接写死了 ws://localhost:8080。这在开发环境能用，部署就炸。

改成同端口后基本能跑。但 WebSocket 的广播逻辑有问题——发消息的那个客户端也收到了自己的广播，导致 UI 闪烁。加个 if (client !== ws) 判断就好了。

拖拽排序"能用"但不丝滑，没做乐观更新，每次拖完要等服务端返回才刷新。

GLM-5：路还很长

说实话 GLM-5 让我有点失望。之前看热榜有人说"国产模型什么时候这么能打了"，但在这个测试里...

第一次生成的代码有 3 个语法错误（少了括号和分号），改完之后 WebSocket 只能单向通信（服务端能推，客户端发不过去）。排查了半天发现它 ws.on('message') 的回调参数写错了。

拖拽排序用了一个很奇怪的实现方式，直接操作 DOM 而不是更新数据再渲染，导致刷新页面后顺序丢失。

真正值得聊的：模型切换成本太高了

测试过程中最让我头疼的不是 debug，而是 在不同模型之间切换。

每个平台的 API 格式、认证方式、速率限制都不一样。Claude 用 x-api-key，GPT 用 Bearer，Gemini 要走 Google Cloud 认证... DeepSeek 和 GLM 虽然都兼容 OpenAI 格式，但各有各的小区别。

我一开始是每个模型单独写 API 调用代码，写到第三个的时候已经疯了。

后来发现有个叫 ofox.ai 的聚合平台，所有模型统一用 OpenAI 格式调用，一个 API key 搞定。我把测试代码改成：

import openai

client = openai.OpenAI(
    base_url="https://api.ofox.ai/v1",
    api_key="your-key"
)

# 切换模型只需要改 model 参数
models = [
    "claude-opus-4-6",
    "gpt-4.5-preview",
    "gemini-2.5-pro",
    "deepseek-v4",
    "glm-5"
]

for model in models:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        max_tokens=8000
    )
    save_result(model, response.choices[0].message.content)

这比之前每个 SDK 单独调爽多了。而且国内直连速度还行（据说走的阿里云/火山云节点），Claude 和 Gemini 不用折腾网络问题。

我的真实感受

测完之后我的焦虑反而减少了一些：

1. AI 写代码确实强，但"一次跑通"的概率远没有热榜说的那么高。 5 个模型只有 2 个一次跑通，而且测试需求并不算特别复杂。

2. AI 生成的代码需要程序员 review。 GPT-4.5 的排序 bug、DeepSeek 的端口问题，都是那种"看起来对但实际有坑"的问题。如果不懂代码，根本发现不了。

3. 模型之间差距确实大。 Claude 和 GPT 是一个梯队，Gemini 紧跟，DeepSeek 和 GLM 还需要追赶（尤其是复杂场景）。但半年前 GLM-4 还不能写完整项目，现在至少能跑了，进步是实实在在的。

4. 对于个人开发者来说，最好的策略是多模型混用。 简单逻辑用便宜的模型（DeepSeek、GLM），复杂架构用 Claude/GPT。一个统一的 API 入口比单独对接每个平台效率高太多了。

写在最后

热榜的标题确实吓人，"巨头宣布不写代码了"、"前端将死"... 但实际测下来，AI 是在变强，但程序员不是要被取代，而是要学会用 AI 让自己变强。

说白了，AI 写代码就像自动挡汽车——降低了驾驶门槛，但你还是得知道该往哪开。

如果你也想自己测测不同模型的代码能力，建议别只看跑分和排行榜，自己动手跑一个完整项目比什么都直观 💪

以上测试基于 2026 年 2 月各模型最新版本，结果仅代表特定场景，不同任务可能有不同表现。

avatar
文章
阅读
粉丝