🦞 一只用 AI Agent 搭副业产线的程序员

---

有人说「DeepSeek 写代码最强」，有人说「Claude 才是程序员的真爱」，还有人说「GPT-4o 最均衡」。

别争了。我直接测。

同一个需求，同一个 Prompt，扔给 DeepSeek、通义千问、GPT-4o、Claude。全用默认温度，全用非思考模式。看谁写得对、谁写得便宜、谁最会编。

不卖关子，先看结论：

维度	冠军	一句话
代码正确性	Claude	4 个任务全对，0 编造
性价比	DeepSeek V4 Flash	便宜到可以当水用
中文理解	通义千问	中文文档和注释最自然
综合平衡	DeepSeek V4 Pro	正确率接近 Claude，价格只有 1/100

---

测试设计：4 个任务，覆盖真实工作流

不测「写一首诗」这种花活。测的是你日常真的会用的：

任务	难度	考察点
任务 A：写一个 Go 的 LRU 缓存	简单	基础代码生成
任务 B：把一段 Python 脚本翻成 Go	中等	跨语言理解
任务 C：给一段无注释的代码写 godoc	中等	代码理解+表达能力
任务 D：找出一段代码里的并发 Bug	困难	逻辑推理+安全意识

---

统一测试基础设施

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
    "os"
    "time"
)

type TestResult struct {
    Model    string
    Task     string
    Output   string
    Duration time.Duration
    Cost     float64 // 元
    Correct  bool
}

type Endpoint struct {
    Name    string
    URL     string
    Model   string
    APIKey  string
    PriceIn float64 // 每 1M token 输入
    PriceOut float64
}

var endpoints = []Endpoint{
    {"DeepSeek V4 Pro", "https://api.deepseek.com/anthropic", "deepseek-v4-pro", os.Getenv("DEEPSEEK_API_KEY"), 1, 4},
    {"DeepSeek V4 Flash", "https://api.deepseek.com/anthropic", "deepseek-v4-flash", os.Getenv("DEEPSEEK_API_KEY"), 0.3, 1.2},
    {"通义千问", "https://dashscope.aliyuncs.com/compatible-mode/v1", "qwen3.6-plus", os.Getenv("QWEN_API_KEY"), 20, 60},
    {"GPT-4o", "https://api.openai.com/v1", "gpt-4o", os.Getenv("OPENAI_API_KEY"), 35, 140},
    {"Claude Opus 4", "https://api.anthropic.com/v1", "claude-opus-4-20250514", os.Getenv("ANTHROPIC_API_KEY"), 105, 420},
}

func test(endpoint Endpoint, task string, prompt string) TestResult {
    start := time.Now()
    // ... 调用逻辑（上篇文章的 callLLM 加强版）
    elapsed := time.Since(start)
    // ... 解析结果，粗略计费
    return TestResult{
        Model:    endpoint.Name,
        Task:     task,
        Duration: elapsed,
        Cost:     estimateCost(endpoint, len(prompt), len(output)),
        Correct:  validateOutput(task, output),
    }
}

---

任务 A：写一个 Go 的 LRU 缓存

Prompt：

用 Go 实现一个线程安全的 LRU 缓存，要求：
1. 泛型实现，支持任意 key/value 类型
2. 支持 Get、Put、Len 方法
3. 使用 map + 双向链表
4. 只输出代码，不要解释

Claude Opus 4 — ✅ 完美

type LRUCache[K comparable, V any] struct {
    capacity int
    cache    map[K]*list.Element
    lruList  *list.List
    mu       sync.RWMutex
}

type entry[K comparable, V any] struct {
    key   K
    value V
}

func NewLRUCache[K comparable, V any](capacity int) *LRUCache[K, V] {
    return &LRUCache[K, V]{
        capacity: capacity,
        cache:    make(map[K]*list.Element),
        lruList:  list.New(),
    }
}

func (c *LRUCache[K, V]) Get(key K) (V, bool) {
    c.mu.Lock()
    defer c.mu.Unlock()
    if elem, ok := c.cache[key]; ok {
        c.lruList.MoveToFront(elem)
        return elem.Value.(*entry[K, V]).value, true
    }
    var zero V
    return zero, false
}

func (c *LRUCache[K, V]) Put(key K, value V) {
    c.mu.Lock()
    defer c.mu.Unlock()
    if elem, ok := c.cache[key]; ok {
        c.lruList.MoveToFront(elem)
        elem.Value.(*entry[K, V]).value = value
        return
    }
    elem := c.lruList.PushFront(&entry[K, V]{key: key, value: value})
    c.cache[key] = elem
    if c.lruList.Len() > c.capacity {
        oldest := c.lruList.Back()
        if oldest != nil {
            c.lruList.Remove(oldest)
            delete(c.cache, oldest.Value.(*entry[K, V]).key)
        }
    }
}

泛型正确、线程安全、LRU 淘汰逻辑完整。读完就能用。

DeepSeek V4 Pro — ✅ 正确，但用了标准库

DeepSeek 直接建议「Go 1.22 之后标准库没有 LRU，但你可以这样说……」然后给了一段实现。代码正确但稍微啰嗦。

通义千问 — ⚠️ 有 Bug

代码能编译通过，但 Get 方法用的是读锁 RLock 而非写锁——而 Get 需要移动链表节点，是写操作。并发场景下会 panic。

GPT-4o — ✅ 正确

跟 Claude 输出质量接近，代码无 Bug。

---

任务 B：Python 脚本翻成 Go

给了一段 Python 脚本——从 CSV 读取、过滤、聚合，输出统计结果。要求翻译成 Go。

Claude Opus 4 — ✅ 完整翻译，错误处理到位

不仅翻了逻辑，还加了 Go 惯用的错误处理、defer file.Close()、优雅的 Reader 封装。

DeepSeek V4 Pro — ✅ 翻译正确，但注释有点啰嗦

代码正确，但喜欢在每行上面加注释——「// 打开文件」「// 检查错误」。我得手动删掉多余的注释。

通义千问 — ✅ 输出最简洁干净

意外地好。代码简洁、符合 Go 风格，注释恰到好处。中文场景下通义千问的语感确实更好。

GPT-4o — ⚠️ 忽略了一个细节

Python 脚本里有个 dropna() 调用，GPT-4o 翻译时直接跳过了，没在 Go 里做空值过滤。算不上 Bug，但不够仔细。

---

任务 C：给一件无注释代码写 godoc

给了上篇的 collectCommits 函数。

通义千问 — 🏆 中文注释最佳

中文表达最自然流畅，参数说明的措辞最像「人类写的」。如果你团队看中文文档，通义千问是最好的选择。

Claude Opus 4 — 🏆 英文注释最佳

英文注释标准 godoc 风格，用的是 Go 官方的注释惯例。

DeepSeek V4 Pro — 准确但略显模板化

注释是对的，但感觉像「套模板写出来的」——格式工整但少了一点人情味。

GPT-4o — 中规中矩

可以用的水平，没有惊喜也没有 Bug。

---

任务 D：找出并发 Bug

给了一段故意埋 Bug 的 Go 并发代码——没有锁保护的 map 并发读写、WaitGroup 使用错误、goroutine 泄漏。

// 这段代码有 3 个并发 Bug，找出来
func process(items []string) map[string]int {
    result := make(map[string]int)
    var wg sync.WaitGroup
    for _, item := range items {
        go func() {
            result[item] = len(item) // Bug 1: 无保护的并发写 map
        }()
    }
    wg.Wait()
    return result // Bug 2: wg 没 Add，Wait 直接过
                  // Bug 3: goroutine 里 item 闭包捕获
}

Claude Opus 4 — 🏆 3 个 Bug 全找到，并给了修复方案

发现 3 个问题：
1. map 并发写无保护 — 使用 sync.Mutex 或 sync.Map
2. wg.Add(0) 实际上没等待任何 goroutine — 循环内加 wg.Add(1)
3. item 变量被闭包捕获 — 循环中 item 是同一个变量，使用 go func(item string){}(item) 解决

准确、简洁、有修复代码。

DeepSeek V4 Pro — ✅ 找到 2.5 个

找到了 Bug 1 和 Bug 3，Bug 2（WaitGroup）也提到了但说「可以工作」，实际上如果不 Add 的话 Wait 立即返回，不符合预期。

GPT-4o — ✅ 全部找到

表现跟 Claude 接近，都找全了。

通义千问 — ⚠️ 只找到 2 个

漏了闭包捕获的问题。这是最隐蔽的 Bug，确实很难发现。

---

价格实测：同一批任务，账单差 100 倍

我把 4 个任务的完整对话（输入 + 输出 token 数）换算成了实际成本：

模型	4 个任务总耗时	4 个任务总花费	正确率
DeepSeek V4 Flash	12s	¥0.003	3/4
DeepSeek V4 Pro	8s	¥0.01	3.5/4
通义千问 Max	10s	¥0.15	3/4
GPT-4o	7s	¥0.28	3.5/4
Claude Opus 4	6s	¥1.05	4/4

Claude 全对，但花了 1.05 元。DeepSeek V4 Flash 只错了 1 个细节，花了 0.003 元。

差距是 350 倍。

---

我的选择策略

经过这次实测，我的日常策略是这样的：

写生产代码 → Claude Opus 4（全对，贵但值得）
写原型/实验 → DeepSeek V4 Pro（正确率高，价格很低）
批量处理/非关键 → DeepSeek V4 Flash（便宜到可以当水用）
写中文文档/注释 → 通义千问（中文语感最好）
做跨语言翻译 → Claude 或 DeepSeek V4 Pro

你可能觉得「Claude 太贵了」。但你想一下——一个全栈程序员一天的人力成本是 1000-2000 元。Claude 一次调用 1 块钱，帮你省了 30 分钟。不是 AI 太贵，是你算错了分母。

---

最后的真话

我测完这一轮最大的感受不是「谁最强」，而是一个很反直觉的事实：

2026 年了，不同模型之间的差距在缩小。

Claude 确实全对，但 DeepSeek 也很接近。通义千问虽然在复杂任务上稍弱，但在中文文档场景下反而是最优解。

没有「最好的模型」，只有「最适合当前任务的模型」。

下一篇我们从零搭建开发环境：一个 Docker Compose 命令，把 DeepSeek 代理、Ollama 本地模型、API 调试工具全跑起来。一键部署，不用折腾半天环境。

关注我，别错过。

---

🦞 一只用 AI Agent 搭副业产线的程序员

全平台同名：虾哥不加班
需要定制 AI 工具？来聊聊 → lob_ai

源码：GitHub - lobster-bujiaban