AI AI 工具指南
常见问题解决库

模型只听"最后一句"，无视前面的规则

Prompt 末尾一句"顺便提一下"会覆盖你开头写好的规则。把硬规则同时锚在首尾，最后一句就不再说了算。

发布于: 更新于: 作者: AI Productivity Guide Team 🌐 查看英文版本

你认真写了 12 句规则，末尾顺手加一句”哦，口语化一点”。结果输出无视了 12 条里的 10 条，全口语化。你的规则明明写着”用正式英语、引用来源、返回 JSON”，那句口语化只是顺嘴一说。模型偏偏听了顺嘴那句，因为它在最后。

最快修法： 在交付指令之前的最后一行重申你 2-3 条最硬的规则，并把软动词（“应该""尽量”）换成 MUST / DO NOT；再删掉结尾那句”顺便""哦还有”。如果是聊天会话，把规则挪到 ChatGPT Custom Instructions 或 Claude Project 里，别在 message 里反复重贴。下一次重跑通常就会重新听规则的。

这之所以有效，是因为位置的影响比大多数人以为的大得多。现代 Transformer 模型对 prompt 的开头和结尾注意力最强，中间最弱——这是有实测的”lost-in-the-middle”（迷失在中间）效应：埋在上下文中段的信息，检索准确率比放在两端时低 30% 以上（Liu et al., Lost in the Middle, 2023）。根因在架构层面：GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro 同样使用的旋转位置编码（RoPE）会随距离衰减注意力，于是结尾附近的 token 和开头的锚点 token 占主导。你写在最后的东西，会被读成”最终决定是……”。

本文讲为什么最后一句会赢，以及怎么让顶部规则不被结尾那句顺嘴的话改写。

你属于哪一类

症状可能原因看这里
删掉最后一句就好了顺嘴那句紧贴交付指令原因 1、Step 1
规则用”应该""尽量""最好”规则没标成硬约束原因 2、Step 2
短 prompt 有效，长 prompt 失效长 prompt 稀释了前面的注意力原因 3、Step 6
第 1 轮守住，第 8 轮丢了对话历史叠加近期偏好原因 4、Step 4
最后一段是任务，不是规则末尾没有重锚原因 5、Step 1

常见原因

1. 顺嘴的那句紧贴交付指令

离”现在写答案”越近，权重越大。如果你结尾是”顺便短一点”，“短”就赢过前面所有规则——因为它落在 prompt 高注意力的尾部。

如何判断： 删掉最后一句，输出回到遵守前面规则的状态。

2. 前面规则没标成硬约束

如果你的规则写成 prose（“用 JSON 比较好”）而不是祈使句（“必须返回合法 JSON”），模型就当成偏好。一句”给个简短摘要就行”轻松覆盖偏好。

如何判断： 你的规则用了”应该""最好""尽量”——软情态动词。

3. 长 prompt 稀释前面注意力

2000 字的 prompt 里，模型生成时前 200 字已经”远”了，后 200 字”近”。卡在中段的规则两头都不沾，正好落进”lost-in-the-middle”那段——检索准确率掉得最狠的区间。

如何判断： 同样的规则在短 prompt 里有效，在长 prompt 里失效。

4. 对话历史叠加近期偏好

聊天会话里，你最新的 message 离回答最近。前面轮次（即使规则严格）会被最近一条 casual message 压过去。会话越长越糟：随着窗口填满，模型会改写或压缩最初的 system prompt，规则原文就开始漂移。

如何判断： 第 1 轮的规则第 2 轮还守，第 8 轮就丢了。

5. Prompt 末尾没重锚

很多认真的 prompt 结尾是”现在写答案”。最后没重提规则，近期偏好就反过来不利于规则。

如何判断： 你最后一段是任务，不是规则。

动手前先确认

  • 从下往上读 prompt。最后 3 句是模型最注意的。
  • 分清哪些是硬规则、哪些是偏好。
  • 删掉最后一句重跑。输出变好就找到覆盖源了。
  • 同内容换个顺序跑。光改顺序往往就修好了。
  • 聊天会话里检查你最新的 message 有没有把前面轮次的规则压下去。

需要收集的信息

  • 按顺序的完整 prompt 文本。
  • 无视规则的那次输出。
  • 删除最后一句后的输出。
  • 规则挪到末尾后的输出。
  • 聊天场景：完整对话历史。

最短修复路径

Step 1：硬规则同时锚在首尾，不只放顶部

位置偏好是 U 形的，所以只在顶部放一份反而是最差的——模型对开头和结尾都最注意。规则放顶部，再把最硬的几条在交付指令之前的最后一行重申一遍。这就是三明治模式：

[顶部]
非协商规则：
- 返回合法 JSON
- 字段 "summary" 必须少于 50 个词
- 每个论断附一个来源

[中间：上下文、示例等]

[底部——交付前重申]
硬规则提醒：合法 JSON、summary 少于 50 个词、附来源。

现在产出。

模型最注意末尾，所以规则也要放末尾。别把光秃秃的任务（“现在写答案”）留作最后一行。

Step 2：软情态动词换成 MUST / DO NOT

差：  "尽量保持简短。"
好：  "MUST be under 100 words. DO NOT exceed."

差：  "尽量用 JSON。"
好：  "只返回合法 JSON。JSON 块外的任何 prose 都算违规。"

模型对 MUST / DO NOT 的约束力解析，比对情态动词更稳。关键词大写还能多给一点信号。

Step 3：后期补充挪进结构槽位

有”顺便”的念头，不要 append。把它编辑进结构里对应的槽：

差：  [12 句规则] ... 哦还有口语化一点。
好：  [顶部]
      语气：口语（允许缩略、第二人称优先）
      [12 句规则]
      [底部：重申硬规则 + 语气]

Step 4：聊天会话里把规则挪出消息流

在最新 message 里重贴规则当然能用，但很脆。真正稳的修法是把硬规则放到能彻底躲开近期漂移的地方：

  • ChatGPT： Settings → Personalization → Custom Instructions（账号级），或者建一个带专属指令的 Project（按会话）。注意截至 2026 年 6 月，Custom Instructions 字段仍有字数上限，所以只放你 5-8 条非协商规则。
  • Claude： 新建一个 Project，把规则写进 project instructions。Project 指令不会同步到其他 Project，所以每个需要的 Project 都要各贴一份。
  • API： 把规则放在 system prompt 里，不要放在 user 轮。

如果非得把规则留在聊天里，就每隔几轮重锚一次：

（延续第 1 轮任务。规则：<重申 3 条最硬的>。）
现在做：<新请求>。

Step 5：发送前审最后 3 句

发任何 prompt 前先读最后 3 句。如果会让陌生人误解你想要什么，就重写。最后 3 句大约承担了一半的引导力。

Step 6：工具允许就用输出 schema 收尾

末尾放一个正式 schema，是最强的近期锚：

Output schema (return only this):
{
  "summary": "<string, max 50 words>",
  "sources": ["<url>", ...]
}

schema 因为具体且在最后而占主导。更好的做法是让格式被强制执行，而不是被请求：

  • OpenAI（GPT-5.5） 和 Gemini 3.1 Pro 通过 response_format 支持原生 Structured Outputs / JSON Schema，它在解码层约束格式，任何顺嘴的话都覆盖不掉。
  • Claude 截至 2026 年 6 月没有暴露原生的 json_schema 响应格式；改用 tool use（定义一个工具，其 input schema 就是你的输出结构），或者用 response prefill（把 assistant 轮预填一个 {）。两种都比 prose 请求把格式钉得牢得多。

怎么确认已经修好

  • 删掉最后一句，输出不变（顶部规则守住了）。
  • 末尾加一句口语化的话，输出不翻成口语（底部硬规则顶住了）。
  • 聊天里第 1 轮的规则一直到第 10 轮都守住。
  • 陌生人只读最后 3 句，也能预测出你想要的输出。

如果还是没修好

  1. 把规则挪到 system prompt、ChatGPT Custom Instructions 或 Claude Project——总之挪出 user message。
  2. 用强制结构化输出（response_format 的 JSON Schema，或 tool use）——格式在解码时被固定后，位置偏好几乎不再有影响。
  3. 缩短 prompt——长 prompt 会扩大 lost-in-the-middle 区间，放大这个效应。
  4. 把一个巨型 prompt 拆成两次调用：一次产内容，一次按硬规则重排格式。

预防建议

  • 每个 prompt 结尾都重申硬规则，不要只留交付指令。
  • 硬规则默认用 MUST / DO NOT / MUST NOT。“应该”留给真正的偏好。
  • 用三明治模板：顶部规则、底部规则、交付指令放最后但引用规则。
  • 聊天工作把硬规则放 Custom Instructions / Project 指令，不要放 user message。
  • 发送前滚到底部，问一句：“这读起来像最终决定吗？”
  • 警惕”顺便”和”哦还有”——这是重构信号，不是 append 信号。

常见问题

这跟近期偏好（recency bias）是一回事，还是另一回事？ 它只是更大那个模式的一半。模型对 prompt 的开头和结尾注意力最强、中间最弱——一条 U 形曲线，有时叫”lost in the middle”。近期偏好（结尾赢）是真的，但首因偏好（开头赢）同样真，所以可靠的修法是把规则锚在两端，而不是只挪到底部。

把规则放在最顶部能修好吗？ 单靠这一招往往不行，长 prompt 尤其如此。顶部是个强位置，但结尾那句口语化的话仍然坐在另一个强位置上。底部也要重申硬规则。

为什么我的规则在短 prompt 里守得住，长 prompt 里就崩？ 长度是放大器。短 prompt 里每个 token 都靠近边缘；2000 字的 prompt 里规则可能正好落在最死的中段，实测检索准确率会掉 30% 以上。缩短 prompt，或在末尾再复制一份规则。

每个模型都会这样吗？ 都会，只是程度不同。GPT-5.5、Claude Opus 4.7 / Sonnet 4.6、Gemini 3.1 Pro 都用旋转位置编码（RoPE），会随距离衰减注意力，产生同样的偏向两端的模式。更新更大的模型稍微鲁棒一些，但并非免疫。

规则放到末尾了，模型还是无视它，怎么办？ 别再靠 prose 了。换成强制结构化输出：GPT-5.5 / Gemini 3.1 Pro 用原生 JSON Schema，Claude 用 tool use 或 response prefill。格式在解码时被约束后，结尾那句顺嘴的话就覆盖不了它。

相关阅读

标签: #排查 #Prompt #Prompt 质量 #Prompt 工程

相关文章