让 AI 做 XOR？不如让它写代码

让 AI 做 XOR？不如让它写代码

一次关于模型能力边界与成本控制的复盘

事情的起因平淡得可笑。

我需要给两段字节数据做 XOR 运算。在 CPU 眼里，这是一个时钟周期就能搞定的操作。我随手把它扔给了大模型——毕竟连“帮我写个请假条”都能干得漂亮，算个 XOR 能有什么问题？

结果它错了。

不是差一点点的那种错。0x64 被算成 0x6A，每一个字节都像是在随机输出一个“看起来合理”的十六进制数。更离谱的是，当我让它重算时，它开始“自我纠正”——但纠正的起点已经是错的。越纠越错，最后陷入一个死循环：反复输出同一串错误结果，像卡住的唱片机。

那一刻我意识到，我犯了一个根本性的错误：我在让一个语言模型去做 CPU 的工作。

模型为什么会陷入循环？

要理解这个问题，得先想清楚大语言模型的本质。

它不是在想，它在“猜”。每一步的输出，都是对“下一个 token 最可能是什么”的预测。然后这个 token 会成为下一步的输入上下文。自回归生成，步步为营。

这个机制在日常对话中运转良好，但在计算任务中会暴露出致命缺陷：

一旦中间某步算错，后续所有推理都建立在错误基础上。 模型感知到不对劲后试图修正，但修正时看到的上下文已经被污染了。于是它陷入一个怪圈——输出错误，基于错误修正，修正结果还是错，再修正，再错。

更雪上加霜的是注意力机制的“吸力效应”。当上下文中出现重复模式，模型会天然倾向于延续这个模式。换句话说，上下文里到处都是同一个错误结果，模型就“觉得”自己答对了，越陷越深。

最可怕的是什么？没有监控限制的情况下，它会一直尝试“纠正”自己。你丢了个需求去干别的事，十分钟后回来发现对话跑了上千轮，账单上的数字让你怀疑自己是不是看错了。

而且还有一层隐形损失：错误累积导致每次重试的上下文都微妙不同，KV Cache 无法复用。每一组 prompt 都是冷启动，缓存命中率趋近于零——这意味着你不仅要为错误付费，还要为“重复犯同样的错误”多付几倍的钱。

就算不循环，正确输入也经常算不对

你可能会说：那我不让它循环就是了。单次请求，给干净输入，能算对吗？

答案是：碰运气。

根本原因很简单：模型里没有 ALU。

CPU 计算 XOR，靠的是硬件电路逐 bit 完成异或门操作。而模型做的是——“下一个十六进制数字最可能是什么”。一个字节的 XOR 需要 8 次独立的 bit 级判断，每一步的输入都取决于原始数据的对应 bit。这对顺序生成 token 的模型来说极其困难，它无法并行处理 8 个独立的逻辑判断。

再加上 tokenization 的干扰。你以为模型在逐 nibble 处理，实际上 "0x3A" 可能被当作一个完整 token，模型根本没有“进入”bit 层面的机会。

对比一下就很清楚了：问 0xFF XOR 0x00，模型大概率答对。为什么？因为“最大值和零”是训练数据中的强模式，模型见过无数次。但换成 0xB7 XOR 0x4D，基本靠猜。没有任何统计规律可循，模型本质上是在回忆训练数据，而不是在计算。

教训与对策

这件事之后，我给自己定了三条规则。

第一条：永远不让模型“心算”字节级操作。

需要 XOR？让它写代码。让真正的 ALU 去算。

python

def xor_bytes(a: bytes, b: bytes) -> bytes:
    length = min(len(a), len(b))
    return bytes(x ^ y for x, y in zip(a[:length], b[:length]))

a = bytes.fromhex("3A")
b = bytes.fromhex("5E")
print(xor_bytes(a, b).hex().upper())  # 64 ✓

模型负责生成正确的逻辑，Python 的 ^ 负责执行计算。各司其职，错误率直接归零。

第二条：给模型设护栏。

• 限制最大轮数，超过强制终止
• 监控 Token 消耗，超阈值自动报警
• 不要给模型“自我纠正”的机会——单轮请求一次性给全上下文

第三条：建立成本意识。

每次涉及数值运算的需求，先问自己：如果这个任务跑了 500 轮我能接受吗？

如果不能，就让它生成代码而不是直接算。一次循环可能跑 10 分钟烧掉上万 token，一段 Python 脚本 10 毫秒跑完。这不是技术问题，这是成本管理的基本功。

总结

回顾这次踩坑，三件事值得记住：

• 模型陷入循环：根因是自回归生成 + 注意力机制的自我强化 → 解法是限制轮数
• 正确输入也算错：根因是没有 ALU + tokenization 破坏 bit 结构 → 解法是生成代码执行
• 缓存不命中导致成本飙升：根因是错误累积使上下文变化、KV Cache 失效 → 解法是监控加硬限制

大模型是强大的语言机器，但不是计算机器。它可以帮你写出几乎任何语言的代码，但不应该被要求做 CPU 的工作。

认清这个边界，善用它的长处，设好护栏。这既是技术问题，也是钱的问题。

最后那句话值得再写一遍：

别让它心算，让它写代码，让 ALU 去算。