提示词写得越长效果越差：上下文预算才是关键

有人把提示词写到两千字，规则列了三十条，从语气到格式到禁用词全覆盖。结果模型的输出依然不稳定，规则之间开始互相打架。

直觉是“说得越清楚越好”，但模型的注意力是有限资源。上下文里每多一句无关内容，其他指令分到的注意力就少一点。

为什么长提示词经常更差

第一是指令冲突。三十条规则里总有互相矛盾的，比如既要简洁又要详实，既要口语又要专业，模型只能随机取舍。

第二是稀释。关键约束藏在一堆补充说明中间，权重被平均掉了。

第三是示例污染。塞进去的示例如果风格不统一，模型学到的就是你无意中示范的混乱。

一个更省力的三层结构

• 目标层：这次要产出什么，给谁看，用来解决什么问题（一到两句）
• 约束层：三到五条硬要求，只留真正会改变输出的
• 示例层：一到两个优质样例，比十条形容词更有效

按这个结构整理，通常能从两千字压到四百字以内，输出质量反而更稳。约束越少，每一条被执行得越彻底。

用正向描述替代否定清单

“不要用第一人称、不要用问句、不要太长”这类否定指令，模型需要先理解什么是要禁止的，再绕开它，成本高且容易漏。

换成正向描述：“用第三人称陈述，每段不超过两句，全文三段”。同样的意图，正向表达更容易被准确执行。

一个客服场景的对照

某团队做客服回复生成，最初把公司规范整段贴进提示词，规则密密麻麻，人工修改率一直很高。

后来只保留八条：称呼方式、道歉的条件、可承诺的范围、必须转人工的三种情况、结尾动作。规则砍掉大半，人工修改率明显下降。

省下来的两千字没有变成能力，只是变成了噪声。

两个常见误区

误区一是把多个任务塞进一次调用。让模型同时摘要、翻译、改写、评分，结果每项都做得含糊。拆成两次调用，总成本往往更低，质量更高。

误区二是把提示词当成一次性文档。它应该像代码一样有版本，每次只改一处，再看输出变化，否则你永远不知道是哪句话起了作用。

把提示词当配置文件来管理

一个实用习惯是给提示词标上版本和日期，每次只改一处，记录改动前后的输出差异。积累十几条记录后，你就知道哪些表述在自己的场景里真正有效。

另一个习惯是把提示词拆成固定部分和可变部分：角色与约束保持不动，任务信息在调用时替换。调整的变量越少，判断越可靠。

提示词管理最终拼的不是措辞技巧，而是你是否有稳定的评估方式。

还有一点常被忽略：提示词的效果依赖具体的模型和版本。同一份提示词换了模型可能表现完全不同，所以记录时最好同时写清使用的模型，否则积累下来的经验无法复现。

立刻可以做的删减测试

拿出你正在用的提示词，逐条删掉一条，跑五次，看结果是否变差。没变差就永久删除。

把剩下的约束按重要性排序，只保留前五条，放在最前面。

最后补一个真实样例，用你认可的成品做示范。一个准确的样例，常常抵得上十条抽象描述。