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

来，先讲个有意思的事儿。

昨天在群里，有朋友拿一道题去测刚出的Kimi K3 Max。问题很简单，就问一句：RISC-V的0x0ffef0b3是什么指令？群里截图上Kimi给的答案，老实说，让人大跌眼镜。

坦白说，看到这个结果，第一反应是——不可能吧？机器码反汇编，这活儿不是纯纯的确定性计算吗？移位、掩码、查表，一步到位，没有任何需要“发挥”和“创作”的空间。怎么能错成这样？

更让人意外的是，这6个模型翻车的方式，居然各有各的脑回路。有人位域算错了就开始自由发挥，有人字段都拆对了却不认识扩展指令，还有人连指令格式都搞混了。每一种翻车方式，都精准地戳在大模型的某个命门上。

先把答案说了。

0x0ffef0b3这条指令，正确反汇编是

。它来自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。

但坦率地说，如果只看“谁答对了”，这事就只值一条推文。

模型	位域提取	指令名	校验意识	本次评价
ChatGPT	正确	正确	较强	最佳：结论与证据闭环
豆包	正确	未识别	较强	谨慎但漏掉Zicond
Kimi	正确	误判非法	较强	排除法好，知识缺口大
Grok	正确	误判OR	较弱	字段与结论互相矛盾
Gemini	多处错误	未识别	一般	保守，但底层解码不可靠
DeepSeek	多处错误	误判ANDN	较弱	错误答案被完整解释包装
智谱	格式错误	误判AND	较弱	从指令格式开始就走错

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

机器码解码应该是个确定性计算，移位、掩码、查表。但语言模型在干的，更像是文字接龙。看到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的组合键去查表，把候选助记符反向编码验证。每一步都展开放出来，人工扫一眼就能发现有没有问题。

这个模板的本质，是把大模型从一个“答案生成器”变成一个“带过程的工作台”。它的流畅表述仍然是优势，但每一步的结果你都可以独立复核。

这让人想起《三体》里的一个概念，黑暗森林。不是那个猜疑链的黑暗森林，是宇宙里的文明交流——你收到一条信息，你永远无法确认它是不是真的，因为发出者的思维过程对你是不透明的。你只能通过验证它的输出来间接推断。大模型某种程度上也是这样。你输入一个机器码，它给你一段文字。你不知道它有没有真的“算了”还是“猜了”。它的思维过程对你完全不透明。你唯一能做的，就是拿到它的输出之后自己验证一遍。