给AI的提示词越写越长，效果反而变差：上下文预算该怎么分配

提示词工程有一个反直觉的现象：加得越多，效果越差。很多人第一次遇到时不敢相信——明明规则写得更细了，为什么模型反而不遵守？

原因是「指令稀释」，不是模型不听话。

一、为什么长提示词会失效

模型的注意力在长上下文里是分配不均的：开头和结尾的权重高，中间容易被忽略（这就是所谓的「中间遗忘」）。当你把 30 条规则依次排开，排在中间的那些最先失效。

第二层原因是冲突。规则越多，互相矛盾的概率越高。「回答要简洁」和「要给出充分理由」同时存在时，模型每次选哪个是不确定的。

第三层是优先级不明。模型无法区分「必须遵守」和「建议参考」，它会均匀对待所有句子。

二、给上下文分预算

一个可用的经验分配（以总预算为 100%）：

部分	建议占比	说明
角色与任务定义	10%	一两句话说清楚做什么
硬性约束	15%	必须/禁止，最多 5–7 条
输入数据	45%	文档、代码、用户问题
示例	20%	1–2 个高质量例子，不要堆
输出格式	10%	schema 或模板

最常见的失衡是「约束」和「示例」吃掉太多，把输入数据挤到一边。模型不是不知道规则，是没看到关键内容。

三、约束要分层，不要平铺

把所有规则写成一个大列表，是效果最差的结构。正确做法是分层：

【必须遵守】违反即视为失败
1. 只输出 JSON
2. 金额单位统一为人民币元
3. 缺失字段填 null

【优先遵守】
4. 优先使用表格中的原始表述

【参考】
5. 语气正式

层级的名字本身就是给模型的信号。实测显示，显式标注「必须」的规则遵守率明显高于平铺列表。

四、删掉四类无效内容

写提示词时，以下四类内容基本可以删：

1. 情绪化强调：「非常重要！！」「请务必仔细」——对模型没有额外作用，只是占用 token；
2. 重复表述：同一条规则用不同说法写三遍，还不如一遍写清楚；
3. 泛泛的期望：「请你专业、严谨、有洞察力」——这类词几乎没有可执行含义；
4. 过长的示例：示例的价值在「覆盖边界」，不在「长度」。两个覆盖正反例的短例，胜过一个大段完整案例。

五、示例的用法：一个正例 + 一个反例

最有效的示例结构是极简对照：

正例输入：退款申请，金额 300，理由为空
正例输出：{"type":"refund","amount":300,"reason":null,"need_review":true}

反例输入：退个款，300 块
反例输出（错误）：{"type":"refund","amount":300}   ← 不要像这样省略 need_review

反例能显式告诉模型「什么算错」，这在自由文本输出任务里尤其有用。

六、迭代方法：一次只改一处

提示词优化的正确姿势是像做实验一样：

1. 建一个 20 条的测试集，覆盖典型和边界；
2. 每次只改一处，跑一遍，看准确率变化；
3. 保留有效改动，回滚无效改动。

凭感觉加规则，最后往往得到一个又长又差的提示词，而且不知道哪条在起作用。

七、什么时候该拆提示词

如果你的提示词超过约 2000 字，且包含三个以上不同的子任务，说明它应该被拆开：每个子任务一个独立调用，中间结果落成结构化数据再传递。单次调用干太多事，是提示词臃肿的根源。

结论

好的提示词不是「写得全」，而是「写得准」。把预算优先留给输入数据，约束控制在七条以内并分层，示例只留正反对照，剩下的空间留给模型思考——这比继续加规则有效得多。