Prompt Length vs. Context Window：LLM 性能背后的真实限制

Source: Dev.to

大型语言模型在过去两年里发展得异常迅速。
GPT‑5.1、Gemini 3.1 Ultra、Claude 3.7 Opus——这些模型现在可以一次性读取整本书。

但 LLM 记忆的物理定律 并没有改变。每个模型仍然只有有限的 上下文窗口，提示长度必须围绕这一约束进行设计。如果你曾经遇到过：

• “模型为什么忽略了第 3 节？”
• “为什么输出突然变得模糊？”
• “处理长文档时模型为什么会产生幻觉？”

……那么你已经目睹了提示长度与上下文限制管理不当的后果。

1. 上下文窗口到底是什么

上下文窗口是模型的 工作记忆：在同一个“记忆缓冲区”中同时存放你的输入 和 模型的输出的空间。

Token：真实的记忆单位

• 1 个英文 token ≈ 4 个字符
• 1 个中文 token ≈ 2 个字符
• “Prompt Engineering” ≈ 3–4 个 token

所有计费都以 token 为单位。

输入 + 输出必须一起容纳

以 GPT‑5.1 的 256 k token 窗口为例：

如果超出窗口，模型可能会：

• 驱逐旧 token
• 以有损方式压缩信息
• 完全拒绝请求

2. 提示长度：影响模型质量的隐藏力量

2.1 提示太长 → 溢出、信息丢失、性能下降

当模型超负荷时会出现三种反应：

• 硬截断 – 早期或后期的内容被直接丢弃。
• 语义压缩 – 模型隐式地进行摘要，往往会扭曲人物设定、数值或边缘案例。
• 注意力崩塌 – 密集的注意力图导致回答模糊。这是数学限制，而非 bug。

2.2 提示太短 → 通用、浅薄的输出

Gemini 3.1 Ultra 拥有 200 万 token 的上下文。一个 25 token 的提示，例如：

“Write an article about prompt engineering.”

只使用了其记忆容量的 0.001 %，模型缺乏受众、约束或目的，结果往往是毫无灵魂、充满 SEO 词汇的碎片。

2.3 长上下文模型改变了游戏规则——但规则本身未变

即使拥有百万级 token 窗口，基本规则仍然不变：

强大的记忆 ≠ 好的指令。
好的指令 ≠ 长篇大论。
好的指令 = 适度的细节。

3. 控制提示长度的实用策略

步骤 1 — 了解你的模型

根据提示与预期输出的总大小选择模型。

模型与需求不匹配会导致不稳定、错误率升高以及更多幻觉。

步骤 2 — 统计你的 Token

实用工具：

• OpenAI Token Inspector – 支持多文档、PDF、Markdown。
• Anthropic Long‑Context Analyzer – 显示 “注意力饱和度” 与截断风险。
• Gemini Token Preview – 当接近窗口的 80–90 % 时预测降级情况。

经验法则： 只使用 70–80 % 的完整上下文窗口。

• GPT‑5.1 (256 k) → 安全使用约 180 k token
• Gemini Ultra (2 M) → 安全使用约 1.4 M token

步骤 3 — 智能裁剪

当提示膨胀时，删除噪声而非意义。

1. 结构胜于散文 – 将段落改写为紧凑的要点列表。

2. 语义打包 – 合并相关属性：

   [Persona: 25‑30 | Tier‑1 city | white‑collar | income 8k RMB | likes: minimal, gym, tech]

3. 将示例移到尾部 – 模型仍能学习风格，却不增加指令 token。

4. 对长文档分桶 – 对任何 > 200 k token 的内容：

   Bucket A: requirements
   Bucket B: constraints
   Bucket C: examples
   Bucket D: risks

   先喂入一个桶 → 摘要 → 再喂入下一个桶 → 最后整合。

步骤 4 — 当提示过短时补充深度

如果你的提示使用

You don’t write long prompts; you allocate memory strategically.