Least-to-Most 提示词为什么有效
Least-to-Most Prompting 将复杂问题拆分为一串难度递增的子任务，先让模型解决最简单的问题，再把前面得到的答案拼进后续提示中，作为解决下一问题的已知条件。这种策略的核心假设是：模型直接面对高难度组合问题时容易在中间步骤出错，而如果把推理链条显式拆开，每一步的搜索空间会显著变小。比如一个需要先排序、再分组、最后做条件统计的问题，一次性生成结果时，模型可能记错中间结果，但拆成三个子问题后，每个问题都只包含少量约束，正确率会更稳定。
与思维链提示不同，Least-to-Most 不只是让模型在回答前输出中间步骤，而是要求模型先产生一个可执行的子问题列表，然后基于这些子问题逐步求解。分解阶段关注的是任务结构的拆分，求解阶段关注的是答案的传递。两者分开后，开发者可以单独调试提示词：如果分解结果不合理，就优化拆分规则；如果某个子问题回答错误，就补充该步骤的已知条件或调整粒度。
这种方法的收益在高组合复杂度任务上尤其明显。例如符号操作、关系推理、表格问答和多约束规划中，模型经常因为同时处理多个条件而产生遗漏。Least-to-Most 通过把约束分散到不同步骤，使模型在每一步只需要处理较小的条件集合。它不改变底层模型参数，只改变输入结构，因此很容易接入现有的大模型应用。
分解阶段与求解阶段的提示词设计
分解阶段的目标是得到一组从易到难的子问题。提示词需要明确要求模型不要直接回答原问题，而只输出拆分后的子问题列表。同时要约束子问题之间的依赖关系：每个子问题应当尽量独立，后一个子问题可以把前一个的答案作为输入。可以这样写分解提示词：
请阅读下面的原始问题，将其拆分为多个子问题。子问题按从易到难的顺序排列，每个子问题只解决一个小目标。后一个子问题可以依赖前一个子问题的结果。只输出子问题列表，不要直接给出最终答案。
求解阶段则需要把前序答案逐步注入。假设原问题是“对列表 [4, 7, 1, 9, 3] 先反转，再取第 3 个元素，最后加 10”，分解结果可能包含三个子问题：反转列表、取第三个元素、执行加法。第一轮提示只包含第一个子问题；第二轮提示除了当前子问题，还附带第一轮的答案；第三轮继续累积前两轮的答案。这样每一步都在上一轮确认结果的基础上推进，避免模型在中间步骤产生不确定猜测。
为了减少解析成本，可以让模型在求解阶段只输出当前子问题的答案，不要重复历史步骤。如果希望提高稳定性，还可以在提示词中加入一条约束：如果当前子问题依赖前文答案，请直接使用已知答案，不要重新计算。这样可以避免模型在后续步骤中重新推理已经完成的部分。
代码实现：串起子问题求解流程
下面用 Python 伪代码展示一个最小可用的 Least-to-Most 执行框架。实际项目中，llm 函数可以替换成任意大模型 API 调用，decompose 负责生成子问题，solve_subproblems 负责按顺序求解。
def decompose(question):
instruction = (
"请把下面的问题拆分为多个子问题，"
"按照从易到难的顺序排列，"
"后一个子问题可以依赖前一个子问题的答案。\n"
f"原始问题：{question}"
)
return llm(instruction)
def solve_subproblems(question, subproblems):
context = []
for sub in subproblems:
prompt = "当前子问题：" + sub + "\n"
if context:
prompt += "已知历史答案：\n" + "\n".join(context)
answer = llm(prompt)
context.append("子问题：" + sub + "\n答案：" + answer)
return context[-1]
question = "对列表 [4, 7, 1, 9, 3] 先反转，再取第 3 个元素，最后加 10"
subproblems = decompose(question)
final_answer = solve_subproblems(question, subproblems)
print(final_answer)
这段代码的核心在于 context 变量。每一轮循环结束后，已解决的子问题和答案被追加到历史上下文中；下一轮调用模型时，这些内容会作为已知条件出现在提示词里。这样可以实现真正意义上的答案传递，而不是让模型凭记忆补全前面的步骤。需要注意的是，子问题列表本身可能是模型生成的字符串，需要根据实际输出格式做解析，例如按行拆分或要求模型以 JSON 数组返回。
如果模型在分解阶段给出的子问题粒度不合适，可以在代码中增加过滤逻辑。例如剔除空行、去除重复子问题，或者检查子问题数量是否超过上限。对于简单任务，分解后可能只有 2 到 3 步；对于复杂任务，子问题数量也不宜过多，否则上下文会快速膨胀，后续步骤的注意力反而会被无关信息稀释。
实践中的粒度控制与常见误区
Least-to-Most 的效果高度依赖子问题拆分质量。拆得太粗，每个子问题仍然包含多个约束，方法就退化为普通提示；拆得太细，会产生大量冗余步骤，增加延迟和 token 成本。一个实用的判断标准是：每个子问题只包含一个可验证的中间目标，并且该目标可以用一句简短的话描述。例如“反转列表”是一个清晰子问题，而“先反转并取第三个元素再判断是否为奇数”则包含多个操作，应继续拆分。
常见误区之一是把所有子问题一次性全部交给模型。虽然从表面看模型看到了完整任务分解，但它仍可能直接跳到最终答案，或者在多个子问题之间产生干扰。正确做法是严格串行执行，每一轮只暴露当前子问题和已经确认的历史答案。另一个误区是分解阶段和求解阶段使用完全相同的提示词风格，导致模型把分解与求解混在一起。两个阶段的目标不同，提示词应当明确区分：分解阶段禁止给最终答案，求解阶段禁止重新计算历史步骤。
此外，并非所有任务都适合 Least-to-Most。对于简单的事实问答或单步分类任务，显式拆分反而增加开销。它更适合那些能够自然形成依赖链的问题，比如多条件筛选、程序合成、几何证明和复杂算术。实际应用时可以把 Least-to-Most 作为困难样本的兜底策略：当直接提示或思维链结果不稳定时，再启用分解流程，从而在成本和正确率之间取得平衡。
Least-to-Most Prompt提示词工程多步推理修改时间：2026-08-20 17:57:46