DeepSeek-V4-Flash 正式发布后的一天真实使用复盘——上次吐槽的问题一个没遇到，速度还飞快
DeepSeek-V4-Flash 正式版实测牛逼：为 DeepSeek 正名，上个月的低级问题已不复存在，编码能力直线上升。
先承认：上个月那篇吐槽，我需要回来补个后续
7 月初我写过一篇《不吹不黑，DeepSeek 编程实测翻车》，记录了一周真实使用中遇到的低级错误：字符串拼 YAML 把配置改得面目全非、改完 Java 从不编译验证、跨文件引用追不到、看到版本号数字小就往上加、还时不时越权改不该动的文件。那篇文章的结论很直接——DeepSeek 想学 Claude 做全局理解，能力没跟上，位置很尴尬。
当时我说"希望 DeepSeek 官方能看到这些一线问题，尽快修掉"。说实话，我当时对"尽快"的预期是几个月起步。
结果 7 月 31 日，DeepSeek-V4-Flash 正式版 API 上线公测。本着"吐槽过就要再测一次"的原则，我把它接回 Claude Code，认认真真用了一整天。
先说结论，避免你读不下去：之前那些低级问题，一个都没遇到。不是变少，是没有。而且速度是真的快。
为什么这次值得再测
上个月的问题清单，我简单回顾一下，因为后面要逐条对照：
| # | 上个月的问题 | 严重程度 |
|---|---|---|
| 1 | 用 Python 字符串拼接操作 YAML，缩进全乱 | 🔴 灾难级 |
| 2 | 改完 Java 从不编译验证，10 次 9 次编不过 | 🔴 灾难级 |
| 3 | 只读当前文件，父 pom 继承的版本号追不到 | 🟠 高危 |
| 4 | 看到 3.9.2-beta 就猜该改成 3.9.3，不查证 |
🟠 高危 |
| 5 | 擅自越权改 pom.xml、package.json | 🟡 中等 |
| 6 | replace_all 全局替换污染项目版本号 | 🟡 中等 |
| 7 | 改坏了不停止，继续写脚本救火越陷越深 | 🟠 高危 |
这七条里，前三条是"能力"问题，后四条是"习惯"问题。能力问题可以靠模型迭代解决，习惯问题需要工程流程层面的自省——我原本以为后者更难修，结果这次反而最让我意外。
先说官方数据：Flash 正式版上线时给了什么
在我动手实测之前，官方先放出了对比数据。7 月 31 日上线的 V4-Flash 正式版，官方直接甩出了它与 V4-Pro-Preview、GLM-5.2 的 Agent 基准横评——两个信号相当扎眼：
- 全面超越自家 Pro-Preview：在所有 Agent 基准上，Flash 正式版都压过了 V4-Pro-Preview
- 全面赢了 GLM-5.2：全部 9 项有数据的基准，每一项都是 Flash 领先
挑几个关键数字看：
| 基准测试 | V4-Flash 正式版 | V4-Pro-Preview | GLM-5.2 |
|---|---|---|---|
| Terminal Bench | 82.7 | 72.1 | 81.0 |
| CyberGym | 76.7 | 52.7 | - |
| Toolathlon | 70.3 | 55.9 | 59.9 |
| DSBench-FullStack | 68.7 | - | 61.8 |
| DSBench-Hard | 59.6 | 31.1 | 54.5 |
| DeepSWE | 54.4 | - | 46.2 |
| NL2Repo | 54.2 | - | 48.9 |
我格外关注其中三项：
- Terminal Bench 82.7——衡量模型在终端环境执行命令、操作文件、完成多步骤任务的能力。它比 Pro-Preview 高了 10 分，逼近 Opus 4.8 的 85.0。这条恰好对着上个月"改完不编译验证"的吐槽：终端操作链能力直接决定模型能不能自己完成"改完 → 编译 → 验证"这个闭环
- DSBench-Hard 59.6 vs 31.1——内部 Coding Agent 难题集，接近翻倍。上一轮"10 次修改 9 次编不过"的难堪，在这项数据上已经能看到反转的伏笔
- Toolathlon 70.3 vs 55.9——多工具协同能力，领先 Pro-Preview 近一倍
还有个值得玩味的技术细节：V4-Flash-0731 的模型结构、尺寸和 preview 版本完全一致，只重新做了后训练（post-training）。没有加参数、没有换架构，纯粹靠训练方法论就把 Agent 能力拉到了超过自家 Pro 的程度——这对行业也是个信号：模型能力提升不一定只靠堆规模。
当然，基准是纸面数据，我上个月就说过"别只看跑分"。所以关键还是看真机实测。
实测方式：不跑 benchmark，跑一整天真实工作
这次的测试方法和上个月保持一致：Claude Code 接入 DeepSeek 模型，干真实的活儿。我不太信跑分——上个月那个"10 次修改 9 次编不过"的问题，跑分是绝对测不出来的，只有真实任务会暴露。
这一天我做了什么：
- 改代码：几个 Java 项目的日常修改，包括 JeecgBoot 相关的模块调整、配置调整、依赖处理，有单文件小改，也有跨文件的改动
- 批量改配置：特意让它一次性批量修改多个 YML 配置文件——这正是上个月翻车最惨的场景，必须重测
- 查资料、读代码：让它帮我梳理不熟悉的模块结构、追版本号定义
- 写文章：包括你现在正在看的这篇——从抓取上一篇文章、改写润色、生成 Markdown、维护索引，到后面要跑的多平台发布流程，全流程跑了一遍
- 跑工程流程：编译、SVN 提交（update/commit 一步没含糊）、脚本调试
一整天下来没有刻意设计"考题"，都是真实会遇到的需求。这种测法最公平：上个月翻车的场景，都是真实工作中自然发生的。
逐条对照：上个月的坑，今天还踩吗
直接上对照结果：
| # | 上个月的问题 | 今天的表现 |
|---|---|---|
| 1 | 字符串拼 YAML | ✅ 用精确编辑工具改配置，缩进分毫不差 |
| 2 | 改完不编译 | ✅ 改完 Java 自动编译验证，报错立刻定位修复 |
| 3 | 只读当前文件 | ✅ 追父 pom 继承、跨模块引用都追得到 |
| 4 | 版本号只看表面数字 | ✅ 先查证再动手，不瞎猜 |
| 5 | 越权改不该改的文件 | ✅ 范围控制干净，没碰不该碰的 |
| 6 | replace_all 污染版本 | ✅ 精确匹配替换，diff 干净 |
| 7 | 改坏了闷头救火 | ✅ 出错先复盘再动手，没有越陷越深 |
写出来就是一行行干巴巴的对比，但用的时候是真的爽。挑几个印象深的展开说。
先说 YAML 这件事。 上个月 DeepSeek 用字符串拼接处理 YAML，把 mybatis 改成 ybatis、配置块从文件中间挪到文件末尾——这种事在我心里已经留下阴影了。这次我特意又测了同样的场景：让 AI 批量修改多个 YML 配置文件。结果非常快，改完我盯着 diff 看了一遍：缩进、注释、层级全部完好，没有任何多余修改。一个工具正确使用的问题，上个月翻车翻得那么惨烈，这个月稳稳当当，这种对比最直接。
再说编译验证。 上个月"改完从不编译、10 次 9 次编不过"是最扎心的。这次我特意留意了这一点：一整天下来开了好几个会话任务，改 Java 代码改完会自动编译，编译报错会立刻定位修复，而不是丢给我一堆"你自己看着办"——从头到尾，没有再发现一次低级编译报错。这个习惯的养成，恰恰是我上个月建议"DeepSeek 官方应该优先修掉"的——他们真的修了。
还有跨文件追踪。 上个月让它改项目 B 参考项目 A，版本号定义在父 pom 里它追不到，只会瞎猜。这次同样的情况，它会沿着继承链往上游找真正的定义，找不到就先汇报而不是先动手。这个变化对 Maven 多模块项目意义重大——毕竟依赖版本经常躺在父 pom 里。
速度：这是最出乎意料的部分
如果只用一个词概括今天的体验，我会选"流畅"。
响应速度很快，比上个月用 V4 Pro 时的体感明显更快。我这次用的是 deepseek-v4-flash[1m]——1M 上下文版本，长对话、大项目上下文都不怵。一整天的会话里，我经常开好几个上下文很重的任务（项目代码 + 文档 + 之前的会话记录），没有遇到明显的变慢或者上下文被截断的憋屈感。
对一个整天坐在电脑前的人，"快"意味着什么？意味着你提需求、看结果、给反馈这个循环的节奏能跟得上你的思维，而不是每次等响应等到走神。今天这个循环转得很快，这也是我能一整天高密度用下来的原因之一。
一天下来的整体感受
如果用上个月那篇的"三个灵魂问题"来验收今天的表现：
- 它改完会不会自己编译验证？ —— 会，而且会自动修复编译错误。
- 它会不会擅自改你没让它改的东西？ —— 不会，范围控制得很干净。
- 它看到不理解的代码，是深入追查还是看着表面数字就动手？ —— 追查，找不到先问。
三个问题全过。上个月这三个问题全挂。一个月时间，同一个生态，体验翻转。
横向对比：和 K3、GLM-5.2 比，差距在哪
前阵子我写过 K3 和 DeepSeek V4 Pro 的对比，也聊过国产模型的"速度困局"。今天把 Flash 放进这个坐标系里，结论很有意思：
编码能力上，Flash 和 Kimi K3、智谱 GLM-5.2 目前看不出太大区别。 这三个都是第一梯队的编码选手，日常任务各有千秋，很难说谁明显压谁一头——官方基准里 Flash 赢了 GLM-5.2，实际用起来也确实互有胜负，但都属于"顺手"的范畴，没有哪家明显掉队。
但速度这一项，Flash 完胜。 这一点感受太强烈了：K3 现在我是真不敢用，太慢了。响应慢意味着什么？意味着你等它思考的时间，都够你自己想清楚下一步怎么做了。而 Flash 的响应几乎是即时的，你提需求、它干活、你看结果，节奏完全跟得上。
当模型之间的能力差距拉不开时，速度就是那个决定日常体验的变量。能力 95 分和 92 分的模型，你可能一天都感觉不出差别；但响应快 3 倍和慢 3 倍，你十分钟就能感知到。这就是为什么我现在的日常主力模型已经切到 Flash——不是因为它比谁都强，而是因为它是"够强 + 最快"的那个。
短板也要说：图片识别还是不行
既然是实测，短板也得交代。Flash 目前对图片的理解还是明显短板——今天实测中图片类的任务（比如读取界面截图、分析配图）它处理不了，需要降级到外部视觉模型才能完成。
这对纯文本编程任务影响不大——改代码、写配置、查文档这些用不上读图。但涉及 UI 截图分析、视觉检查、设计稿理解这些场景时会受限，得靠外部视觉能力补位。上个月那篇我吐槽"读不全"，这次倒是真读得全了，但"看不了图"这个新短板依然在。想拿它做全栈视觉任务的，得注意这个边界。
公道话也一起说了，不是无脑吹：
- 这不是"比 Claude 强"，而是"从拖后腿变成了可靠队友"。Claude 自家模型该稳的地方依然稳，Flash 胜在性价比和速度
- 一天的样本有限，长周期稳定性（比如复杂模块的端到端重构）还需要更多时间验证
- "会验证、会追查"这些工程习惯能不能一直保持，比能力本身更值得观察——毕竟上个月的问题大多出在习惯上
总结
上个月那篇的结尾，我给了三个验收问题，说"这三个问题比任何 benchmark 分数都更能预测日常体验"。今天我把同一套问题又跑了一遍，结果全过。
DeepSeek-V4-Flash 正式版这一天用下来，我的感受是：上次吐槽的那些"工程基本功缺失"，官方是真听进去了、真修掉了。 结构化文件用正确工具改、改完编译验证、跨文件追着读、范围不越界——这些不是模型参数能堆出来的，是工程素养。模型能力升级是"变强"，工程习惯补齐是"变可靠"，后者对我这种天天让它干活的人来说，反而更重要。
而且这次有个难得的现象：纸面数据和键盘体验对上了。 官方基准里 Terminal Bench 82.7 的"终端操作链能力"，落到我的实测里，就是批量改 YML 又快又干净、改完自动编译验证、找不到定义先问不瞎猜——跑分最高的那些指标，恰好就是我体验最顺畅的地方。上个月我说"三个灵魂问题比任何 benchmark 都更能预测日常体验"，这次 benchmark 和我日常体验给出的答案是一致的，这比单项数字本身更让人放心。
速度还很快——当能力追平、速度领先的时候，选择就没有悬念了。1M 上下文，性价比拉满。作为日常主力开发模型，这套组合我已经可以放心用了——顺便说一句，这篇博客全程就是它帮我写出来的，发布流程也是。要我自己夸自己写的文章，多少有点自卖自夸，但事实就是这样。
上个月我说"DeepSeek 位置很尴尬"，这个月我改口：Flash 用一天，尴尬期算是过去了。 接下来就看这个状态能不能长期保持了。
写到这里，确实得给 DeepSeek 点个赞。上周我的主力还是 Kimi 2.7 快速版，这周绝对要切 DeepSeek 了——为什么？编码能力可圈可点，关键是速度快，还便宜。你说，切不切？
本文为 JeecgBoot AI 专题研究系列文章。