通义千问算法题拆解：加示例的提示词更稳定

直接给通义千问这类模型丢一道算法题，提示词里如果缺少具体示例，模型很容易理解偏差，要么过度推断，要么跳过关键步骤，甚至曲解题意。最终给出的解题方案往往遗漏边界条件，时间复杂度估算失准，整体不可靠。

在提示词中嵌入带注释的典型示例

操作流程仅三个步骤，每一步都必须执行到位。

第一步：选题。挑选一道与目标题型结构一致、但难度略低的真题。例如，你要攻克“滑动窗口+单调队列”这类题目，可以用LeetCode 239练手，但需移除多层嵌套分支，仅保留最核心的结构。

第二步：完整拆解。手动写出这道题的完整推演过程，每一步都不能遗漏。顺序是：【题目重述 → 关键约束提取（如“O(n)时间”“禁止使用额外空间”）→ 暴力法缺陷分析 → 优化切入点（核心追问：重复计算发生在哪里？）→ 子问题定义 → 状态转移依据 → 边界初始化逻辑】。这条推理链上每个环节都要写清楚，不能跳过。

第三步：嵌入示例。将这套人工拆解内容作为示例，紧跟在系统指令后面、用户待解题之前，中间用分隔线隔开。关键点：示例中所有推理节点必须显式呈现。比如“为什么想到单调队列”这种因果链条，绝不可简化成一句话。

还有一个要点：示例里必须包含真实代码片段，哪怕只有三行。并且每行代码旁边都要用中文短注说明它的作用。像deque.append(i)这种操作，就注上一句“记录可能成为未来窗口最大值索引的位置”，这样模型才能理解每一步的意图。

控制示例数量与位置

这里有两种实用方案，根据场景选择。

方案一：单示例强引导。只放一个高信息密度的示例，放在提示词最前面。这个示例要覆盖目标题80%以上的核心动作——比如模式识别、剪枝、状态设计都包含在内。长度建议控制在180到240字。超过这个长度，模型注意力会分散；少于150字，又不足以建立完整的推理锚点。

方案二：双示例对比式。第一个示例展示正确的拆解过程，带好关键注释。第二个示例故意保留一处典型错误，比如忘记处理空输入校验。然后在后面跟一句【错误点：未处理nums=[]的corner case，导致后续len(nums)-k+1计算报错】。模型看到这种正反对比后，对鲁棒性检查的敏感度会明显提升。

动态替换变量名增强泛化

还有一种很实用的技巧：把示例里的变量名替换成无意义但符合语义的代号。比如原题用的是prices，示例里改成arr；原题用targetSum，改成goal。这样做能防止模型死记硬背原始命名，迫使它去关注操作逻辑，而不是做字符串匹配。

不过这里有个坑：替换必须全局一致。而且新名称在首次出现时要用括号注明原意，比如arr（即原题中的prices数组）。不然模型可能误判数据类型。

操作起来其实不复杂，用VS Code的批量替换功能就能搞定。但千万要小心——漏掉任何一个不一致的变量名，后续生成的伪代码就会出现混用，整个理解链条就断了。

来源：互联网