23 道模型选择与优化练习题及答案

Claude 认证开发者（基础级）考试练习的全部模型选择与优化练习题，附正确答案和简短解析。

1. 一个高流量的摘要接口需要降低每次调用的 token 消耗，开发者决定调低推理 effort。在 Messages API 请求中，effort 这个设置应该放在哪里？
- A.放在请求的 HTTP 头信息里面，而完全不出现在 JSON 请求体中。
- B.放在 thinking 对象里面，与它已有的 type 字段并列排列。
- C.放在请求体的顶层，与 max_tokens 字段处于同一并列位置。
- D.放在 output_config 对象内，作为它的 effort 字段。✓ 答案
effort 是 output_config 对象里的字段，既不是顶层请求参数，也不属于 thinking 对象；它在同一个模型内部调节推理深度和 token 花费，是免费手段用尽之后第一个用质量换成本的旋钮。
编号 QB-GJVN22依据： Anthropic Messages API reference - output_config.effort报告此题的问题
2. 某服务在旧模型上用 budget_tokens 设定固定思考预算。把模型字符串换成新模型之后，每个请求都返回 HTTP 400。这说明这次迁移意味着什么？
- A.该参数只是被弃用，服务端会忽略它，请求体可以保持原样不动。
- B.新模型移除的参数会被直接拒绝，所以请求体本身也必须跟着改。✓ 答案
- C.这是发布过程中的临时故障，原样重试之后请求就会恢复正常。
- D.该预算改从请求头读取，所以同一个值需要移出 JSON 请求体。
新模型不再接受的请求参数会返回校验错误，而不是被静默忽略；自适应思考已经取代了固定思考预算，因此换用新模型是一次代码改动，而不只是替换一个模型字符串。
编号 QB-X2C6AY依据： Anthropic model migration guide - removed request parameters报告此题的问题
3. 开发者希望当前模型在难工单上多想一些、在简单工单上少想一些，又不想为每个请求手工调一个数字。下列哪一项符合当前模型上扩展思考的配置方式？
- A.深度完全由模型所在的档位固定，请求方无法对推理的多少产生任何影响。
- B.每个请求都要声明一个固定的 token 预算，并且模型必须把预算用完。
- C.思考深度由 temperature 参数决定，把它调高之后推理过程就会变长。
- D.把思考设为自适应，由模型逐轮决定深度，再用 effort 调节整体花费。✓ 答案
当前模型使用自适应思考，由模型逐轮决定推理多少，整体花费则由 effort 档位来调节；为每个请求设定固定思考预算属于上一代 API 的做法。
编号 QB-FJHBVY依据： Anthropic extended thinking documentation - adaptive thinking报告此题的问题
4. 某团队使用流式输出，看到 thinking 块的文本是空的（display 保持默认值），于是认为这次请求没有产生也没有计费任何推理 token。这个判断为什么是错的？
- A.thinking 块为空说明模型这次请求走了不带思考的那条路径。
- B.只有在返回可读摘要时才对思考 token 计费，隐藏就不产生费用。
- C.块为空是因为推理被推迟到了会话的下一轮，本轮还没有开始。
- D.display 只控制可见性，推理照常发生，也照常按输出计费。✓ 答案
display 设置只决定是否返回一段可读的推理摘要；原始思维链在任何设置下都不会返回，而思考 token 无论显示与否都会照常生成并计费。
编号 QB-23E6T3依据： Anthropic extended thinking documentation - thinking display and billing报告此题的问题
5. 为了压低成本，开发者把 max_tokens 设得远低于该接口答案通常需要的长度。用户开始反馈回答讲到一半就断了。这些请求实际发生了什么？
- A.生成在上限处截断，返回 max_tokens 停止原因，本轮需要重来。✓ 答案
- B.模型会把答案改写到刚好能塞进上限，质量下降但内容仍然是完整的。
- C.剩下的文本会暂存在服务端，在会话的下一个请求里补发给客户端。
- D.请求会在生成之前就被拒绝，因此这些被截断的尝试完全不产生费用。
max_tokens 是模型自身感知不到的单次响应硬性上限：触顶会让输出在半句话处截断并返回 stop_reason 为 max_tokens，已经生成的 token 照常计费，所以除非输出本来就该很短，低上限在重试之后其实并不省钱。
编号 QB-JJKBD4依据： Anthropic Messages API reference - stop_reason max_tokens报告此题的问题
6. 某报告生成器让当前模型输出一份很长的文档，并相应把 max_tokens 设得很大，但没有开启流式。调用在返回任何内容之前就以 HTTP 超时失败。正确的修复方式是什么？
- A.把这一个请求拆成多个并行调用，让每个调用都在超时之前就返回。
- B.把 max_tokens 一路调小，直到回复能在客户端默认超时之内返回。
- C.调高客户端的重试次数，让请求不断重发，直到某一次能够成功返回。
- D.改用流式发送请求，再用 SDK 的最终消息辅助方法拼出完整回复。✓ 答案
非流式请求会一直占着连接，直到整段响应生成完毕，因此很大的输出上限很容易撞上 HTTP 超时；流式让数据持续返回，在不需要逐个处理事件时，用 SDK 的最终消息辅助方法即可拿到完整回复。
编号 QB-Z23UM2依据： Anthropic SDK guidance - streaming required for large max_tokens报告此题的问题
7. 某团队在聊天产品里全面启用流式输出，本以为月度账单会下降，结果用量数据几乎没有变化。流式输出真正改变的是什么？
- A.它在传输时压缩响应内容，因此同样的回答按更少的输出 token 计费。
- B.它复用上一轮已经发过的 token，让重复上下文每次会话只计费一次。
- C.它让 token 边生成边显示，降低体感延迟和超时风险，但不改变价格。✓ 答案
- D.它在客户端渲染够用的文本之后停止生成，从而减少被计费的 token。
流式改变的是同一批 token 的送达方式，而不是生成的数量，因此计费完全相同；它的收益在于让等待中的用户更早看到内容，以及避免长输出撞上请求超时。
编号 QB-HJ8Z73依据： Anthropic streaming documentation - purpose of streaming报告此题的问题
8. 有四万条支持工单需要在早班报告之前完成分类，而且没有任何人在等待其中某一条的结果。哪种做法最符合这个约束？
- A.把这批工作提交给 Message Batches API，等结束之后再读结果。✓ 答案
- B.对所有工单都换用能力最小的模型，因为真正花钱的根源就在这个数量级。
- C.用大量工作线程并行发起调用，因为提高并发可以降低单位 token 成本。
- D.逐条发送请求并开启流式输出，因为流式是所有送达方式里最省钱的一种。
批处理用延迟换成本：同样的请求异步提交后，按低于实时调用的价格计费，而通宵窗口正好提供了批处理所需要的延迟容忍度。并行扇出只缩短墙钟时间，并不降低每个 token 的价格。
编号 QB-435U56依据： Anthropic Message Batches API - asynchronous processing discount报告此题的问题
9. 几千条请求的批处理跑完之后，开发者按位置把结果和输入列表逐一对齐，结果有些记录用错了别的工单的输出。这里违反的规则是什么？
- A.结果是分页返回的，因此只有第一页能和原始输入的顺序对得上号。
- B.结果会略过失败的请求，所以列表整体错位，需要补位之后再对齐。
- C.结果返回的顺序是任意的，必须用调用方自己的 custom_id 来匹配。✓ 答案
- D.结果按完成时间排序，所以在逐一对齐之前必须先把列表重新排序。
Batches API 按调用方提交的 custom_id 返回每一条结果，且顺序任意，因此结果流中的位置与提交列表中的位置没有任何对应关系；按下标匹配会悄悄把记录张冠李戴。
编号 QB-MJAZQ6依据： Anthropic Message Batches API - results are returned by custom_id in any order报告此题的问题
10. 开发者把一个可用的实时请求（开启了流式）原封不动放进批处理请求里提交，该批处理被判为无效。原因是什么？
- A.失败是因为带流式的请求必须在批次对象上再带一个与之匹配的请求头。
- B.只有当批次里每一个请求都同样开启流式时，批处理才会接受这个参数。
- C.批处理里的请求不能使用流式，它的结果是在批次结束后整体取回的。✓ 答案
- D.批处理其实允许流式，这次失败说明该批次超出了它允许的体积上限。
批次里的条目是异步处理的，结果要等批次结束之后再取回，因此逐请求的流式在这里没有意义，该参数不被接受；流式属于有人在等待响应的实时路径。
编号 QB-2EW74P依据： Anthropic Message Batches API - unsupported request parameters报告此题的问题
11. 某个 agent 缓存了一段很长的系统提示并在多轮之间复用。一次发版给工具列表新增了一个工具，此后每个请求的缓存读取都掉到了零。为什么这一处小改动代价这么大？
- A.工具列表本来就不在被缓存的前缀里，所以这次下降只能来自系统提示改动。
- B.工具变更会重置缓存的存活时间，条目提前过期，但下一轮就会被重新建立。
- C.工具定义是单独缓存的，新增一个只会清掉这个工具自己的那条缓存条目。
- D.工具在系统提示和消息之前渲染，改动它会让其后的整段前缀全部失效。✓ 答案
提示缓存是前缀匹配，渲染顺序依次是 tools、system、messages；前缀中任何一个字节发生变化，其后的全部内容都会失效，所以改动工具列表会一路波及系统提示和消息历史。
编号 QB-HWQ2HN依据： Anthropic prompt caching documentation - cache invalidation hierarchy报告此题的问题
12. 某服务缓存了一段很长的系统提示，但每次重复请求的 cache_read_input_tokens 都是零。该系统提示由一个辅助函数拼装，会把当前时间写进它的第一行。开发者应该怎么做？
- A.延长缓存的存活时间，让条目撑过这些重复调用之间的间隔。
- B.把时间戳挪到系统提示的最前面，让后面的前缀内容保持稳定。
- C.多设几个缓存断点，让其中至少有一个落在变化的那一行前面。
- D.把这个时间戳移出前缀，放到最后一个缓存断点之后的位置上。✓ 答案
请求之间只要有一个字节不同，其后的全部内容就无法命中前缀匹配，所以系统提示里任何位置的每请求时间戳或 id 都会让缓存静默失效；易变内容应当放在最后一个断点之后，这样它就无法破坏稳定部分。
编号 QB-3E9J9Q依据： Anthropic prompt caching documentation - silent invalidators报告此题的问题
13. 开发者查看一个命中缓存的请求的 usage，看到 input_tokens 很小，而 cache_read_input_tokens 很大。这个很小的 input_tokens 代表什么？
- A.模型真正参与注意力计算的 token，也就是丢掉缓存前缀之后的部分。
- B.本次请求写入缓存的 token 数量，这些内容要等以后才可能被读回。
- C.整个提示的总规模，其中被缓存的 token 在这个总数里又算了一遍。
- D.本次请求中位于最后一个断点之后、没有从缓存读到的那部分 token。✓ 答案
input_tokens 只统计本次请求中未命中缓存的输入；cache_read_input_tokens 与 cache_creation_input_tokens 是分开上报的，本次调用的输入总量是这三项之和。
编号 QB-JW3DPP依据： Anthropic prompt caching documentation - usage fields报告此题的问题
14. 开发者给一个接口加上了提示缓存，而该接口的流量几乎全是一次性请求，用户之间没有共享前缀。账单反而略有上升。这是为什么？
- A.读取缓存和普通输入是同一个价位，所以建条目只增加成本不带来节省。
- B.缓存让前缀在每个请求里被计费两次，一次算输入一次算缓存条目。
- C.每个请求都付了写入的溢价，却没有一个请求真正读到过缓存。✓ 答案
- D.缓存条目按整个存活期计费，因此没人使用的空闲条目也在持续计费。
把前缀写入缓存比同样的未缓存输入略贵，而缓存读取则便宜得多，所以只有前缀真的被复用时缓存才回得了本；一次性流量只付了写入溢价，永远拿不到读取折扣。
编号 QB-4EMVER依据： Anthropic prompt caching documentation - cache write and read pricing multipliers报告此题的问题
15. 一个长时间运行的 agent 启用了服务端压缩。开发者每轮只把响应里的文本追加回消息列表，结果上下文照样一直增长，像是压缩从未生效。问题出在哪里？
- A.必须把响应的完整内容追加回去，因为压缩状态就存放在这些块里面。✓ 答案
- B.压缩要求调用方先自行删掉更早的轮次，之后它才会真正开始起作用。
- C.压缩只作用于工具结果，所以以文本为主的会话根本不会被它处理到。
- D.摘要出现在下一次响应里，所以还要再多走一轮它才会开始起作用。
压缩在服务端汇总更早的上下文，并把该状态以块的形式放在响应内容里返回，所以只追加抽取出来的文本会静默丢掉它，会话又退回到完整历史；清除类策略是另一种机制，它删除旧块而不是做摘要。
编号 QB-KWEQUQ依据： Anthropic context management documentation - compaction versus context editing报告此题的问题
16. 在上线一个每次都把大文档塞进提示的接口之前，开发者想拿到准确的输入规模用于做预算。正确的做法是什么？
- A.先发一次请求并读取输出 token 数，因为输入规模和它是高度相关的。
- B.用字符数除以四，因为这是英文散文里公认的字符与 token 换算比例。
- C.用同样的模型、系统提示和消息去调用 token 计数接口，拿回准确数值。✓ 答案
- D.用第三方分词库把这段文本跑一遍，直接采用它报出来的 token 数量。
count_tokens 接口会完全按照 API 的方式统计整个请求，包括系统提示和工具定义，因此它是唯一可靠的事前数值；第三方分词器针对的是别的模型的词表，而按字符估算的比例会随语言和内容漂移。
编号 QB-5EY7MS依据： Anthropic token counting endpoint - /v1/messages/count_tokens报告此题的问题
17. 开发者要在两个模型之间，为一条需要接收超大输入的路由做选择，需要知道每个候选模型的上下文容量和所支持的特性。在代码里怎样确定才稳妥？
- A.不断发送越来越大的提示，直到有一次报错，就把那个规模当作上限。
- B.假定同一系列里的模型上限一致，因为容量是跟着系列名称一起定的。
- C.调用 Models API 取回当前条目，读取其能力字段与各项上限。✓ 答案
- D.把该档位发布公告里的数字硬编码成代码中的一个常量，直接拿来用。
能力、价格和上下文容量因模型而异，并且随每次发布而变化，所以当前数值应当通过调用 Models API 或查阅当前文档得到，而不是靠记忆、靠试错试探，或者按系列名称去推断。
编号 QB-MWS22S依据： Anthropic Models API - GET /v1/models capability discovery报告此题的问题
18. 某条路由使用前沿模型并把 effort 调低。另一个更便宜的模型在高 effort 下单价更低，但要多跑几轮、多重试几次才能完成同一个任务。这个选择应该怎么做？
- A.比较首字响应的延迟，因为跑得更快的模型完成同样的工作也更省钱。
- B.比较每完成一个任务的成本，因为多出来的轮次和重试同样会计入账单。✓ 答案
- C.只比较输出 token 的单价，因为一次请求的费用主要由输出部分决定。
- D.比较每个输入 token 的单价，因为账单本来就是按这个数字算出来的。
Anthropic 的指引是按每完成一个任务的成本来判断，而不是按每 token 单价：能力更强的模型即使在较低 effort 下，往往也能用更少的轮次和更少的重试解决问题，因此单价更高反而总成本更低。
编号 QB-WDGVDH依据： Anthropic cost optimization guidance - cost per completed task报告此题的问题
19. 为了压缩开销，团队打算把简单请求路由到小模型、把复杂请求路由到大模型，两条路径上都带同一段很长的缓存系统提示。动手之前他们应该先权衡什么后果？
- A.缓存是按模型隔离的，这段共享前缀会在两条路径上各缓存一次也各付一次。✓ 答案
- B.路由本身必须由一次模型调用来做，多出来的这一跳才是级联昂贵的真正原因。
- C.这样路由会迫使前缀每次都以未缓存方式重发，因为条目只能归属一个模型。
- D.缓存是跨模型共享的，第二条路径可以免费读到第一条路径建好的那条条目。
提示缓存是按单个模型隔离的，级联架构无法在另一个模型上复用前一个模型的缓存前缀，两条路径都要各付一次写入成本；应先量一量更简单的替代方案，也就是同一个高能力模型配更低的 effort。
编号 QB-DWAQTG依据： Anthropic prompt caching documentation - caches are model-scoped报告此题的问题
20. 某个 TypeScript 服务把客户端超时设成了 30，本意是三十秒。长请求随即几乎立刻开始失败。原因是什么？
- A.这个值被夹到了该客户端允许的最小超时，而那个下限远小于一秒。
- B.该 SDK 的超时必须逐请求设置，所以客户端层级的这个值没有生效。
- C.超时是按每个 token 计算的上限，无论怎么写长生成都会触发它。
- D.该 SDK 的超时以毫秒为单位，这个值实际上设成了三十毫秒的上限。✓ 答案
各官方 SDK 的超时单位并不一致：有的用秒，有的用毫秒，有的用时长类型，所以把一个数字从一种语言照抄到另一种语言，含义会悄悄改变；设置之前应确认所用 SDK 的单位。
编号 QB-P57CHW依据： Anthropic SDK client configuration - timeout units by SDK报告此题的问题
21. 某个对延迟敏感的接口设了较宽松的客户端超时，并保留了自动重试的默认设置。有用户反馈某个请求挂了远超超时时长之后才最终失败。这该怎么解释？
- A.超时本身也会被重试，最坏情况的墙钟时间是超时乘以尝试的总次数。✓ 答案
- B.超时只覆盖建立连接的阶段，生成所花的时间并不计入这个超时里面。
- C.每收到一个流式事件超时就会重置，所以慢速流可以把它无限延长下去。
- D.重试要排在限流后面，所以这段延迟来自排队等待，而不是调用本身。
超时属于 SDK 会自动重试的失败类型之一，因此总墙钟时间可能达到超时时长乘以尝试次数，也就是首次调用加上配置的重试次数；这两个设置必须放在一起预算。
编号 QB-7NCH4X依据： Anthropic SDK client configuration - timeouts are retried报告此题的问题
22. 某集成把所有 API 调用都包在一个宽泛的 catch 里，记录日志然后重试。现在它对格式错误的请求无限重试，却在遇到限流时过早放弃。这段处理应该怎么重构？
- A.对所有失败都带退避重试，因为永久性错误再失败一次的代价也很低廉。
- B.按从具体到宽泛的顺序捕获各类型化异常，只对可重试的失败做重试。✓ 答案
- C.按每种错误的消息文本做匹配，这样新出现的失败类型可以随时补进来。
- D.把带状态码的错误一律视为可重试，只跳过连接层面出现的那一类失败。
SDK 提供了类型化的异常类，只有按从具体到宽泛的链式捕获，才能把可重试的失败（限流、服务端错误、连接问题）与永久性失败（请求格式错误、凭据无效）区分开；靠字符串匹配会随消息文案改动而失效。
编号 QB-Q5JPPX依据： Anthropic SDK error handling - typed exception classes报告此题的问题
23. 某聊天功能每轮只发送最新的一条用户消息，结果 Claude 不断忘记会话早先提到的细节。开发者需要改什么？
- A.打开流式输出，它保持连接不断开，从而按顺序保留住之前的每一轮。
- B.每轮都把整段对话历史重新发过去，因为该 API 在调用之间不保存状态。✓ 答案
- C.在每次调用上带一个会话 id，让服务端把这些轮次串成同一个会话。
- D.调高 max_tokens，好让模型有足够空间回想起前几轮里说过的内容。
Messages API 是无状态的，每个请求只依据它自身携带的内容来作答，因此历史必须每一轮都重新发送；而不断增长的历史正是长会话的主要成本来源，所以其中大部分应当以缓存读取的形式命中。
编号 QB-8NQU9Y依据： Anthropic Messages API - stateless conversation history报告此题的问题

本考试的其他主题

智能体与工作流22 道免费练习题应用与 API 集成22 道免费练习题提示工程、Claude Code 与评估23 道免费练习题安全、工具与 MCP23 道免费练习题

练习题依据官方 Claude 认证开发者基础级（CCDV-F）考试指南和 Anthropic 公开文档编写。这是一个独立的学习工具，与 Anthropic 无关联、未获其认可，也不授予任何认证。考试由 Pearson VUE 交付；当前的题量、考试时长、通过分数和费用以 Anthropic 官方 CCDV-F 考试指南公布的为准。官方认证页面 →

1. 一个高流量的摘要接口需要降低每次调用的 token 消耗，开发者决定调低推理 effort。在 Messages API 请求中，effort 这个设置应该放在哪里？

2. 某服务在旧模型上用 budget_tokens 设定固定思考预算。把模型字符串换成新模型之后，每个请求都返回 HTTP 400。这说明这次迁移意味着什么？

3. 开发者希望当前模型在难工单上多想一些、在简单工单上少想一些，又不想为每个请求手工调一个数字。下列哪一项符合当前模型上扩展思考的配置方式？

4. 某团队使用流式输出，看到 thinking 块的文本是空的（display 保持默认值），于是认为这次请求没有产生也没有计费任何推理 token。这个判断为什么是错的？

5. 为了压低成本，开发者把 max_tokens 设得远低于该接口答案通常需要的长度。用户开始反馈回答讲到一半就断了。这些请求实际发生了什么？

6. 某报告生成器让当前模型输出一份很长的文档，并相应把 max_tokens 设得很大，但没有开启流式。调用在返回任何内容之前就以 HTTP 超时失败。正确的修复方式是什么？

7. 某团队在聊天产品里全面启用流式输出，本以为月度账单会下降，结果用量数据几乎没有变化。流式输出真正改变的是什么？

8. 有四万条支持工单需要在早班报告之前完成分类，而且没有任何人在等待其中某一条的结果。哪种做法最符合这个约束？

9. 几千条请求的批处理跑完之后，开发者按位置把结果和输入列表逐一对齐，结果有些记录用错了别的工单的输出。这里违反的规则是什么？

10. 开发者把一个可用的实时请求（开启了流式）原封不动放进批处理请求里提交，该批处理被判为无效。原因是什么？

11. 某个 agent 缓存了一段很长的系统提示并在多轮之间复用。一次发版给工具列表新增了一个工具，此后每个请求的缓存读取都掉到了零。为什么这一处小改动代价这么大？

12. 某服务缓存了一段很长的系统提示，但每次重复请求的 cache_read_input_tokens 都是零。该系统提示由一个辅助函数拼装，会把当前时间写进它的第一行。开发者应该怎么做？

13. 开发者查看一个命中缓存的请求的 usage，看到 input_tokens 很小，而 cache_read_input_tokens 很大。这个很小的 input_tokens 代表什么？

14. 开发者给一个接口加上了提示缓存，而该接口的流量几乎全是一次性请求，用户之间没有共享前缀。账单反而略有上升。这是为什么？

15. 一个长时间运行的 agent 启用了服务端压缩。开发者每轮只把响应里的文本追加回消息列表，结果上下文照样一直增长，像是压缩从未生效。问题出在哪里？

16. 在上线一个每次都把大文档塞进提示的接口之前，开发者想拿到准确的输入规模用于做预算。正确的做法是什么？

17. 开发者要在两个模型之间，为一条需要接收超大输入的路由做选择，需要知道每个候选模型的上下文容量和所支持的特性。在代码里怎样确定才稳妥？

18. 某条路由使用前沿模型并把 effort 调低。另一个更便宜的模型在高 effort 下单价更低，但要多跑几轮、多重试几次才能完成同一个任务。这个选择应该怎么做？

19. 为了压缩开销，团队打算把简单请求路由到小模型、把复杂请求路由到大模型，两条路径上都带同一段很长的缓存系统提示。动手之前他们应该先权衡什么后果？

20. 某个 TypeScript 服务把客户端超时设成了 30，本意是三十秒。长请求随即几乎立刻开始失败。原因是什么？

21. 某个对延迟敏感的接口设了较宽松的客户端超时，并保留了自动重试的默认设置。有用户反馈某个请求挂了远超超时时长之后才最终失败。这该怎么解释？

22. 某集成把所有 API 调用都包在一个宽泛的 catch 里，记录日志然后重试。现在它对格式错误的请求无限重试，却在遇到限流时过早放弃。这段处理应该怎么重构？

23. 某聊天功能每轮只发送最新的一条用户消息，结果 Claude 不断忘记会话早先提到的细节。开发者需要改什么？

本考试的其他主题