prompt-repetition

提示词重复

何时使用此技能

• 用户使用的是非推理型或轻量级模型，重要问题出现在提示词靠后位置时，准确率会下降。
• 提示词属于长上下文检索、选项在前的选择题或位置敏感查找。
• 用户想要一条明确的决策规则，判断是将提示词重复 2 次还是 3 次，而不是含糊地承诺提示词工程会有所帮助。
• 工作流需要先进行低成本实验，再考虑更换模型或搭建检索基础设施。
• 用户提到类似模型忘了问题、漏掉最后一条指令、没找到第 25 项、被很长的选项列表弄糊涂，或Haiku / Flash / mini 模型的表现不如更强的推理模型等情况。

以下情况不要将此技能作为主要工作流：

• 真正的问题是上下文选择、检索设计或将嘈杂的来源塞进提示词 → 使用更全面的上下文工程或 RAG 方法。
• 真正的问题是推理深度，并且有支持推理的模型可用。
• 提示词涉及大量工具 / Agent、多步骤流程，重复整个提示词可能只会增加成本和混乱。
• 用户需要普遍适用、始终启用的中间件策略。此技能用于有针对性的场景，不应一概自动应用。

核心理念

提示词重复是一种针对特定任务形态的干预手段，并非普遍适用的提示词定律。

证据最充分的场景有：

1. 长上下文检索——问题出现在大量上下文之后，模型会漏掉靠后的细节。
2. 选项在前的选择题——选项出现在问题之前，或提示词结构容易让模型忽略实际问题。
3. 位置敏感查找——清单、有序列表或记录位置等场景中，模型会丢失类似索引的细节。

此技能在清楚回答以下三个问题时才算成功：

1. 这是否属于值得测试重复提示词的任务形态？
2. 重复多少次才足够安全，不会耗尽上下文预算？
3. 如果重复提示词不是合适的方法，我们应该改用什么？

指令

第 1 步：先判断提示词形态，再做任何更改

将当前提示词归入以下一类：

形态	典型信号	重复提示词的适用性	适用性较低时的更好替代方案
长上下文检索	“上下文块特别大，模型忽略了后面的问题”	适用	精简 / 选择上下文、检索、在末尾重述问题
选项在前的选择题	“选项先出现，模型选错了字母”	适用	调整问题和选项的顺序，简化答案格式
位置敏感查找	“模型漏掉长列表中的第 25 项”	适用	将列表分块，提供结构化表格，使用检索
工具繁多的 Agent 提示词	“工具、策略和步骤很多”	不太适用	简化策略、分离阶段、使用更好的编排
推理密集型任务	“需要逐步综合信息或制定计划”	不太适用	使用推理模型、任务分解、示例
RAG / 搜索架构	“检索到的证据嘈杂或不完整”	不太适用	改进检索、排序、分块和上下文整理

如果任务属于不太适用的一类，不要将提示词重复作为主要解决方案。

步骤 2：检查模型和成本防护措施

重复提示词会增加输入令牌，即使论文报告称，在测试运行中，生成的输出长度或延迟并未增加。

最低限度的检查：

• 模型类别——这是非推理型／轻量级模型，还是具备更强推理能力的模型？
• 当前提示词长度——估算长度增至 2 倍或 3 倍后，是否仍能轻松控制在可用上下文预算内。
• 运行预算——此工作流是否可以接受额外的输入成本？
• 失败模式——我们要解决的是未能关注上下文后段内容，还是任务实际涉及推理或检索质量？

保守的默认做法：

• 如果提示词已接近上下文限制，不要建议完整重复提示词
• 如果任务需要结构化推理，不要用重复提示词代替模型选择
• 如果只有最终问题／指令重要，请先尝试重述问题，再考虑复制整个提示词

步骤 3：选择最小且有效的干预

针对失败情况，采用成本最低的干预措施：

1. 仅重复问题

   • 适用于上下文很长，但只有最后的要求被忽略的情况。
   • 成本最低的首轮实验。

2. 将完整提示词重复 2 次

   • 适用于轻量级模型上的长上下文检索和选项在前的选择题，是默认实验方案。
   • 当整个提示词结构都很重要时，可作为首轮尝试。

3. 将完整提示词重复 3 次

   • 仅用于明显受位置影响或索引密集型任务。
   • 仅当成本和上下文窗口仍足够时使用。

如果用户无法承担输入令牌开销，请改用提示词重构或检索。

步骤 4：明确应用不适用规则

出现以下任一情况时，不要建议重复提示词：

• 用户已经使用了良好的推理模型，且问题出在多步推理上
• 提示词包含许多工具、策略或操作约束，重复只会造成冗余
• 检索结果较弱、相互矛盾或无关
• 上下文预算已经很紧张，重复可能导致截断或性能下降
• 通过移动问题、缩减上下文或添加少量示例，就能更简洁地解决问题

步骤 5：给出决策，而不只是提供技巧

好的回答应包括：

1. 适用性——说明重复提示词在此处是否合适，以及原因
2. 建议的最小干预措施——仅重复问题、将完整提示词重复 2 次、将完整提示词重复 3 次，或不使用重复提示词
3. 预算说明——说明对输入令牌／上下文窗口的影响
4. 备选方案／转向方案——如果重复提示词不合适，说明应采取什么做法

使用以下回答格式：

“提示词重复对这里的任务来说[适用／不太适用]，因为[任务特征]。我建议先尝试[最小干预措施]。请留意[令牌／上下文风险]。如果无效，请改用[更合适的替代方案]。”

步骤 6：保持评估范围狭窄且便于比较

测试提示词重复时：

• 除重复方式外，使用相同的提示词
• 仅在预算允许时比较基线版本、2 次重复和 3 次重复
• 根据任务准确性而非单纯的风格或长度判断效果
• 如果重复提示词造成上下文压力或明显臃肿，请停止

如果需要进行不止一项更改，重复提示词可能就不是主要手段。

步骤 7：出现其他问题时转向相应方案

• 上下文选择／检索／分块／来源质量 → 更广泛的上下文工程或 RAG 工作
• 推理密集型综合／规划 → 更强的推理模型或任务分解工作流
• 提示词示例／输出格式引导 → 少样本示例或提示词结构调整
• 工具策略／操作约束混淆 → 简化编排，而不是重复整个提示词

示例

示例 1：轻量级模型上的选项优先型选择题

提示词：

我在 Flash 模型上使用一个很长的选项优先型选择题提示词。应该复制提示词，还是重新组织结构？

理想回复要点：

• 判断为选项优先型选择题
• 建议先尝试重述问题，或将完整提示词重复 2 次，作为初步且有界的实验
• 提及 Token 成本权衡
• 指出调整提示词顺序也是有效的结构性替代方案

示例 2：RAG 质量问题

提示词：

我们的 RAG 答案质量不佳。应该到处添加提示词重复吗？

理想回复要点：

• 说明这种情况不太适合
• 解释检索/上下文质量才是更重要的影响因素
• 建议改进上下文工程或 RAG，而不是一概重复提示词

示例 3：位置敏感的库存查询

提示词：

一个 mini 模型总是漏掉长库存清单中第 25 个位置的商品。

理想回复要点：

• 判断为位置敏感型查询
• 如果预算允许，可重复 2 次，甚至 3 次
• 如果成本过高，提及结构化表格或分块作为备选方案

示例 4：关于推理模型的问题

提示词：

我们可以使用一款具备推理能力的模型，但成本更高。提示词重复能取代它吗？

理想回复要点：

• 说明不能，重复提示词无法替代推理能力
• 仅针对特定的非推理类失败模式使用重复
• 对于多步推理，建议改用更强的模型或进行任务分解

最佳实践

1. 将提示词重复视为有针对性的实验，而不是默认中间件。
2. 从符合失败模式的最小干预开始。
3. 始终提及输入 Token 成本和上下文预算压力。
4. 如果真正的问题在于上下文质量，优先选择重新组织提示词或改进检索。
5. 对证据薄弱的主张予以舍弃，避免这项技能沦为通用提示词技巧的杂物箱。
6. 最终建议保持明确二选一：在此处尝试重复提示词，或改用其他方案。

参考资料

• references/evidence-and-boundaries.md
• references/operator-checklist.md