你贴了 1200 字：一段会议转录、3 条 Slack 消息、两段背景、4 条要求 bullet，末尾一个问题。所有内容的视觉权重一模一样，模型没有”哪段更重要”的地图。没有可锚定的东西时，它就退回去按长度估算——最长的那块是转录，于是它总结了转录，把你的要求忽略了。
这是分级问题，不是能力问题。模型不知道哪几行是承重墙，因为你从没标出来。这同时也是一个已知的注意力问题：语言模型对 prompt 开头和结尾的注意力最高、中间最低（即”lost in the middle”现象），所以埋在 prompt 中段的重要信息，权重恰恰最低。
最快的修法： 把任务和硬要求放进带标签的分块，把粘贴的长材料移进打了 tag 的块里，再把真正的问题放到 prompt 最底部。对于长输入（大约 20k+ token / 30 页以上），Anthropic 官方的建议是文档放前、问题放后——在它的测试里，把 query 放最后能让回答质量提升最多 30%（截至 2026 年 6 月）。
“lost in the middle”到底是什么意思
长上下文检索的研究发现了一条 U 形注意力曲线：在 20 篇文档的上下文里，把相关文档从第 1 位移到第 10 位时，多文档问答的准确率会掉 30 个百分点以上。模型没坏，它就是对窗口两端的权重高于中段。所以分级不是表面功夫——一个事实摆在 prompt 的哪个位置，直接影响模型对它”看见”多少。
Anthropic 一个有名的例子：在长上下文的大海捞针测试里，只在答案前面加一句 Here is the most relevant sentence in the context:，就把 Claude 2.1 的准确率从 27% 拉到了 98%。修好它的不是更强的模型，而是告诉模型该往哪看。
你属于哪一类
| 症状 | 可能原因 | 跳到 |
|---|---|---|
| 模型总结最长的那块，而不是回答问题 | 没有分块标签，默认按长度走 | Step 1 |
| 输出把代码、转录、规格搅成一团 | 多种输入类型混在一起，没有分隔 | Step 2 |
| 一条”必须”的要求被悄悄丢掉 | 硬规则写成了软 prose | Step 3 |
| 事实对，但强调错了重点 | 任务埋在 prompt 中段 | Step 4 |
| 模型把错误的来源当成权威 | 粘贴材料没有出处 | Step 2 |
| 长参考被整段无视 | 区块太长，没有摘要锚点 | Step 5 |
常见原因
1. 没有分块标签
一面 prose 墙逼着模型自己去推断上下文在哪结束、任务从哪开始。这个推断会挑出主导主题，通常就是背景。
如何判断： 没有 ## 标题，没有 Task: / 背景： 之类的标记，也没有一张要求清单。
2. 多种输入类型粘在一起
代码、转录、需求、截图转成的文字塞在一个块里。模型跨它们做平均，产出一个混血回答。
如何判断： 两种以上输入类型之间没有任何分隔（没有 tag、没有栅栏、没有标题）。
3. 硬要求埋在软 prose 里
如果能 X 就好了 和 我们绝对需要 Y 出现在同样的视觉权重上。模型读到了”绝对”，但周围的软语境把这个信号稀释了。
如何判断： 不可协商的规则写在段落里，而不是一张带标签、全大写的清单里。
4. 参考材料没有出处
你贴了三个来源的文字，却没标明哪段是哪个。模型把它们当成同等权威，哪怕一个是粗草稿、一个是已定稿的规格。
如何判断： 粘贴内容没有归属标头（没有 <source>、From: …，也没有点名文档的标题）。
5. 区块顺序不按优先级
短 prompt 里，任务落到了中段——注意力最低的地方。长 prompt 里，问题压在最顶上，排在模型回答它所需要读的文档之前。
如何判断： 结构倒置——背景占了高注意力位置，任务没占到。
动手前先确认
- 列出当前 prompt 里的每种输入类型（转录、规格、代码、邮件等）。
- 标出哪些行是硬要求、哪些是背景上下文。
- 定一个优先级顺序：模型最该关注什么？
- 确认每个粘贴的来源是否有清晰出处。
- 估一下大致 token 量。2000 字以内的表现，和 30 页的粘贴完全不同（见 Step 4）。
最短修复路径
Step 1：每一块都打标签
## 任务
<一句祈使句>
## 硬要求（不可协商）
- 要求 1
- 要求 2
## 软偏好（冲突时放弃）
- 偏好 1
## 背景上下文
<参考材料>
## 输出格式
<schema>可见的结构胜过推断出来的结构。Anthropic 的 prompt 指南给了一条黄金法则：把你的 prompt 拿给一个完全没有背景的同事，让他照着做。如果他会困惑该干什么，模型也会。
Step 2：给混源输入打上来源 tag
把每一块粘贴内容包进一个 tag，标明它是什么、来自哪里。这正是 Anthropic 推荐的多文档输入格式：
<documents>
<document index="1">
<source>standup-2026-05-21</source>
<document_content>
... 转录文本 ...
</document_content>
</document>
<document index="2">
<source>product-spec-v3</source>
<document_content>
... 需求 ...
</document_content>
</document>
</documents>块数不多时，更轻的内联写法也行：
<transcript source="standup-2026-05-21">
... 转录文本 ...
</transcript>
<requirements source="product-spec-v3">
... 需求 ...
</requirements>XML 风格的 tag 解析得很干净，因为模型靠 tag 就能区分指令和数据，而不用去猜。Markdown 栅栏也能分隔块，但 tag 还额外带上了出处，正好修掉原因 #4。
Step 3：用全大写关键词标硬规则
## 硬要求
MUST: 每个输出都包含客户订单号。
MUST NOT: 透露内部员工姓名。
MUST: 返回合法 JSON。MUST / MUST NOT 读起来比”应当”更强，因为它们对应 RFC 2119——这是 IETF 的惯例，模型从多年的规范和文档里吸收了它。有一个细节很关键：RFC 2119 里只有关键词写成全大写时才带规范性效力。小写的 must 读作普通行文。所以真正想要的不可协商项，关键词一定要大写。
Step 4：把任务放到注意力最高的位置
放哪取决于 prompt 有多长。
短 prompt（约 2000 字以内）： 开头和结尾的注意力最高，两头都用上。开头放任务和硬要求，最底部再把不可协商项重申一遍。
[顶] 任务 + 不可协商项
[中] 背景、转录、参考
[底] 输出格式 + 重申不可协商项长 prompt（大约 20k+ token / 30 页以上的粘贴材料）： 反过来。Anthropic 的长上下文建议是把长文档放在最上面、排在 query 之前，把真正的问题和指令放到最底部。在它的测试里，这个顺序能让复杂、多文档输入的回答质量提升最多 30%（截至 2026 年 6 月）。
[顶] <documents> ... 长粘贴材料 ... </documents>
[底] 任务 + 指令 + 输出格式两条规则之所以都成立，是因为背后是同一条 U 形曲线：别把你最需要模型去执行的东西放进死掉的中段。
Step 5：长参考加摘要，并让回答落在引文上
如果某一块超过约 200 字，前置一段两行摘要，让模型在看证据之前先拿到一张地图：
<reference source="customer-email">
<summary>客户对账单不满；关键论断是同一周期被收了两次费。</summary>
<full>
... 400 字邮件 ...
</full>
</reference>对于长文档任务，再加一条能稳定提升准确率的指令：让模型先引用相关片段、再回答。Anthropic 明确推荐这一招，帮模型从周围文本里”切穿噪音”：
Find the quotes from the documents above that are relevant to the
question, and put them in <quotes> tags. Then answer using only those
quotes. If nothing is relevant, say so.这强制让检索这一步发生在推理之前，而平铺 prompt 制造的恰恰就是反过来的失败模式。
Step 6：复用模板
对于反复出现的任务类型，把结构骨架（任务 / 硬要求 / 背景 / 输出格式）存下来，填槽即可。填模板比每次重搭结构快，也能防止版式漂回那面平铺的墙。
怎么确认已经修好
- 一个陌生人读完 prompt，能在大约 30 秒内说出任务、要求和背景。
- 输出处理的是真正的任务，而不是最长的那段。
- 每一条硬要求都出现在输出里。
- 出处站得住：模型引用一个事实时，你能追溯到某个
<source>tag。 - 重跑同一个 prompt，输出结构一致，而不是每次都换个形状。
如果还是没修好
- Prompt 可能就是太长了。在加更多结构之前，先剪掉那些不改变答案的背景。
- 硬要求可能太多。给它们排序、砍掉最弱的；十条”必须”读起来等于零条。
- 把长期有效的规则彻底搬出消息本身——放进 system prompt、Claude/ChatGPT Project 的自定义指令，或 Cursor 的 rules 文件——让它们跨轮次持久，而不是每次重新粘贴。
- 如果输入实在没法再短，换一个上下文窗口更大、对中段注意力更好的模型。截至 2026 年 6 月，Claude Opus 4.7、Sonnet 4.6 和 Gemini 3.1 Pro 都是 1M token 窗口；ChatGPT Plus 在应用内大约暴露 320 页，完整的 1M 上下文留给 $200 的 Pro 档。
常见问题
模型真的会更不仔细地读我 prompt 的中段吗？
会，而且是可测量的。在 20 篇文档的上下文里，答案从第 1 位移到第 10 位时，多文档问答准确率会掉 30 个百分点以上。把关键指令放在开头或结尾——别放中段——就能直接对冲它。
任务应该放 prompt 顶部还是底部？
短 prompt：开头放任务，结尾再重申不可协商项。粘了大段文档的长 prompt（约 20k+ token）：文档放前、任务放后——Anthropic 测得”以 query 结尾”能带来最多 30% 的质量提升。
我必须用 XML tag 吗，Markdown 行不行？
两者都能分隔块。XML 风格 tag 有一个优势：像 <source>product-spec-v3</source> 这样的 tag 带着出处，模型就能分辨哪段粘贴更权威。需要标明来源时用 tag，不需要时栅栏就够了。
为什么 MUST 和 MUST NOT 要大写？
因为 RFC 2119 惯例只对全大写的形式赋予规范性效力。小写的 must 读作普通行文。在规范上训练过的模型会把 MUST NOT 当成硬性禁止——这正是你对一条不可协商规则想要的效果。
这些都做了，要求还是被忽略，怎么办？
先减少要求数量（排序后砍掉最弱的），再加上 Step 5 里那条引文落地指令，让模型先检索再推理。如果还是漏，就把规则搬进 system prompt 或 project 指令，让它不必和粘贴材料抢注意力。
预防建议
- 默认规则：任何超过约 200 字的 prompt 都用带标签的分块。
- 每种反复出现的任务类型留一份模板，骨架预先就位。
- 多源拼接时，每段粘贴都打上来源 tag。
- 硬规则用
MUST/MUST NOT（大写）；“应当”留给偏好。 - 长输入默认采用”文档在前、问题在后”的顺序。
- 团队里，商定一套共享的分块分类，让所有人的 prompt 读起来一致。
相关阅读
外部参考：Anthropic 长上下文 prompt 指南 与 RFC 2119 的要求关键词定义。