Reducing cost and improving performance with Claude Platform使用 Claude 平台降低成本并提升性能

Performance and cost are often viewed as a trade-off: to spend less, you accept worse results. In practice, we've found that many applications using Claude Platform can cut costs without giving up performance with three fixes: maximize the prompt cache hit rate, remove anti-patterns from your prompts when upgrading to frontier Claude models, and calibrate effort to the task. We've put this guidance into the claude-api skill. In this article, we show how Claude Code with the claude-api can often find ways to reduce cost while maintaining or improving performance.性能和成本通常被视为一种权衡：为了花更少的钱，你接受更差的结果。在实践中，我们发现许多使用 Claude 平台的应用可以通过三个调整来削减成本而不牺牲性能：最大化提示缓存命中率，在升级到前沿 Claude 模型时从提示中移除反模式，以及根据任务校准努力程度。我们已将这些指导整合到 claude-api 技能中。在本文中，我们展示了带有 claude-api 的 Claude Code 如何经常找到降低成本同时保持或提升性能的方法。

Prompt cache提示缓存

Before Claude generates a response, it first processes your prompt into an internal working state. This step, called prefill, is the expensive part of handling input. Prompt caching saves that state (the key–value, or KV, cache): when a request starts with the same prefix, Claude reads it back instead of recomputing it. Cache reads are billed at a fraction of the full input price.在 Claude 生成响应之前，它首先将你的提示处理成一种内部工作状态。这个称为预填充（prefill）的步骤是处理输入中开销最大的部分。提示缓存会保存该状态（即键值缓存，KV 缓存）：当请求以相同前缀开始时，Claude 会读回它，而不是重新计算。缓存读取的计费仅为完整输入价格的一小部分。

There are a few practical considerations to ensure effective use of the prompt cache. First, the prompt cache is pinned to a specific model. Second, prompt cache reads must be byte-exact across the full span of the prompt. Finally, the prompt cache has a limited time-to-live (TTL).为确保有效使用提示缓存，有几个实际注意事项。首先，提示缓存绑定到特定模型。其次，提示缓存读取必须在整个提示范围内字节完全一致。最后，提示缓存的生存时间（TTL）是有限的。

With these points in mind, there are a few practical tips:考虑到这些要点，这里有一些实用技巧：

• Avoid changing effort or thinking settings mid-conversation. These settings render into the prompt ahead of your content, so they are part of the cached prefix. With Claude Opus 5 and Fable 5.1 specifically, you can update effort mid-conversation without breaking the cache.避免在对话中途更改努力程度或思考设置。这些设置会在你的内容之前渲染到提示中，因此它们是缓存前缀的一部分。特别地，对于 Claude Opus 5 和 Fable 5.1，你可以在对话中途更新努力程度而不会破坏缓存。

• Keep volatile values out of the prefix. A dynamic timestamp or ID in the system prompt can change across model calls, and break the cache. 将易变的值排除在前缀之外。系统提示中的动态时间戳或 ID 可能在不同模型调用之间变化，从而导致缓存失效。

• Avoid tool definitions that reorder themselves. When using the Claude Messages API, the prompt is assembled in a fixed order with tool definitions rendered at the top. Any change to the tool definition will break the cache. 避免会自我重新排序的工具定义。使用 Claude Messages API 时，提示按固定顺序组装，工具定义渲染在顶部。工具定义的任何更改都会破坏缓存。

• Be careful when forking conversations. Subagents and branches only share the parent’s cache when the fork’s prefix is byte-identical, on the same model, and using the same effort. 在分叉对话时要小心。只有当分叉的前缀在字节级别完全相同、使用相同模型并且使用相同的努力程度时，子代理和分支才会共享父级的缓存。

• Avoid synchronous tool calls and subagents that outlive the cache TTL. If an agent blocks on a long-running tool call or sub-agent, the cache can expire before the results come back. The next turn has to rewrite the cache, at 1.25× the normal input price (2× for a 1-hour cache) instead of the cheap read price.避免超出缓存 TTL 的同步工具调用和子代理。如果代理因长时间运行的工具调用或子代理而阻塞，缓存可能会在结果返回之前过期。下一轮就必须以正常输入价格的 1.25 倍（一小时缓存的 2 倍）重写缓存，而不是享受便宜的读取价格。

How to fix it如何解决

We’ve accumulated a few lessons for prompt cache management: 我们积累了一些提示缓存管理的经验：

• Monitor your prompt cache hit rate carefully. Claude Console provides prompt cache diagnostics, including reasoning for prompt cache misses (Figure 1). If hits drop unexpectedly, the cache diagnostics API tells you exactly where two requests diverged.仔细监控你的提示缓存命中率。Claude Console 提供提示缓存诊断，包括提示缓存未命中的原因（图1）。如果命中率意外下降，缓存诊断 API 会确切地告诉你两个请求在何处出现分歧。

• Defer rarely used tools. Declare all your tools up front but mark the rarely used ones defer_loading: they stay out of the cached prefix and are appended into the conversation only when Claude looks them up with tool search, so the cache is preserved.延迟加载不常用的工具。提前声明所有工具，但将不常用的标记为 defer_loading：它们不会进入缓存前缀，仅在 Claude 通过工具搜索查找它们时才追加到对话中，从而保持缓存有效。

• Apply system prompt updates as messages. Claude Platform lets you add a system instruction as a message mid-conversation instead of editing the system prompt, which preserves the cache.以消息形式应用系统提示更新。Claude 平台允许你在对话中途将系统指令作为消息添加，而不是编辑系统提示，这样可以保留缓存。

• Lay out the request out so the stable part stays stable. Add static context (tool definitions and the system prompt) first and the growing conversation behind them (Figure 2).合理安排请求，让稳定的部分保持稳定。先添加静态上下文（工具定义和系统提示），再将不断增长的对话放在它们之后（图2）。

• Make changes to model or effort when the prompt cache will already be broken. Certain operations, like compaction, already rewrite much of the cache (the conversation). That is a good moment to switch model or effort, since you are paying for a miss anyway.在提示缓存本就会失效时再更改模型或努力程度。某些操作（如压缩）已经重写了大量缓存（对话内容）。此时是切换模型或努力程度的好时机，因为你反正都要为未命中买单。

• Move the cache breakpoint as the conversation grows. With Claude Platform, you can set automatic caching to automatically apply the cache breakpoint to the last cacheable block. 随着对话增长移动缓存断点。借助 Claude 平台，你可以设置自动缓存，将缓存断点自动应用于最后一个可缓存块。

• Pre-warm the cache. To reduce latency, send a request with max_tokens: 0 and an explicit cache breakpoint. This processes the prompt and writes it to the cache without generating anything. If you run it at session start (for example, while a user is typing), the first real request hits a warm cache.预热缓存。为降低延迟，发送一个 max_tokens: 0 并带有显式缓存断点的请求。这会处理提示并写入缓存，而不生成任何内容。如果你在会话开始时运行它（例如，在用户输入时），第一个真实请求将命中一个已经预热的缓存。

• Don’t exceed the prompt cache TTL. The 5-minute cache TTL counts from the start of the request. If an agent blocks on tool calls or sub-agent requests that run longer than 5 minutes, the parent's cache expires before the result comes back. In cases like this, consider setting a 1-hour TTL on the prefix instead.不要超过提示缓存 TTL。5 分钟缓存 TTL 从请求开始计时。如果代理在运行时间超过 5 分钟的工具调用或子代理请求上阻塞，父级的缓存会在结果返回之前过期。在这种情况下，请考虑为前缀设置 1 小时的 TTL。

Instructions指令

Prompts can accumulate instructions that patch model weaknesses. These instructions can drift relative to the capabilities of the latest Claude models. Here are common prompting “anti-patterns” that hobble frontier Claude model and can inadvertently increase costs:提示可能会累积一些用来修补模型弱点的指令。这些指令会与最新 Claude 模型的能力产生偏差。以下是一些常见的提示“反模式”，它们会妨碍前沿 Claude 模型，并可能无意中增加成本：

• Verification rituals. Instructions like "double-check your work” or "verify twice before responding” are often taken literally by frontier models and can waste tokens.验证仪式。像“仔细检查你的工作”或“在回复前验证两次”这类指令，前沿模型通常会从字面理解，从而浪费 token。

• Thoroughness and emphasis boosters. "Be maximally thorough," "CRITICAL: YOU MUST ALWAYS…" can lead to verbosity and extra tool calls when working with frontier models.强调全面性和加强语气。诸如“尽量做到最全面”、“关键：你必须始终……”等表述，在使用前沿模型时会导致冗长输出和额外工具调用。

• Mandatory procedures and scratchpad scaffolds. Fixed step processes (e.g., "think step by step in a scratchpad") or reasoning templates are rituals that frontier models don't need. This scaffolding can stack on top of native reasoning and use unnecessary tokens.强制流程和草稿纸式支架。固定步骤流程（例如“在草稿中一步一步思考”）或推理模板是前沿模型不需要的仪式。这类支架会叠加在模型原生推理之上，消耗不必要的 token。

• Stale examples. Few-shot examples tuned to an older model's failure modes can teach a frontier model to imitate long reasoning chains on requests that don't need them.过时的示例。针对旧模型失败模式调整过的少样本示例，可能会教导前沿模型在不需要的请求上模仿长篇推理链。

• Contradictory rules. Frontier models are better at instruction following. Contradictory instructions ("always refund within policy" vs. "never issue refunds without escalation") can be followed more literally by frontier models, resulting in degraded performance.  矛盾规则。前沿模型更擅长遵循指令。矛盾的指令（“始终在政策范围内退款” vs. “未经上报绝不退款”）可能被前沿模型更字面地执行，导致性能下降。

• Dated configuration. Settings written for an older Claude generation (e.g., manual thinking budgets) can be rejected by the Claude Platform when upgrading to frontier models.过时的配置。为旧一代 Claude 编写的设置（例如手动思考预算）在升级到前沿模型时可能会被 Claude 平台拒绝。

How to fix it 

We've updated the claude-api skill with a new command that watches out for these anti-patterns. In Claude Code, run /claude-api prompt-audit against your prompts, skills, or tool descriptions. The audit covers anything in your working directory, including application code that calls the Claude API and Claude Code's own configuration (e.g., CLAUDE.md or skills).我们已更新 claude-api 技能，新增了一个命令来识别这些反模式。在 Claude Code 中，对提示、技能或工具描述运行 /claude-api prompt-audit。该审计覆盖工作目录中的任何内容，包括调用 Claude API 的应用程序代码以及 Claude Code 自身的配置（例如 CLAUDE.md 或 skills）。

For example, we tested a model migration from Opus 4.8 to Opus 5 on a customer support benchmark. We started from a clean prompt and planted one anti-pattern at a time (a retired thinking setting, a pair of contradictory refund rules, a manual scratchpad, "verify twice", "be maximally thorough", and a mandatory six-step procedure), giving six legacy prompts. 例如，我们在一个客户支持基准上测试了从 Opus 4.8 到 Opus 5 的模型迁移。我们从一个干净的提示开始，每次植入一个反模式（一个已停用的思考设置、一组矛盾退款规则、一个手动草稿、“验证两次”、“尽量做到最全面”以及一个强制的六步流程），从而生成了六个旧提示。

We ran each on Opus 4.8, on Opus 5 with only the model ID changed, and on Opus 5 after running /claude-api prompt-audit once per prompt (Figure 3 shows the average across the six).我们分别使用 Opus 4.8、仅更改模型 ID 的 Opus 5，以及在每个提示上运行一次 /claude-api prompt-audit 后的 Opus 5 来运行每个提示（图3显示了六个提示的平均结果）。

Figure 3 | The effect of prompting anti-patterns during model migration from Opus 4.8 to Opus 5.图3 | 在从 Opus 4.8 迁移到 Opus 5 期间，提示反模式的影响。

With Opus 5, verification rituals ("verify twice") use unnecessary tokens by duplicating order lookup on every refund. Emphasis boosters ("be maximally thorough") became dozens of unneeded knowledge-base searches. 使用 Opus 5 时，验证仪式（“验证两次”）通过每次退款重复查询订单而浪费不必要的 token。强调词（“尽量做到最全面”）则导致几十次多余的知识库搜索。

Running /claude-api prompt-audit removed the anti-patterns, decreasing costs by 14.6% and increasing accuracy by 5.3% on average. Cost dropped because extra tool calls and duplicated reasoning were eliminated. Accuracy rose for three reasons. The retired thinking setting made the API reject every routing request outright. The contradictory refund rules led Opus 5 to withhold four refunds it owed while it asked the customer to confirm. And the manual scratchpad collided with Opus 5's built-in thinking: on three tickets it wrote the tool call inside its reasoning and never executed it.运行 /claude-api prompt-audit 可移除这些反模式，使成本平均降低 14.6%，准确率平均提升 5.3%。成本下降是因为消除了多余的调用和重复推理。准确率上升有三个原因：已停用的思考设置导致 API 直接拒绝所有路由请求；相互矛盾的退款规则使 Opus 5 在要求客户确认的同时，扣下了四次本应执行的退款；手动草稿与 Opus 5 的内置思考发生冲突：在三个工单中，模型将工具调用写在其推理内容中，却从未执行该调用。

Effort努力程度

Effort tells Claude “how hard to work.” At low effort Claude generally reaches conclusions faster. At high effort, Claude deliberates, verifies, and explores alternatives before answering. 努力程度告诉 Claude '应该多努力地工作'。在较低努力程度下，Claude 通常能更快得出结果。在较高努力程度下，Claude 在回答前会进行深思熟虑、验证并探索替代方案。

Cost-versus-performance across effort levels on a single model can vary. For example, Claude Fable 5 scores 11.5% at low effort for $5.35 per task on FrontierCode Diamond (the hardest 50 tasks). At max effort, Fable 5 gets 30.9% for $19.00 per task; changing effort raises the score about 2.7x (+19 points) for about 3.5x the cost (Figure 4). 仅改变努力程度所带来的成本与性能关系，在同一模型上也会有所不同。例如，Claude Fable 5 在 FrontierCode Diamond（最难的 50 个任务）上，低努力程度下得分为 11.5%，每个任务成本 5.35 美元；在最大努力程度下，Fable 5 得分 30.9%，每个任务成本 19.00 美元；更改努力程度可将得分提升约 2.7 倍（+19 分），成本增加约 3.5 倍（图4）。

On Claude Fable 5.1, Humanity's Last Exam (without tools) shows a steep curve with a diminishing last step. It scores about 53% at low effort for about $0.30 per question and about 61% at max effort for about $2.23; the last step up to max adds about half a point for 46% more cost. The gain inside the benchmark's run-to-run noise, so you pay more for no measurable gain.在 Claude Fable 5.1 上，Humanity's Last Exam（无工具）显示出陡峭的曲线，但最后一步收益递减。低努力程度下得分约为 53%，每道题成本约 0.30 美元；最大努力程度下得分约为 61%，每道题成本约 2.23 美元；从上一档提升到最大一档仅增加约 0.5 分，成本却增加 46%。该提升落在基准测试逐次运行的噪声范围内，因此你多花了钱却没有可衡量的收益。

Effort can be miscalibrated in either direction:努力程度可能在两个方向上校准不当：

• Assuming higher is always better. High effort can cause over-thinking. Claude spends more time deliberating than the task warrants, which adds cost / latency and can degrade answer quality. Deliberation only helps while there's still evidence to find. 认为越高越好。高努力程度可能导致过度思考。Claude 花费比任务实际所需更多的思考时间，这会增加成本/延迟，并可能降低回答质量。只有在仍有证据可寻时，思考才会有所帮助。

• Biasing to low effort. Set too low, Claude stops before it has enough evidence. It makes fewer tool calls, so it may answer from the first search result instead of the third. It thinks less on hard steps and skips the check it would normally run on its own. The answer looks finished, but it's built on partial information. 倾向于过低努力。设置过低会使 Claude 在获得足够证据前就停下。它调用的工具更少，因此可能基于第一个搜索结果而非第三个来作答。它面对困难步骤时思考更少，且会跳过原本会自行执行的检查。答案看起来完整，但建立在部分信息之上。

How to fix it 

There are some useful ways to calibrate effort: 有一些有用的校准努力程度的方法：

• Test stronger models at lower effort. A stronger model at low effort can be cheaper than a weaker model working hard (high effort). For example, on CursorBench 3.2, Claude Fable 5.1 at low effort matches the performance of Fable 5 at high effort at a third of the cost (Figure 5). Two things make the newer model cheaper: at low effort it does less work per task, and Fable 5.1's prompt-cache reads are priced at $0.25 per million tokens versus $1.00 for Fable 5. Even at Fable 5's prices, Fable 5.1 at low effort would cost about 40% less.在较低努力程度下测试更强的模型。一个低努力程度的更强模型，可能比一个高努力程度的较弱模型更便宜。例如，在 CursorBench 3.2 上，Claude Fable 5.1 在低努力程度下的表现与 Fable 5 在高努力程度下相当，而成本仅为后者的三分之一（图5）。这个较新模型更便宜有两个原因：在低努力程度下每个任务做的功更少；Fable 5.1 的提示缓存读取价格是每百万 token 0.25 美元，而 Fable 5 是 1.00 美元。即使按 Fable 5 的价格计算，低努力程度下的 Fable 5.1 成本也大约降低 40%。

• Understand your task shape. Measuring application performance across a sweep of effort levels is a useful way to understand the cost-performance tradeoff for your particular task. On a non-saturated evaluation, a flat performance-cost curve across effort levels suggests that the task is not bound by thinking compute; increasing effort is not beneficial.了解你的任务形态。在一系列努力程度下衡量应用性能，是理解你特定任务中成本-性能权衡的有效方法。在一个未饱和的评估中，如果性能-成本曲线在各个努力程度上保持平坦，说明该任务不受思考算力的限制；增加努力程度没有益处。

This calibration often involves running an evaluation across models and effort levels. In Claude Code, /claude-api hillclimb performs this search for you: it splits your evaluation into train and test sets, proposes configuration changes, and reads failing train examples to fix what it finds.这种校准通常涉及跨模型和努力程度运行评估。在 Claude Code 中，/claude-api hillclimb 可以帮你执行这种搜索：它会把评估拆分为训练集和测试集，提出配置更改建议，并通过查看失败的训练示例来修复发现的问题。

We ran it on a customer support benchmark, starting from Opus 4.8 at its default (high) effort. The hillclimber first tried Opus 5 at low effort, applying prompt-audit to remove mandatory tool-call rituals, scratchpad steps, and contradictory rules. That cleared the Opus 4.8 baseline at 98.9% train accuracy and cut cost to 2.6 cents per ticket.我们在一个客户支持基准上运行了它，从 Opus 4.8 默认（高）努力程度开始。hillclimber 首先尝试了低努力程度的 Opus 5，应用 prompt-audit 移除强制的工具调用仪式、草稿步骤和矛盾规则。这使模型达到了 Opus 4.8 基线的 98.9% 训练准确率，并将成本降至每张工单 2.6 美分。

It then stepped down to Sonnet 5 at low effort, which was cheaper still at 1 cent per ticket, but accuracy fell to 88.9%. Reading the failing train tickets, Claude added routing rules and a refund-cap cross-reference to the prompt, bringing Sonnet 5 back to 98.9% at the same cost.随后，它降低到低努力程度的 Sonnet 5，每个工单成本仅 1 美分，更加便宜，但准确率降至 88.9%。通过查看失败的训练工单，Claude 在提示中加入了路由规则和退款上限交叉引用，使 Sonnet 5 在相同成本下恢复到 98.9% 的准确率。

On the 14 held-out tickets the search never saw, the final configuration scored 90.5% against the original setup's 78.6%, at about one fifth the cost.在搜索从未见过的 14 张保留工单上，最终配置的得分为 90.5%，而原始配置为 78.6%，成本约为原来的五分之一。

Automating cost reduction自动化成本削减

Prompt caching, instructions, and effort are common levers for reducing cost. Our documentation covers even more. To run a holistic cost audit of application code that uses the Claude API, we've added /claude-api cost-optimize: it profiles where your spend goes, applies cost reductions, and, if you provide an evaluation, shows how savings trade off with performance.提示缓存、指令和努力程度是降低成本的常见杠杆。我们的文档还涵盖更多内容。为了对使用 Claude API 的应用程序代码进行整体成本审计，我们新增了 /claude-api cost-optimize：它会分析你的支出去向，应用成本削减方案，并且如果你提供评估，它还会展示节省与性能之间的权衡。

cost-optimize starts by finding where your tokens go: from your organization's usage and cost reports if you have a Claude Admin API key, from the usage object on each API response if your application logs it, or, failing both, by reading your request-building code and estimating.cost-optimize 首先找出你的 token 用在哪里：如果你有 Claude Admin API 密钥，则从组织的使用量和成本报告中获取；如果你的应用记录了每个 API 响应中的用量对象，则从那里获取；如果两者都没有，则通过阅读你的请求构建代码并进行估算。

It then ranks the available savings, starting with prompt caching, trimming what each request carries (including a prompt-audit), bounding output, and batching unattended work. If you supply an evaluation, it goes further and computes cost and performance across effort levels and model choices. 然后，它对可用的节省方案进行排序，从提示缓存开始，包括精简每个请求携带的内容（包括 prompt-audit）、限制输出长度，以及将无人值守的任务进行批处理。如果你提供评估，它会进一步计算不同努力程度和模型选择下的成本与性能。

We ran this on four public benchmarks, starting with Sonnet 5 as a baseline (Figure 7):我们在四个公共基准上运行了该工具，以 Sonnet 5 作为基线（图7）：

• LegalBench (~58% lower cost):  cost-optimize proposed caching a shared prefix across tasks, setting low effort, and processing tasks via the Batch API. Thinking tokens fell from 102,779 to 8,284, but pass rate stayed within noise and cost dropped by ~58%.LegalBench（成本降低约58%）：cost-optimize 建议跨任务缓存共享前缀、设置低努力程度，并通过 Batch API 处理任务。思考 token 从 102,779 降至 8,284，但通过率保持不变（在噪声范围内），成本下降了约 58%。

• tau2-bench retail (~73% lower cost): By implementing prompt caching with explicit breakpoint placement, cost-optimize reduced spend by 73% while keeping pass rate flat.tau2-bench retail（成本降低约73%）：通过实现带有显式断点放置的提示缓存，cost-optimize 将支出减少了 73%，同时保持通过率持平。

• OfficeQA Pro (~52% lower cost): cost-optimize added batch processing and document caching, which brought cost down from $136.20 to $64.87. OfficeQA Pro（成本降低约52%）：cost-optimize 增加了批处理处理和文档缓存，使成本从 136.20 美元降至 64.87 美元。

• SWE-bench Verified (~55% lower cost): cost-optimize  found that the default config already caches correctly. Savings came from setting effort to medium and constraining the agent’s output to just a few concise sentences. Median steps per task went from 29 to 17 and prompt tokens fell from 75.2M to 33.7M. SWE-bench Verified（成本降低约55%）：cost-optimize 发现默认配置已经正确缓存。节省来自将努力程度设为中等，并限制代理的输出只有几个简洁句子。每任务的中位步骤数从 29 降到 17，提示 token 从 75.2M 降至 33.7M。

‍

Getting started开始使用

Start with /claude-api prompt-audit when you've migrated to a frontier Claude model and want to check your existing prompts against it. It scans the prompts, skills, and tool descriptions in your working directory. This can be application code that calls the Claude API or Claude Code's configuration (CLAUDE.md, skills). It removes common anti-patterns that hobble frontier models.当你已迁移到前沿 Claude 模型并希望检查现有提示时，请从 /claude-api prompt-audit 开始。它会扫描工作目录中的提示、技能和工具描述。这些可以是调用 Claude API 的应用程序代码，也可以是 Claude Code 的配置（CLAUDE.md、skills）。它会移除阻碍前沿模型的常见反模式。

Reach for /claude-api cost-optimize when your application uses the Claude API and you want a cost audit. It profiles token spend and then tests different levers: it applies prompt-audit, but also checks for ways to lower cost via prompt caching, batching unattended work, or bounding output. If you provide an evaluation, it measures the effort and model selection trade-offs.当你的应用程序使用 Claude API 并希望进行成本审计时，请使用 /claude-api cost-optimize。它会分析 token 支出，然后测试不同的优化手段：它应用 prompt-audit，同时也会检查通过提示缓存、批处理无人值守工作或限制输出来降低成本的方法。如果你提供评估，它还会衡量努力程度和模型选择之间的权衡。

Finally, use /claude-api hillclimb for an iterative search over cost and performance. Given an evaluation, Claude splits it into train and test sets, then proposes updates to your application that aim to reduce cost while maintaining baseline performance. Claude reads the failing train cases to guide the search, and the final configuration is scored on the held-out test set.最后，使用 /claude-api hillclimb 进行成本与性能的迭代搜索。给定一个评估，Claude 会将其拆分为训练集和测试集，然后提出针对你的应用的更新建议，目标是在保持基线性能的同时降低成本。Claude 会阅读失败的训练案例来引导搜索，最终配置会在保留的测试集上进行评分。

To learn more: 了解更多：

• See our documentation, here参阅我们的文档，点击此处
• See our cookbook, here参阅我们的实用手册，点击此处