一道中学生也能算的题：为什么难住了6个大模型？

故事是这样的。

昨天天我在群里看到，一个群里的朋友想测试当红的kimi k3 max。于是，就问了它 一个看起来简单的问题

risc-v 0x0ffef0b3是什么指令？

群里截图显示kimi给出的结果出人意料，让我大跌眼镜。

我有点不相信。

这么简单的问题，大模型不应该啊。

于是，我就把这条命令分别给了deepseek，智谱 ChatGLM，豆包，gemini，gork，还有chatgpt。

问了一遍之后。

怎么说呢，看到这个结果我是真的有点意外。

我当时的第一个反应是，？？？

机器码反汇编这东西，不就是一个纯种确定性的活儿么。

移位，掩码，查表。

没有任何需要「发挥」和「创作」的空间。

怎么还能错的？

这6个模型翻车的方式，居然各有各的脑回路。

有人位域算错了开始自由发挥，

有人字段都拆对了却不认识扩展指令，

有人连指令格式都搞混了。

每一种翻车方式，都精准地戳在大模型的某个命门上。

我觉得这事挺有意思的，值得好好聊一聊。

先把答案说了吧。

0x0ffef0b3 这条指令，正确反汇编是 czero.nez ra, t4, t6。

它来自 RISC-V 的 Zicond 条件操作扩展。

语义是：如果 rs2 非零，就把 0 写入 rd；否则把 rs1 写入 rd。代入寄存器后，即 t6 ≠ 0 时 ra = 0，t6 = 0 时 ra = t4。

把 32 位机器码拆开，答案已经写在位域里

真正的陷阱在于：opcode=0x33 只说明它使用 OP 类 R-type 外壳，不能据此直接套用 RV32I/RV64I 的 AND/OR 表。必须继续把 funct3 与 funct7 作为组合键，并检查扩展指令集。

Zicond 算是个比较年轻的扩展，RISC-V 在 2022 年左右把它标准化了。

它不属于那堆人人都熟悉的「基础指令」，在参数记忆里刚好落在那个「学过但没完全记住」的灰色地带。

好，下面来看看这6个模型分别是咋翻车的。

我只能说，不同的翻车，各有各的精彩。

第一个是 Kimi K3 Max。

Kimi 其实干得不错。

它正确拆出了 rd=ra、rs1=t4、rs2=t6、funct3=111、funct7=0000111，而且意识到标准 AND 的 funct7 应该是 0000000，所以不可能是 AND。

然后它说，这个组合不属于常见扩展，所以是非法指令。

就差一步啊朋友们。Zicond 就在那。但它没检索到，于是把一条标准的扩展指令判成了非法。并且它没有就此打住，还进一步猜测可能是数据污染、字节序问题、厂商自定义。开始编故障叙事了。

这就是第一种典型失败，位域拆对了，扩展知识没覆盖到，然后用猜测填补了空白。

第二个是 DeepSeek。

DeepSeek 的翻车方式是我觉得最「危险」的一种。

它给出了 andn x22, x30, x31。

但正确值应该是 rd=x1、rs1=x29。所有的寄存器编号都不对。

错误发生在最基础的位提取阶段，就是从十六进制数里读二进制位的时候就错了。

然后离谱的是，它接下来把错误结果归入了 Zbb 扩展，还给它配了完整的指令语义、使用场景、注意事项。

读起来极其专业，极其流畅。你如果不是拿着规范逐字对，根本发现不了底层的字段全错了。

你想想看，如果是一个刚入门的工程师，拿到这个答案他根本不会怀疑。

这就是第二种典型失败，先算错，再自洽。

解释能力成了幻觉的放大器。

第三个是智谱 ChatGLM。

这个属于最基础的错误，但也是最离谱的。

ChatGLM 先说是 and，然后把它按 I-type 格式拆了。I-type 的格式是 imm[11:0]、rs1、funct3、rd、opcode。给出的 opcode 是 0x23。但最低7位明明是 0x33。

这就像你把一个卡车底盘认成了轿车底盘，后面的分析就全没意义了。

这是第三种典型失败，连指令格式都选错了，结构识别完全失准。

第四个是豆包。

豆包其实拆得挺准的，funct7=0x07、rs2=x31、rs1=x29、funct3=7、rd=x1、opcode=0x33。然后它正确排除了基础 AND、M 扩展和若干位操作编码。

但它没命中 Zicond。结论是厂商自定义或数据异常。

和 Kimi 一样，解码正确但知识不够。

但我想说，这种「我无法确认所以不乱猜」的克制，在态度上比那些瞎编一个指令的要好。虽然从结果来说都是错，但这个错法至少是诚实的。

第五个是 Gemini。

Gemini 在字段读取阶段就出错了。rs2 被读成 x15、funct3 被读成 110。跟原始机器码对不上。

不过它没有凭空捏造一条具体的指令，而是保留了一个「自定义或非法」的模糊结论。这种做法虽然没答对，但至少没有编造一个听起来很真但其实全错的答案。

只能说位域读错让后续一切判断都没有了可靠基础。

第六个是 Grok。

Grok 在这儿的表现特别有意思。

它正确地提取了 rd=x1、rs1=x29、rs2=x31、funct3=111、funct7=0000111。字段没错。

然后它说这是 or x1, x29, x31。

但是，OR 的 funct3 应该是 110，不是 111。基础 OR 的 funct7 应该是 0000000，不是 0000111。

它自己列出来的字段就已经把 OR 给排除了。它等于一边列出了「不是 OR」的证据，一边给出了「是 OR」的结论。

这是典型的「证据与结论脱节」。说真的，这种错误比单纯的「不知道」更值得警惕。模型在看到 funct3=111 和熟悉的 OP 类 opcode 后，联想到了 OR，然后硬是让文字去迎合这个猜测，哪怕自己刚写的字段数据已经把这个猜测推翻了。

这6个模型的翻车方式，可以归纳成三个明显的层次。

最底层是「字段读取错误」，DeepSeek、ChatGLM、Gemini 都在这个层面出问题了，连二进制位都数不对，后面的分析全是空中楼阁。

再往上一层是「字段读对了但知识覆盖不足」，Kimi 和豆包都拆对了位域，排除了标准指令，但认不出 Zicond。这不是算数的问题，是知识边界的问题。

最上面一层是「知识有但证据与结论脱节」，Grok 就是典型，字段数据已经排除了 OR，但还是给出了 OR 的结论。

唯一全部通过的是 ChatGPT。它给出了 czero.nez ra, t4, t6，字段全对，扩展归属清晰，语义准确。还额外提醒了处理器和工具链需要支持 Zicond。

但我坦率的讲，如果只看「谁答对了」，这事就只值一条推文。

真正有意思的，是这些翻车方式暴露出来的四个结构性问题。

第一个问题，模型会把十六进制当成文字模式匹配题。

机器码解码应该是个确定性计算，移位、掩码、查表。

但语言模型在干的，更像是文字接龙。

看到 0x33 这个熟悉的 opcode，就联想到 AND、OR，然后让后续的文字去迎合这个联想。

它不是不会算，它是压根没走「算」那条路。

它走的是「觉得像什么就说什么」。

这在很多场景下都好使，因为模式匹配覆盖了大部分常见情况。但一旦遇到需要精确计算的场景，这个机制就崩了。

第二个问题，能切字段，不等于认识扩展。

Kimi、豆包、Grok 其实都拿到了正确的位域。

他们缺的不是算数能力，是 Zicond 这个知识。

长尾扩展指令集、不同版本的规范差异、工具链支持状态，这些恰好就是参数记忆最容易模糊的区域。

大模型的知识压缩方式决定了它不可能记住所有长尾知识。

这是一个底层限制，不是靠「扩大训练数据」能解决的问题。

第三个问题，解释能力会放大幻觉的可信度。

这个我觉得是最危险的。

DeepSeek 的输出读起来非常专业。它给出了完整的指令格式拆解、扩展归属分析、备选方案、使用场景。看起来滴水不漏。你如果不是拿着 RISC-V 规范逐字核对，你根本不知道它从头到尾全错了。

这就产生了一个可怕的效应。一个刚入门的开发者，去问大模型一个机器码问题。大模型给了个「非常专业」的回答，而且是很详细、很权威的语气。这个人会直接把这个答案当真理，拿去用、去学、去教别人。

这不是假设。这就是正在发生的事情。

第四个问题，模型缺少自动一致性检查。

Grok 已经写出了 funct3=111，但结论却是 OR 的 funct3=110。ChatGLM 写出了 opcode=0x33，却按 I-type 去切字段。

任何一个有基础编程能力的开发者，看到这种矛盾都会立刻停下来，「等等，我这个字段和结论对不上」。

但模型没这个机制。

它不会回头检查自己说了什么。

生成就是终点。

这种事后验证的能力，在当前的架构下是完全缺失的。

说真的，写到这里我自己也有一些感慨。

这两年大模型的发展太快了，快到我们已经开始默认它们什么都能干。

写代码、写文章、做翻译、画图、算数学题。

在很多领域里，它们的表现确实惊艳。

但这次翻车击中了一个让我挺在意的问题，我们是不是对模型的能力边界越来越模糊了？

机器码反汇编是一个极端的测试用例。它没有任何模糊空间，对就是对错就是错。

这正是大模型最不擅长的那种任务。

它不是一个「语言问题」，它是一个「计算问题」。

语言模型的核心能力是在高维空间里做语义相似度匹配，不是按规范执行确定性的位运算。

但这并不意味着大模型在这种问题上就完全不能用。我觉得关键是要转变使用方式。

不是让模型直接给答案，而是让模型输出一条可审计的证据链。

在这类问题上，最有效的做法是要求模型按步骤输出，先把十六进制补齐32位、逐字段给出位段和二进制值、先由 opcode 确定格式再解析、用 funct7+funct3+opcode 的组合键去查表、把候选助记符反向编码验证。

每一步都展开放出来，人工扫一眼就能发现有没有问题。

这个模板的本质，是把大模型从一个「答案生成器」变成一个「带过程的工作台」。

它的流畅表述仍然是优势，但每一步的结果你都可以独立复核。

让我想起了《三体》里的一个概念，黑暗森林。

不是那个猜疑链的黑暗森林。

是宇宙里的文明交流，你收到一条信息，你永远无法确认它是不是真的，因为发出者的思维过程对你是不透明的。

你只能通过验证它的输出来间接推断。

大模型某种程度上也是这样。

你输入一个机器码，它给你一段文字。

你不知道它有没有真的「算了」还是「猜了」。

它的思维过程对你完全不透明。

你唯一能做的，就是拿到它的输出之后自己验证一遍。