LLMs Can't Jump，直译过来是“大语言模型不能跳跃”。我第一次看到这个说法时，以为是在吐槽模型跑步能力不行。后来在一次真实任务里，我才真正明白这句话说的是什么。
那次任务很简单：给一小段客服对话，让模型判断用户是否要取消订阅，并生成回复。常规对话模型处理得很好。但其中有条记录是：“请帮我把账单寄过来，然后取消所有营销邮件，顺便不要再打电话给我。”模型给出的回复是：“我们已经为您取消所有邮件和电话服务，祝您生活愉快。”非常客气的回复，但漏掉了最关键的“寄账单”。不是模型没读到那句话，而是它把“用户提出多个要求”这个场景处理成了最常见的“取消服务”模板，没有在两条独立指令之间跳跃一步——既要取消营销邮件，又要保留账单邮件。
这个错误看起来很小，但它揭示的不只是某次提示写得不好。它让我开始思考：为什么一个能写出流畅文案、能总结论文、能生成代码的模型，会在这种简单逻辑上翻车？带着这个问题再回头看 “LLMs Can't Jump”，我觉得这句话真正想说的是：大语言模型在“概念空间”里很难完成一次真正的跳跃——从已见模式跳到未见的组合、从语言形态跳到因果推理、从局部信息跳到全局判断。它擅长在数据密集的地方滑行，但不擅长在稀疏的地方起跳。
下面我从几个角度拆解这个判断，并给出实际使用中更稳的路径。
1. 先说清楚：模型到底是跳不过哪一类任务？
1.1 一个看似容易、却在多指令场景翻车的例子
上面客服场景不是孤例。我们可以在很多常见任务里复现同类问题：要求模型“根据A条件排除B情况，再生成C结果”，当条件之间存在交叉或互斥时，模型很容易只执行最显眼的那条指令。我通常把这个现象叫“指令优先级误判”。
为什么会这样？因为模型在训练数据里见过大量“用户说要取消，回复就确认取消”的样本，这类样本密度高、路径短。当用户指令里同时包含“保留账单”和“取消营销”两个动作时，模型倾向于走到概率更高的那个分支，而不是真正理解两个动作同时成立。它不是在执行指令，它是在预测用户接下来最可能看到什么文本。
所以，这类任务翻车不是因为模型“不聪明”，而是因为它本来就不按照“指令集合”的方式工作。真正的根因在于：要让模型同时满足两个互相独立的约束，需要它在内部建立一张类似“条件表”的结构，并基于这张表做逻辑判断。这种能力对它来说，是一种“跳跃”。
1.2 三种最常见的“跳跃”类型
我观察下来，模型容易跳不过去的任务大致有三类：
- 分布外跳跃：输入或期望输出超出了它训练数据覆盖的范围。比如让一个以中文为主的基座模型回答某个地区极其细分的地方政策，或者让它模拟一个它从未见过的界面。它不是不能生成文字，而是生成的所有文字都只是“看起来像答案”的合理幻觉。
- 组合性跳跃：模型分别知道两个概念，但把这两个概念组合成一个新场景时，表现不稳定。比如一个模型可以解释“苹果”，也可以解释“笔”，但让它描述“一支外形像苹果的笔”时，它可能生成一个既不像苹果也不像笔的缝合怪。原因是组合后的概念在训练语料里出现的次数太少，模型没有足够的高概率路径可供延续。
- 反事实跳跃：当需要模型基于一个与常识相反的假设推演结果时，它很容易被训练数据里的常识“拉回去”。比如“如果重力突然消失，墨水会怎样流动”，模型会先顺着物理常识说“墨水向上飘”，但如果你继续追问“如果只消失1秒呢”，它可能又开始正常物理分析，因为那1秒的假设它没有在记忆里对应到稳定的概率分布。
这三类跳跃的共性在于：任务要求模型在已学到的概念之间建立一条新的、不常见的路径。而模型更擅长的，是沿着已经出现的路径走下去。
1.3 失败背后的共同信号：输出流畅，但逻辑断裂
这类失败还有一个共同特征：输出通常是流畅的，甚至语气自信，但内部逻辑是断的。这正是它比传统规则引擎更难排查的地方。传统程序如果逻辑不对，会报错、崩溃、返回空值；LLM 会给你一段看起来完整、但关键内容缺失的文字。所以判断模型是否完成“跳跃”，不能只看句子通顺不通顺，要看它是否忠实处理了所有约束，是否改变了输入事实，是否在关键决策点上做出了正确联动。
这提醒我们：在使用模型时，必须先把“需要跳跃”的环节识别出来，再考虑用提示词、外部逻辑还是人工规则去补上。
2. 为什么不能跳：预测下一个 token 的底层机制到底决定了什么？
2.1 训练目标只要求“猜下一个 token”
大语言模型的核心训练目标其实非常朴素：给定一段文本前缀，预测下一个 token 的概率。从表面看，这个目标很容易被低估，因为它积累出的文本生成能力非常惊人。但要注意，它优化的始终是“语言上的连贯”，而不是“逻辑上的正确”。
当模型生成“因为下雨，所以...”，它可以顺畅接出“地面是湿的”，是因为训练语料里这两者的共现次数足够多，而不是因为它理解了因果。如果有一天你让它接“因为下雨，所以太阳从西边升起”，它大概率会抵抗这个荒谬逻辑，因为它在这个位置学到的分布里，几乎没有出现过这种接法。这种抵抗不是逻辑推理的结果，而是概率分布的束缚。
这句话很关键：**模型的“知识”是以概率分布的形式存储的，不是以规则和实体关系图的形式存储的。**因此，面对需要因果链、条件分支、反事实推演的任务时，它不能像人一样在心里“跳一步”，它只能找到一条已经被语法和语义惯性铺好的路。
2.2 上下文学习本质上是在“找相似段落”
模型在某些情况下表现得像会推理，是因为它学会了在上下文中模仿示例。给它两个“输入-输出”样例后，它生成第三个输出，往往能模仿得很像。不少人把这当成模型具备“举一反三”能力的证据。但如果仔细分析，会发现这种能力更接近“模式补全”：模型在上下文里看到了一段隐含的映射模式，然后按最可能的延续方式补全结果。
这就是为什么 few-shot 通常有效，但提示词里一旦包含多个示例，且示例之间有冲突或边缘情况，模型就可能开始“混合”多个示例的模式，而不是严格遵循逻辑规则。你可以把它理解成一个擅长临摹的学徒：他能照着范本画出一张很接近的画，但如果你给他两套风格完全不同、还要抽象取交集的任务，他就容易画歪。
所以，用示例可以降低跳跃难度，但不能根除跳跃可能失败的风险。示例越多，模型越容易找到“看起来最像”的输出，而不一定是最符合规则逻辑的输出。
2.3 为什么它又会给出“像推理”的长篇答案？
经常有人用“让模型解释一道数学题”来证明模型会推理。实际上，模型可能只是复现了它在训练语料中见过的解题叙述范式。它先说“设未知数为 x”，然后写“根据题意”，再生成一串等式。这个过程看起来就是推理，但如果等式中的某个数字需要根据前文代入，模型很可能把数字写错。
一个测试方法很简单：让模型做一个需要精确步骤的小任务，比如统计一句话里某个字母出现了多少次。如果模型给出结果，你逐步追问中间步骤，会发现它经常先在某个中间数字上出错，而后续步骤则是按那个错误数字“自洽”地推下去的。这说明模型没有在执行一个封闭的计算过程，它是在生成一个“看起来像计算过程”的文本流。
这里我要特别说明：我不是说所有大语言模型都完全不具备推理能力，也不是要否定它在多种任务上的有效性。更准确地说，它是把“推理”以一种不可靠、不稳定、偶尔正确的方式混合在语言生成中。对于高风险任务，我们不能默认这种能力可靠；对于简单任务，它又往往够用。我们需要判断的，是它在具体场景下的可靠性。
3. 既然不能跳，怎么用才稳？三条关键策略
3.1 任务拆解：把“跳跃”留在代码里，不留给模型
最核心的用法，是接受“模型不能独自跳跃”这个设定，然后把任务重构为多个“一步就能完成”的小步骤。我通常这样做：
- 把完整任务拆成若干子任务，每个子任务只做一类局部的语言理解或生成。
- 找出子任务中需要精确计算、状态更新、条件判断的部分，考虑用代码、表格或规则引擎完成。
- 模型只负责两个边界：一是从非结构化输入中抽取结构化信息，二是把结构化结果转成自然语言输出。
举个例子：假设你想让模型从一堆简历里筛出符合条件的人。不要直接问“这些人里谁最适合当项目经理？”因为这个问题需要跨多个字段做加权判断，模型容易把条件混淆。更稳妥的做法是：先让模型逐条抽取每个候选人的项目经验、年限、技能标签，输出 JSON；然后由代码按你的规则（比如年限>3，且有管理经验）做筛选；最后再让模型为筛选结果生成一段简短推荐语。这样模型没有跳，它只做了它最擅长的“理解文本”和“生成文本”，真正的判断逻辑由确定性的代码完成。
我把这个流程称为“最小跳跃原则”：模型只需要从 A 到 B，不需要从 A 到 C 再到 D。
3.2 用提示词和少量示例，把跳跃变成“表面上的类比”
不是所有任务都能完全拆成确定性子步骤，有些场景仍然需要模型做一点跨越。这时我会用一组提示策略：
- 把规则写具体，不要只写“请遵守要求”，要写“如果 X 出现，必须返回 Y；如果同时出现 X 和 Z，必须同时返回 Y 和 W”。
- 给 2 到 3 个覆盖边界条件的例子，尤其要包含一个反例，明确说“当出现这种情况时不要做常规回复”。
- 让模型先复述一遍规则，再处理用户输入。也就是要求它在输出前先生成“我的判断依据是...”，这能帮助它把规则在上下文里“激活”，降低漏约束的概率。
- 在需要控制输出格式时，使用 JSON 或固定字段模板，并要求模型只输出该结构，不要解释。
这类方式并不能百分百解决问题，但它能显著提高模型在规则清晰、矛盾较少场景下的稳定性。如果任务本身的矛盾点多到需要一张决策表，那还是要回到 3.1 的做法，把决策表写进代码里。
3.3 对接工具：让模型“语言理解”，让工具“逻辑执行”
当任务涉及计算、检索、日期处理、状态流转时，最可靠的方式是让模型生成一个可被程序执行的中间表示，再交给外部工具执行。例如，用户问“下周每天下午三点提醒我喝水”，模型不需要自己保存提醒，它只需要输出一个结构化的工具调用：
{ "action": "create_reminder", "params": { "repeat": "daily", "time": "15:00", "start_date": "2025-01-06", "end_date": "2025-01-10" } }然后由外部系统解析这个 JSON、创建提醒、返回成功状态，再让模型把结果转成一句话。这样做的好处是模型不需要维护状态，也不需要精确计算日期，它只负责把自然语言翻译成工具指令。日期计算、去重、冲突检测都在工具层完成。
这种设计，本质上是把模型的“跳跃”替换成了系统的“跳板”。如果你在做一个真正面向用户的产品，这就是目前最值得投入的架构方向。另外，选用的模型如果支持函数调用或工具调用能力，可以优先使用那种接口，因为它更接近“输出结构化指令”而不是“生成一段包含指令的自然语言”，成功率更高。
3.4 输出校验：建立一条最小排查链路
最后，所有使用 LLM 的流程都应该配一道校验关卡。我的习惯是：先跑通一条样本，再扩大批量。但跑通不等于正确，所以我会按以下顺序排查：
- 看现象：是报错、卡住、无输出，还是输出异常但格式正常？
- 看输入：原始文本是否有编码问题、字段缺失、格式错误、上下文过长截断？
- 看提示词：指令是否含糊，是否同时要求了多个可能冲突的目标，示例是否覆盖了边界？
- 看配置：温度是否过高导致输出发散？
max_tokens是否太小导致答案被截断？是不是开了某种优化选项导致输出不稳定？ - 看模型边界：这个任务是否超出了模型的能力范围？比如需要精确计算或长链因果，那么再调提示词可能都是在浪费时间。
把这个排查链路固化下来，效果比一次次碰运气要好得多。你可以在每次接入模型时，先拿 10 条代表性样本走一遍这个流程，把错误分成“提示词问题”和“模型结构性不足”两类。前者当场调整，后者必须换架构或加工具。
4. 什么时候别指望它跳？适用边界与长期判断
4.1 适合让模型做的事：局部理解与表达
根据前面的分析，模型更适合那些“不需要跨越多步逻辑”的任务。常见场景包括：
- 文本改写、润色、风格迁移，尤其是输入输出一对一映射。
- 信息抽取，从非结构化文本中提取实体、时间、金额等明确字段。
- 初稿生成，比如营销文案、会议摘要、代码注释，这些任务允许少量修改，迭代成本低。
- 语义检索和分类，让模型把自然语言映射到预定义的标签或向量。
- 代码自动补全，在上下文很充分的场景下生成候选片段，再由程序员审查。
这些任务的共同点，是模型可以基于局部上下文直接产出结果，不需要在一长串因果链条里保持精确的状态。即使出错了，人工也能快速发现和修复。
4.2 不适合让模型直接做的：长程精确与高风险决策
反过来，以下任务在没有外部工具和规则守护时，不要指望模型稳定完成：
- 多步精确计算，包括金额、税率、统计聚合。
- 需要实时更新状态的工作流，比如订单状态流转、库存扣减。
- 医疗、法律、财务等需要严格依据专业规则的结论生成，除非你把规则全部显式编码并做校验。
- 需要严格遵循外部知识的问答，尤其是知识有版本和时效性时，模型无法自行判断它记住的是哪一年的事实。
- 需要反事实推演或假设驱动的复杂分析。模型可以生成“类似分析”的文字，但你很难保证推演逻辑一致。
这不是说这些场景完全不能碰 LLM，而是说在这些场景里，LLM 应该只充当语言界面，核心决策必须由确定性系统完成。把“决定正确性”的职责交给一个概率系统，是很多事故的来源。
4.3 为什么“会跳”的错觉一直存在？
很多人仍然高估模型的原因，我在前面的分析里提过一部分。更细一点说，有三个因素在起作用：
- 评估指标的误导：公开 benchmark 大多偏重知识问答、摘要和生成质量，对长程逻辑一致性的考察相对有限。一旦模型在这些榜单上分数好看，用户就容易默认它也能完成复杂的组合推理。
- 人类叙事补全的本能：当我们读一段流畅的文本时，大脑会自动补全其中的逻辑缝隙。模型输出的段落里即使存在错误跳跃，只要整体通顺，我们也会下意识地把它脑补成一个连贯的推理过程。
- 产品包装的平滑效应：很多产品交互层已经把工具调用、知识检索、人工规则都藏在后面，用户看到的是“模型直接给出了正确答案”。于是你很难分清哪些能力来自模型本身，哪些来自外围系统。
理解这三点，能帮助你在团队讨论或技术选型时，更理性地评估“把这件事交给 LLM”到底意味着什么。你真正要评估的，不应只是模型 API 的能力，而是整套系统的能力。
4.4 长期更值得投入的不是“等模型会跳”，而是搭好外部脚手架
顺着上面的思路，我认为未来一两年的工程重点，不应该是每天测试模型是否突然获得了“跳跃能力”，而是稳定地搭好三类脚手架：
- 规划层：把任务分解成模型可执行的小步骤，并在每步之间设计校验点。
- 工具层：为模型提供计算、检索、数据库操作、接口调用等确定性能力。
- 校验层：对模型输出做格式、字段、业务规则和人工抽验的多级检查。
这三层加起来，就是一套把“模型的语言能力”和“系统的确定性”结合起来的架构。这也是目前 RAG、智能体、函数调用、编排框架等概念真正要解决的问题。方向不是让模型更像人，而是让我们设计的系统更可靠。
如果你现在刚开始接触这一领域，我的建议很简单：先用一条最简单的业务路径，跑通一次“模型生成文本 -> 外部工具执行 -> 校验返回”的闭环。不要急着堆各种花哨的 Agent 编排，先在这条最小闭环里理解模型的不可靠边界，再逐步扩展。你会发现，“LLMs Can't Jump”并不是一句负面的评价，它更像一句自我认知清晰的座右铭——知道哪里要跳，先把跳板放到哪里，剩下的，模型可以走得很稳。
