DeepSeek V4 编程实测：等得够久，但这次确实有东西

一句话结论：DeepSeek V4 等得的确久，但从编程表现来看，这次基本配得上这段等待。

DeepSeek 一直不是突然才开始做代码模型的。

早在 V2 阶段，它就单独推出过 V2 Coder。后来到了 V2.5，代码能力逐渐并入主线模型。也就是说，DeepSeek 在编程方向上的积累实则很早，只是过去一段时间，大家更多关注的是它的通用推理、价格和开源影响力。
在 V3.2 之前，DeepSeek 的代码基本功一直很稳。尤其在一些偏传统的代码生成榜单里，它的一遍通过率在国产模型里超级靠前。问题出目前 Agent 时代之后。

目前的编程任务已经不只是“写一段函数”或者“补一个接口”了，而是要读项目、理解结构、跨文件修改、跑测试、定位 Bug，甚至连续多轮叠加需求。到了这种复杂工程环境里，V3.2 的优势就没有以前那么明显了。

所以这次 V4 出来之后，真正值得看的不是它会不会写代码，而是它能不能适应目前这种更接近真实开发的 Agent 工况。

Flash 更像是高速、低价、响应快的实用型模型，体量接近主流中小尺寸模型，适合日常任务和中低难度开发。Pro 则是主打上限的版本，规模更大，推理能力也更强，明显是冲着复杂工程任务来的。
从工程编码测试结果看，V4 Pro 的表现基本重新坐回了国产代码模型第一梯队的位置。尤其在 max 档位下，整体表现已经能够压过上一轮表现很强的 GLM-5.1，并且和 Opus 这类顶级模型之间的距离也被明显拉近。
更难得的是，V4 Pro 在 high 档位下也能完整跑完 4 个工程任务。这说明它不是只靠最高档硬堆出来的成绩，正常高推理档位已经有比较强的可用性。

我觉得 V4 Pro 在编程上最明显的优势，主要有三个。

第一个是知识覆盖很广。

这次测试里的几个工程，尤其是 C 和 F，并不是单纯考算法或者普通 Web 开发。里面涉及一些比较细的工程知识和平台细节。如果模型知识面不够，许多 Bug 看起来很小，但就是定位不到。
列如 macOS 程序里 storyboard 配置不对，窗口就可能无法正常显示。再列如某个项目里 Canvas 配置有问题，导致渲染失败。对于这类问题，V4 Pro 的反应很快，基本不是靠猜，而是能直接往正确方向定位。
这一点和 GPT、Opus 这类模型的体验有些接近：它知道许多不那么热门的工程细节，所以遇到边缘问题时，不会轻易卡死。
Flash 在常见知识上和 Pro 差距没有想象中大，普通开发任务它也能覆盖。但如果问题比较偏、Bug 比较绕，Flash 就更容易出现“看起来在修，实则没抓住根因”的情况。

第二个优势是长上下文下的稳定性。

目前许多工程测试不是单轮完成，而是一轮一轮叠功能。越到后面，模型越需要重新理解整个项目，找出所有相关文件和历史修改点。
这件事对 GPT、Opus 来说比较自然，但对许多国产模型来说实则是门槛。由于上下文一长，就容易幻觉、漏文件、误判旧逻辑，甚至改着改着把前面做好的功能破坏掉。
V4 Pro 和 Flash 在 high、max 档位上的表现都比预期稳。尤其是 Pro，到了后几轮再做全局修改时，依旧能比较准确地回到项目结构里，不太容易凭空编造不存在的逻辑。
这对真实开发很重大。由于实际项目里，最怕的不是模型写不出代码，而是它自信地改错地方。

第三个优势是编码流程比较规矩。

V4 Pro 在一轮任务里，一般会先读项目、整理思路，再聚焦修改代码，最后做自测。它不像一些模型那样，边写边想，写到一半又推翻设计，测试没跑完又去改别的地方。这种编码纪律感很重大。
许多低级 Bug 实则不是模型能力不够，而是流程混乱导致的。V4 Pro 这次在这方面控制得不错，所以明显减少了那种“看起来很离谱”的错误。

当然，V4 也不是没有问题。

它最大的问题之一，是复杂任务里偶尔会注意力失焦。
当项目比较大、要求比较多时，V4 Pro 在 high 档位下有时会漏掉某些实现细节。不是不会做，而是注意力分配不够稳，某些需求被它跳过去了。
好在这类问题一般不是硬伤。只要提醒它补一轮，再让它自测一次，基本都能修回来。到了 max 档位，这种漏细节的概率会明显下降，复杂功能一遍过的机会也更高。
但要说完全解决，也还没有。即便 max 档位下，偶尔还是会出现一些小遗漏。
和 Codex、Opus 这类一线 coding agent 相比，差距也主要体目前这里。顶级模型一般也会犯错，但更少出现这种随机漏需求的问题。它们更多是某个边角场景思考不够，而不是明显丢掉一块实现。

另一个短板是 Bug 定位方法论还可以更强。

V4 Pro 有知识，也有推理能力，但遇到特别生僻的 Bug 时，它一开始未必会马上采用最好的排查路径。有些场景还是需要人工提醒它加日志、缩小范围、做对照测试。提醒之后它能跟上，但主动性还不算顶级。架构和 UI 也是老问题。
V4 的代码架构总体是能用的，该有的分层、解耦、模块组织基本都会思考，不会糊弄。但它不太追求那种超级美丽、超级讲究的工程设计。
如果你看 Opus 写复杂项目，有时候会觉得它的结构是“老工程师手感”，命名、边界、抽象层次都比较舒服。V4 Pro 则更偏实用主义：能拆，能跑，能维护，但不必定优雅。

UI 方面也类似。

它不是不能做界面，但直出的审美和细节不算强。大多数时候是“基本可用”，偶尔能出一点不错的细节，但整体离真正高级的产品页面还有距离。如果有设计稿配合，它问题不大；如果完全靠 vibe coding，让它自由发挥，那就需要多抽几轮。

综合来看，V4 Pro 的 high 和 max 档位都已经有很高的实用价值。

high 适合大多数中等复杂度任务，速度和成本比较平衡。max 更适合复杂工程、长上下文、多轮开发、疑难 Bug 定位这类场景。
比较有意思的是，max 的成本并没有比 high 高特别多。平均输出量差不多，但它会读更多文件、调用更多工具、检查得更深。代价主要不是钱，而是时间。复杂任务下，max 最多可能多花 60% 左右的工具调用和阅读深度，但换来的是更高的一遍成功率。

Flash 的定位也很清楚。

它在中低难度 oneshot 编程任务上，和 Pro high 的差距没有想象中大。写小功能、改普通 Bug、做常规脚本，Flash 完全有可用性。
但一旦任务复杂起来，Flash 的随机性就会明显变大。同样的提示词，它可能一次写得很好，也可能连续几轮都修不好。这个问题不只 DeepSeek Flash 有，许多小尺寸模型都会这样：上限不低，但稳定性不够。
另外，Flash 的 Token 消耗反而可能比 Pro 更高。不过思考到它的单价、速度和吞吐能力，整体性价比依然不错。