上下文不是越长越好，是越靠前越好
约 2 分钟1 阅读
有个坑我踩了很久才反应过来。
我有条提示词，里面有条关键规则：「输出时不要包含任何解释，只给最终结果」。规则写在提示词中间，前面是一堆背景介绍，后面是一堆示例。结果模型每次都带解释，我每次都骂它不听话。
直到有天我闲得无聊，把这条规则从中间挪到开头，原封不动一句话。奇迹发生了：它开始照做了。
中间被忽略综合症
这事儿一开始我觉得玄学，后来查了才知道这是有据可查的现象——模型对上下文的注意力不是均匀分布的，而是呈 U 型：开头和结尾强，中段弱。放在中间的信息，最容易被「看见但没当回事」。
我的那条规则就是个典型。它被夹在背景介绍和示例之间，模型读到了，但在生成时它更受开头（任务是什么）和结尾（示例长什么样）的影响，中间那条禁忌被稀释了。
挪到开头，它就成了模型第一个记住的事；挪到结尾，它成了模型生成前最后被强化的事。两头都比中间强。
一个简单的自检
发现这个规律后，我重新审了一遍所有提示词，把每条「最重要」的规则挑出来，要么放开头要么放结尾。具体做法很土：
- 把提示词里所有规则列出来，标出「绝不能违反」的那几条。
- 这几条挪到 prompt 最前面，或者最末尾。
- 中间留给背景、示例这些「参考资料」——丢了影响不大。
就这么一挪，好几个长期不听话的提示词突然就乖了。
这比堆上下文更值
这个发现还帮我省了另一件事——我以前遇到模型不听话，第一反应是加更多上下文、写更多要求。结果提示词越堆越长，中间的关键信息反而被埋得更深，模型表现更差。
正确的方向相反：不是加更多，是把关键的挪到更显眼的位置。
很多时候模型没遵循你的指令，不是它能力不够，是你把指令放在了它最不看的地方。就像你给同事交代任务，把最关键的要求埋在邮件第三段，他大概率也会漏。
一个小习惯
现在写提示词，我有个固定动作：写完先问自己一句——「如果模型只记住开头和结尾，它还能干对吗？」
如果能，说明关键信息在位。如果不能，说明我把重要的东西埋中间了，得挪。
这个习惯比「写更长提示词」有用得多。毕竟，再长的上下文，放错位置等于没有。位置，比长度值钱。