Rephrase and Respond：先改写，再回答

很多时候模型答非所问，不是它笨，是你的问题本身有歧义，而它按错误的理解答了。 Rephrase and Respond（RaR，改写并回答）就是来堵这个漏的。

做法一句话：让模型在回答前，先用自己的话把你的问题重新表述、补全细节，然后再基于改写后的版本作答。

为什么有用

人和人之间，听不懂会反问「你是说……对吧？」。模型默认不会反问，它会直接按自己的理解开答——如果理解偏了，整个回答就废了。

RaR 相当于强制它先「复述确认」一遍。这一复述，常常会：

暴露歧义：把模糊的地方明确化。

补全隐含条件：把你没说全的补上。

对齐理解：让它的理解和你的意图对上。

模板

最简单的单步版本：

请先用更清晰、更完整的方式重新表述我下面这个问题（补全可能隐含的条件），
然后再回答重述后的版本。
我的问题：{你的问题}

模型会先输出「你的问题其实是想问……」，再作答。你一眼就能看出它有没有理解对——理解错了，你立刻能纠正，不用等它答完一大段废话。

一个真实例子

原问题：

这个函数怎么优化？

太模糊了——优化什么？速度？内存？可读性？直接答，模型只能瞎猜一个方向。

加上 RaR，模型会先重述：

你想问的是：在不改变这个函数功能的前提下，如何提升它的执行性能（如减少时间复杂度、避免重复计算）？

这时你发现「哦它以为我要优化性能，其实我想优化可读性」，一句话就能拨正。这就是 RaR 省下的来回。

适合的场景

问题容易有歧义：一词多义、指代不清、条件不全。

高代价任务：答错成本高，宁可先花一步确认。

非母语提问 / 措辞不严谨：让模型帮你把问题「翻译」成清晰版本。

不适合的场景

问题已经很明确时，是浪费。 「Python 怎么读 CSV 文件」这种，没歧义，让它先改写纯属啰嗦。

会增加输出长度和成本。 多了一段改写，token 上去了。批量、对延迟敏感的场景要掂量。

和别的技巧配合

RaR 解决的是「输入端的理解对齐」，思维链解决的是「输出端的推理过程」，两者管不同环节，可以叠加：先 RaR 对齐理解，再 CoT 推理作答。

它和 Step-Back 后退提示 也有点像——都是「先做点别的，再正式答」，但 Step-Back 是抽象原理，RaR 是澄清问题，目的不同。

小结

Rephrase and Respond 的本质是「让模型先确认听懂了没」。问题越模糊、答错越亏，它越值得用。问题本身清楚的，跳过这步。