22 道应用与 API 集成练习题及答案

Claude 认证开发者（基础级）考试练习的全部应用与 API 集成练习题，附正确答案和简短解析。

1. 某应用与 Claude 进行多轮对话。当它向 Messages API 发送第四轮用户消息时，请求体中必须包含什么？
- A.之前轮次的简要摘要；完整历史只在会话的第一次请求中被接受
- B.只需最新一条用户消息，因为服务端会按会话 ID 保存之前的轮次
- C.最新一条用户消息，加上上一次响应的 ID，由服务端在后台还原上下文
- D.之前所有用户和助手轮次的完整有序历史，再加上新的用户消息✓ 答案
Messages API 是无状态的：两次调用之间服务端不保存任何对话记录，模型只能看到当前请求中携带的内容。因此对话记录由客户端维护，每一轮都必须重新发送完整有序的 messages 数组，其中也包括助手此前的回复。
编号 QB-ZX7SQ6依据： Anthropic docs — Messages API overview (stateless requests)报告此题的问题
2. 开发者构造的 messages 数组中，第一条的角色是 assistant，随后才是一条 user 消息。文档中规定的结果是什么？
- A.API 会静默地重排数组，把 user 消息放到最前面
- B.请求被判定为无效请求而被拒绝✓ 答案
- C.该 assistant 消息会被当作系统提示词处理
- D.请求成功，该 assistant 消息被当作风格示例使用
对话必须以 user 轮次开始，因此以 assistant 开头的 messages 数组属于格式错误的请求，会被拒绝并返回客户端（4xx）无效请求错误，而不会被自动修正。assistant 消息可以出现在数组的后续位置（例如作为少样本示例），只是不能位于第一条。
编号 QB-FFP9Y4依据： Anthropic docs — Messages API, message roles报告此题的问题
3. 客户端在调用 API 前，向 messages 中连续追加了两条 user 角色的消息。API 如何处理它们？
- A.只有后一条会送给模型，前一条被丢弃
- B.请求被拒绝，因为两者之间必须插入一条 assistant 消息
- C.它们会被合并为一个 user 轮次✓ 答案
- D.在同一次请求中，每条都会各触发一次助手回复
角色相同的连续消息会被合并为一个轮次，既不会丢内容，也不会报错。当代码把上下文（例如检索到的文档）作为单独一条 user 消息追加在真正的问题之前时，这一点很重要：两者会按顺序合并为同一个轮次。
编号 QB-YXUEJ5依据： Anthropic docs — working with Messages (consecutive same-role messages)报告此题的问题
4. 用于定义助手角色、且需要贯穿整个对话的指令，应当放在什么位置？
- A.放在一种专用的内容块类型中，可以出现在 assistant 轮次内的任意位置
- B.放在请求顶层的 system 参数中，它位于 messages 数组之外✓ 答案
- C.拼接到每条用户消息文本的前面，以便模型每轮都能看到
- D.作为 messages 数组的第一条、角色为 system 的消息，且必须始终是 messages[0]
系统指令是请求的顶层参数，在结构上与对话轮次分离，正因如此它才能作用于整个对话，而不会与用户输入混淆。把它塞进用户消息中效果较差，还会让运营方指令与不可信的用户文本混杂在一起。
编号 QB-EFBXS3依据： Anthropic docs — Messages API, system prompts报告此题的问题
5. 关于 Messages API 中一条消息的 content 字段，下列哪种说法最准确？
- A.它是一个键/值映射，键名表示各部分的模态
- B.它必须始终是纯字符串；非文本输入需要使用另一个端点
- C.它可以是纯字符串，也可以是有类型内容块的有序列表✓ 答案
- D.用户轮次中它是纯字符串，助手轮次中它始终是内容块列表
content 本质上是有类型的内容块列表，纯字符串形式只是单个 text 块的简写。正是这种类型化设计，才让同一轮消息可以混合文本、图片、文档、工具调用与工具结果，并且顺序明确。
编号 QB-XXG4D4依据： Anthropic docs — Messages API, content blocks报告此题的问题
6. 直接读取 content 的第一个元素的文本来解析响应，为什么是一种脆弱的写法？
- A.因为第一个元素始终被保留用于存放响应元数据
- B.因为响应可能含多种类型的内容块，你需要的文本不一定排在第一位✓ 答案
- C.因为 content 是逆序返回的，最终答案总是在最后一个
- D.因为只有在关闭流式输出时 content 才会被填充
一次响应是一个可以容纳多个不同类型内容块的数组——例如工具调用块，或被拆分成多个块的带引用与不带引用的文本——因此索引 0 并不一定就是答案文本。健壮的代码应遍历数组，并根据每个块声明的类型分别处理。
编号 QB-DFYKM2依据： Anthropic docs — Messages API response format报告此题的问题
7. 应用需要把本地保存的一张截图发给 Claude 进行描述。该图片应如何提供？
- A.作为一个包含绝对文件路径的 text 块，由 API 从调用方的文件系统读取
- B.作为 image 内容块，携带 base64 数据及其媒体类型✓ 答案
- C.作为附加在 JSON 主体之后的原始二进制数据，使用 multipart 请求
- D.作为包含 base64 字符串的 text 块，因为模型会自动识别格式
本地图片以 image 块的形式放在 JSON 主体中，其 base64 类型的 source 必须显式声明媒体类型；API 不会自行嗅探格式，也无法访问调用方的文件系统。若图片可公开访问，也可以改用 URL 类型的 source；若已上传，则可用文件引用。
编号 QB-WX5S73依据： Anthropic docs — vision (image content blocks)报告此题的问题
8. 某个用户轮次包含一个 image 块和一个针对该图片提问的 text 块。文档推荐两者应如何排列？
- A.把它们拆成两个独立的用户轮次，先图片后文本
- B.把 text 块放在 image 块之前
- C.顺序由 API 强制规定，它总会把图片移到最后
- D.把 image 块放在 text 块之前✓ 答案
内容块按给定顺序处理，把图片放在前面意味着模型在读到问题时已经具备视觉上下文，实测效果更好。API 不会重排内容块，因此顺序完全由调用方负责。
编号 QB-MFFXTA依据： Anthropic docs — vision, prompt structure best practices报告此题的问题
9. 需要在一次 Messages API 请求中分析一份 PDF 合同。该 PDF 应如何提供？
- A.由调用方先逐页渲染成图片，再作为一串 image 内容块发送
- B.通过一个专用的文档端点上传，返回一个句柄供后续消息使用
- C.作为 document 内容块，source 可为 base64、URL 或已上传文件✓ 答案
- D.作为一个 text 内容块，内含调用方自行抽取的文本，这是唯一受支持的方式
PDF 与其他内容一样放在同一个 messages 数组中，以 document 块的形式提供，其 source 可以是内联 base64、URL 或文件引用——不需要单独的端点，也不必手动逐页渲染。由于每一页都会同时按图像和文本处理，合同这类版式复杂的文档仍可被正确理解。
编号 QB-5YM4EB依据： Anthropic docs — PDF support (document content blocks)报告此题的问题
10. 某个 agent 循环在其众多轮次中，每一轮都重复发送同一张很大的参考图片，导致请求体极其庞大。哪种改动能解决根本原因？
- A.只在第一轮发送该图片，之后依赖 API 在整个对话中记住它
- B.通过文件端点上传该图片一次，随后每次请求都引用返回的标识符✓ 答案
- C.在发送前对 JSON 字段中的 base64 字符串做 gzip 压缩
- D.把图片移到 system 参数中，因为该参数不计入请求体大小
由于 API 是无状态的，内联的 base64 内容每一轮都会被重新上传；上传一次并引用返回的文件标识符，可以让后续每个请求体都保持很小。这种“上传一次、多次引用”的模式正是文件端点的用途，该标识符可在多次请求中复用。
编号 QB-BVG7DR依据： Anthropic docs — Files API报告此题的问题
11. 上传一张 PNG 和一份 PDF 并各自拿到标识符后，在后续的 Messages 请求中应如何引用它们？
- A.两者都作为 image 块，因为标识符本身已编码了媒体类型
- B.两者都作为 document 块，因为所有上传文件都被视为文档
- C.PNG 作为 image 块，PDF 作为 document 块✓ 答案
- D.作为包含标识符字符串的纯 text 块，由 API 自动替换为文件内容
文件标识符并不改变内容的类型归属：块类型必须与文件的媒体类型匹配，因此图片放入 image 块，PDF 或纯文本放入 document 块。类型不匹配会被判为无效请求而拒绝，而不会被静默转换。
编号 QB-TCB2TQ依据： Anthropic docs — Files API, referencing files in Messages报告此题的问题
12. 某产品需要显示 Claude 回答中的每条结论分别由所提供文档的哪一段支撑。正确的实现机制是什么？
- A.在提示词中要求给出带页码的引文，这是获取来源引用的唯一受支持方式
- B.在该 document 内容块上启用 citations✓ 答案
- C.事后调用一个独立的引用端点，并传入响应标识符
- D.任何文档都会自动生成引用，因此请求端无需任何改动
引用是在每个 document 块上按需开启的设置，开启后会改变响应结构：答案会以多个 text 块返回，其中带引用的块携带结构化引用信息，可定位到原文中的支撑片段。正是这种结构让界面能可靠地高亮证据，而不必依赖模型可能改写的自由文本引文。
编号 QB-CVUHJS依据： Anthropic docs — citations报告此题的问题
13. 某夜间任务需要对数万份文档进行分类。结果直到第二天早上才需要，而单份文档的成本很重要。哪种方案最合适？
- A.把文档拆分为并行的同步请求，在速率限制允许范围内尽快跑完
- B.把这些工作提交为异步批处理任务，并享有价格折扣✓ 答案
- C.仍用同步请求，但不做质量评估直接换成最便宜的模型
- D.仍用同步请求，但大幅调低每次请求的输出 token 上限来降低成本
判断依据是“是否真的需要低延迟”；当不需要低延迟且数量很大时，异步批处理端点就是既定方案，因为它用交付时间换取更低的价格。三个干扰项都仍停留在实时路径上，只是从别处“省钱”：并行分发只会耗尽速率配额，压低输出上限会截断答案，而未经评估就降级模型则是盲目牺牲准确性。
编号 QB-UCPCYR依据： Anthropic docs — Message Batches API overview (batch vs realtime)报告此题的问题
14. 通过异步批处理端点执行任务的正确生命周期是怎样的？
- A.提交批次后直接从创建响应中读取结果，该调用会一直阻塞到结果就绪
- B.提交批次，轮询其处理状态直到显示处理已结束，然后读取结果✓ 答案
- C.逐条单独提交请求，并按各自的标识符分别轮询直到完成
- D.提交批次后等待服务端主动向客户端发起连接并推送结果
批处理在设计上就是异步的：创建请求会立即返回批次标识符和处理状态，客户端据此轮询状态，待处理结束后再拉取结果。整个过程不会阻塞，服务端也不会回调客户端——正因如此，该端点适合运行时长远超单次 HTTP 请求所应承受的任务。
编号 QB-9VSH2P依据： Anthropic docs — Message Batches API, polling for completion报告此题的问题
15. 读取一个已完成的批次结果时，应如何把每条结果与产生它的输入请求对应起来？
- A.把每条结果的文本与原始提示词逐一比对，取最接近的一条
- B.通过每条请求上由调用方自定义的标识符匹配✓ 答案
- C.按请求完成的先后顺序匹配，服务端会单独给出该顺序
- D.按位置匹配，因为结果会按请求提交的顺序返回
批次中的每条请求都带有调用方自定义的标识符，正是为了让结果能被重新对应，结果流中的每条记录都会回带该标识符。返回顺序没有保证，因此按下标把结果与输入列表逐一配对的代码，会静默地把答案挂到错误的记录上。
编号 QB-RCMCFN依据： Anthropic docs — Message Batches API, retrieving results报告此题的问题
16. 对于预计会产生很长响应的请求，为什么推荐使用流式输出？
- A.因为流式输出会提高模型被允许生成的最大输出 token 数
- B.因为只要响应可能很长，非流式请求就会被直接拒绝
- C.因为长时间的非流式请求会让连接空闲，可能触发客户端或代理的 HTTP 超时✓ 答案
- D.因为流式输出的 token 计费比非流式更便宜
关闭流式时，服务端在生成完成前不会发送任何数据，因此较长的生成过程可能超出 HTTP 客户端或中间代理的超时时间，导致工作已经完成却仍然请求失败。流式会持续发送事件，使连接保持活跃，同时客户端可以边收边渲染部分输出。
编号 QB-AV5V7Q依据： Anthropic docs — streaming Messages报告此题的问题
17. 对于只包含一个文本块的流式响应，哪一个事件序列符合文档描述的结构？
- A.不断重复的 message start 与 message stop 成对出现，每段文本各一对
- B.content block start，然后 message start，接着是各个 delta，最后 message stop
- C.message start、content block start、delta、content block stop、消息级 delta、message stop✓ 答案
- D.一个携带完整内容的 message start，随后是 message stop
数据流以 message start 事件开始，其中的消息外壳 content 为空；随后每个内容块都由一个 start 事件、一个或多个增量 delta 和一个 stop 事件包裹；最后由消息级更新和 message stop 结束整个流。按这种信封结构来处理事件（而不是假设文本会裸奔而来），才能让消费端同样适配多内容块和使用工具的响应。
编号 QB-SCYPMP依据： Anthropic docs — streaming, event flow报告此题的问题
18. 客户端以流式方式接收响应，并需要知道生成为何停止。这一信息在何处到达？
- A.在流末尾附近的消息级 delta 中✓ 答案
- B.在每个 content block stop 事件中，每个内容块各一次
- C.只能对同一提示词再发一次非流式请求才能得知
- D.在 message start 事件中，它已经预先给出消息将如何结束
开头的 message start 事件只携带一个 content 为空的消息外壳，且没有最终的停止原因，因为此时尚未开始生成；停止原因是只有在结束时才能确定的顶层字段，因此通过消息级 delta 下发。若误以为一开始就能拿到，代码就永远不会发现响应其实是因为达到输出上限而被截断的。
编号 QB-FVWH3W依据： Anthropic docs — streaming, message_delta event报告此题的问题
19. 关于 API 返回的 HTTP 状态码与其成因的对应关系，下列哪一项是正确的？
- A.429——调用方的密钥对所请求的资源没有权限
- B.401——凭据缺失或无效✓ 答案
- C.404——请求的 JSON 主体格式错误
- D.413——服务暂时过载
401 表示认证问题——凭据缺失、格式错误或已被吊销——它与 403 不同，后者表示凭据有效但无权访问该资源。其余选项都张冠李戴：请求体格式错误是 400，超出速率限制是 429，请求体过大是 413，而服务过载由 5xx 服务端状态码表示。
编号 QB-XCRCGV依据： Anthropic docs — API errors (HTTP status codes)报告此题的问题
20. 客户端应当以退避方式重试、而不是视为永久失败的，是哪一类错误？
- A.请求体过大的响应，因为服务有空闲容量后就会成功
- B.限流响应和服务端错误，包括表示过载的状态✓ 答案
- C.认证与权限失败，因为它们通常过一会儿会自行恢复
- D.请求格式错误与资源不存在的响应，因为该端点稍后可能会出现
只有当失败是暂时性的——请求本身合法、稍后重试可能成功——重试才有意义，限流、暂时性服务端错误和过载都属于这种情况。凭据错误、权限不足、请求体格式错误、资源不存在以及请求体过大，反映的都是请求本身有问题，因此原样重试只会持续失败并徒增负载。
编号 QB-GMFPJK依据： Anthropic docs — API errors, retryable errors报告此题的问题
21. 某次请求因超出速率限制被拒绝，响应中带有 retry-after 头。客户端正确的做法是什么？
- A.立即在紧凑循环中不断重试，直到某次被接受
- B.视为永久失败并丢弃该请求，因为速率限制不会恢复
- C.忽略 retry-after，按固定的短间隔重试，因为该头只是给浏览器的建议
- D.至少等待 retry-after 指示的时长，再以带抖动的指数退避重试并限制次数✓ 答案
速率限制会随时间恢复，因此该请求是可重试的——但必须等到服务端在 retry-after 中指明的时长之后，并采用逐次增长的等待时间加随机抖动，以免大量客户端同时恢复而再次形成尖峰。立即紧凑重试只会加剧限流而非缓解，同时设置重试次数上限可避免持续性故障陷入无限循环。
编号 QB-Z4NU5M依据： Anthropic docs — API errors and rate limits (retry-after)报告此题的问题
22. 集成代码应如何区分 SDK 可能抛出的不同错误情形？
- A.按从最具体到最宽泛的顺序捕获 SDK 提供的类型化异常类，最后再捕获基类✓ 答案
- B.让所有异常向上抛出，依赖 SDK 自动重试所有失败
- C.解析异常打印出的字符串以还原状态码
- D.只捕获一个宽泛的基类异常，然后在错误消息文本中查找诸如 rate limit、not found 之类的子串
SDK 为每种错误情形定义了不同的异常类，正是为了让调用方按类型分支处理；把处理分支按从具体到宽泛排列，才能保证具体情形不会被基类先行吞掉。依赖错误消息文本匹配十分脆弱，因为措辞不属于 API 契约，可能随时更改；而只用一个统一捕获则会丢失这些类所编码的“可重试与永久失败”的区分。
编号 QB-HMTZQM依据： Anthropic docs — SDK error handling (typed exceptions)报告此题的问题

本考试的其他主题

智能体与工作流22 道免费练习题模型选择与优化23 道免费练习题提示工程、Claude Code 与评估23 道免费练习题安全、工具与 MCP23 道免费练习题

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

1. 某应用与 Claude 进行多轮对话。当它向 Messages API 发送第四轮用户消息时，请求体中必须包含什么？

2. 开发者构造的 messages 数组中，第一条的角色是 assistant，随后才是一条 user 消息。文档中规定的结果是什么？

3. 客户端在调用 API 前，向 messages 中连续追加了两条 user 角色的消息。API 如何处理它们？

4. 用于定义助手角色、且需要贯穿整个对话的指令，应当放在什么位置？

5. 关于 Messages API 中一条消息的 content 字段，下列哪种说法最准确？

6. 直接读取 content 的第一个元素的文本来解析响应，为什么是一种脆弱的写法？

7. 应用需要把本地保存的一张截图发给 Claude 进行描述。该图片应如何提供？

8. 某个用户轮次包含一个 image 块和一个针对该图片提问的 text 块。文档推荐两者应如何排列？

9. 需要在一次 Messages API 请求中分析一份 PDF 合同。该 PDF 应如何提供？

10. 某个 agent 循环在其众多轮次中，每一轮都重复发送同一张很大的参考图片，导致请求体极其庞大。哪种改动能解决根本原因？

11. 上传一张 PNG 和一份 PDF 并各自拿到标识符后，在后续的 Messages 请求中应如何引用它们？

12. 某产品需要显示 Claude 回答中的每条结论分别由所提供文档的哪一段支撑。正确的实现机制是什么？

13. 某夜间任务需要对数万份文档进行分类。结果直到第二天早上才需要，而单份文档的成本很重要。哪种方案最合适？

14. 通过异步批处理端点执行任务的正确生命周期是怎样的？

15. 读取一个已完成的批次结果时，应如何把每条结果与产生它的输入请求对应起来？

16. 对于预计会产生很长响应的请求，为什么推荐使用流式输出？

17. 对于只包含一个文本块的流式响应，哪一个事件序列符合文档描述的结构？

18. 客户端以流式方式接收响应，并需要知道生成为何停止。这一信息在何处到达？

19. 关于 API 返回的 HTTP 状态码与其成因的对应关系，下列哪一项是正确的？

20. 客户端应当以退避方式重试、而不是视为永久失败的，是哪一类错误？

21. 某次请求因超出速率限制被拒绝，响应中带有 retry-after 头。客户端正确的做法是什么？

22. 集成代码应如何区分 SDK 可能抛出的不同错误情形？

本考试的其他主题