你花 45 分钟写完美 prompt，1400 字，覆盖语气、受众、约束、边界、避雷、3 段参考、一份 checklist。结果回来 200 字的稀粥。同一天早上用 60 字版本问同样的事，回答又准又锋利。继续加字没用：大约过了 500 字之后，每多一句都是在稀释优先级，而不是在把任务讲清楚。
这不是你的错觉，也不是模型”读不下来”。前沿模型瞬间就能读完 1400 字。真正的问题在于位置和层级。长输入会掩盖”哪几句最关键”，而模型的架构本身对一大段文字的注意力就是不均匀的。没有清晰的形状，模型只能取平均，平均出来的东西就是平庸。
一句话总结
- 长 prompt 失效主要是结构问题，不是触到了长度上限。第一句祈使决定回答的框架，最后一块拿到最高的”近期权重”，而中间部分得到的注意力最少（这就是有据可查的”中间迷失 / lost in the middle”现象）。
- 把任务放在第 1 行、输出 schema 放在最后。把大块参考文本挪进带标签的区块，让模型当数据看、而不是当指令。
- 截至 2026 年 6 月，即便是 100 万 token 的模型，也会在窗口填满之前很早就开始掉准确率。GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro 在多事实任务上的”有效上下文”都远低于标称上限，所以更紧的 prompt 通常比更满的 prompt 更好。
- 目标是**“还能产出正确答案的最短 prompt”**，而不是”塞满全部细节的最长 prompt”。
长度为什么会悄悄拖垮回答
prompt 一长，两个效应会叠加。
中间迷失（Lost in the middle）。 模型对长输入的注意力，起头和结尾最强、中间最弱，画出来是一条 U 形准确率曲线。斯坦福 / 普林斯顿 / 伯克利那篇被广泛引用的研究（《Lost in the Middle: How Language Models Use Long Contexts》）发现：把一个关键事实从两端挪到中间，准确率会掉几十个百分点。这部分源于旋转位置编码（RoPE）随距离衰减注意力，因此它内嵌在大多数当前架构里，不是某一个模型的毛病。2025 年的一项后续研究（Chroma 的”context rot / 上下文腐烂”研究）测了 18 个前沿模型，全部随输入变长而退化——而且往往不是平滑下滑，而是过了某个模型特有的阈值后突然掉崖；Claude 系列衰减最慢，但没有一个能免疫。
有效上下文比标称上下文短。 现在每个旗舰都号称 100 万 token 窗口，但检索和多事实推理的质量，在窗口填满之前就开始下滑。截至 2026 年 6 月，独立测试中只有 Gemini 的深度推理模式能在接近满窗口时还稳住质量；对 GPT-5.5、Claude Opus 4.7、Gemini 3.1 Pro 来说，多事实生产任务的有效上下文大致落在 20 万–40 万 token 区间，超过之后准确率明显下降。1400 字的 prompt 离这些上限差得远，所以长度不是你的硬天花板——但那个会在 30 万 token 输入上”压垮”模型的注意力偏置，已经在啃你这 1400 字了。结构才是杠杆，长度只是症状。
这对一份 1400 字的 prompt 意味着什么
| prompt 中的位置 | 模型给的注意力 | 应该放什么 |
|---|---|---|
| 前 1–3 行 | 最高（首因效应） | 唯一的任务 / 交付物 |
| 最后一块 | 高（近因效应） | 输出 schema 或格式 |
| 中间大块 | 最低 | 参考数据，要圈起来并打标签，不要塞成被埋的指令 |
结论：必须被遵守的指令要放在顶部或底部。放在中间的，应该是模型去查的数据，而不是它要记住的规则。
常见原因
1. 目标埋在中间
第一句祈使决定回答的框架。如果你的祈使句在第 4 段，模型读到它之前就已经锁错框架了。
如何判断：搜 prompt 里的交付动词（写、产出、返回、决定）。在第 5 行之后才第一次出现，就是埋了。
2. 隐性约束冲突
“全面又简洁”。“覆盖所有情况又 ≤200 字”。长 prompt 会无声地累积这些。模型取平均，结果两边都不满足。
如何判断：把所有约束列在一张纸上，找方向相反的形容词对。
3. 背景占了 80%
1400 字里有 1100 字是背景、只有 300 字是任务/约束/输出规范，模型就会把 prompt 解读成”对这段背景做点什么”，而不是”产出 X”。
如何判断：逐节数字数。背景对任务超过 3:1，你就把真正的要求埋了。
4. 没有输出格式
长 prompt，却没有 schema。模型默认输出 5 段散文，因为训练分布里”认真的长答案”就长这样。即使你顺嘴提了格式，没有 schema 块也落不下来。
如何判断：你要 JSON、表格或 bullet，但每次回来的都是散文。
5. 重复强调反而失效
“特别重要”写 5 次，结果没一次让人觉得重要。模型把重复解析成”这是文体”，而不是”这里要更注意”。
如何判断：数 prompt 里”重要""关键""必须""特别”各出现了几次。超过 5 次，强调就被压扁了。
6. Prompt 是一面 prose 墙
没标题、没标签、没空行。模型只能自己推断结构，而长输入上的推断很不稳。Anthropic 自己的测试也表明：结构化的 prompt 比同样内容但无结构的版本，输出明显更一致。
如何判断：通篇找不到 ## 背景、## 约束、## 输出 这类标签。
动手前先确认
- 把当前 prompt 和那份差输出并排存好。
- 用早上能用的 60 字版本再跑一次。还能用吗？这能把”prompt 形状问题”和”模型问题”分开。
- 逐节数字数：任务 vs 背景 vs 约束 vs 输出规范。
- 不回读 prompt，用一句话写出真正的交付物。
- 判断哪几段背景删掉之后，答案不会变。
最短修复路径
Step 1：把目标提到第 1 行
任务：决定下列负载下从 Postgres 迁到 DynamoDB 是否值得。
二选一。用 3 句话辩护。
[上下文紧接]第一句祈使决定一切，确保它是对的。
Step 2：正文分块
## 任务
<一句话>
## 上下文
<bulleted，只放承重事实>
## 约束
- <一条一行>
- <若冲突，写明谁赢>
## 输出格式
- decision: postgres 或 dynamodb
- reason: 不超过 60 字标签对长输入的解析帮助巨大。对 Claude 来说，把每一节用具名 XML 标签圈起来——比如 <task>、<context>、<output_format>——是官方文档推荐的最佳实践。
Step 3：剪掉冗余约束
每条约束都问一句：“审稿人真的会去检查这条吗？“不会就删。软偏好会跟硬规则打架；删掉软的，反而让硬的更强。
Step 4：加 1 个正例，删 3 句规则
一个”正确输出”的样本，抵得上一整段规则。如果你写了一堆”输出应该长什么样”的描述，把它换成一个示例。Anthropic 和 OpenAI 都建议用几个带标签的示例，而不是用大段散文去描述格式。
Step 5：输出 schema 放在最后
prompt 的最后一块拿到最高的近期权重，这个位置留给结构规范：
[其他全部内容]
输出（只返回这个）：
{ "decision": "...", "reason": "..." }如果你是调 API 而不是用聊天框，那就根本不要在 prose 里描述 JSON 形状，直接把它作为真正的 schema 传进去。截至 2026 年 6 月，OpenAI 的 GPT-5.5 Structured Outputs（response_format: { type: "json_schema", json_schema: {...}, strict: true }）和 Anthropic 的 tool-use / structured-output schema，都通过受限解码（constrained decoding）在服务端强制格式——模型在 token 层面就根本无法吐出不合规的输出，比在 prompt 里”好声好气地请求”可靠得多。OpenAI 的官方建议很明确：开了 Structured Outputs 就”无需用措辞强硬的 prompt 去保证格式一致”，把 schema 描述从 prompt 里删掉，交给 API 提供。
Step 6：大块参考挪进带标签的区块
如果你有 800 字参考材料，就把它圈起来，让模型当输入数据，而不是当要去执行的指令：
<reference>
... 800 字政策 ...
</reference>
任务：<一句话；对 Claude，把问题放在 reference 之后效果最好>Anthropic 的长上下文指南在这点上很具体：一旦输入超过约 2 万（20K）token，就把长文档放在 prompt 的顶部，把问题放在末尾。在他们的测试里，把问题放到文档之后，复杂的多文档输入响应质量最多能提升 30%（Anthropic 长上下文建议）。给 Claude 包裹多个文档时，文档推荐的写法是用 <document index="1"> 包住一个 <source> 子标签和一个 <document_content> 子标签，让每一块都有清晰的边界。
怎么确认已经修好
- 陌生人只读前 3 行，就能正确说出交付物。
- “重要 / 关键 / 必须”加起来出现少于 3 次。
- 背景段不超过 任务+约束 段的 2 倍。
- 输出匹配你规定的 schema，而不是泛泛的散文。
- 同一个 prompt 跑 3 次，3 个输出形态一致。
如果还是没修好
- 再压。目标是”还能产出正确答案的最短 prompt”，不是”含全部细节的最长 prompt”。
- 拆成多轮：第 1 轮规划、第 2 轮执行、第 3 轮验证。更短、更聚焦的回合好过一个巨型回合，因为每一轮都贴着高注意力的两端。
- 让回答”引用落地”。对长参考输入，Anthropic 建议先让模型把相关原文摘出来（比如”找到相关引文，放进
<quotes>标签，然后只基于这些引文作答”）。在推理之前强制走一步检索，等于先把承重事实从低注意力的中段拎出来。 - 从聊天 UI 切到带结构化输出的 API（JSON schema 强制、tool use），格式从”建议”变成”保证”。
- 如果 prompt 真的不能再短，就换一个长上下文表现更好的模型。截至 2026 年 6 月，Claude Opus 4.7 和 Gemini 3.1 Pro 在长输入上保留细节的能力，往往强于 ChatGPT 网页版 Plus 的上下文——后者远低于 API 的窗口上限。也要清楚极限：独立的多针检索测试（Chroma 的”context rot”研究，测了 18 个前沿模型）发现，GPT-5.5 和 Claude Opus 4.7 的有效上下文大致落在 20 万–40 万 token 区间，只有 Gemini 的深度推理模式能在接近满 100 万 token 窗口时还稳住质量。
预防建议
- 不是非要参考材料时，prompt 控制在 600 字以内。
- 默认模板：任务在前、上下文居中、输出格式在末。
- prompt 一超过 200 字，就用分块标题（对 Claude 用 XML 标签）。
- 重复性工作存成模板，不要每次现编结构。
- 长寿 prompt 每季度审一次，它们会累积已经过时的约束。
- 发送前回读前 3 行，陌生人也应该知道要产出什么。
常见问题
越长的 prompt 一定越差吗？
不是。在大约 500 字、结构清楚的范围内，多放相关细节通常是有帮助的。退化是从”多出来的字开始稀释优先级、重复强调、或把任务埋进低注意力的中段”那一刻才开始的。一份分块干净的长 prompt（任务在顶、参考打标签、schema 在底）完全可以胜过一份又短又含糊的 prompt。决定成败的是结构，不是纯字数。
这跟撞到上下文窗口上限是一回事吗？
不是，这点经常被搞混。1400 字大约用 1900 token，离任何模型的窗口都远着。“中间迷失”的注意力偏置在你跑完上下文之前很早就在拉低质量了。截至 2026 年 6 月，连 Claude Opus 4.7、Gemini 3.1 Pro 这种 100 万 token 模型，也会在窗口填满之前就出现可测量的准确率下滑——所以更满的 prompt 并不是更好的 prompt。
最重要的指令应该放哪？
第 1 行，或者最后一块。模型对长输入的起头（首因）和结尾（近因）注意力最强。把唯一的交付物放在最前、输出 schema 放在最后。中间留给模型可以”去查”的参考数据，而不是它必须记住的规则。
ChatGPT、Claude、Gemini 之间有区别吗？
U 形注意力对三家都成立，但 Claude 对具名 XML 标签反应尤其好，而且 Anthropic 有文档说明：把问题放在文档之后，质量最多能提升 30%。对 ChatGPT 要注意：截至 2026 年 6 月，完整的 100 万 token 窗口只保留给 200 美元的 Pro 套餐；网页版 Plus 的上下文要小得多，所以过长的 prompt 会更早被截断或退化。
JSON 格式该写在 prompt 里还是用 API？
只要你做的是程序化的东西，就用 API 的结构化输出功能，而不是在 prose 里描述 schema。OpenAI 的 GPT-5.5 Structured Outputs 和 Anthropic 的 tool schema 都在服务端强制格式。OpenAI 明确建议：开了 Structured Outputs 就把 schema 描述从 prompt 里删掉。如果只是普通聊天框、没有 API，那就在 prompt 的最后一块放一个最小化的示例 schema。