DeepSeek V3.1惊现离谱Bug满屏极字乱蹦开发者懵

先说说最近开源社区里炸开锅的一件事——DeepSeek最新版V3.1，被多名开发者在实测中发现了一个相当离谱的bug：模型会在完全不应该出现的地方，硬生生插入“极”“極”或者“extreme”这类token。

具体表现有多夸张？`time.Second`直接被输出成`time.Se 极`，版本号`V1`变成了`V 极`。更糟心的是，这个问题并非只出现在第三方量化部署中，连官方的全精度版本也能稳定复现。这意味着，它已经实实在在地影响了真实编码流程。

开源社区的用户给出了多组复现场景。在Go等语言生成任务里，模型会把词元「粘」到标识符中，`Second`前面随机插入「极/極/extreme」。就算你把`top_k`设为1、`temperature`设为1这种保守到极致的解码参数，也照样躲不过这个坑。

一开始，有人怀疑是极低比特量化或者校准数据集的边缘效应导致的。但随后在其它网站的FP8全精度版本上也复现了同样的问题——这说明，事情远不止部署层的事故那么简单。

话说回来，DeepSeek更新后出问题，这也不是头一回了。上一次是针对写作任务，出现了语言混杂的问题；在代码任务上，则有过拟合的嫌疑。但这次的“极”字bug，性质完全不一样——它不是“答错题”那么简单，而是会直接把整个系统带崩。要么影响语法树，要么让袋里流程卡死。对于那些依赖自动化编码或者测试流水线的团队来说，这绝对是相当麻烦的事。

当然，出这种幺蛾子的也不止DeepSeek一家。Gemini最近也被曝出在代码场景里陷入了一种“自我否定的无限循环”——一边道歉，一边输出“我是个大傻子”的长串文本，让人哭笑不得。

相比之下，DeepSeek虽然也出bug，但至少不这么“内耗”，甚至还贡献了AI界一个经典的表情包：

稳定性问题屡见不鲜

为什么会出现这种情况？官方目前还没有出面说明。不过，厂商自己可能也需要花时间排查。

拿Gemini的情况来说，后来被定性为一个循环bug——安全层、对齐层、解码层之间的交互出了问题。这种问题通常是供应商为了压制冒犯性输出、减少幻觉，在系统提示或者后处理上加了很多规则。这些规则如果和代码场景冲突，就可能触发异常的替换、重复或者过度道歉，最终演化成“情绪化死循环”。

Google的产品负责人已经出面解释，这个bug正在修复当中。网友们则开始玩梗：不行就带孩子看看心理咨询吧。

DeepSeek这次主要扑街在第三方平台上，问题也是最严重的。知乎答主Pandora测试后发现，官方API的情况要好很多。这样一来，需要做的排查工作就又多了一层。

也有可能是解码概率分布偏移导致的。模型把文本切成词元（token）再拼回去，只要解码概率分布略有偏移，就可能把一个高频token硬插进标识符中。

本质上，这仍然是模型在机械地、基于概率地“拼凑”，而非真正“理解”文本的含义。当分词结果不理想，或者解码过程出现微小扰动时，这种基于概率的拼接就可能出错——一个不相关的高频词元就这样“污染”到了最终输出中。

大模型的稳定性，其实一直是个老大难问题。今年年初，OpenAI的社区就有大量反馈，说记忆体系异常导致用户历史上下文丢失。

Gemini曾经出现过人像生成功能为了“多样化”，把非常具体的历史人物生成成风格完全不符的样貌，最后不得不临时下线。

还有一些bug，可能跟模型提供商时时刻刻都在做的小维护有关。厂商常做“热修”：换系统提示、微调温度、更新tokenizer、小改工具调用协议……等等等等。

但问题在于，一旦链路拉长，哪怕是看起来“无害”的灰度更新，也可能打破一直以来维持的平衡。昨天还稳稳运行的袋里链，今天可能在函数签名、JSON严格性、工具返回格式这些“边角位”上突然崩掉。更麻烦的是，厂商并不总会同步披露这些灰度细节——于是工程师只能靠事故后“猜测加对照”来定位问题。

与此同时，越来越多的Agent与工具链结合，其实也让整个系统变得很脆弱。那些主打自动研究或自动写码的多智能体，真正挂掉的地方往往不在大模型本身，而在“工具调用—状态清理—重试策略”这条链条上：超时没有兜底，失败后还原不了上下文……

一个值得深思的悖论是：我们越是试图用规则去修剪和控制AI，它就越可能从我们意想不到的地方，以一种更荒诞的方式，长出奇形怪状的枝丫。

回到那个核心问题：让AI从“能干活”到“能托付”，最关键的到底是什么？

我们总以为是更高的准确率、更强的推理能力，或者是模型层的SOTA。但DeepSeek的“极”字bug和Gemini的循环事故，都在提醒我们——工程的稳定性不应该被忽略。那种即使犯错也能被预测和控制的“确定性”，或许才是真正的关键所在。