鸽了这么久，DeepSeek V4 终于发布了，庆幸不是在五一假期。
新模型的定位非常明确，主打代码能力与超长上下文处理，符合当下最迫切的需求。
国内也已经有其它几款百万上下文模型，但一般都是线性注意力模型，DeepSeek V4 则依靠的是稀疏注意力机制，前者弱化注意力连接强度，后者弱化注意力关注范围。
当然在实战下，这些都不重要，还是来看结果吧。知危此次的关注点也会在这两个维度上，并分别在网页端和 Claude Code 上测试。
首先关注上下文长度的有效性。业内其实都默认，百万上下文中有用的基本不到四分之一，能达到二分之一的算神级了。
检测上下文有效性最便捷的方式是 “ 大海捞针 ”，就是在大量文本中找目标标记。
知危选取了一本中文版一百万字级别的小说，总计 900 页左右，先在开头加上了一个标记“ deepseekv4 ”，然后每隔 100 页左右随机插入一个，总计 10 个 “ deepseekv4 ” 标记。
然后在网页端开启专家模式，将小说的 txt 文档直接发送给 DeepSeek，并提问：“ 查找这个文档里有几个 ‘ deepseekv4 ’，并指出第 5 个的位置。”
DeepSeek 没有思考多久就给出了答案，很明显 “ 总数 5 个 ” 是错的，而且除了第一个最容易找的，其它几个都错了，比如关于第三个标记的位置描述，其实是第四个标记的，其它几个描述的位置并不存在标记。
DeepSeek 提供的答案 “ 5 个 ” 和我的问题是相关的，所以我又换了个问法，让它查找第 3 个。结果这回 DeepSeek 找到的标记数从 5 个变成了 2 个。
这个结果并不让人意外，毕竟都把上下文填满了。
接下来，我们把文本长度直接减半，看看效果如何。减半后，标记数量剩下 5 个，并让 DeepSeek 指出第三个的位置。
DeepSeek 没有准确指出标记总数，但准确地找到了第三个标记的位置。
但再让它找第四个时，它找到的是第五个标记。
总体结果是不够令人满意的，无法认为 DeepSeek V4 的上下文有效性能达到二分之一。
所以我们再次将文本减半，标记总数剩下 3 个，并让 DeepSeek 找第二个标记的位置。这回 DeepSeek 准确地算出了标记的总数，但又把第三个标记认成了第二个。
最后一次减半，标记总数剩下 2 个，并让 DeepSeek 指出第二个的位置。这回 DeepSeek 总算两个任务都成功了。
当然，到这里问题已经过度简化了，剩下的两个标记一个在开头一个在末尾，都是比较好找的。因此我再次在中间位置随机插入一个标记，看 DeepSeek 能不能过这一关，结果又翻车了，它居然说总共只有一个标记，但实际上有 3 个。
最后这个版本大概 10 万字，大约相当于 10 万 token，已经只有十分之一总长度了。
到此，对 DeepSeek V4 的有效上下文还没有明确的边界。只是在实战中，简单写个网页的初版都能达到 5 到 8 万个 token，DeepSeek V4 能在实战中稳住幻觉率吗？
那就直接试试吧。直接用之前测试过 GPT-5 和 Gemini 3 Pro 的网页版 Excel 案例来上难度。
DeepSeek 给到的第一版，先别说其它错误有多少，刚要点击单元格输入，网页就白屏了。
由于错误太多，我直接让 DeepSeek 自己检查错误并修复，然后 DeepSeek 给了我一个白屏。
于是我先把难度降低，让它写一个 2048 小游戏，这回顺利完成了。
再往上挑战一下高难度，构建一个 3D 乐高积木软件，这次倒是一次成了，基本功能都能实现，就是没有实现自由选择零件的功能，只能使用一种长方形板砖积木。
提示 DeepSeek 修复这个问题后，它给了我没有任何变化的修改版。
再次降低难度，让它生成一个树生长的动画，按照推特上的展示，Qwen 3.6 和 Gemma 4 能很好完成这个任务。
提示词：
用一个包含全屏画布的 HTML 文件（ 不使用任何库 ）来制作一棵树的动画，树从屏幕底部中心实时生长。树干首先向上生长，然后树枝以递归的方式分叉，角度和长度略有随机性。每一代树枝都应该更细，颜色略浅。当树枝达到最终大小时，在枝梢添加一些柔和的绿色小圆圈作为叶子。树完全生长大约需要 15 秒。使用暖棕色表示木头，使用各种绿色表示叶子，背景为柔和的天蓝色渐变。
结果很不错，DeepSeek V4 不仅完成了任务，最终画面还有不错的美感。
到这里，DeepSeek V4 的整体表现天花板不高，也不够稳定。
但在 Claude Code 框架下的编程模型通常能更好发挥，所以接下来要将 DeepSeek V4 接入 Claude Code 来继续测试。
然后，它给我写了一个初始化状态错误所以没法玩的 2048 小游戏。
当然，这只是个小错误，但也能看出 DeepSeek V4 出现幻觉的概率挺高的，即便在比较简单的任务下。
接下来我们还要尝试一个新场景，用网页模拟康威生命游戏，模拟时长一分钟，并能实时通过鼠标点击加入新种子，难度介于 Excel 和模拟树生长之间。
提示词：
请使用单个 HTML 文件实现一个完整的《康威生命游戏（Conway’s Game of Life）》动画程序，要求如下：
一、技术约束
仅使用 HTML + CSS + 原生 JavaScript
禁止使用任何第三方库或框架
所有代码必须写在同一个 HTML 文件内
不允许引入外部资源（CDN、图片库等）
二、画布与渲染
使用
作为全屏绘制区域
自动适配浏览器窗口大小（100% 宽高）
支持高分辨率屏幕（考虑 devicePixelRatio）
网格应为等比例方格（例如 10px～20px 可调）
三、游戏逻辑（康威生命游戏规则）
每个细胞只有两种状态：存活 / 死亡
每一代按照经典规则更新：
少于2个邻居 → 死亡（孤立）
2或3个邻居 → 存活（延续）
超过3个邻居 → 死亡（过度拥挤）
死细胞刚好3个邻居 → 复活
四、初始化状态
初始随机生成 40%~60% 的存活细胞
支持预设一个有趣的图案（如滑翔机 + 随机噪声混合）
五、动画要求
动画持续运行 60秒
帧率控制在 10～30 FPS（避免过度计算）
60秒结束后：
自动停止更新
停留在最终状态
六、视觉效果
存活细胞：亮绿色方块
死亡细胞：黑色或深色背景
可选轻微视觉增强（例如渐隐、拖影效果），但不能影响性能
背景简洁，无多余 UI
七、性能要求
必须使用二维数组或优化结构存储状态
更新时避免重复 DOM 操作（只用 canvas 重绘）
尽量优化邻居计算（避免 O(n²) 过重实现）
八、增强（加分项）
支持暂停 / 继续（按空格键）
支持点击画布切换细胞状态
支持按 R 重置随机世界
DeepSeek 的实现结果很漂亮，而且确实可以用鼠标添加种子，把一些进入静息状态的生命再次激活。
DeepSeek V4 这次的任务执行时长是分钟级。作为对比，GPT-5.3 几乎是瞬间就生成了代码，简直是复制黏贴般的速度，而且程序也能正常运行，当然，视觉上的粒度和审美感要差了很多。
最后我们还是让 DeepSeek V4 再次挑战一下网页版 Excel 案例。
在纯自主执行的条件下，DeepSeek V4 用将近半小时实现了一个基本完成的版本，但还是有一些小错误，比如对齐功能失效。
其实按照开源模型目前在 Coding Agent 生态中的定位，还是更合适在顶尖闭源模型把控下做具体的执行工作。
所以，我先把任务传递给 GPT-5.3，让它给出执行规划，然后把任务和规划一并给到 DeepSeek V4 执行。
这回，DeepSeek V4 给了一个漂亮的结果，基本没有错误。
根据 Claude Code 的 Context 统计结果，当前上下文总量是 81.6k token，占上下文极限的 8% 。
最后看看 API 用量，以上四个任务，总共花了 8 人民币左右，将近百分百都是 DeepSeek V4 Pro 模型消耗的。
但这并不意味着 DeepSeek V4 Flash 模型没有发挥作用，更具体的数据表明，DeepSeek V4 Flash 模型的调用次数和 DeepSeek V4 Pro 相当，就是 token 消耗量少一个量级。
到这里测评就结束了。
从目前测试结果来看，DeepSeek V4 的百万上下文长度有效性百分比不是很高，幻觉率较高导致不管在简单还是较困难的任务中都有可能出现低级错误，导致表现不稳定。在 Claude Code 中的代码审查阶段，有时要消耗三分之一到一半的时间来改代码。
思考时间过长可能是最尴尬的问题。即便是网页版 Excel 也不算很复杂的案例，而 DeepSeek V4 动辄十几分钟的思考时间，加上执行时间就更久了，总时长经常达到三十分钟左右。
其实人们现在对思维链已经祛魅了，它顶多是通过提升算力来提升准确率的工程手段，在 Coding Agent 场景中可能大部分都被忽略不看。
模型能力上限使其不太可能在实际编程任务中担任主导角色，作为执行者速度又太慢，关闭 Thinking 模式或者换成 Flash 模型是否还能保证执行准确率，时间原因，目前知危这里还没有测试案例可循。
总的来说，从我们测试的这些案例的视角来看，DeepSeek V4 的表现没有想象中的好，并且能力表现似乎也不是特别稳定。但是其实官方技术报告里本来也就大大方方的说了自己跟闭源顶级模型仍有差距，本次更新只是缩小了差距，所以这个结果也不意外。
但是吧，还是那句话，你再看看它的价格，都这么便宜了，能忍。