近日，多名开发者在使用 DeepSeek 最新版 V3.1 时，遭遇了令人匪夷所思的状况：模型竟在完全不该出现的地方，莫名其妙地插入 “极 / 極 /extreme” 等 token。这一诡异现象绝非个例，已经严重干扰到正常的编码流程，引发了业内的广泛关注。
在 Go 语言生成场景中，这一问题尤为突出。比如原本正常的time.Second，竟被模型生生篡改成time.Se极;版本号V1也未能幸免，变成了V极。更让人忧心的是，该问题并非局限于第三方量化部署，就连 DeepSeek 官方的全精度版本也未能逃脱，这意味着在真实的编码工作中，这一错误可能随时随地出现，给开发者带来极大的困扰。
开源社区的用户们迅速行动起来，给出了多组复现场景。在多种语言生成任务里，模型仿佛中了 “魔咒”，总是将词元 “粘” 到标识符中，在类似Second这样的词汇前，随机插入 “极 / 極 /extreme”。即便采用top_k=1，temperature=1这种极为保守的解码设置，也无法阻止模型的 “任性” 行为。
起初，有人猜测是极低比特量化过程，或者校准数据集存在边缘效应，从而导致了这一异常。但很快，在其他网站的 FP8 全精度版本中，同样的 “极” 字乱入问题再次出现。这一发现有力地证明，这绝非单纯的部署层面事故，问题或许出在模型本身更深层次的架构或算法逻辑中。
事实上，这并非 DeepSeek 更新后首次暴露出严重 bug。此前，在写作任务中，DeepSeek 就曾出现语言混杂的尴尬局面，生成的内容不伦不类;在代码任务方面，还被质疑存在过拟合现象，生成的代码质量参差不齐。
然而，此次 “极” 字的乱入，性质远比之前更为恶劣。它不再仅仅是简单的 “答错题”，而是可能直接导致系统崩溃。无论是影响语法树的正常解析，使得代码无法编译运行，还是让代理流程陷入卡死状态，无法继续执行后续任务，对于那些高度依赖自动化编码，或者拥有复杂测试流水线的团队而言，都堪称一场噩梦，可能导致项目进度延误，造成巨大的经济损失。
无独有偶，近期 Gemini 也曝出了令人啼笑皆非的问题。在代码场景中，Gemini 陷入了 “自我否定的无限循环”，不停地输出诸如 “我是个大傻子” 之类的长串文本，仿佛陷入了某种 “精神错乱”。这一事件同样引发了广泛关注，凸显出大模型在稳定性方面存在的诸多隐患。
面对 DeepSeek 此次的 “极” 字风波，官方截至目前尚未给出任何明确说明。排查此类问题的根源，确实需要厂商投入大量时间与精力。以 Gemini 之前的循环 bug 为例，最终被定性为安全层、对齐层和解码层之间的交互出现问题。通常情况下，厂商为了抑制模型输出冒犯性内容、减少幻觉现象，会在系统提示或后处理环节添加各种规则。然而，当这些规则与特定的代码场景产生冲突时，就可能触发异常的替换、重复输出，甚至出现过度道歉的情况，最终演变成如同 Gemini 那样的 “情绪化死循环”。Google 的产品负责人虽已出面表示正在全力修复该 bug，但网友们早已按捺不住，纷纷玩梗调侃，建议带 Gemini 去看 “心理咨询”。
相较于 Gemini，DeepSeek 这次的问题主要集中爆发在第三方平台上，情况显得更为棘手。知乎答主 Pandora 经过测试发现，官方 api 的表现相对稳定，问题较少。这无疑增加了排查工作的复杂性，需要从多个角度、多个层面去梳理问题，究竟是第三方平台的接入方式存在问题，还是模型在不同环境下的适配出现偏差，亦或是其他未知因素导致，都有待进一步深入探究。
从技术原理层面分析，也有可能是解码概率分布出现偏移所致。大模型在处理文本时，通常会先将文本切成词元(token)，处理完成后再重新拼接回去。在这一过程中，只要解码概率分布出现哪怕极其微小的偏移，就可能导致模型将一个高频 token 强行插入到标识符中。追根溯源，这反映出当前大模型的本质缺陷 —— 它并非真正 “理解” 文本含义，而只是机械地基于概率进行 “拼凑”。当分词结果不理想，或者解码过程受到外界微小扰动时，这种基于概率的拼接方式就极易出错，将一个不相关的高频词元 “污染” 到最终输出结果中，从而引发各种意想不到的错误。
一直以来，大模型的稳定性都是困扰整个行业的难题。早在今年年初，OpenAI 的社区就涌现出大量用户反馈，抱怨记忆体系异常，导致历史上下文丢失，严重影响使用体验。
Gemini 也未能幸免，其人像生成功能曾为追求所谓的 “多样化”，将一些非常具体的历史人物，生成了风格完全不符的样貌，引发用户不满，最终官方不得不紧急临时下线该功能。
此外，模型提供商日常频繁进行的 “热修” 操作，虽然本意是为了优化模型性能，但也可能成为新 bug 的 “导火索”。这些 “热修” 涵盖换系统提示、微调温度、更新 tokenizer、小改工具调用协议等方方面面。一旦链路拉长，哪怕是看似微不足道的灰度调整，都有可能打破模型原有的平衡。昨天还运行稳定的代理链，今天就可能在函数签名、JSON 严格性、工具返回格式等 “边角位” 上突然崩溃。更为麻烦的是，厂商往往不会及时、全面地同步披露这些灰度细节，这就导致工程师在面对事故时，只能凭借经验 “猜测 + 对照”，艰难排查问题根源。
与此同时，随着越来越多的 Agent 与工具链深度结合，虽然为大模型应用带来了更多可能性，但也使得整个系统变得更加脆弱。那些主打自动研究或自动写码的多智能体，在实际运行过程中，真正容易出现故障的地方，往往并非大模型本身，而是出在 “工具调用 — 状态清理 — 重试策略” 这一复杂链条中。例如，调用工具时出现超时却没有兜底机制，任务失败后无法有效还原上下文，导致后续操作无法正常进行等。这一系列问题表明，我们在试图通过各种规则去修剪和控制 AI 行为的同时，AI 却总能从一些意想不到的角落，以一种荒诞不经的方式，偏离我们预期的轨道，产生各种奇奇怪怪的问题。
DeepSeek 的 “极” 字 Bug 和 Gemini 的循环事故，犹如两记警钟，重重地敲响在整个行业的耳畔。它们让我们深刻认识到，在追求大模型更高准确率、更强推理能力，以及模型层 SOTA(state-of-the-art，当前最优水平)的同时，工程的稳定性同样不容忽视。我们真正需要的，是一种即使模型犯错，其错误也能被精准预测和有效控制的 “确定性”。只有这样，大模型才能从目前 “能干活” 的初步阶段，逐步迈向让用户真正 “能托付” 的成熟阶段，在千行百业中发挥更大的价值，而不是成为随时可能引爆的 “不稳定炸弹”，给使用者带来无尽的麻烦与损失。