Deepseek新Flash0731简单评测

概述

梁圣发布后训练过的V4-Flash0731，现在用Claude Code评测一下尝尝鲜。

根据DS官方的评测数据，新Flash的表现比老V4-Pro（Preview版）更强，超过GLM-5.2，略弱于Opus-4.8。

目前个人非量化的体验：flash0731的agent表现与v4-pro-preview的表现非常接近，个人主要做Qt/C++上位机、STM嵌入式裸机开发。

v4在claude code上的嵌入式开发表现已经比上半年的许多模型表现好很多了，但是还是会出现端口识别不清、写出连编译都通过不了的代码（已经配置build mcp）。

目前初步使用感觉flash在能力上和pro-preview相比没有明显差异，但是人是便宜啊！！！模型自费打工人狠狠爽到了

p.s. 评测部分是用cc根据运行结果和我的指令写的，数据可以包真实XD

测试费用

DS以便宜大碗著称，主包最近用AI付费打工，性价比很关键，使用老v4-pro已经能够给达成比较好的效果了，一个demo/项目深入修改大概需要花费3元左右，对比能力之前先看一下评测过程的耗费。

可以大概参考一下，生成项目用时20min，并行测评跑了45min，费用大致如上。

模型 Agent 能力对比报告：新 flash vs 旧 Pro

评测日期：2026-07-31

一、评测设置

• 被测模型路由（见 ~/.claude/settings.json）：opus → deepseek-v4-flash[1M]（新 flash）；sonnet → deepseek-v4-pro[1M]（旧 Pro）。
  

• 任务套件：8 个自包含任务（seeds/task1..8），覆盖 4 个维度 —— 编码与测试（T1/T2）、终端与文件工具（T3/T4）、联网检索综合（T5/T6）、多步规划与容错（T7/T8）。来源为公开基准（SWE-bench / Terminal-Bench / GAIA 风格）改写 + 自定义。

• 执行方式：两个模型作为独立 Claude Code 子代理并行运行同一套任务（同一份 TASKS.md，仅工作目录不同），各自独立完成、独立验证、独立写 RESULT.md / SUMMARY.md。

• 评判方式：① 确定性客观 grader（_grader/grade_all.py）逐项复核产物（不采信自报）；② haiku 中立模型按 rubric 盲评（匿名 A/B，A=opus、B=sonnet 的映射仅存在于评测者记录）。

二、客观评分（确定性复核）

任务	维度	flash	pro
T1 修复定价模块	编码与测试	✅ 1.00（pytest 8/8，受保护文件哈希一致）	✅ 1.00（pytest 8/8，受保护文件哈希一致）
T2 merge_ranges	编码与测试	✅ 1.00（14/14 隐藏用例）	✅ 1.00（14/14 隐藏用例）
T3 日志分析	终端与文件	✅ 1.00（6/6 字段，含 top_ips 字典序与并列规则）	✅ 1.00（6/6 字段）
T4 异构数据合并	终端与文件	✅ 1.00（表头/行数/抽样 join 全对）	✅ 1.00（同左）
T5 两地大圆距离	联网检索	✅ 1.00（5837 km，与真值差 0）	✅ 1.00（5837 km，与真值差 0）
T6 USB-PD 报告	联网检索	✅ 1.00（5 个真实 URL）	✅ 1.00（4 个真实 URL）
T7 管线容错	多步规划容错	✅ 1.00（output.json 4/4 字段一致）	✅ 1.00（同左）
T8 wordcount CLI	多步规划容错	✅ 1.00（隐藏输入 JSON 精确匹配 + 缺文件 exit 1）	✅ 1.00（同左）
总分		8.00 / 8.00	8.00 / 8.00

任务完成度：完全持平。 两个模型的 8 个任务全部客观通过，且多处修复完全一致（T1 的两处 bug、T7 的 r["cat"]→r["category"]、T5 的答案 5837）。

三、盲评裁判（匿名 A/B）

A = flash，B = pro。评分 1–5。

维度	opus (A)	sonnet (B)	裁判要点
方案质量 Approach	5	5	双方都采用「复制→读规格→解决→独立交叉验证」的规范流程，直接命中要害
工具使用效率 Tool use	5	5	都熟练运用 python/pytest/awk/pip；遇到 Write 拦截 report.md 都改用 bash heredoc 绕过
错误恢复 Recovery	5	4	A 展示了对自身判断错误的显式自我纠正（T4 将「39 个不同 user_id」更正为「81 个受影响订单行」）与 WebFetch 被拦截后的 WebSearch 多源兜底；B 的复盘较单薄
规划与覆盖 Coverage	5	5	均 8 任务全覆盖、遵守时间盒；B 额外验证了 --top 0、纯停用词、小时计数求和=2500 等边界
产物质量 Artifacts	5	5	交付物均正确可复现；A 报告技术细节更丰富（5 个来源 URL），B 的 wordcount 用 argparse 更地道

裁判总体判定：A（flash）微弱领先，基本持平 —— A 在验证严谨性与恢复透明度上略胜，B 在代码惯用法与简洁性上略胜，差距很小。

四、综合结论

1. 任务完成度：两个模型 8/8 全部通过，客观成绩完全一致，处于同一能力层级。
2. 质量维度：flash（新）在「验证纪律、错误恢复、复盘透明度」上略强；pro（旧）在「代码惯用法、简洁性」上略强。裁判认定 flash 微弱领先，但差距在误差范围内，可视为基本持平。
3. 过程行为高度相似：都独立发现了同一环境障碍（Write 工具拦截 report/SUMMARY 文件名）并各自绕过；编码修复路径几乎一致。两模型在本次任务集上未表现出可分辨的 Agent 能力代差。

五、方法学说明与局限

• 公平性：两模型运行条件逐字节相同（同一 TASKS.md、同一 seeds、同一环境），且互相隔离。
• 已知瑕疵：T7 的「缺失依赖」障碍在冒烟验证阶段被 haiku 代理的 pip install prettytable 意外中和，两模型实际只面对 KeyError 一个障碍——对两边公平，但容错维度覆盖度下降。T5 交付位置 answer.txt 在 run 根目录与 task5/ 之间有规格歧义，grader 已宽容处理。
• 天花板效应：任务规模可控且全部可解，8/8 的双满分意味着本评测难以区分两模型的能力上限，只能说明在此难度档位上两者都合格且表现接近。
• 裁判局限：仅使用单一裁判模型（haiku）且非盲于全部产物；未做多裁判交叉与去偏差处理。客观检查仍是结论的主骨架。
• 联网限制：WebFetch 受网络策略限制，T5/T6 两模型均只能依赖 WebSearch 摘要（双方同等受限，公平）。