你贴了 1200 字：一段会议转录、3 条 slack 消息、两段背景、4 条 bullet 要求、末尾一个问题。所有内容视觉权重一样。模型把它们当同等重要，按长度估算——最长的是会议转录，于是它总结了转录，忽略了要求。模型没地图。没显式层级（分块、标签、优先级标记）时，模型默认走”最长的段是主题”，几乎从不是你想要的。
本文讲怎么给平铺 prompt 加结构，怎么标硬要求让它在背景噪音里活下来。
常见原因
1. 没分块标签
你写了一面 prose 墙。模型自己推断上下文止、任务始。推断挑主导主题，通常是背景。
如何判断：没 ##、任务：、背景： 或其他标记。
2. 多种输入类型粘一起
代码 + 转录 + 需求 + 截图转文字塞一块。模型跨它们平均，产出混血回答。
如何判断：多个输入类型，块间无分隔。
3. 硬要求埋在软 prose 里
“如果能 X 就好了” + “我们绝对需要 Y” 视觉权重相同。模型读到”绝对”但被软语境淹没。
如何判断：硬要求写成段落，不是标签清单。
4. 参考材料没出处
你贴了 3 个来源的文字没说哪个是哪个。模型把它们当同等权威，哪怕一个是草稿一个是终稿。
如何判断：粘贴内容没归属标头。
5. 区块顺序不按优先级
长背景在前，任务在后。模型最关注首尾位置。任务在中间最不被关注。
如何判断：结构倒置——背景压顶。
动手前先确认
- 识别当前 prompt 里每种输入类型。
- 标出哪些是硬要求、哪些是背景。
- 定优先级：模型该最关注什么？
- 规划分块标题和标签。
- 检查参考材料是否有清晰出处。
需要收集的信息
- 你能识别出分块的当前 prompt。
- 强调了错内容的输出。
- 你真实的硬要求清单。
- 每个输入源 + 它的权威级别。
- 模型 + system prompt。
最短修复路径
Step 1：每块都标签
## 任务
<一句祈使>
## 硬要求（非协商）
- 要求 1
- 要求 2
## 软偏好（冲突时放弃）
- 偏好 1
## 背景上下文
<参考材料>
## 输出格式
<schema>可见结构胜过推断结构。
Step 2：混源输入打标签
<transcript source="standup-2026-05-21">
... 转录文本 ...
</transcript>
<requirements source="product-spec-v3">
... 需求 ...
</requirements>
<slack source="incident-channel">
... slack 消息 ...
</slack>XML 风格 tag 很好用。Markdown 栅栏也行。重点是机械分隔。
Step 3：硬规则强调
## 硬要求
**必须**：所有输出包含客户订单号。
**禁止**：透露内部员工姓名。
**必须**：返回 JSON。MUST / MUST NOT 比”应当”强，因为模型内化了 RFC 2119 习惯。
Step 4：按优先级排序
Prompt 头尾是最高注意位。用来放：
- 顶部：任务 + 非协商项
- 中部：背景、转录、参考
- 底部：输出格式 + 非协商项重申
[顶] 任务 + 非协商
[中] 背景、转录、参考
[底] 输出格式 + 非协商提醒Step 5：长参考加摘要
区块超 200 字时前置 2 行摘要：
## 参考：客户邮件
<summary>客户对账单不满；关键论断：同一周期被收了两次费。</summary>
<full>
... 400 字邮件 ...
</full>模型用 summary 当”地图”，full 当证据。
Step 6：复用模板
常做任务存结构模板。填槽比每次现编快，也防结构漂。
怎么确认已经修好
- 陌生人 30 秒能列出 任务/要求/背景。
- 输出处理的是真任务，不是最长段。
- 硬要求全部出现在输出里。
- 出处保留：模型引用事实时可追溯到来源 tag。
- 重跑输出结构一致。
如果还是没修好
- Prompt 可能还是太长——剪掉不改变答案的背景。
- 硬要求可能太多——排序砍掉底部。
- 硬要求挪到 system prompt 或 project 指令持久化。
- 上下文不能再短就换长上下文注意力更强的模型。
预防建议
- 默认：超 200 字的 prompt 都用分块标签。
- 每种任务类型维护带结构骨架的模板。
- 多源粘贴时一定打出处 tag。
- 硬规则用 MUST / MUST NOT；“应当”留给偏好。
- 审生产 prompt：无结构且超 200 字的都算风险。
- 团队工作流商定分块分类，让大家的 prompt 读起来一致。