把提示词粘贴两遍，准确率就变了

第一次看到这个技巧的时候，我以为在看段子。把提示词复制粘贴两遍，模型准确率就能提升？这也太糊弄人了吧。

直到我翻开这篇论文——Google Research 发布的《Prompt Repetition Improves Non-Reasoning LLMs》（arXiv 2512.14982），用了7个不同的基准测试，跑了7个主流模型，老老实实把结果摆出来。我自己也照着试了一遍。确实有效。

模型其实是”盲读”上下文的

要搞清楚为什么重复提示词有用，得先理解一件事：语言模型是逐词从左到右处理文本的，注意力机制有一个硬性约束——前面的词看不到后面的词。

这就带来一个结构性问题。假设你给模型发了一段很长的文档，然后在末尾提问：模型在读那段文档的时候，根本不知道你要问什么。它是在完全不了解问题的情况下，把整段上下文编码进去的。等到读到问题那一行，上下文已经处理完了，没有机会回头重新理解。

越长的提示词，这个问题越严重。文档越长，模型带着”盲目”状态读完的内容就越多，关键信息很可能就在这个过程中被稀释掉了。

重复一遍，让所有词都能看见问题

论文的做法非常直接：把整段提示词（上下文加问题）完整复制一遍，拼在后面，变成[上下文+问题][上下文+问题]这样的结构。

第二遍读上下文的时候，模型已经知道要问什么了。注意力机制在处理第二段上下文中的每一个词时，都能看到第一段里已经出现过的问题。相当于模型做了一次”带着问题重读材料”的操作。

不需要微调，不需要改模型，不需要设计复杂的提示词结构。论文测试了 Gemini、GPT、Claude、DeepSeek 等7个模型，全部都有提升。有一组测试数据从21%直接跳到97%，不是个例，多个任务上都有显著改善。而且输出长度和推理速度几乎没有变化。

翻倍不等于翻倍慢

很多人第一反应是：token 数量翻倍，那速度不也得翻倍？

实际上不是这样。现代推理硬件在处理输入（prefill 阶段）时是并行计算的，2倍的输入 token 并不等于2倍的时间，耗时增加往往远小于这个比例。输出 token 才是真正占推理时间大头的部分，而重复提示词不影响输出长度。

成本方面，输入 token 的单价本来就比输出便宜，翻倍以后整体花费不到原来的两倍。如果这个方法能减少需要重试的次数，综合算下来可能还更省。

论文也测试了重复三遍的效果。结论是：边际收益很小，成本却是三倍，不值当。两遍是最优解，<问题><问题> 够用了，<问题><问题><问题> 就是在浪费钱。

什么情况下没用

这个方法有它的适用边界，论文也没有遮掩这一点。

短问题没什么效果。如果你的提示词本来就很简洁，上下文不长，模型根本不存在”盲读”的问题，重复一遍也不会带来明显变化。这个技巧的价值在于解决长上下文场景下的结构性缺陷。

更关键的一点是：只对非推理模式有效。o1、Gemini 的思考模式这类推理型模型，在内部推理链中已经有类似的”重读”机制，它们本身就会反复思考问题和上下文的关系。对这类模型重复提示词，等于做了一件它们自己已经在做的事，提升空间自然不大。

所以这个方法真正发光的场景是：长文档问答、复杂检索、需要从大段上下文里精准抽取信息，同时用的是非推理模式的普通模型。

我怎么用它

目前我把这个方法用在处理长合同文本和技术文档的场景里。提示词结构改成重复之后，模型漏掉关键条款的情况明显少了。不是每次都有戏剧性的提升，但稳定性确实变好了。

实现上也没什么复杂的，就是字符串拼接。如果你用 API 调用，在发送请求之前把 prompt 拼一遍就行，不需要改任何其他东西。

论文原文在这里：Prompt Repetition Improves Non-Reasoning LLMs，作者是 Google Research 的 Yaniv Leviathan、Matan Kalman 和 Yossi Matias。如果你手头有长上下文的任务，值得花半小时测一下。