Least-to-Most提示分解推理技巧

CH-11-01-064·约 17 分钟·AI应用开发·更新 2026-08-11

想象你是后厨新手，接到的任务是“做一桌十菜的年夜饭”。直接开火当然会手忙脚乱：菜还没上齐，汤就凉了，鱼还糊了。而老师傅的做法是——先摊开一张菜单，把整桌菜拆成凉菜、热菜、汤品、甜点，再按难度排好顺序：凉菜最先上桌，复杂的硬菜放在后面慢慢炖，前一道菜的汤汁还能顺手当下一道菜的底料。这就是 Least-to-Most（L2M）提示技巧的核心：与其让 AI 一口吞下复杂问题，不如让它先列出子问题清单、再从易到难逐个击破、把前面的答案当作后续解题的上下文，最后一气呵成汇总出最终答案。本文会用这套“年夜饭心法”带你搞懂 L2M 的来龙去脉、拆解流程、与思维链（CoT）的区别，并附上你立刻能跑的实验代码。

岗位关联

对 Prompt 优化、大模型应用的开发者来说，Least-to-Most 是把“不可靠的复杂推理”变成“稳定多步流水线”的实用利器，能让 LLM 在数学推理、多步规划等长链条任务上显著减少出错。

可视化演示
核心概念：先学会“列菜单”
分解原则：刀工与配菜
推理流程：上菜的顺序
CoT对比：默背菜谱还是贴墙卡片
应用场景：一桌菜招待不同客人
实践技巧：沉淀一份标准菜谱
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示问题分解策略、由易到难逐步求解流程、与CoT思维链对比及数学推理应用，步进式切换深入理解Least-to-Most提示技巧。

本节配有交互动效（进入视口后自动加载，约 3KB）。

问题分解：复杂问题拆为子问题序列分解阶段：引导模型将复杂问题拆为从易到难的子问题求解阶段：从最简单子问题开始逐步推进 Q = {q1（易） → q2 → q3（难）} 分解是Least-to-Most的第一步。

核心概念：先学会“列菜单”

大厨接手年夜饭任务的第一件事不是开火，而是铺开菜单：把“十菜一汤”拆成凉菜、热菜、汤品、甜点四类，心里有数再动手。Least-to-Most 的灵感完全由此而来——名字里的 “Least“ 是最简单，”Most“ 是最复杂，合起来就是”从最简单的问题入手，一步步解决到最复杂的问题”。

当用户抛给大模型一个复杂问题 Q 时，直接问就像让一个新手直接炒十个菜，模型容易“手忙脚乱”。L2M 的做法分两轮：第一轮让模型先输出“子问题清单”（q₁, q₂, …, qₙ），第二轮按清单从易到难逐个求解，并把前一个子问题的答案拼进下一个问题的输入里。这样一来，模型每次只专注一个小目标，错误率大幅下降。

这个方法由 Google 团队在 2022 年提出，核心论文标题就叫《Least-to-Most Prompting Enables Complex Reasoning in LLMs》。它跟普通提示最大的不同是“显式规划”：模型不是边想边写，而是先列出完整的解题计划再执行。形式化写出来就是：

所以 L2M 像极了一位从容的大厨：第一步是“设计菜单”，第二步是“按顺序做菜，每一道都借前一道的汤汁提味”，最后热气腾腾地端上桌。菜单列得越清楚，翻车的概率越低。

\displaystyle Q \rightarrow \{q_1, q_2, \ldots, q_n\}; \qquad A = \text{汇总}(A_{q_1}, A_{q_2}, \ldots, A_{q_n})

通俗地说：原始问题 Q 被拆成一串子问题，最终答案 A 等于把每个子问题的答案拼装起来。

拆分符号Q 是原始复杂问题（比如“这桌菜怎么做”），q_i 是切出来的第 i 个子问题（比如“凉菜先备什么料”），箭头表示“拆成”。
$\displaystyle Q \rightarrow \{q_1, q_2, \ldots, q_n\}$
逐个求解每个子问题单独向模型提问，但提问时把前面所有问答拼在后面作为上下文。
$\displaystyle A_{q_i} = \text{LLM}(q_i,\ \text{上文}(q_1, \ldots, q_{i-1}))$
汇总答案把一串答案组织成完整回答。实践中常直接以最后一个综合性子问题的答案作为最终结果。
$\displaystyle A = \text{汇总}(A_{q_1}, A_{q_2}, \ldots, A_{q_n})$

分解原则：刀工与配菜

菜单不是随手写的。凉菜必须在热菜前，红烧肉要留给小火慢炖，甜点最后出场——这个排序决定了整桌菜能否流畅上齐。在 L2M 里，子问题怎么拆、怎么排，直接决定最终答案的质量。

好的分解有三条经验：第一，子问题要“小到可以单独验证”，就像每道凉菜都能先尝一口确认咸淡；第二，难度要递增，每一步都站在前一步的肩膀上；第三，所有子问题合起来要覆盖原问题，不能漏掉关键步骤。如果拆出来的子问题连模型自己都说不清“这步在干啥”，那这个拆分就是失败的。

用数学方式记录这三条约束：记 d(q) 为子问题难度，则序列满足难度递增与覆盖条件：

回到年夜饭：拆得太粗，一道菜里还是十个步骤；拆得太细，菜单比菜谱还厚，反而拖慢上菜。L2M 的分解也要“粒度适中、由浅入深、面面俱到”，这三板斧记住就不会跑偏。

\displaystyle d(q_1) \le d(q_2) \le \cdots \le d(q_n); \qquad \bigcup_{i=1}^{n} q_i \supseteq Q

通俗地说：子问题必须一个比一个难，而且把它们全加起来，要能覆盖原问题的所有关键点。

难度函数 dd 衡量一个子问题需要多少推理步骤，可以粗略理解为“这道菜有多费工夫”。
$\displaystyle d(q_i)$
递增链保证模型每次只前进一步，不会突然面对超出能力的跳跃。
$\displaystyle d(q_1) \le d(q_2) \le \cdots \le d(q_n)$
覆盖条件所有子问题的并集要盖住 Q 的全部要素，否则会漏解。
$\displaystyle \bigcup_{i=1}^{n} q_i \supseteq Q$

推理流程：上菜的顺序

菜单定好，后厨开始忙碌。真正的流程是：凉菜先上，热菜跟进，炖菜在后台咕嘟，最后甜点收尾；每上一道菜，传菜员还要记得前面端出去过什么。L2M 的推理流程就是这条“传菜流水线”。

具体到 API 调用：第一步，用一个“分解提示”让模型输出子问题列表；第二步，对每个子问题构造新请求，并把之前所有问答作为“桌上的菜”一并放进去；第三步，等最后一个综合子问题答出来，那就是最终答案。这也解释了为什么 L2M 对上下文长度更敏感——每一步都要把历史带在身上。

从概率角度看，L2M 是在用链式条件概率逼近最终答案：每个子问题的答案都条件于前序所有问答。这也是它和“一口气答完”最本质的数学差别：

这条流水线的妙处在于：如果某一道“菜”做砸了（某个子问题答错），你可以立刻定位是第几环节出的问题，而不必整桌重来。对追求稳定性的 AI 应用来说，这种“可定位、可重试”的特性比玄学式的一次性成功值钱得多。

\displaystyle P(A) = P(A_{q_1}) \times P(A_{q_2} \mid A_{q_1}) \times \cdots \times P(A_{q_n} \mid A_{q_1}, \ldots, A_{q_{n-1}})

通俗地说：最终答对的概率，等于第一步答对的概率，乘以在第一步正确的前提下第二步答对的概率，一路乘到最后。

第一项无前文第一个子问题没有前序答案可参考，所以是单独的概率。
$\displaystyle P(A_{q_1})$
条件项第二个子问题要参考第一个的答案，因此写成“竖线”右边的条件。
$\displaystyle P(A_{q_2} \mid A_{q_1})$
连乘到底把每步的条件概率相乘，就是整个推理链的联合概率，体现“步步依赖”。
$\displaystyle P(A) = P(A_{q_1}) \times P(A_{q_2} \mid A_{q_1}) \times \cdots \times P(A_{q_n} \mid A_{q_1}, \ldots, A_{q_{n-1}})$

CoT对比：默背菜谱还是贴墙卡片

有人会说：让模型“一步一步思考”的思维链（Chain-of-Thought, CoT）不是也能解复杂题吗？确实，CoT 是推理增强的另一个重量级选手。区别可以用厨房里的两种人形容：一种是“默背菜谱”的厨师，脑子里把步骤过一遍，然后一口气做完；另一种是“把菜谱贴墙上”的厨师，每一步对照着执行，而且提前把菜单也公示出来。

CoT 让模型自由写出推理步骤，这些步骤由模型自己临时规划，容易“走一步看一步”甚至迷路；L2M 则强制模型先输出一个显式的子问题清单（相当于把菜单公示），再逐个解决。用论文里的话说，CoT 是“同一个提示内生成推理链”，而 L2M 是“两次甚至多次查询之间共享答案”。

数学上对比两类目标函数：

一句话：CoT 是把菜谱背在脑子里，L2M 是把菜谱和菜单都贴到墙上。前者轻便，后者稳妥。复杂任务优先选后者。

\displaystyle \text{CoT: } P(A \mid Q) \approx \prod_{i} P(s_i \mid s_{<i})

\displaystyle \text{L2M: } P(A \mid Q) = P(q_1, \ldots, q_n \mid Q) \times \prod_{i} P(A_{q_i} \mid q_{<i}, A_{q_{<i}})

通俗地说：CoT 是让模型顺着思路一路写下去；L2M 是先规划出子问题清单，再逐个求解并复用前序答案。

CoT 的自由链s_i 是模型自由生成的每一步思考，每个思考都依赖之前所有思考。
$\displaystyle \text{CoT: } P(A \mid Q) \approx \prod_{i} P(s_i \mid s_{<i})$
L2M 的两段式先规划子问题序列 q₁…qₙ，再逐条解子问题，每条都以前序问答为条件。
$\displaystyle P(A \mid Q) = P(q_1, \ldots, q_n \mid Q) \times \prod_{i} P(A_{q_i} \mid q_{<i}, A_{q_{<i}})$
选择策略步骤不超过两三个的题，CoT 就够了；一旦要五步以上且中间易出错，L2M 的显式分解更能兜底。

应用场景：一桌菜招待不同客人

同一个“列菜单+由易到难”的思路，招待不同客人时可以灵活变化：生日宴重气氛，婚宴重流程，家宴重省事。L2M 的妙处是任务无关，只要能拆成步骤，它就能上。

最适合的三类任务：数学推理——多步运算、应用题；多步规划——行程安排、资源调度；代码与长文档生成——先列函数清单再逐个实现。这些任务共同点是“直接答容易断片，拆开答步步可验”。

举个经典例子：“5 个工人 8 天修完一条路，3 个工人几天修完（效率相同）”。L2M 会先拆出三个子问题：总工程量是多少？3 人每天完成多少？需要几天？然后逐个求解：

你发现了吗？这道题如果直接问模型，它可能张嘴就是“13 天 8 小时”，却答不出为什么；而经过了分解，每一步都看得见、算得清。教育类、办公类 AI 产品最吃这一套。

\displaystyle T_{\text{总}} = 5 \times 8 = 40; \qquad T_{\text{日}} = 3; \qquad D = \frac{40}{3} \approx 13.33

通俗地说：把“几天修完”拆成“总量多少”“每天修多少”“除法一算”，每一步都能独立验证。

子问题一先算总工程量，把人数乘天数当作“这块蛋糕的总大小”。
$\displaystyle T_{\text{总}} = 5 \times 8 = 40$
子问题二3 个工人每天完成的量，就是“每人每天效率乘以人数”。
$\displaystyle T_{\text{日}} = 3$
子问题三天数等于总量除以日完成量，得出约 13.33 天。
$\displaystyle D = \frac{40}{3} \approx 13.33$

实践技巧：沉淀一份标准菜谱

老厨师最宝贵的资产，不是某一桌菜，而是一本写满标准做法的菜谱卡片。L2M 工程化的关键，就是把分解方式沉淀成可复用的提示模板。

一个最精简的分解模板长这样：

用 API 时，第一轮只让模型输出子问题清单，第二轮开始把“前序问答+当前子问题”拼进 user 消息。还要记得把 temperature 调低（0～0.3），减少发散。

工程上还需要处理两类失败：一是模型拆出来的子问题没用，这时要换模板或补几个示例（few-shot）；二是上下文太长，每步都带全量历史容易超长，可以先让模型生成一句摘要再拼入下一步。分解的“停止条件”可以这样理解：

把这些技巧沉淀成模板、调好参数、设好兜底，你就拥有了自己的“后厨标准手册”。以后无论来什么复杂问题，只要往模板里一塞，后厨就能有条不紊地开工。

\displaystyle \text{停止条件：}\ d(q_i) \le \theta; \qquad \text{上文} \approx \text{摘要}(q_1, A_{q_1}, \ldots, q_{i-1}, A_{q_{i-1}})

通俗地说：当子问题简单到“一步就能答”时就不再拆；历史对话太长时，用摘要代替全文继续推进。

难度阈值 θ当模型估计某个子问题已经简单到“一步能答”，就停止继续拆分。
$\displaystyle d(q_i) \le \theta$
摘要压缩历史问答过长时，用摘要替代原始文本作为下一步的上下文。
$\displaystyle \text{上文} \approx \text{摘要}(q_1, A_{q_1}, \ldots, q_{i-1}, A_{q_{i-1}})$

text6 行

请把下面的问题分解成由易到难的子问题，并逐一回答：问题：{{question}}子问题 1：子问题 2：……最终答案：

AI 应用场景

教育辅导：数学应用题的逐步讲解

阶段：推理增强 / Prompt 工程

解决的问题：传统问答模型直接给答案，学生看不懂过程，老师也无法定位错因。用 L2M 把“鸡兔同笼”这类题拆成“求头脚总数→假设全为鸡→算差值→求兔数→求鸡数”的阶梯，每个子问题都输出可验证的算式，AI 就能像家教一样讲清每一步。

具体案例：某在线学习 App 接入了 L2M 提示模板。学生提问“头 35、脚 94，鸡兔各几只”，系统先让模型列出子问题清单，再逐个求解并把前序答案拼入下一步，最终不仅给出“鸡 23 只、兔 12 只”，还自动生成了分步讲解卡片，学生可逐层展开查看。

智能客服：多步骤工单的流程编排

阶段：智能体流程编排 / 任务规划

解决的问题：复杂退换货涉及“核验订单 → 检查退还规则 → 计算退款金额 → 生成售后方案”，一步错步步错。L2M 可让模型先输出流程清单，再逐步执行，每一步都引用上一步的结果，客服机器人不再“答非所问”。

具体案例：某电商客服机器人用 L2M 处理“商品降价申请价保”的工单：先识别订单状态，再查价保周期，再计算差价，最后生成赔付指令，全程在对话记录中保留每步中间结果。上线后工单一次解决率提升了约 20%。

代码生成：大函数拆成小函数逐个实现

阶段：代码生成 / 多步规划

解决的问题：直接让模型生成一个 200 行的完整函数，经常出现语法崩坏或逻辑跳步。L2M 让模型先列出“需要的函数清单及依赖顺序”，再逐个生成并测试，每个函数都以前面生成的代码为上下文。

具体案例：某低代码平台用 L2M 生成数据处理管道：模型先规划“数据清洗 → 特征提取 → 模型训练 → 结果导出”四个子任务，再按依赖顺序生成代码片段，最后合并。生成代码的单元测试通过率从 55% 提升到 81%。

Python 演示

python46 行

# -*- coding: utf-8 -*-"""Least-to-Most 玩具演示：把复杂问题拆成由易到难的子问题再逐步求解"""from typing import List, Callable, Dict  class LeastToMost:    def __init__(self, decompose: Callable[[str], List[str]],                 solve: Callable[[str, List[str]], str]):        self.decompose = decompose        self.solve = solve     def run(self, question: str) -> Dict:        subs = self.decompose(question)        context: List[str] = []        answers: List[str] = []        for q in subs:            ans = self.solve(q, context)            context.append(f"{q} -> {ans}")            answers.append(ans)        return {"subs": subs, "answers": answers,                "final": context[-1] if context else ""}  def mock_decompose(question: str) -> List[str]:    # 真实场景请用 LLM 生成；这里演示"鸡兔同笼"的固定分解    return ["求共有几只脚", "若全是鸡有几只脚",            "多出的脚对应几只兔子", "最后求鸡的数量"]  def mock_solve(q: str, context: List[str]) -> str:    answers = {        "求共有几只脚": "35个头、94只脚，共94只脚",        "若全是鸡有几只脚": "35只鸡共有70只脚",        "多出的脚对应几只兔子": "多出24只脚，每只兔多2只，故兔12只",        "最后求鸡的数量": "鸡 = 35 - 12 = 23 只",    }    return answers.get(q, "无法直接求解，需借助上文：" + ", ".join(context))  if __name__ == "__main__":    demo = LeastToMost(mock_decompose, mock_solve)    result = demo.run("鸡兔同笼，头共35，脚共94，鸡兔各几何？")    for i, (q, a) in enumerate(zip(result["subs"], result["answers"]), 1):        print(f"[子问题{i}] {q}")        print(f"    -> {a}")    print("最终答案：", result["final"])

目的：用纯 Python 模拟 Least-to-Most 的完整流程——先分解子问题，再按由易到难的顺序逐个求解，每个子问题都能看到前面所有问答，最后输出最终答案。

class LeastToMost:封装完整的“分解→逐步求解→汇总”流水线，是 L2M 的骨架。
subs = self.decompose(question)第一步：把原始问题拆成由易到难的子问题清单。
for q in subs:严格按顺序逐个求解，绝不跳步，对应“由浅入深上菜”。
ans = self.solve(q, context)每个子问题都能看到之前所有问题的问答，即“前道菜给后道菜当底料”。
context.append(f"{q} -> {ans}")把这一步答案“端上桌”，供后续子问题参考。
demo = LeastToMost(mock_decompose, mock_solve)注入分解函数和求解函数，方便日后替换成真实 LLM 调用。
result["final"]最终答案取最后一个子问题的输出，正如 L2M 的汇总方式。

常见误区

误区“我理解了，就是让模型分步骤回答嘛，我平时让它'先做什么再做什么'也一样。”

正解分步只是表象。L2M 的关键有三个硬约束：先显式输出子问题清单（规划与执行分离）、子问题严格由易到难排序、后一个子问题的输入必须携带前序所有答案。少了任何一条，效果都会大打折扣。就像年夜饭，光是“分几步做”还不够，必须先把菜单列出来、按冷热排序、每道菜借用前菜汤汁。

为何常见：因为 CoT 也强调“一步步思考”，初学者很容易把一切分步方法都混为一谈，忽略了 L2M 在提示结构上的独特性。

误区“思维链就是让模型写步骤，L2M 也是写步骤，两个名字不同而已。”

正解CoT 是在一次回答里让模型自由写出推理链，步骤由模型临时规划；L2M 则先让模型输出子问题清单，再针对每个子问题发起新的提问，并把前序问答拼入。前者像“默背菜谱一口气做完”，后者像“把菜单贴墙上，每做一道菜都对照一次”。在多次调用、上下文复用、错误定位上，两者有本质差异。

为何常见：两者都涉及“多步推理”和“中间步骤”，表面形态相似，加上许多文章把 L2M 描述为 CoT 的变体，容易让人误以为等同。

误区“既然分解能提高准确率，那我拆成 50 个小问题，效果肯定比 5 个更好。”

正解粒度太细会带来三重问题：上下文膨胀导致超长、每步之间的依赖错误被放大、“为了拆而拆”的无效子问题引入噪音。好的拆分标准是“每步可独立验证、难度递增、总量覆盖原问题”，而不是数量越多越好。就像年夜饭不会把一盘凉拌黄瓜拆成 20 道工序。

为何常见：人脑直觉是“细=更精确”，但在语言模型的概率链里，步骤越多，误差累积的乘积项也越多，过细反而降低可靠性。

误区“听下来全是算术例子，L2M 应该是数学竞赛专用技巧吧？”

正解数学只是最直观的展示场景。L2M 适用于一切“能拆成有序步骤”的任务：旅行路线规划、售后工单流程、代码分模块生成、长文档结构化写作等。甚至可以把多个独立子问题并行求解后再汇总。判断标准是任务是否有多步依赖关系，而非是否和数字有关。

为何常见：多数论文和教程都用数学应用题做案例，因为数学题的“可验证性”最容易展示成效，导致读者形成刻板印象。

误区“我只要在提示里写'请用 Least-to-Most 方法'，模型就会自己拆好。”

正解L2M 是一种提示结构，需要你明确给出分解指令和输出格式，比如“先列出由易到难的子问题清单，再逐个回答”。如果不给格式约束，模型可能直接输出长段推理，退化成普通 CoT。必要时还要给一两个示例（few-shot）引导分解风格。就像给新厨子一张白纸让他“做年夜饭”，他只会发呆；给他一张菜单模板，他才知道该怎么填。

为何常见：提示词新手常以为“方法名有魔法”，忽略了 LLM 是“按格式输出”的，方法的效力来自提示结构的显式约束。

面试题

Q1. Least-to-Most 提示方法的第一步是什么？

单选题 · easy

A.直接让模型输出最终答案
B.把问题拆成子问题清单← 正确答案
C.随机采样多个回答投票
D.给模型增加更多训练数据

答案：B。L2M 的第一步是“分解”，即让模型先输出由易到难的子问题清单。直接答就退化成普通问答；随机采样是自洽性（Self-Consistency）的思路；增加训练数据属于微调范畴，均与 L2M 无关。

Q2. L2M 中子问题的处理顺序是？

单选题 · easy

A.按随机顺序处理
B.由难到易倒序处理
C.从易到难逐步处理← 正确答案
D.一次性并行全部处理

答案：C。L2M 要求子问题严格按“由易到难”排序，每一步都站在前一步的答案之上，所以必须顺序处理。随机或倒序会破坏依赖链；并行处理则无法利用前序答案，都不符合 L2M 的设计。

Q3. L2M 中“上下文复用”指的是什么？

单选题 · easy

A.前序子问题的答案拼进后续提问← 正确答案
B.把训练数据重复输入给模型
C.使用更大上下文窗口的模型
D.在同一请求中重复相同问题

答案：A。L2M 的核心机制就是把前一个子问题的问答作为上下文，拼进下一个子问题的输入，让后续求解“站在前面的肩膀上”。反复输入训练数据、换大窗口、重复问题都不是 L2M 的做法。

Q4. 与思维链 CoT 相比，L2M 最核心的区别是？

单选题 · mid

A.先列子问题清单再逐个求解← 正确答案
B.完全不依赖任何提示词
C.只适配图像分类任务
D.必须额外微调大模型

答案：A。CoT 是在一次回答中自由写出推理链，L2M 则先显式规划子问题清单，再逐个子问题发起求解并复用前序答案，规划与执行分离。L2M 依然需要精心设计的提示词，也无需微调，更不限于图像任务。

Q5. 哪种任务最适合用 L2M 方法？

单选题 · mid

A.需要多步推理的数学应用题← 正确答案
B.情感分类的简单二分类
C.英文单词的拼写检查
D.图片颜色的归一化处理

答案：A。L2M 的优势场景是“可拆解、多步骤、有依赖”的任务，数学应用题是典型代表。简单分类、拼写检查、颜色归一化都是一步到位的操作，拆分子问题反而增加开销，不需要 L2M。

Q6. L2M 把复杂问题 Q 拆成子问题序列后，最终答案如何得出？

单选题 · mid

A.取最后一个子问题的答案← 正确答案
B.去掉子问题只回复原问题
C.随机挑选一个子问题答案
D.用投票合并全部子问题答案

答案：A。L2M 的“汇总”在实践中通常就是最后一个综合性子问题的输出。它前面已经携带了所有子问题的答案作为上下文，所以本身就是汇总结果。去掉子问题等于没分解；随机挑选会丢失信息；投票是自洽性的思路，不是 L2M。

Q7. 关于 L2M 的分解粒度，下列说法正确的是？

单选题 · hard

A.子问题宜细到单步可独立验证← 正确答案
B.拆得越粗越省成本越好
C.粒度大小完全不用控制
D.粒度只影响效率不影响质量

答案：A。好的子问题应“小到可以单独验证”，这样每步都能定位错误。但也不是越细越好——粒度过细会引发上下文膨胀和误差累积。粒度同时影响效率和质量，拆得过粗则退化成直接回答，两者都需要平衡。

Q8. 以下哪些是设计 L2M 分解提示时的要点？

多选题 · mid

A.要求按由易到难的顺序输出子问题← 正确答案
B.要求每个子问题可独立验证← 正确答案
C.要求直接输出最终答案不列过程
D.要求子问题大而全不要继续拆分

答案：AB。L2M 的分解提示必须明确指定“由易到难”的顺序（A），并让子问题小到可独立验证（B）。C 直接输出最终答案就失去了分解的意义；D 与“拆分”背道而驰，子问题需要细分到合适粒度，而不是大而全。

Q9. L2M 适合的应用场景包括哪些？

多选题 · mid

A.数学应用题逐步求解← 正确答案
B.多步骤旅行路线规划← 正确答案
C.单字拼写的自动纠错
D.长代码文件的分步生成← 正确答案

答案：ABD。数学求解、多步规划、长代码生成都有明确的步骤依赖关系，适合 L2M 拆解。单字拼写纠错是一步操作，拆分子问题属于过度设计。L2M 的适用标准是“能否拆成有序、可验证的子任务”，而非任务领域。

Q10. 关于 L2M 的局限与失败处理，下列说法正确的有？

多选题 · extreme

A.子问题分解错误会传导给最终答案← 正确答案
B.上下文过长时可用摘要压缩历史← 正确答案
C.子问题越多效果一定越好
D.L2M 无需定制提示模板即可用

答案：AB。L2M 是链式结构，前序子问题出错会顺链传导，所以 A 正确；上下文过长时用摘要替换历史是主流兜底策略，B 正确。子问题过多会引入误差累积和上下文膨胀，“越多越好”不成立；L2M 的效果强依赖精心设计的分解提示模板，D 错误。