一个客服助手把"所有可能的情况"都写进系统提示，长度 6000 token。上线后质量问题反而更多：模型开始漏掉后半段的要求，并且在简单问题上给出过度谨慎的回答。查下来是两个效应叠加：长提示的信息密度下降（重要规则被淹没），以及每轮成本与延迟翻倍。
提示长度不是"越多越保险"，而是有一条"有效区间"：太短缺少约束，太长则互相干扰。而多数团队只经历过前者的痛苦，于是在后者上踩坑。
1. 三个成本维度
| 维度 | 影响 |
|---|---|
| 金钱（token 计费） | 线性增长 |
| 延迟（prefill） | 线性增长 |
| 质量（注意力稀释） | 非线性（先稳后降） |
第三项最容易被忽略：模型对"位置"敏感（开头与结尾更容易被遵循），于是 6000 token 中间的要求形同虚设。
而"质量先稳后降"意味着"加长提示"在某个点之后同时增加成本与降低质量这个"拐点"的位置取决于"信息密度"：去重彻底、结构清晰的 4000 token 可能还没有到拐点，而散乱堆砌的 1500 token 已经到了。
——这时它没有任何可取之处。
2. 提示的"有效区间"
| 长度 | 表现 |
|---|---|
| < 200 token | 约束不足，输出漂移 |
| 200–1500 | 通常最好（密度高、可遵循） |
| 1500–4000 | 需分节与小结 |
| > 4000 | 必须重构（拆任务/给结构） |
第三项的做法是"分节 + 每节有标题 + 结尾重申关键约束"，因为模型对"结构化的文本"遵循得更好。
第四项（>4000）的处置不是"删到 1500"，而是"先结构化，再看还剩多少"。因为很多"必要信息"结构化之后 token 数会自然下降（去掉了重复的过渡句与同义表述）。
第四项说明"长提示不是问题，无结构的堆砌才是问题"——一个 6000 token 但结构清晰、去重彻底的提示，可能比 2000 token 的散乱提示更好。
3. 五个"提示膨胀"的来源
| 来源 | 处理 |
|---|---|
| 历史踩坑案例堆叠 | 合并成规则 |
| 重复表述同一要求 | 去重 |
| 示例给太多 | 留 2–3 个代表性 |
| 大段背景介绍 | 移到用户消息或检索 |
| 输出格式的详细描述 | 用 schema/模板 |
第一项最常见：每次出问题就加一条"不要…"，于是提示变成一部事故史。第一项的机制是"规则的边际价值递减"：第一条"不要编造"作用很大，第十条"不要用感叹号"几乎为零，而它们占用同样的注意力。
而"加规则"的正确做法是"改规则"——把三条相关规则合并成一条更准确的。
第四项还有个"位置"理由：背景放在开头，会把"真正的指令"推到中间——而中间是最容易被稀释的位置。所以"背景外移"同时改善成本与遵守率。
第四项能省一半 token："公司背景、业务介绍"通常在"该做什么"上没贡献，而它们占了几千字。
// 提示瘦身的四个动作（按收益排序）
1 去重：同一要求出现 5 次的，合成 1 条
2 合并：三条"不要 X"的规则 → 一条"只做 Y"的正面规则
3 外移：背景材料移到检索/用户消息，只在需要时给
4 结构化：分节 + 标题 + 结尾重申三条核心约束
"提示瘦身"要有可验收的判据，否则会变成"凭感觉删"。两个判据就够：token 数下降 30% 以上，且规则命中率不下降。
// 瘦身的三步验收
1 记录基线：token 数、20 条抽检的规则命中率
2 瘦身：去重 + 正面化 + 外移背景
3 复测：token 降幅 ≥30%，命中率不低于基线
// 若不达标 → 回滚，别"再删一点试试"
4. 长提示的两种拆分方式
| 方式 | 适用 |
|---|---|
| 拆任务（多个短提示） | 任务可分解 |
| 拆阶段（先分类再处理） | 需要选择分支 |
| 用检索替代 | 知识型内容 |
| 用微调替代 | 风格/格式固化 |
第一项最有效：**"一个提示做五件事"改成"五个提示各做一件"**第一项的成本要说清：拆成五个提示意味着五次调用，于是"总 token 可能更多"。所以它适合"质量优先"的任务，而不是"成本优先"的任务。
，每段都短，而质量通常更好——因为每次的注意力都集中在一件事上。
第三项是最容易被忽视的"减法"：把"知识"从提示移到检索，于是提示只保留"怎么用知识"。
"位置敏感性"还有一个工程化的用法：把"最重要的三条约束"同时放在开头与结尾。这不是"重复"，而是"针对位置稀释的冗余"——而它的成本远低于"把整段规则再写一遍"。
// 三段式布局（对长提示有效）
[开头 3 行] 角色 + 三个核心约束（关键）
[中间 N 段] 细则、示例、格式要求（可被稀释）
[结尾 3 行] 三个核心约束重申（与开头一致）
// 判据：把这三条单独抽出来，能否独立描述"这个助手该做什么"
5. 怎么量"是否过长"
| 指标 | 判据 |
|---|---|
| 规则命中率 | 抽查输出是否违反某条规则 |
| 首尾 vs 中间 | 中间规则是否被忽略 |
| 成本/token | 每请求成本 |
| 延迟 | prefill 时间 |
第二项的实验设计要控制变量：同一批输入、同一模型版本、只改位置。否则"遵守率差异"可能来自输入分布，而不是位置。
第二项是关键实验：把同一条约束分别放在开头、中间、结尾，测遵守率。若"中间"明显更低，说明提示已经过长（需要重申或分节）。
第一项最实用：每周抽 20 条输出，逐条核对"是否违反明确写过的规则"。违反率高且集中在后半段规则 → 提示过长。
"结尾重申"要用"三条以内"的形式，否则重申本身也变成噪声：
// 结尾重申（示例，三行）
必须遵守：
1 只依据检索到的资料回答，无依据就说"资料中没有"
2 输出只包含三段：结论 / 依据 / 下一步
3 涉及金额必须给单位与币种
// 关键：与正文不重复表述，只做"最关键的几条"的提醒
6. 排错：五种"长提示导致的问题"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 规则莫名不遵守 | 位置稀释 | 结尾重申/分节 |
| 简单问题答得过度谨慎 | 大量"不要…" | 改正面表述 |
| 成本翻倍质量没涨 | 冗余内容 | 去重/外移 |
| 输出格式时好时坏 | 格式说明太长 | 用 schema |
| 不同请求表现差异大 | 提示与输入互相干扰 | 拆任务 |
第二项很典型："不要承诺、不要猜测、不要…"堆十几条之后，模型对"什么该做"反而不清楚第二项的正解是"用正面表述替代禁止"："不要编造政策"改成"只依据检索到的政策原文回答，无依据时说不知道"。后者给出了"该做什么"，而前者只给"不该做什么"。
——因为提示里"禁止"多于"允许"。
最后一个"监控"建议：把提示的 token 数作为发布指标。因为它会悄悄增长（每次加一条规则），而"成本翻倍"这件事在账单上出现时，已经过去一个月。
// 两个可跟踪的数（按版本）
prompt_tokens（system） → 每次发布记录；环比涨 >20% 需说明
cost_per_request → 结合流量看"是否被提示拖高"
// 用法：把它写进发布的检查单，而不是等账单
7. 边界：什么情况长提示是合理的
| 场景 | 为什么 | 做法 |
|---|---|---|
| 复杂格式与规范（如合同模板） | 需要精确 | 用 schema + 少量说明 |
| 多步流程（有分支） | 需要完整 | 分节 + 编号 |
| 强合规要求 | 每条都要在 | 结构化 + 结尾重申 |
| 少量高频调用（成本不敏感） | 成本影响小 | 可长，但要看质量 |
最后一条与"演进"有关的边界：提示会自然膨胀（每次事故加一条），所以需要"定期瘦身"这个动作。建议每季度做一次"去重 + 结构化"，把它从 6000 拉回 2000——而这件事通常没人做。
判断口径一句话：这条内容"模型不知道会做错"还是"说了它也记不住"。前者值得写；后者写了也会被稀释——此时该做的是"拆任务"或"用检索"，不是"再写一遍"。
8. 自测
- 长提示的三个成本维度里，哪一个是"非线性"的？"质量先稳后降"意味着什么？
- 提示的"有效区间"大致是多少？超过 4000 token 时该做什么？
- 五个"膨胀来源"里，哪一个让提示变成"一部事故史"？正确的"加规则"该怎么做？
- "把知识移到检索"为什么是一种减法？它改变了提示的什么职责？
- 怎么验证"中间规则被忽略"？"规则命中率"怎么测？
- 判断"长提示是否合理"的那个问题是什么？