热榜都在聊 Claude Code 写代码，我实测了 5 个模型的 Coding 能力，结果出乎意料

ofox
8 阅读5分钟

今天掘金热榜被 Claude Code 刷屏了，说 Anthropic 100% 用 AI 写代码，工程师要失业了。作为一个天天用 AI 辅助开发的独立开发者，我觉得事情没那么简单——你用的模型不同，写出来的代码质量天差地别。

起因：一个 Next.js 项目让我破防了

年前接了个私活，做一个数据看板。需求不复杂：接 API 拿数据，前端用图表展示，加个筛选功能。

我想着正好趁这个机会，用不同的 AI 模型来写，看看 2026 年了到底谁的 Coding 能力最强 🤔

测试方式很野蛮：同一个 prompt，丢给 5 个模型，看谁写出来的代码能直接跑，Bug 最少。

测试的 prompt

用 Next.js 14 App Router 写一个数据看板页面：
1. 从 /api/dashboard 获取数据（GET 请求）
2. 用 recharts 画一个折线图和一个饼图
3. 加一个日期范围筛选器
4. 要有 loading 状态和错误处理
5. 响应式布局，手机端折叠图表

看起来不难对吧？但细节很多：Server Component 还是 Client Component？数据获取用 fetch 还是 SWR？图表库怎么处理 SSR？每个选择都会影响最终代码能不能跑。

5 个模型的表现

Claude Opus 4.6

直接给了一个完整的方案：用 Client Component（因为有交互），SWR 做数据获取，recharts 用 dynamic import 绕过 SSR。

'use client';
import dynamic from 'next/dynamic';
import useSWR from 'swr';
import { useState } from 'react';
import { DateRangePicker } from '@/components/ui/date-range-picker';

const LineChart = dynamic(
  () => import('recharts').then(mod => mod.LineChart),
  { ssr: false }
);

export default function Dashboard() {
  const [dateRange, setDateRange] = useState({ from: null, to: null });
  const { data, error, isLoading } = useSWR(
    \`/api/dashboard?from=\${dateRange.from}&to=\${dateRange.to}\`,
    fetcher
  );
  // ...
}

评价： 架构决策很准，知道 recharts 不支持 SSR 要 dynamic import，这个坑很多人踩过。代码几乎可以直接跑，改改样式就行。9/10

GPT-4.5

写得很规范，但是……用了 Server Component 来 fetch 数据，然后又在里面用 useState。

// ❌ 这段代码跑不了
import { useState } from 'react';  // Server Component 不能用 hooks！

export default async function Dashboard() {
  const [dateRange, setDateRange] = useState({});
  const data = await fetch('/api/dashboard');
  // ...
}

第一轮就翻车了。 提醒它之后改成了正确的 Client Component 方案，但是丢了 loading 状态。来回改了 3 轮才勉强能跑。6/10

DeepSeek V4

给了个很有意思的方案：Server Component 做数据获取 + Client Component 做交互，通过 props 传递。架构上比 Claude 的还优雅：

// app/dashboard/page.tsx (Server Component)
import { DashboardClient } from './client';

export default async function DashboardPage() {
  const initialData = await fetch('http://localhost:3000/api/dashboard', {
    next: { revalidate: 60 }
  }).then(r => r.json());

  return <DashboardClient initialData={initialData} />;
}

但是——recharts 的 SSR 问题它没处理，而且 DateRangePicker 组件它自己造了一个，CSS 写了 200 多行，一半是错的 😂。7/10

GLM-5

智谱最近进步很大，GLM-5 写前端比之前强了不少。但这次测试暴露了一个问题：它对 Next.js 14 的 App Router 理解不够深，给的方案里混了 Pages Router 的写法（用了 getServerSideProps）。提醒后改正了，最终代码能跑但比较粗糙。5/10

豆包 Seed 2.0

字节刚发布的 Seed 2.0，我第一时间就试了。中文理解确实强，prompt 用中文描述需求的时候，它给的注释和变量命名比其他模型更"中国开发者友好"。但是写复杂组件的能力还有差距，recharts 的图表配置写错了好几个 prop 名。6/10

总结对比

模型架构设计代码可运行性Bug 数量综合评分
Claude Opus 4.6⭐⭐⭐⭐⭐直接能跑1个（样式）9/10
DeepSeek V4⭐⭐⭐⭐⭐需要改2处3个7/10
GPT-4.5⭐⭐⭐改3轮才行5个6/10
豆包 Seed 2.0⭐⭐⭐需要改3处4个6/10
GLM-5⭐⭐⭐改2轮才行6个5/10

一个实用建议：别绑死一个模型

测完这一轮，我最大的感受是：不同模型擅长的东西不一样。

Claude 写前端架构和 React 组件特别强，DeepSeek 对复杂逻辑推理更好，GPT 的知识面最广但容易犯低级错误，豆包在中文场景和代码注释上有优势。

我现在的工作流是这样的：

  1. 架构设计和复杂组件 → Claude Opus
  2. 算法和后端逻辑 → DeepSeek V4
  3. 写文档和解释代码 → GPT-4.5
  4. 中文项目的快速原型 → 豆包 Seed 2.0

问题来了——每个模型的 API 都要单独申请 key，管理起来很麻烦。而且如果你在国内，调 Claude 和 GPT 的 API 还有网络问题 😩

后来朋友推荐了个叫 ofox.ai 的聚合平台，一个 API key 就能调上面所有模型，国内直连不用折腾代理。我试了下确实方便，像这样就能切换模型：

from openai import OpenAI

# 同一个 client，换个 model 参数就行
client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="your-key")

# 用 Claude 写组件
resp = client.chat.completions.create(
    model="claude-opus-4-6",
    messages=[{"role": "user", "content": "写一个 React 数据看板组件"}]
)

# 切 DeepSeek 写算法
resp = client.chat.completions.create(
    model="deepseek-v4",
    messages=[{"role": "user", "content": "实现一个高效的时间序列聚合算法"}]
)

接口都是 OpenAI 格式兼容的，LangChain、Dify 啥的都能直接接，不用改代码。

写在最后

回到热榜那个话题——Claude Code 确实强，但说 AI 完全替代程序员还为时尚早。至少目前来看，你需要懂架构才能判断 AI 给的代码好不好，不然 GPT 那个 Server Component 里用 useState 的 bug 你都发现不了。

AI Coding 的正确姿势不是让某一个模型从头写到尾，而是根据任务选合适的模型。就像你不会只用一把螺丝刀修所有东西一样 🔧

如果你也在做类似的 AI 辅助开发，欢迎评论区聊聊你的模型使用心得，看看大家都是怎么搭配的。

以上测试基于 2026 年 2 月各模型最新版本，API 调用环境为 macOS + Python 3.12。不同 prompt 和场景下结果可能不同，仅供参考。

avatar
文章
阅读
粉丝