一次真实网站改版：5 个 Flash模型 CC 实测

最近拿自己的一个真实网站修改任务，顺手测试了一下几个模型在 Claude Code 里的实际表现。

这次没有跑 Benchmark，也没有准备专门的测试题，就是让几个模型去完成同一个真实网站改版任务。

测试的方案一共 5 个：

• GLM5.3-Flash
• DeepSeek-V4-Flash
• Qwen3.8-Flash API
• Qwen3.8-Flash Token Plan
• GPT5.6-Luna-Max

最终 5 个方案都完成了任务。

真正让我觉得有意思的，不是“谁能完成”，而是它们完成同一件事的过程差异非常大。

最少的只用了约 1110 万 Token，最多的跑到了 6584 万 Token；最快 25 分钟，最慢 107 分钟。

最后生成出来的东西也并不完全一样。

GLM 和 DeepSeek 的后台代码非常接近，Qwen 的实现方式和它们有一些区别，而 Luna 虽然这次耗时最长，但最终做出来的前端反而是几个方案里我觉得最好看的。

所以这次我主要想看看几个问题：

• 同一个任务到底要消耗多少 Token
• 要跑多长时间
• 实际花多少钱
• 最后做出来的代码和页面有什么区别

先看最终结果

单看这张表，几个特点已经很明显了。

GLM 最省 Token。

DeepSeek 最快。

Qwen API Token 消耗最高。

Luna 这次跑得最慢。

但如果把最后生成的代码和页面也放进来，情况又没有这么简单。

这次实际用了什么价格

本次测试的 API 价格并不是统一标准原价。

另外两个是订阅方案：

• Qwen3.8-Flash Token Plan：¥39/月
• GPT5.6-Luna-Max：$20/月订阅额度

所以后面的成本对比，准确说应该是：

这一次实际使用环境下的成本。

并不是 GLM、DeepSeek、Qwen 三家标准原价的横向对比。

尤其 DeepSeek 这次刚好用了闲时价格，GLM 又是限时半价，而 Qwen API 是原价。

GLM：最省 Token，而且后台完成度没问题

GLM 这次一共用了：

11,103,347 Token

耗时：

35 分钟

这是 5 个方案里 Token 最少的。

DeepSeek 虽然更快，但用了 2132 万 Token，差不多是 GLM 的 1.92 倍。

所以从这次实际运行来看，GLM 最大的特点就是：

完成同样的事情，走的路径比较短。

至少没有出现特别夸张的重复读取、上下文膨胀或者长时间反复尝试。

最终后台代码也比较完整，没有因为 Token 少就出现明显的“省步骤”。

如果单纯看 Token 利用率，GLM 这次确实最好。

DeepSeek：最快，而且和 GLM 的后台实现很像

DeepSeek 这次只用了：

25 分钟

是全部方案里最快的。

Token 消耗是：

21,319,868

虽然比 GLM 多不少，但还是远低于 Qwen 和 Luna。

它的缓存命中率也很高：

98.76%

这次还有一个很明显的感受。

我对比最终后台代码后发现，DeepSeek 和 GLM 的实现思路非常接近。

不仅是“都做出来了”，而是一些代码组织、业务处理和实现路径都比较像。

第一反应确实会让人怀疑：

GLM 和 DeepSeek 在 Coding 后训练、代码数据或者 Agent 优化方式上，会不会有一些类似的地方？

不过这个只能算观察，不能当结论。

一次任务完全不足以证明两家的后训练方式类似。

也可能只是因为这个后台任务本身最合理的实现方式就比较集中，两个模型都选择了相似的软件工程方案。

所以更准确的描述是：

在这一次任务里，GLM 和 DeepSeek 的后台输出风格和最终实现存在明显趋同性。

至于这种趋同性来自后训练方式、训练数据、模型偏好，还是单纯来自任务本身，目前没有办法判断。

Qwen：Token 消耗明显偏高

Qwen 是这次 Token 数据里最突出的一组。

Qwen API：

65,843,099 Token
87 分钟

Qwen Token Plan：

46,208,164 Token
70 分钟

尤其普通 API，Token 是全部方案里最高的。

和 GLM 相比：

65.84M ÷ 11.10M ≈ 5.93 倍

也就是说，同一个任务，Qwen API 实际处理的 Token 接近 GLM 的 6 倍。

这也是这次测试里我觉得非常值得关注的一组数据。

因为 Qwen API 的缓存命中率其实并不低：

95.18%

但最终依然累计跑出了超过 6500 万 Token。

从最终代码结果来看，我也没有看到足以解释这接近 6 倍 Token 差距的明显质量提升。

所以至少在这一次任务里，Qwen API 的主要问题可以很直接地概括为：

执行路径偏重，Token 消耗过大。

当然，仅凭一次任务还不能判断这是模型本身的问题，还是 Claude Code 接入方式、上下文管理、缓存策略或者请求方式造成的。

但对于真实使用者来说，最后付费看的就是实际结果，所以这个数字本身依然有参考价值。

Qwen Token Plan 比普通 API 明显更合理

比较有意思的是，同样是 Qwen3.8-Flash，两种调用方式的数据差距非常大。

Token Plan：

46,208,164 Token
70 分钟

普通 API：

65,843,099 Token
87 分钟

Token Plan 少用了大约：

19,635,000 Token

同时快了：

17 分钟

Token 大约下降了 30%。

缓存命中率也从：

95.18%

提高到了：

98.01%

这说明在 Claude Code 这种 Agent 场景里，底层模型一样，也不代表实际表现一样。

接入方式、上下文管理、缓存方式、请求策略，都可能明显影响最终消耗。

至少按照这一次结果，如果已经有 Qwen Token Plan，我会优先用 Plan，而不是再额外走普通 API。

Luna：最慢，但前端反而是这次最好看的

GPT5.6-Luna-Max 这次的数据其实并不好看。

总 Token：

54,568,584

耗时：

107 分钟

是 5 个方案里最慢的。

Token 消耗也比较高，仅低于 Qwen API。

如果只看 Token 和时间，它在这次测试里毫无疑问属于执行效率比较低的一档。

但真正打开最终页面后，我反而觉得：

Luna 做出来的前端，是这几个方案里最好看的。

这里的“最好看”仍然只是横向比较。

这几个模型做出来的前端整体都谈不上特别惊艳，也达不到专业 UI 设计师重新设计一遍的水平。

但 Luna 的页面在：

• 整体布局
• 信息层级
• 视觉协调
• 页面完成度
• 细节处理

上，给我的最终观感最好。

这就出现了一个很有意思的情况。

如果只看数字：

54.57M Token
107 分钟

Luna 基本垫底。

但如果把最终页面效果也算进去，它又不能简单被定义为“最差”。

至少这次，它确实用更多时间和 Token 换来了一部分可以直接看到的前端质量。

至于这个提升值不值得 107 分钟和 5457 万 Token，那就取决于具体项目。

如果我做的是后台、API、数据处理或者大量 CRUD，我肯定更倾向 GLM 或 DeepSeek。

但如果本身就是一个用户直接访问的网站，最终页面效果很重要，那么 Luna 这次的结果反而值得参考。

Luna 的订阅成本其实很低

Luna 这次还有一个比较特殊的地方，就是它走的是订阅额度。

本次大约使用月额度的：

1%

如果按：

$20/月

简单分摊：

$20 × 1% = $0.20

大约相当于：

¥1.34

不过这个数字一定要正确理解。

¥1.34 是订阅额度的理论分摊成本，并不是这次任务真的额外扣了 ¥1.34。

如果订阅本来就已经购买，那么跑这次任务实际上并没有再产生一笔 ¥1.34 的 API 账单。

所以 Luna 的情况比较特殊：

• Token 不低
• 时间最长
• 前端最好看
• 但如果订阅已经买了，额外现金成本很低

它和 API 模型其实很难用单一价格指标直接比较。

缓存命中率高，并不代表一定省

这次还有一个很明显的现象，就是几乎所有模型缓存命中率都很高。

统一按照：

缓存命中输入 ÷ 总输入

计算。

结果是：

Qwen API 有 95.18% 的输入都命中了缓存，看起来已经非常高。

但它最终依然用了：

65.84M Token

所以缓存命中率只能说明：

大部分上下文按照更便宜的缓存价格计费。

它并不能说明：

这个模型整体只处理了很少的上下文。

如果每一轮都携带巨大的上下文，哪怕 95% 都命中缓存，最终累计 Token 还是可能非常夸张。

缓存命中率是怎么计算的

为了尽量统一几个平台的统计口径，这次缓存命中率都按照：

缓存命中 Token ÷ 总输入 Token

计算，不把输出 Token 放入分母。

GLM

10,155,136 ÷ (10,155,136 + 911,838)
= 91.76%

DeepSeek

20,967,296 ÷ (20,967,296 + 263,641)
= 98.76%

之前原始记录里的 98.35%，是因为把输出 Token 也算进了分母。

只看输入侧缓存命中，98.76% 更合适。

Qwen API

Qwen API 输入分成三部分：

普通输入：2,792
 
显式缓存创建：3,162,220
 
显式缓存命中：62,509,786

总输入：

2,792 + 3,162,220 + 62,509,786
= 65,674,798

所以：

62,509,786 ÷ 65,674,798
= 95.18%

这里要注意：

缓存创建不等于缓存命中。

第一次把内容写进缓存属于创建，之后再次使用才属于命中。

Qwen Token Plan

45,130,075 ÷ (45,130,075 + 916,119)
= 98.01%

Luna

52,273,920 ÷ 54,293,851
= 96.28%

其中 98,817 个推理输出 Token 已经包含在 274,733 个输出 Token 中，所以不重复计算。

Qwen API 的账单还有一个小问题

Qwen API 后台显示的实际费用是：

¥10.24

但按照我记录的价格重新计算：

普通输入：
2,792 × ¥0.80/M
≈ ¥0.0022
 
缓存创建：
3,162,220 × ¥1.25/M
≈ ¥3.9528
 
缓存命中：
62,509,786 × ¥0.10/M
≈ ¥6.2510
 
输出：
168,301 × ¥2.70/M
≈ ¥0.4544

理论合计：

约 ¥10.66

和实际面板：

¥10.24

相差大约：

¥0.42

具体原因目前不确定。

可能是：

• 缓存创建实际价格存在差异
• 平台存在其他折扣
• 部分请求使用了不同计费规则
• 平台账单统计口径不同

所以这篇文章统一采用：

• 实际账单：¥10.24
• 理论重算：约 ¥10.66

在没有更完整账单明细的情况下，就不继续猜具体原因了。

API 真正花了多少钱

如果只比较真正按照 API 用量产生的账单：

这里有两个不同的“最便宜”。

总账单最低的是：

GLM，约 ¥1.58。

单位 Token 成本最低的是：

DeepSeek，约 ¥0.086/M。

不过 DeepSeek 本次是闲时价格，GLM 是限时半价，所以不能把它理解成三家标准 API 原价排名。

Qwen 这次真正拉高账单的关键也不是缓存单价，而是它跑出了：

65.84M Token

总量太高。

Qwen Token Plan 的成本怎么算

Qwen Token Plan 本次使用了 7 日额度的：

24.4%

简单折算为月额度约：

6.1%

套餐价格：

¥39/月

所以按额度比例分摊：

¥39 × 6.1%
= ¥2.379

也就是约：

¥2.38

这个算法和 API 实际扣费并不是一回事，只是为了方便估算一次任务占用了多少订阅价值。

如果只看 Token 和时间

为了简单比较执行效率，我用了一个比较粗暴的算法。

Token 得分 =
最低 Token ÷ 当前模型 Token × 100
 
用时得分 =
最短用时 ÷ 当前模型用时 × 100
 
综合效率 =
(Token 得分 + 用时得分) ÷ 2

也就是：

Token：50%
时间：50%

结果如下：

如果只评价：

完成这次任务所需要的 Token 和时间

那么排序很明确：

GLM > DeepSeek > Qwen Token Plan > Qwen API > Luna

但这个排名不能理解成模型能力排名。

因为它完全没有考虑最终代码质量和页面效果。

而 Luna 这次就是一个很好的反例。

它在执行效率里排名最后，但是最终前端却是我认为最好看的。

最终代码实际看下来是什么感觉

如果把最终结果简单总结一下：

这里的“最好”完全是这一次任务的主观观察。

并不是说：

Luna 的前端能力一定比其他模型强。

只能说：

这一次测试中，Luna 最终给我的页面观感最好。

而且这几个方案整体前端表现其实都只能算比较普通。

如果真的要正式上线，我后面还是会继续专门做 UI 调整。

这次我最大的感受：模型单价可能没想象中那么重要

以前看 API，最容易比较的是：

输入多少钱 / M
输出多少钱 / M
缓存多少钱 / M

但真正把 Agent 跑起来以后，我越来越觉得，这些只是表面价格。

真实成本更接近：

实际任务成本
=
模型单位 Token 成本
×
完成任务所需要处理的 Token

比如这次：

GLM：
11.10M Token
 
Qwen API：
65.84M Token

相差接近 6 倍。

这种情况下，就算 Qwen 的缓存只有：

¥0.10/M

也扛不住总量太大。

所以以后评测 Coding Agent，我觉得“完成同样任务需要多少 Token”应该成为一个很重要的指标。

一个模型如果能：

理解需求
→ 找到文件
→ 修改
→ 验证
→ 完成

另一个模型却是：

读取
→ 分析
→ 再读取
→ 尝试
→ 回退
→ 再尝试
→ 继续携带大量上下文

即使最后都完成了，成本和使用体验都会完全不同。

但 Token 少，也不能代表模型一定更好

Luna 这次又刚好说明了另一面。

如果只看效率：

54.57M Token
107 分钟

确实不好看。

但最终前端又是几个方案里我最满意的。

所以 Token 多并不一定全部是无效消耗。

真正完整的 Coding Agent 评测，我觉得至少应该同时看：

• 任务是否完成
• 需求理解是否准确
• 最终代码质量
• 前端页面效果
• 是否引入 Bug
• 测试是否通过
• 返工次数
• Token 消耗
• 完成时间
• 实际成本

只看 Token 和时间，评出来的其实只是：

执行效率。

而不是完整的：

Coding 能力。

如果让我现在选

只根据这一次真实任务，我自己的选择其实比较明确。

如果是：

• 后台开发
• API
• CRUD
• 业务逻辑
• 批量代码修改

我会优先考虑：

GLM 或 DeepSeek。

GLM 更省 Token。

DeepSeek 更快。

而且这次两者最后做出来的后台代码非常接近。

如果主要使用 API，而且能够利用 DeepSeek 闲时价格，那这次 DeepSeek 的综合体验确实很好。

如果使用 Qwen，我会明显更倾向：

Qwen Token Plan。

因为同一个模型，这次 Plan 比普通 API：

• 少约 1963 万 Token
• 快 17 分钟
• 缓存命中率更高
• 成本也低很多

普通 Qwen API 在这次任务里的 Token 消耗确实有点夸张。

至于 Luna，它这次属于一个很特别的情况。

如果我最在意的是：

尽快、尽量少 Token 地完成开发

那我不会优先选 Luna。

但如果做的是用户真正会看到的页面，而且我希望模型顺手把前端做得更完整一些，那么这次 Luna 的最终结果反而是几个模型里最好的。

再考虑到它属于订阅额度，如果本来就已经买了订阅，实际额外现金成本并不高。

一句话总结

这一次真实网站改版跑下来：

GLM 最省 Token，DeepSeek 最快，两者后台实现非常接近。

Qwen 普通 API 的 Token 消耗明显偏高，而 Token Plan 的表现要合理很多。

Luna 虽然耗时最长、Token 也不少，但最终前端反而是这次几个方案里最好看的。

所以我现在越来越觉得，Coding Agent 不能只问一句：

哪个模型最强？

更应该问：

我现在做的是什么任务，我到底在意速度、Token、价格、后台代码，还是最终页面效果？

因为同一个任务，这几个模型最后都能做完。

但它们完成任务的方式、成本和最终结果，确实可以完全不一样。

关于这次测试的限制

这次只有一个真实网站修改任务，样本量很小。

所以不能根据这一次测试就判断某个模型长期一定比另一个强。

而且本次价格条件并不统一：

• GLM 使用限时半价
• DeepSeek 使用闲时价格
• Qwen API 使用原价
• Qwen Token Plan 使用订阅额度
• Luna 使用订阅额度

不同模型在 Claude Code 中的：

• 上下文处理方式
• 缓存机制
• 工具调用策略
• 文件读取次数
• 重试行为
• 推理长度

也可能完全不同。

这些因素都会影响最终 Token 和完成时间。

另外，这次没有对最终代码进行标准化评分。

比如：

• GLM 和 DeepSeek 后台代码非常接近
• Luna 的前端最终效果最好
• Qwen 的实现方式和 GLM、DeepSeek 有一些区别

这些都属于这一次任务中的实际观察，不应该直接推广成模型的普遍能力结论。

所以这篇文章更准确的定位不是：

5 个模型到底谁最强？

而是：

同一个真实网站修改任务，5 个方案分别用了多少 Token、多少时间、多少钱，以及最后交出来的东西到底有什么区别。