旧提示把应用留在前沿内侧｜AI Engineer × Lance Martin

Lance Martin 是 Anthropic 的技术人员，以前在 LangChain。他开场画的是一张人们默认的权衡：要更好的质量就多花钱，要降成本就牺牲质量。任何一次评测上，模型会排出一条 Pareto 前沿。他口播里，Fable 在曲线最右，然后是 Opus、Sonnet、Haiku。他要说的是，很多应用并不在这条曲线上，而是坐在由这些模型围出的前沿内侧。原因是一些小的配置失误。他见过同一类改动同时把质量抬上去、把成本压下来。

字幕是自动生成的英文。型号按口播留在 Opus 48、Opus 55、Opus 5、Opus 5.5、Opus 45、Fable、Sonic 5。下文不把它们改写成另一套官方型号名。

原始来源：Your Old Prompts Are Making Claude Worse - Lance Martin, Anthropic。中文深度整理，非逐字翻译。本文依据 YouTube 自动生成的英文字幕，专有名词和数字可能有识别误差。现场问答里的工坊报名和社交账号不纳入。

提示会欠债，前沿模型会被旧规矩弄糊涂

他的第一个主题是审计提示。提示和代码一样会累积债务。几代以前，常见写法是 think step-by-step，是核对仪式、double-check your work，是 be maximally thorough 这一类 booster，还有 scratch pad：告诉智能体怎么想、给它一块地方去想。

他说前沿模型已经会自己决定什么时候想。它们会自然核对，不必再被吩咐「想得周到」。这些旧句子留着，会增加成本，有时还会把表现压低。另一条分界在互相矛盾的规则上。更早的模型指令遵循差一点，提示里两条打架，它常常忽略其中一条，所以看起来还能用。前沿模型更听话，矛盾的规则会把它们弄糊涂。

他当场给的命令有两条，都在 Claude Code 里，链到同一份技能、同一份代码。checkup prompt audit 通常用来检查 Claude Code 自己的配置：技能、提示。Claude API prompt audit 是捆在 Claude Code 里的另一条技能，对着调用他们 API 的代码。工作目录里的技能、工具、提示都会被扫一遍，针对这些反模式，并替你删掉。他说 Anthropic 内部很多人在用，Twitter 上也开始有人用。这是口播，不是一份客户名单。

例子是他自己做的合成评测：客服工单，大约 50 张。起点是口播里的 Opus 48，他模拟迁到 Opus 55。迁移过程中，每种反模式单独注入再测量，中间那个点是这些反模式在基准上的平均。带着反模式从 48 迁到 55，已经能看到一些成本下降，表现也上去一点：图上往左、略往上。再跑 prompt audit，质量和成本再各抬一截。命令会去掉核对仪式和 booster，那些句子正在让 Opus 55 多花 token；矛盾提示把前沿模型弄糊涂的地方，表现也会回来。

反模式从哪一代开始变得不必要，他试过，边界是糊的。他的感觉是大概到口播里的 Opus 45，这些写法开始不那么相关。55 这一系列则明确不需要。技能里有按模型区分的说明。若目标是 Haiku，他承认也许还要一点 booster，因为没那么自主；这只是他顺口的猜测，他并不确定。他的做法是：迁到最新的 Opus 55 时，就把这些清掉。

多轮只追加一点点，缓存认的是严格前缀

第二件事是 prompt cache。智能体很多轮。每一轮只多一点点，比如一次工具调用，大量上下文却在轮与轮之间重复。他不想为同一段付两次钱。

缓存 token 大约是基础 token 价格的十分之一。他口播说，按模型会有一点差别，十分之一是他记得的现价，具体去看定价页。缓存也更快。多轮应用要大量用它。

约束是严格前缀匹配。前缀里哪怕一个字节变了，缓存就失效。做智能体或多轮应用时，不能把这个前缀碰碎。用 Claude API 时，Claude console 能看到应用自己的缓存命中率。他说 Claude Code 自己把这个命中率盯得很紧，因为这就是应用的经济账。

提示按生命周期分层。系统说明和工具，是所有会话都能共用的全局缓存。字幕里的 Claude MDM memory 按项目缓存。会话状态按会话。消息每一轮往后追加。他没有在口播里把 MDM 展开成另一个产品名，下文保留这四个词。

他让人在 Claude Code 里对使用 API 的项目跑诊断：看缓存用得对不对，找机会把提示重新排过，好让命中率高。他和 Claude AI 团队的人，对一批带着默认 harness 的内部基准跑了这条命令。有的 harness 没用好缓存。他们找到的机会是成本最多降大约 72%，表现没有有意义的变化。他把整理好的缓存说成几乎是白捡的成本。同一条检查还会看 effort 和提示，重点仍是命中率。72% 是这批内部基准上的「最多」，不是对外的统一折扣。

评测要爬得动：换更强的模型，分数应该上去

前沿 Claude 很会自我修正。给它一份结构清楚的评测，它可以在上面爬山。前提是这份评测爬得动。他花很多时间在评测设计上，好让爬山有机会成功。这几条他说是基本功，不是 Anthropic 专有的。

图的横轴是每次尝试的 token，也就是思考量，纵轴是分数。上面一条是前沿模型，中间是中等模型，下面是小模型，对应他口播的 Opus、Sonnet、Haiku。一份好评测上，一般应该看见四件事。模型往上换一档，分数上去。思考变多，分数上去。前沿上还有抬头的空间，评测没有饱和。各次运行之间的方差要低。

他常见的坏法是任务含糊。看起来还剩 20% 可以拿，可没有任何模型拿得到。人会在一份其实已经饱和的评测上烧掉很多 token。很流行的评测里也有这种任务，把前沿的抬头空间封死。

命令是 Claude API build eval。它是 Claude Code 里的一条技能，不规定数据放在哪，追踪方案随便指。你给它要解决的问题、关心的东西、原始数据或轨迹，它带你建评测集：把数据和评测摊开，和你一起检查打分标准。他说这套做法旁边有一篇博客，现场没有念出链接。

问答里他补了 Hamel 在 Twitter 上的反馈。Hamel 对评测想得很细，认为这条技能应该先带人看数据。Lance 同意，说自己有一个 PR 要加上这一步。现在的技能会直接分析数据、建评测再给你看。他认为中间应该有一步：先看原始数据，同时让 Claude 标出值得看的地方，像一个对着离线日志的在线评估器，指出可能出错的例子。人再决定哪些例子升进评测集。目标是什么、为什么重要，仍由人来掌舵。客服应用里，在乎什么，是人的口味。目标说清之后，Claude 可以在轨迹里找达不到目标的地方。

打分他偏向人能讲清楚的量表。先做一份人自己拿着文本能打的量表。尺度不要随意。他经常看见 0 到 5，或者 1 到 10，噪声很大。能做成二元的好与坏，就做成二元；要评好几件事，就做多个二元分类器。想清楚的多档量表也可以，只要方差低、换模型还能复现、人能分清相邻两档。检验方法是让 Sonnet、Opus 和 Fable 用同一份量表打；它们互相不同意，就是坏信号。再跑重复，看方差紧不紧。开放式文本没有确定性的启发式检查时，带一份清楚量表的模型裁判可以用。两两比较往往比单独打分容易：人和模型都更容易说「这个网页比那个好」，而不是给一个网页打 0 到 5。他见过生成界面的评测用两两比较，多次试验后收成类似 Elo 的分数。打分本身他倾向于更小、更便宜的模型，并说按成本敏感度，不想让 Fable 来打分。

样本要代表生产里真正在乎的情况。一种歪的抽法是对抗采样：只把某一档模型的失败例升进评测。模型的能力是锯齿状的。口播里 Sonnet 5 做不成的例子，Opus 5 可能全做完，只因为那一口袋恰好是前一个模型的凹处。他建议按第一性原理、按自己的直觉、按生产数据，挑难的和有意思的例子，而不是只从某一个模型的失败里取样。换模型之后，那份按凹处裁出来的分布可能不再适用。

爬山会过拟合，卡住时常常是题本身含糊

评测有抬头空间、方差低、随思考量和模型档位按预期变化之后，才爬。前沿 Claude 可以自己看评测、自己改，人不在回路里。失败的经典样子是过拟合评测分布。某个任务需要 OCR，harness 为了做完评测就加了一个 OCR 工具，生产里却看不到这类问题。提示也会被拧成只贴评测例句的说法，换到测试分布就没用。花了很多 token，评测分很好看，生产一点没变。

命令是 Claude API hill climb。它不完美，人要在回路里看懂它在改什么。做法里有一条统计上的旧规矩：把评测拆成训练和测试。爬山时它只看训练集上的失败，据此决定改什么；每一轮再用测试和训练两边看表现。训练升、测试平，就是过拟合的早信号。评测分布本身要在 build eval 那一步先建好。

他用 Claude API 这条技能本身做过一次。技能要让 Claude 掌握他们的 API 和 SDK，并且落在文档上。他按文档建了评测集。技能一开始在这套题上是 66%。他把技能文本和文档交给 Claude Code，让它一轮轮看失败，找技能哪里把文档说错了。Claude 自己找到该改的技能文本，评测表现明显变好。他没有在口播里给出爬完之后的那个百分比。他说这种窄范围、好改的文本表面最适合：提示和技能。改整个智能体 harness 也有人做过，但每一轮的 diff 大，更容易改到和你量的那个信号无关的地方。文本的代价是特别容易过拟合。即便有训练测试拆分，Claude 也很会把提示拧成评测上好看、生产里不像的形状。所以提示适合起手，也要盯着过拟合。

爬山不保证收敛。他见过很多次卡住。技能里加了退路：连续几轮不动，就去聚类剩下的失败，看是不是题含糊、打分器有错。那最后的 20% 常常全是有问题的打分例和含糊指令。卡住是因为评测结构差，不是因为 Claude 不能更好。他讲的那次成本爬山，第二阶段就卡住过，聚类之后发现一批含糊题，并把它们改写了。人如果没先跑 build eval、评测集没仔细建过，这种事很常见。评测若那最后 20% 根本无解，爬山会为了这 20% 烧掉大量 token。

同一条爬山也可以用来降成本。你告诉它降成本，它会找至少保持表现持平、并且确实更便宜的配置，搜索范围包括 effort、模型和提示。客服那份基准上，起点是口播里的 Opus 48、高 effort、一份基线提示。它换到 Opus 5、低 effort：表现明显上去，成本略降。字幕接着说它又自己去试 flying at 5、低 effort：表现掉一点，成本大降。再调提示，把表现救回来。他的结果是成本降大约 90%，表现还有明显提升。评测已经饱和时也可以用：表现保持住，只把成本烧掉。90% 是这一次自主搜索的口述，不是一张价目表。

评测分布上的这种搜索，和训练时给奖励、改系统去抬目标，在道理上相近，也用了训练里常见的训练测试拆分。差别是它发生在模型已经部署之后，改的是提示或技能这种运行时表面。他提到评测意识是更广的研究话题，他们在研究博客里讨论过。在这场要做的爬山里，他更担心的实际问题是过拟合：Claude 也许知道自己在被评测，它仍会把提示拧到让数字上涨。那不一定是「它知道自己在考试所以作弊」的意外行为，而是你给了它一个目标，它就去把数字做高。

问到和 DSPy 的关系时，他表示尊重 DSPy 团队和 Omar。这条技能捆在 Claude Code 里，技能本身开源，可以拿到别的表面里用。他没有用过 DSPy，不知道结构细节，只说这些爬山原则有可能放得进去。

先试更强的模型、更低的 effort

effort 让人糊涂，他自己也说被 effort 弄糊涂。有评测时，爬山可以替你搜模型和 effort 的组合。原则很简单，而且他见过很多次成立：更强的模型配更低的 effort，往往比更弱的模型配高 effort 更省 token，因此更便宜。更聪明的一方少使一点劲，有时把事做得更好，token 也更少。搜索会先看各模型的低 effort，直到表现掉到基线以下。口播里的 Haiku 4.5、低 effort，在他那次是明显退步，这个点被拿掉了。他说现在的 Haiku 5.5 好了不少。

没有评测时，effort 更微妙。他留下的一般建议是：先试更强的模型、低 effort。口播点名 Opus 5.5 的低 effort。从 low 开始，不够再往上拨。有人一上来就用 max，非常吃 token。effort 是在告诉 Claude 想多用力。低 effort 是别想那么用力，往上拨是想得更用力。因此基础更聪明的模型在低 effort 下，可以比「基础 token 更便宜、但高 effort 上想了很多」的模型更省。他举的例子是口播里的 Sonic 5 在高 effort 上花大量 token 去想。问答里有人问要不要从 medium 开始，他说先试 low。

effort 不是硬顶。题很简单时，即便 effort 很高，它也不会无故花掉巨大 token 去核对。Claude 对自己需要多少额外思考有判断。差别出现在更难的前沿编程题上：extra high 或 max，相对 medium 或 low，token 可以差得很大，结果却差不多，因为 Claude 会做更多核对。他没有当场给出证明这件事的评测。

预算由技能来问。你跑爬山时它会问预算，并按你拨的额度记账。

长时任务才把 harness 拆开

幻灯后半他接到当天上午的话题：任务时长在变。横轴是时间，纵轴是对人来说的任务时长，他称为 meter 图表。口播里 Claude Opus 3 只能做大约 4 分钟的自主工作，那时产品基本上是自动补全或聊天。2025 年里，模型变得能做大约一小时到两小时的人类等价工作，Claude Code 也在这一年明显起来。现在的任务时长正在超过大约一天到两天，他说这可能已经超出 meter 量得到的范围。模型能做相当于数天的工作时，harness 要让它自己跑很久，安全和可靠的算法就变了。

他点名的新 API，字幕听成 Cloud Manage Agents。原则写在他四月的一篇引擎博客里：把脑子和手拆开。harness 是脑子，沙箱是手，代码和动作发生在沙箱里。两边要分开，并且都能恢复。智能体过夜跑，沙箱半夜死了，会话日志和状态不该一起没。会话日志是独立对象，既不属于 harness 也不属于沙箱，只追加，可恢复。沙箱死了可以新开一个，harness 死了可以由编排器再拉起一个。

安全上，Manage Agents 不把秘密直接交给 Cloud。秘密在库里，放在他幻灯顶部那个工具盒一类的位置。Cloud 可以引用 API key 或秘密，看不见它们本身。跑几天的智能体直接拿着敏感秘密，他觉得渗人。可靠和安全会随着小时、天、以及也许很快到来的星期，变得更重要。

他和 CJ 写过一篇近期博客，例子是一个定期跑的智能体：按你指定的来源做上下文更新，写到 Slack。调度部署跑在 Anthropic 的基础设施上，秘密分开存，带记忆。在 Claude Code 里，字幕听成的命令是 Cloud API magic sandboard，把博客链接给它，它会把教程拉起来。下文不把这串听写改成另一个命令名。

他收束时把几件事放在一起。提示要审计。做长时间智能体时，缓存要把成本管住。长时间任务的 harness 要考虑可靠和安全。评测和爬山要一起想。人把越来越多的时间放在评测设计上，把 Claude 爬得动的任务写清楚，让它安全地跑一夜，早上回来看它是否明显变好。他说这已经是很多同事的工作方式。模型变好之后，旧评测上的分数应该跟着上去；分数不涨，先回头查评测是不是没建好。很难再做出能压住今天最好模型的题，他点名 Fable 和 Opus 5.5。生产里线上评测打分差的轨迹，抽进离线集再爬，通过之后放进回归，这个外环他觉得合理。字幕里做这类产品的名字是 LangChain、Rises、Braintrust，不把 Rises 改成另一个厂牌。线上什么叫好、该把什么升进离线集，仍然难。