很多人都发现，明明连复杂编程题都能解的 ChatGPT 或 DeepSeek，遇到 24 点这种看起来像小学数学的游戏却经常翻车。这背后的关键并不是算力不够，而是大语言模型（LLM）的底层结构在处理这类组合搜索任务时，遇到了一道迈不过去的坎：它的推理深度是固定的，而且没有“撤回键”。
为什么 Transformer 天生就不擅长 24 点
24 点游戏表面简单，实则需要在一个不大的解空间里完成多步试探。标准的 4 个数、四则运算配合括号，总表达式数量其实只有几万个，但对 LLM 来说，逐个试错恰恰是它的短板。
核心问题出在 Transformer 架构的计算方式上。在配备标准注意力的实现中，它属于电路复杂度类 TC⁰，意味着无论输入多长，模型内部完成一次前向计算的电路深度都是一个常数。换句话说，它没有循环结构，不能像编程语言那样根据需要动态增加推理步数来进行深度优先搜索（DFS）或回溯。而 24 点的括号嵌套会破坏自然的运算顺序，必须先算括号内再算外侧，这本质上是一串多层组合逻辑，要求计算步骤随括号深度线性增长。模型只能用有限的固定深度去“拟合”这种线性深度需求，一旦表达式所需步骤超出模型能力边界，就会出错，哪怕参数再大也无济于事。
自回归生成的单向性又雪上加霜。LLM 都是从左往右一个 token 一个 token 地输出，当它生成到一半发现前面选的运算符和括号导致最终结果不等于 24 时，无法回头修改——就像已经说出口的话不能收回。人类解题时可以草稿、撤销、再重试分支，但在 Transformer 的生成过程中，这种“尝试－验证－回溯”的循环是不存在的，一次输出就是最终答案。
另外还有一个容易被忽视的现实：虽然 24 点的有效组合就 1820 种，有解的约占四分之三，但几乎没有人会把自己的游戏过程详细记录下来并上传到互联网。互联网上的相关语料极度稀疏，使得模型想靠“死记硬背”来过拟合这些题目也行不通。于是，“背不了”叠加“推不动”，表现糟糕就顺理成章了。
这告诉我们什么
这一现象不单是 24 点这一个玩具问题，它折射出 LLM 在处理需要精确组合搜索、多步验证和回溯调整的任务时普遍存在的结构性短板。像数学证明、复杂的多步推理、需要枚举可能性的规划问题，如果脱离外部工具而完全靠模型“裸算”，都可能遭遇同样的天花板。
对于普通使用者来说，更实际的启示是：遇到这类问题，不必强求模型直接给出最终结果，而可以让模型生成 Python 代码，利用外部执行器来完成遍历和验证。这样做，才是对架构缺陷最务实的补救，也让我们更清楚地看见当下 AI 的能力边界。
编注：信源为知乎问答，主要引述了 LLM 架构局限与组合搜索的解释，未涉及具体模型的横向评测数据。