旧提示词正在让 Claude 变差：Anthropic 工程师谈提示词审计、提示缓存与评估设计

在 AI Engineer 纽约大会的演讲《Your Old Prompts Are Making Claude Worse》中，Anthropic 技术团队成员 Lance Martin 指出：许多来自数代模型之前的提示词习惯，如今正在推高 Claude 等前沿模型的成本并拉低输出质量。本文梳理这场演讲的三个核心内容：通过提示词审计清除过时指令、按照严格前缀匹配的原则正确使用提示缓存，以及设计足够好的评估体系（eval），让提示词优化有数据可依而非凭感觉。

快速回答

• 当前的前沿模型已经能自主推理并自我检查结果。 "请一步一步思考""请再检查两遍""请尽可能详尽"这类指令是模型较弱年代的习惯；保留它们只会多烧 token，还可能降低质量。
• 提示词和代码一样会积累"债务"。 指令层层叠加、彼此矛盾，会让模型难以遵循；解决办法是定期做提示词审计（prompt audit），清除冗余。
• Claude Code 已内置提示词审计功能： 面向调用 API 的代码可用 /claude-api prompt-audit，面向 Claude Code 自身配置可用 /doctor prompt-audit（别名 /checkup）。
• 提示缓存按严格前缀匹配（strict prefix match）： 提示词开头改动一个字符，其后全部缓存都会失效。应把固定内容（系统提示词、工具定义）放在最前面，把变化内容放在最后面。
• 据 Anthropic 在演讲中公布的内部基准，正确使用提示缓存可降低最高 72% 的成本； 一个"爬山"式（hill climbing）优化案例通过换用更强的模型并降低 effort 档位，成本降低 90% 的同时性能还得到提升。
• 好的评估必须让模型能"爬得上去"： 评分标准清晰，并将数据划分为 train/test 两部分，避免对测试本身过拟合。

什么是提示词审计？

提示词审计（prompt audit）是对正在使用的整份提示词——系统提示词、指令、示例——逐条审查并分类：保留、删除、改写或移动位置。其目的是清除那些为早期模型世代添加、如今已不起作用、甚至相互矛盾并拖累质量的指令。

什么是提示缓存？

提示缓存会把提示词开头（前缀）已被模型处理的部分保存下来，供后续调用复用，而不必从头处理。由于缓存匹配严格按前缀进行，所有固定内容必须排在最前面并且逐字保持不变；开头只要有一处小改动，其后缓存全部作废。

为什么旧的提示词习惯不再适合前沿模型？

Martin 认为，提示词会像代码一样随时间膨胀：每一代模型，用户都会再加一层"技巧"——要求模型一步一步思考、反复自我检查、用 scratchpad 标签写草稿，或者用频繁调用工具来"防偷懒"。在模型较弱的年代，这些技巧曾经是必要的。

问题在于，如今的前沿模型已经能自主推理、自行判断何时需要深入思考，并主动复查自己的输出，不需要再被提醒。当用户继续把旧指令塞进提示词，后果有两方面：一是为不产生价值的文字多付 token 费用；二是重叠、矛盾的指令可能让模型表现更差。在 Vietnam Java User Group 分享这场演讲的 Linh Vu 也表示，这与他个人体验一致：提示词越简短利落，模型处理得越顺、越准。

Claude Code 的提示词审计如何使用？

演讲介绍了直接集成在 Claude Code 里的审计机制，有两个入口：面向调用 Anthropic API 的代码使用 /claude-api prompt-audit，面向 Claude Code 配置本身使用 /doctor prompt-audit（别名 /checkup）。审计工具会读取当前提示词，把每一行分为四类——保留（keep）、删除（remove）、改写（rewrite）、移动（move），附上置信度，并提出 diff 形式的修改建议，由用户审批后再生效。

值得注意的是，审计不会盲目删除：每项改动都附带理由，最终决定权在人。Martin 用一个内部评估作为例证：以 50 个合成客服工单模拟从 Opus 4.8 升级到 5.5，在去掉旧习惯并运行审计之后，质量上升而成本进一步下降。

提示缓存的黄金原则是什么？

演讲最强调的原则是严格前缀匹配：只有当提示词开头在多次调用之间逐字完全一致时，缓存才有效。只要在开头改动一个字符——例如把时间戳注入系统提示词——其后全部缓存都会失效，该次调用只能按完整 token 价格计费。

正确做法是按稳定性递减排列提示词：系统提示词与工具定义（几乎不变）放最前面，变化较慢的上下文放中间，不断变化的对话内容放最后面。Anthropic 表示，按此方式其内部基准的成本最高可降低 72%，且质量保持不变。

"爬山"式优化如何降低成本？

演讲提出用 hill climbing 循环代替凭感觉改提示词：提出一处小改动（diff），用评估测一遍，分数上升就保留，下降就回滚（revert）。Claude Code 的 /claude-api 命令集里也包含面向 API 代码的成本优化支持。

演讲中最引人注目的案例是：一个系统把成本降低了 90%、性能反而提升——靠的不是裁剪提示词，而是换用更强的模型并把 effort 设得更低：更强的模型用更少的推理轮次就能一次做对，总账单反而便宜得多。以上数字为 Anthropic 在演讲中公布的数据；实际结果取决于各系统的工作负载。

如何设计评估，才能让 Claude 改进又不"背题"？

爬山法成立的前提是有一套可信的评估可以"爬"。按演讲所说，好的评估需要三点：每个测试用例都有清晰的评分器（scorer）；数据集划分为 train split 与 test split，改动在 train 上试验、结论以 test 为准；并保留模型从未见过（unseen）的用例来发现过拟合。分析器（Analyzer）循环阅读评估结果、提出错误原因假设、给出提示词修改建议，再重新测量——与工程师用基准优化代码是同一套纪律。

连续运行数天的智能体怎么办？

演讲最后讨论长时运行智能体的可靠性：当智能体按日程（scheduled）运行、自主读取数据源、跨运行保留记忆、并把凭据存放在专用保险库（vault）里时，问题就不再是提示词写得好不好，而是系统运维——需要心跳监控、明确的判断规则与预先批准的输出目的地。Anthropic 以其托管智能体平台 Claude Managed Agents 来承接这类需求。

对比表：旧习惯与新做法

旧习惯	问题	新做法
给每个提示词都加"请一步一步思考"	前沿模型已能自主推理，只会多烧 token	默认去掉，仅在评估证明有效时保留
"请再检查两遍""请尽可能详尽"	空洞的仪式，增加成本却不提升质量	让模型自我检查；用明确的输出标准代替口号
用 scratchpad 标签强迫草稿格式	弱模型时代的脚手架，容易与其他指令冲突	删除或压缩到最少
把变化内容（时间戳、动态数据）放在提示词最前面	按严格前缀匹配原则会击穿提示缓存	固定内容在前，变化内容在后
凭感觉改提示词	无法度量进步，容易对少数熟例过拟合	用带 train/test 划分的评估 + 数据驱动的爬山法

常见问题

彻底去掉"请一步一步思考"，Claude 的回答会变差吗？

按演讲的说法，对当前前沿模型不会：模型已能自主推理并自行判断何时需要深入思考。更稳妥的做法是，用你自己任务上的评估来验证，而不是出于习惯保留这句话。

提示词审计用哪个命令运行？

在 Claude Code 中：面向调用 Anthropic API 的代码用 /claude-api prompt-audit，面向 Claude Code 配置用 /doctor prompt-audit（别名 /checkup）。工具会逐行分类提示词并提出 diff 供你审批。

为什么只改提示词开头的一个字符，缓存就全丢了？

因为提示缓存严格按前缀匹配：缓存是按从提示词起始处算起的字符序列计算的。前缀中任何一个字符变化，都会让其后全部内容与已缓存版本不再匹配。

成本降低 72% 与 90% 的数字可信吗？

这些数字来自 Anthropic 的内部基准，由 Lance Martin 在演讲中公布，尚未经过独立验证。实际节省幅度取决于各系统的提示词结构与工作负载；可靠的办法是在自己的系统上用评估实测。

评估要让模型"爬得上去"是什么意思？

意思是评估的评分粒度要足够细，让提示词的每一小步改进都能体现为可测量的分数变化；同时用独立留出的测试集，防止提示词被过度优化到已见过的用例上（过拟合）。

---

来源：Linh Vu 在 Vietnam Java User Group 的分享，内容整理自视频《Your Old Prompts Are Making Claude Worse》——Lance Martin，Anthropic，于 AI Engineer 纽约大会（YouTube 的 AI Engineer 频道）。文中成本数字为 Anthropic 在视频中公布的内部基准，未经独立验证。