五个主流 AI 模型跑同一个任务，谁的返工率最低？

做模型选型的时候，大多数人看的是 benchmark 排行榜。但排行榜分数高不代表输出能直接用——你拿到结果还得改两遍才能交付，效率照样拉胯。最近在库拉镜像平台（leadhi.cn）上把 Claude、GPT、Gemini、DeepSeek、Qwen 五个模型拉出来，用同一组真实开发任务跑了一轮对比，专门看返工率这个指标。结果跟预想的差距不小。

测试设计：不跑 benchmark，跑真实任务

选了 10 个开发者日常最常遇到的任务类型：RESTful 接口设计、SQL 查询优化、正则表达式编写、单元测试生成、错误处理补全、API 文档生成、Dockerfile 编写、代码重构方案、Git 冲突解决、并发场景方案设计。

每个任务用完全相同的 prompt 给五个模型各跑一次，然后逐个验证生成结果能否直接交付。直接能用算 0 次返工，改一轮能用算 1 次返工，改两轮以上或放弃重写算 2 次返工。

评判标准不是"对不对"，是"拿来能不能用"。

实测结果

Claude 的返工率最低，10 个任务里 6 个直接能用。GPT-5.5 紧随其后，虽然直接可用率略低但"改一轮就用"的比例最高。DeepSeek 和 Qwen 在需要业务理解的任务上翻车较多。

三个核心发现

发现一：差距最大的在"带业务语境"的任务上。

纯技术实现（正则、Dockerfile、SQL）五个模型差距不大。但一旦涉及业务逻辑——比如"设计电商订单状态机"或"写并发安全的库存扣减方案"——差距就拉开了。

Claude 和 GPT 能从 prompt 里推断出隐含的业务约束，主动加上并发控制、幂等校验这些你没提但实际需要的东西。DeepSeek 和 Qwen 更倾向于严格按字面意思执行，你没说的它就不做，导致结果"逻辑对但不完整"。

发现二：返工成本最高的不是"写错了"，是"方向对但细节错"。

完全写错的反而好改——大方向不对直接推翻重来。最消耗时间的是那种"看了觉得差不多，用起来才发现边界条件没处理"的情况。

比如五个模型都正确实现了分页查询，但只有 Claude 和 GPT 主动考虑了排序字段为空时的默认处理。这类问题不会在首次测试中暴露，上线后才被用户触发，排查成本远高于开发阶段的返工。

发现三：prompt 越详细，模型间差距越小。

当 prompt 里把技术栈、框架版本、输入输出格式、边界条件全部明确后，五个模型的返工率差距从 50 个百分点缩小到 20 个百分点。这说明：模型间的差距，有相当一部分可以通过更好的 prompt 来弥补。

按任务类型拆开看

代码生成类（接口设计、Dockerfile、单元测试）：Claude 和 GPT 并列最优，直接可用率 67%。DeepSeek 和 Qwen 差距不大。

代码审查类（SQL 优化、错误处理补全、重构方案）：Claude 明显领先。它在审查任务中会主动指出潜在的性能问题和安全风险，其他模型更倾向于只解决你明确提到的问题。

诊断修复类（Git 冲突、正则调试）：五个模型差距最小。输入输出都很明确，拉不开差距。

趋势：从"谁最聪明"到"谁最省事"

模型能力的竞争正在从 benchmark 分数转向实际交付效率。Anthropic 最近把"减少返工"作为核心卖点——强调的不是更高的考试分数，而是首次交付质量更高。

这个方向是对的。对开发者来说，衡量模型好不好用的标准不是它在测试集上得多少分，而是你拿到输出后还需要花多少时间来改。返工率才是真正影响开发效率的指标。

选模型的时候别只看排行榜，拿你自己的真实任务跑一轮，看谁的输出最接近"拿来就能用"。这个答案可能跟排行榜完全不同。