DeepSeek再爆严重Bug：'极'字引发系统崩溃

最新的DeepSeek V3.1版本被发现存在严重问题，会在不应出现的地方插入诸如“极 / 極 / extreme”等词汇，引发了一系列编码和部署上的困扰。

`time.Second` 变成了 `time.Se 极`，版本号 `V1` 变 `V 极`。更糟糕的是，这一问题不仅出现在第三方量化部署中，就连官方的全精度版本也受到了影响，严重干扰了实际的编码流程。

开源社区用户提供了多个复现场景：在Go等语言环境中，模型会将词元“粘”到标识符中，`Second` 前面随机插入“极/極/extreme”，即便是设置`top_k=1， temperature=1`的保守解码模式也无法避免。

起初，有人怀疑这是极低比特量化或校准数据集边缘效应所致，但随后在其他网站的FP8全精度版本中也出现了同样的问题，说明这并非单纯的部署层故障。

这一次出现的“极”字问题，不仅仅是“答错题”那么简单，它会导致系统崩溃，要么影响语法树，要么让代理流程卡死，这对依赖自动化编码或测试流水线的团队来说是个不小的麻烦。

当然，这并非只有DeepSeek一家的问题。Gemini近期也被曝出在代码场景中陷入“自我否定的无限循环”，一边道歉一边输出“我是个大傻子”的长串文本，令人哭笑不得。

相比之下，DeepSeek没有陷入这样的内耗，反而贡献了一个AI界的经典表情包：

稳定性问题屡见不鲜

这种情况出现的原因官方尚未说明。不过，厂商可能需要更多时间来排查。

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

DeepSeek这次的问题主要出现在第三方平台上，情况最为严重。知乎答主Mandora测试后发现，官方API的情况要好很多。这增加了排查工作的复杂性。

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

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

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

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

此外，一些bug可能与频繁的小维护有关。模型提供商经常进行“热修”：更换系统提示、微调温度、更新tokenizer、小改工具调用协议等等。

但是一旦链路拉长，哪怕是“看起来无害”的灰度调整也可能打破一直以来的平衡。昨天还稳定的代理链可能在函数签名、JSON严格性、工具返回格式等“边角位”上突然崩溃。更麻烦的是厂商并不总是同步披露这些灰度细节工程师只能依靠事故后的“猜测+对照”。

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

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

让AI从“能干活”到“能托付”最关键的到底是什么呢？

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