200 Token 的系统提示词如何击败你的 4000 Token 提示词

我合作过的一个团队花了六个月的时间，将一个系统提示词（system prompt）调整到大约 4000 个 token。这是他们的镇店之宝——通过不断累积边缘情况处理、格式规则、人设指令、回退行为以及十几个 few-shot 示例而精心打造。后来，一名初级工程师加入，问为什么提示词这么长，并用一个下午的时间重写了它。新版本只有 200 个 token。在他们现有的评估集上，它的得分高出了 4 分。运行成本也降低了 40 倍，而且速度明显变快。

这并不是一个关于神奇短提示词的轶事。这是我几乎在每次阅读运行超过一个季度的生产级系统提示词时都会看到的模式。长提示词是随意的累加，而非设计的结果。QA 中出现的每个失效模式都贡献了一个段落。观看演示的每位利益相关者都贡献了一条语气指令。每个“似乎有帮助”的例子都被固定在了底部。结果就是，提示词比它要引导的用户输入还要长，充斥着模型在推理时必须默默解决的内部矛盾，注意力被稀释在各种相互竞争的需求中。

关于这方面的研究已经很明确，而且越来越难以忽视。Chroma 的上下文腐烂（context-rot）基准测试对 18 个前沿模型进行了测试，发现每一个模型都会随着输入长度的增加而性能下降——有些缓慢，有些剧烈，但趋势是一致的。Anthropic 自己关于上下文工程的论述也非常直白：目标是“能够最大限度提高预期结果可能性的最小高信号 token 集”。微软的 LLMLingua 表明，在 GSM8K 等推理基准测试中，提示词最多可以压缩 20 倍，而性能损失仅为 1.5% 左右。2026 年初的一项关于评估驱动提示词迭代的研究发现，特定任务的短提示词通常优于通用的长提示词——而且在测试的每个数据集中，长提示词生成的响应都更慢、更模糊。

然而，大多数团队仍在不断增加文本。这篇文章将探讨其原因，以及如何摆脱这种困境。

提示词之所以通过累加而增长，是因为失效反馈循环是不对称的

当模型出错时，最廉价的修复方法就是加一句话。审阅者可以在 15 秒内读完 diff。下一次评估运行显示 bug 消失了。发布。

当模型表现正确时，没有人会写一个删除补丁。没有失败可以指责，也没有显而易见的理由去删掉六周前为了修复利益相关者在演示中注意到的问题而添加的段落。所以提示词只会不断膨胀。其他生产代码都会经历的垃圾回收步骤——重构、删除死分支、需求演变后的简化——从未在提示词上执行过。

结果是可预见的。团队最终得到的系统提示词中，大约三分之一的 token 是为了处理新版本模型不再产生的 bug，另外三分之一是为了解决仅在少数用户群体中出现的失效模式，剩下的三分之一才是在做实际工作。模型在处理每个请求时都在为阅读那些对行为毫无影响的指令支付推理成本。

长提示词不仅耗费金钱，还会主动降低质量

大多数工程师的直觉是，指令越多，行为就越可靠。但实证研究的结果恰恰相反，这其中有几个机械性的原因。

首先是注意力稀释。Transformer 的注意力预算是有限 of 的。每个 token 都会为了模型的关注与其他 token 竞争。当提示词包含 4000 个 token 的指令时，模型对“用户实际请求”的注意力只是大蛋糕中的一小块。研究测量到推理能力在 3000 个 token 左右开始下降——这远低于广告宣传的上下文窗口——而且下降曲线会变得越来越陡峭。

其次是指令之咒（curse of instructions），这是 2025 年一篇 OpenReview 论文中对该问题进行的量化命名。模型满足所有 N 条指令的概率，大约是单条指令成功率的 N 次方。一个单条指令遵循率为 95% 的模型，同时遵循 10 条指令的概率约为 60%，同时遵循 20 条指令的概率约为 36%。如果团队为了“确保”模型处理罕见的边缘情况而在提示词中添加第 20 条要点，那么从数学上讲，他们就是在保证其他 19 条指令的性能会下降。

第三是矛盾。几乎每个长提示词都包含在某些输入子集中相互冲突的指令对。“简洁”与“始终提供示例”冲突。“始终引用来源”与“以对话方式回答”冲突。“从不推测”与“在用户询问意见时提供帮助”冲突。模型必须在推理时默默解决这些问题，而解决方式是非确定性的。你添加了第二条指令来修复一个 bug，却在其他地方引入了另一个 bug，而你从未将两者联系起来。

第四是位置偏差。Transformer 表现出近因偏差和首因偏差——长提示词中间的指令权重低于开头或结尾的指令。一个 10,000 token 的提示词实际上可能表现得像一个 2,000 token 的提示词，中间部分被悄悄降级了。如果团队将最重要的规则放在 200 行提示词的第 87 行，那么他们构建的系统在开发者的笔记本电脑上能运行，但在生产环境中会悄无声息地丢掉规则。

精简纪律：将 Token 视为预算，而非免费赠品

发布短 prompt 的团队并不比别人更擅长写 prompt。他们只是执行了一套长 prompt 团队没有的纪律。这里有四个实践，按影响力排序。

定期进行精简审查。 每季度一次，或者每当 prompt 超过某个 token 阈值时，安排一次明确的审查，每一部分内容都必须根据当前的评测案例（eval cases）证明其存在的合理性。如果某个段落是为了修复一个在当前模型版本中已不再复现的 bug 而添加的，就将其删除。如果删掉某个少样本示例（few-shot example）对评测性能没有明显影响，也将其删除。精简时的默认动作是删除而非保留；你必须通过实力来为一段内容的继续存在“赚取”资格。

审计矛盾点。 将 prompt 放入检查器中运行——用另一个 LLM 来做这件事就很好——标记出在某些可能的输入下会产生冲突的指令对。大多数团队会发现，在任何维护超过几个月的 prompt 中，总会存在 5 到 15 个真正的矛盾点。每一个矛盾点都是模型在运行时的一次抛硬币行为，而团队对此甚至尚未察觉。

根据边际贡献削减少样本示例。 针对每个示例，尝试在删除该示例的情况下运行评测集。那些删除后不会导致质量明显下降的示例，就是在白白消耗推理税（inference tax）而没有带来任何质量收益。大多数团队会发现，在 7 个示例中，真正起作用的只有两三个；其他的加入只是因为觉得“多多益善”，且从未被重新审视。

倾向于使用特定任务的覆盖层，而非臃肿的前导内容。 一个试图涵盖所有产品功能的 4,000 token 系统提示词，其效果几乎总是差于一个 200 token 的核心 prompt 加上若干个几百 token 的特定任务覆盖层。模型在处理每个请求时只需关注一组范围紧凑的指令，prompt 整体保持了可维护性，且单个任务的迭代不会影响到无关行为。这与微服务优于单体架构的逻辑相同——虽然协调成本确实存在，但单个共享代码块中冲突带来的代价更高。

评测才是真正关键的部分

如果没有评测集（eval suite），这一切都无从谈起。长 prompt 之所以长期存在，是因为在缺乏衡量标准的情况下，每一段看起来都像是起支撑作用的“承重墙”。而有了衡量标准，你会发现三分之二的内容显然不是。精简审查本质上是一系列 A/B 测试：“删除这一部分会改变评测得分吗？”如果你无法运行这种测试，你就无法在那些坚持认为某段内容很重要的工程师面前为“删除”正名。你每次都会输掉争论，而 prompt 则会持续膨胀。

用于 prompt 精简的评测集不需要太复杂。它需要覆盖那些真正关键的失败模式——即一旦发生退化会导致用户投诉的问题——并且每个模式要有足够的示例，以便你能从噪声中检测出真实的性能偏移。对于大多数团队来说，分布在十几个失败类别中的几百个示例就足够了。但绝对不能是“我们针对三个测试案例运行 prompt 然后凭感觉检查（check vibes）”。

能够做好 prompt 精简的团队，通常也会在生产环境之外维护一个“挑战者”提示词。挑战者更短。每次发布时，都会让挑战者在当前的评测集上运行。当挑战者打平或击败生产环境版本时，挑战者就变成生产版本，并开始一个新的、更短的挑战者。这让 prompt 最小化成为一种持续的实践，而不是一个总是被推迟的周期性项目。

200 Token 到底是什么样的

怀疑的读者会问，对于一个真实产品，200 token 是否现实。答案是这取决于产品，但门槛其实比大多数团队想象的要低。一个针对单一产品线的专注型客户服务助手，可以装进 200 token 的系统提示词加任务特定上下文。一个代码审查机器人可以装进 300 token 的指令加 Diff 内容。一个生成结构化输出的提取 Agent 可以装进 150 token 加 Schema。

200 token 装不下的是“一个处理跨越所有产品面、涉及我们讨论过的所有角色变化的每一次客户互动的助手”。这本身不是一个提示词工程问题；而是一个伪装成技术问题的范围管理（scope）问题。试图将这类 prompt 压缩到 200 token 的团队注定会失败，因为这个 prompt 承担了三个从未被拆分的独立 prompt 的工作。

大多数团队最终会痛苦地意识到，prompt 的简洁性并不是一个可以调节的参数。它是一种处于下游的工艺，源自清晰的产品范围定义、诚实的评测集，以及删除那些没人愿意站出来辩护的内容的意愿。那些试图通过增加更多文本来优化“护栏”的团队，其模型在处理每个请求时都在交税，去读取那些并不能改善其行为的指令。而那些发布短 prompt 的团队，则是已经决定了 prompt 到底是为了什么而存在的团队。

核心结论

每一个超过一千个 token 的提示词（prompt）都值得进行一次成本预算讨论。我读过的一半生产环境中的系统提示词，长度都可以缩减到原来的四分之一，而且在团队自有的评估集（eval suite）上的得分会持平甚至更高 —— 如果他们有评估集的话。另一半提示词在缩减后得分会下降，而这正是真正的信号：评估（eval）现在成了团队可以使用的工具，可以根据证据来保留或删除段落，而不是取决于在提示词评审会议上谁的嗓门最大。

安排一次压缩迭代。审计矛盾之处。修剪你的 few-shot 示例。维持一个挑战者（challenger）提示词。那个击败你 4,000 个 token 提示词的 200 个 token 的提示词并非什么戏法；它是如果你一直都在进行测量，本就该写出的提示词。