Anthropic工程师建议改进提示词

在近期AI Engineer纽约大会的一场演讲中，Anthropic技术专家兰斯·马丁分享了几个简单却极其有效的实用技巧，帮助开发者充分释放前沿大模型的潜力，往往能在提升输出质量的同时大幅削减成本。 开场：你可能还没站上成本—效果前沿 我们通常认为，成本和质量是一对矛盾。 想要更好的性能，就得砸更多钱； 想要省钱，就得牺牲性能。 在任何一个评测集上，不同模型都会画出一条“帕累托前沿”（指在成本与性能之间达到最优平衡的边界曲线）。

在这条曲线上，Fable位于最右端，往下依次是Opus、Sonnet，然后是Haiku。 兰斯·马丁在AI Engineer纽约大会的工作坊上（2026年10月12日，视频画面） 但今天我想挑明一个事实：很多时候，你的应用根本没摸到这条前沿曲线。 因为一些微小的配置失误，你的应用其实落在曲线内侧。 我们已经反复看到，很多客户仅仅做了一点简单的调整，就同时实现了性能提升和成本下降。 接下来我将围绕五个核心主题，演示如何修复这些问题。 一、给提示词做个全面体检 第一件事：审查你的提示词。

提示词就像代码一样，时间长了也会攒下“技术债”。 回想几代模型之前，大家习惯在提示词里写“请一步步思考”； 习惯加上各种验证仪式，比如“仔细检查你的工作”； 还会塞进各种督促思考的强化词，比如“务必做到极致详尽”； 有时候甚至会专门开辟“草稿区”，手把手教智能体怎么思考、把思考过程写在哪里。 现在完全不需要这套了。 前沿大模型本身就很擅长思考，也知道什么时候该思考。 它们不需要你教怎么干活、怎么检查作业，自检已经成为它们的本能。 更糟糕的是，继续保留这些旧习惯不仅会推高成本，有时还会拉低性能。

还有一个有意思的现象：以前的模型如果遇到提示词里存在自相矛盾的规则，由于指令遵循能力没那么强，往往会自动忽略其中一条，最后勉强也能跑通。 但现在的前沿模型遇到矛盾的规则，反而常常会被搞糊涂。 现在就可以动手做一件极简单的事。 如果你手头有想检查的代码，可以在Claude Code里直接运行/checkup prompt-audit命令，或者运行/claude-api prompt-audit。

这是Claude Code里的两个技能，底层指向同一套代码，只是调用入口不同：/checkup通常用来检查Claude Code自身的配置（比如你的技能和Claude Code里的提示词）； 而内置的claude-api技能则专门针对调用我们API的业务代码。 这两个命令会扫描Claude Code当前工作目录下的所有内容——无论是技能、工具定义还是提示词，揪出上述反模式并直接帮你清理掉。 这个工具在Anthropic内部很多人在用，在Twitter上也有点名气，操作极其简单，却往往能带来成本和性能的双重改善。

清理提示词能省多少钱？ 来看一个例子。 我搭建了一个包含约50个客户支持工单的合成评测集，起点是Opus 4.8，模拟迁移到Opus 5.5的过程。 在迁移时，我人为注入了各种反模式提示词并分别测试效果。 核心结论很明显：即使带着这些反模式提示词，单纯从Opus 4.8升级到5.5，也能看到成本有所下降，性能略有提升（图表上的点向左上方移动了一点）。 但如果在此基础上运行一次提示词审查，性能和成本还会再进一步改善。

原因在于，这个命令清除了那些要求模型“反复验证”和“强行深度思考”的冗余指令，正是这些指令在逼着Opus 5.5白白消耗大量Token。 这个简单的命令往往能减少Token消耗、省下成本； 在矛盾提示词把前沿模型搞糊涂的情况下，还能提升性能。 无论是调用API的业务代码，还是Claude Code自身的配置，我都建议跑一遍这个命令。 二、把提示词缓存用起来 第二点，务必用好提示词缓存。 拿智能体来说，一次任务往往要经历多轮交互。 每一轮其实只新增了一点点内容，比如一次工具调用。

大量的上下文在多轮对话中是不断重复的，你肯定不想为同样的内容付两次钱，这正是提示词缓存的用武之地。 命中缓存的Token计费大约只有基础价格的十分之一（不同模型略有差异）。 重点在于，它不仅便宜得多，速度也快得多。 因此在开发多轮交互应用时，重度依赖提示词缓存是必修课。 但这里有个坑：提示词缓存采用的是“严格前缀匹配”机制。 只要前缀里变动了一个字节，整个缓存就会失效。 所以在构建智能体或多轮应用时，必须格外小心，千万别在无意中破坏了缓存结构。

如果你在用Claude API开发应用，Claude控制台提供了直观的诊断工具，可以查看应用的提示词缓存命中率。 在研发Claude Code时，我们就把缓存命中率当成核心指标死死盯住，因为这直接关系到整个产品的经济账。 那么，日常该怎么组织提示词结构呢？ 大体可以按这样的顺序来排：最前面放系统指令、工具定义等跨所有会话全局缓存的内容； 接着是类似CLAUDE.md这种按项目缓存的记忆文件； 然后是按单次会话缓存的会话状态； 最后才是每一轮不断追加的消息记录。

在Claude Code里，你可以直接针对API项目运行诊断命令。 它会全面检查提示词缓存的使用情况，找出可以重组提示词结构的机会，从而把缓存命中率拉高。 性能基本不变，成本最高降72% 我和Claude AI团队的几位同事做过一个测试：拿这个命令去跑内部一批使用默认运行框架（指驱动模型运行的底层代码框架）的基准测试。 结果发现，仅仅因为部分运行框架没用好提示词缓存，在性能没有明显变化的前提下，最高能省下72%的成本。

只需在API代码库里跑一下这个命令，它不仅会帮你深挖提示词缓存的省钱潜力，还会顺带检查推理力度设置和提示词写法。 优化提示词缓存不会对模型表现产生任何副作用，省下来的每一分钱都是纯赚的。 三、设计一个让Claude能“拾级而上”的评测集 前沿代的Claude模型具备极强的自我纠错能力。 只要给它一个结构良好的评测集，它就能顺着这个评测集不断进行“爬山优化”（指像爬山一样通过反复试错迭代，逐步逼近最优解的算法过程）。 但这背后的前提是：评测集本身得设计得好，必须具备“可攀爬性”。 先温习几个优秀评测集的基本特征。

如果把每次尝试消耗的Token数（代表思考深度）作为横轴，得分作为纵轴，从上到下画出大、中、小三个模型（对应Opus、Sonnet和Haiku）的表现曲线，一个健康的评测集通常应该呈现出四个特征： 第一，模型档次越高，得分越高； 第二，思考时间越长（消耗Token越多），得分越高； 第三，即使是最顶尖的模型，也依然留有提升空间，也就是说评测集还没有饱和； 第四，多次运行的方差要小，结果稳定。 道理听起来很简单，但实际操作中却极容易翻车。

我们见过太多热门评测集，里面充斥着大量表述含糊的任务，实际上压缩了前沿模型的提升空间。 你辛辛苦苦建好一个评测集，表面上看距离满分还有20%的提升空间，但实际上是一堆含糊不清、本来就解不了的题，没有任何模型能做对。 如果拿这种实际上已经饱和的评测集去跑自动优化，除了白白烧掉海量Token，什么也得不到。 为了解决这个问题，可以试试Claude Code里的/claude-api build-eval命令。 这个工具对数据存储位置毫无限制，你可以把它指向任何现有的链路追踪系统。

你只需要告诉它你想解决什么问题、你关注的是什么，并提供原始的运行日志，它就会运用上述原则，一步步引导你搭建评测集：给你看数据、看评测，还会和你一起核对打分器的评判标准是否合理。 四、自动“爬山优化”，但别掉进过拟合陷阱 一旦手头有了前沿还有提升空间、方差低、分数随模型档次和思考量如期上升的优质评测集，就可以开启自动“爬山”了。 前沿Claude模型能够完全脱离人工干预，自主分析评测结果并持续迭代改进。 但这里潜藏着一个巨大的危机：过拟合（指模型过度迎合测试题目的特殊规律，导致到了真实环境里并不见效）。

举几个典型的反面教材。 比如基准测试里恰好有一道题需要用到OCR（光学字符识别），为了拿分，自动优化程序就在代码框架里硬塞了一个OCR工具，但线上真实业务根本没这需求； 再比如，优化后的提示词死死咬住测试集里的某些特定句式，一旦放到生产环境面对真实用户的表达，立刻原形毕露。 你烧了一大笔钱跑爬山优化，测试集分数突飞猛进，结果一部署到线上毫无起色，往往就是因为优化过程完全迎合了评测集的数据分布。 为此，可以在Claude Code里试试/claude-api hillclimb命令。

它的核心防过拟合工作流借鉴了统计学里最经典的做法：将评测集拆分为训练集和测试集。 在每一轮迭代中，Claude Code只被允许查看训练集里的失败案例，并据此反思、修改配置； 它自始至终看不到测试集的题目。 每一轮修改后，系统会同时在训练集和测试集上跑分。 这就提供了一个过拟合的早期预警信号：如果看到训练集分数一路高歌猛进，测试集分数却原地踏步，那就提示你可能正在过拟合。 当然，工具不是万能的，人工审查和把控依然不可或缺，但这套机制能帮你检查优化成果是否真正适用于生产环境（前提是评测集本身建得好）。

实战案例一：让内置技能准确率从66%飙升 分享一个我亲手操刀的真实案例，对象就是前面提到的claude-api技能本身。 这个技能的作用是让Claude全面掌握我们的API和SDK用法，所有回答必须严格遵循官方文档。 我基于官方文档构建了一个评测集，摸底测试发现，初始版本的技能准确率只有66%。 于是我架起了一个自动爬山循环，把技能的文本文件和官方文档一并交给Claude Code，让它自己去对比评测集里的错题，排查技能描述到底在哪里曲解了文档原意。 最终，Claude