Claude认证架构师考试：5大知识域与6大场景实战解析

1. 项目概述：Claude认证架构师考试全景解析

最近身边不少做AI应用开发和技术架构的朋友都在讨论一个话题：Claude认证架构师考试。这让我想起了几年前云计算认证刚兴起时的场景，大家一边吐槽考试费贵、内容更新快，一边又默默刷题备考，因为市场确实认这个。现在，大模型技术栈的认证也开始进入这个循环了。我花了些时间，把Claude认证架构师考试（Claude Certified Architect Exam）的里里外外研究了一遍，发现它确实不是那种“背题库就能过”的认证。它的核心是围绕5个知识域和6个典型应用场景，考察你如何用Claude的API和工具集，去解决真实的商业问题。简单说，它考的不是你会不会调API，而是你能不能成为一名合格的“AI解决方案架构师”。

这个认证适合谁呢？我觉得主要有三类人。第一类是技术负责人或架构师，你们需要为团队引入大模型能力，这个认证能帮你系统化地理解技术边界和最佳实践，避免踩坑。第二类是AI应用开发者，你们可能已经用Claude API做过一些Demo，但想更体系化地提升，把玩具项目变成可落地、可维护的生产级应用。第三类是想转型或提升竞争力的工程师，一个权威的认证是简历上不错的加分项，能证明你不仅跟上了趋势，还达到了某个专业标准。接下来，我会结合这5个知识域和6个场景，把我梳理出的备考重点、实战心得以及那些官方文档里不会明说的“坑”，毫无保留地分享给你。

2. 考试核心框架：深入解读5大知识域

Claude认证架构师考试的整体框架非常清晰，它不像一些传统认证那样罗列零散的技术点，而是从架构师的实际工作流出发，构建了五个环环相扣的知识域。理解这五个域的关系，比死记硬背任何一个单独的技术细节都重要。

2.1 知识域一：模型能力与限制的精准把握

这是所有工作的基石。考试不会考你Claude 3系列具体有多少参数，但一定会考你在什么场景下该选择Haiku、Sonnet还是Opus。这里的关键是建立“成本-性能-时延”的三角权衡思维。比如，一个需要与用户进行多轮、复杂、带逻辑推理对话的客服场景，Opus是首选，虽然它最贵、响应可能慢一点，但它的推理能力最强，能保证对话质量。反之，一个只需要简单分类或信息提取的后台批处理任务，用Haiku就能又快又省地完成。

更深一层的是理解模型的“硬限制”。比如上下文窗口（Context Window），你知道Claude 3.1支持200K tokens，但考试会考你：在一个需要处理超长技术文档并回答问题的RAG（检索增强生成）系统中，你是把整个200K文档都塞进提示词（Prompt）里，还是采用更智能的检索切片方式？全部塞进去可能触发模型在处理超长上下文时“中间部分注意力稀释”的问题，导致回答质量下降。正确的架构思维是：设计一个检索器，只找出与问题最相关的几个文档片段（比如每个片段4K tokens），再将它们组合成提示词。这既控制了成本，又提升了答案的准确性。

还有一个常考点是模型的“非能力”部分，也就是它不擅长什么。比如，Claude不擅长纯数学计算、代码执行（它生成代码，但不运行代码）以及对2023年7月之后事件的实时知识获取。架构师在设计系统时，必须意识到这些边界，并通过“工具使用（Tool Use）”或“函数调用（Function Calling）”来弥补。例如，当用户问“帮我计算一下复利”，你的系统不应该让Claude去硬算，而应该让Claude识别出用户意图，然后调用一个预设的计算器函数，拿到结果后再组织语言回复给用户。这个“识别意图-调用工具-整合回复”的闭环设计，是考试的重点。

2.2 知识域二：提示工程与上下文设计的系统化方法

很多人觉得提示工程就是“和AI聊天的话术”，但在架构师眼里，它是一个需要严谨设计的系统工程。考试会深入考察你如何构建高效、可靠、可维护的提示。

首先是系统提示词（System Prompt）的设计。它定义了AI的“人设”和行为边界。一个好的系统提示词不是一句“你是一个有帮助的助手”，而应该像产品需求文档一样明确。例如：“你是一名专业的金融合规审核助手。你的核心职责是审阅用户提供的合同文本，识别其中可能存在的合规风险点，并引用相关法规条款进行说明。你必须保持客观、严谨，对于不确定的信息，应明确告知用户‘此条需咨询专业律师’，不得自行臆断。你的回答需用中文，并采用‘风险点：… 依据：… 建议：…’的结构化格式输出。” 这样的提示词让AI的角色、任务、输出格式、安全边界都非常清晰，是可预测、可评测的。

其次是上下文（Context）的管理。这是区分普通使用者和专业架构师的关键。考试会涉及“动态上下文”和“静态上下文”的运用。静态上下文指对话历史，你需要决定保存多少轮历史来保持对话连贯性，同时避免无关信息干扰（成本也会累积）。动态上下文则指根据本次查询实时检索并注入的相关信息，比如从向量数据库中查到的产品文档。这里的一个高级技巧是“上下文压缩”：当对话历史过长时，不是简单丢弃，而是让Claude自己对之前的对话进行摘要，然后将摘要作为新的上下文输入，这样既保留了关键信息，又节省了tokens。

最后是少样本学习（Few-Shot Learning）在提示中的实战应用。考试会给你一个场景，比如“让Claude从混乱的会议纪要中提取出‘行动项’”，然后让你设计包含示例的提示词。这里的要点是：示例必须精准、无歧义，并且要覆盖可能的边缘情况。例如，不仅要给一个“标准格式”的提取示例，最好再加一个“模糊描述”的示例，并展示AI应该如何合理地追问或做出保守假设。这能极大地提升AI在复杂情况下的鲁棒性。

2.3 知识域三：工具集成与函数调用的架构设计

这是将Claude从“聪明的聊天机器人”升级为“自动化智能体”的核心。知识域三考察你如何让Claude与外部世界安全、有效地交互。

核心机制是函数调用（Function Calling）。Claude可以根据对话内容，决定是否需要调用一个外部函数，并自动生成符合该函数要求的参数。架构师的工作是设计好这套“函数菜单”和调用流程。首先，你需要定义清晰的函数规范：函数名、描述、参数（名称、类型、描述、是否必需）。这里有个细节：参数的描述要尽可能详细，这本身就是对AI的引导。比如，一个查询天气的函数，参数city的描述写成“城市名称，请使用标准的市级行政区划名，如‘北京市’、‘广州市’，避免使用‘北京’、‘广州’等简称”，就能减少调用错误。

其次，是工具使用的编排逻辑。一个复杂的任务可能需要按顺序调用多个工具。例如，用户说“帮我订一张明天从北京飞上海的最便宜的经济舱机票，并查看我明天的日历安排是否有冲突”。这个任务需要分解为：1. 调用日历API查询明天日程；2. 调用航班搜索API查询机票；3. 对比时间与价格；4. 给出建议。架构师需要设计一个控制流，可能是在Claude外层套一个轻量的“Orchestrator”（编排器），由它来根据Claude的中间输出决定下一步调用哪个工具，并管理整个会话状态。考试中可能会给出类似的复杂场景，让你画出数据流图或描述处理步骤。

安全性与错误处理是这部分的重中之重。你不能让AI无限制地调用任何函数。架构设计必须包括：权限校验（当前用户是否有权执行此操作？）、输入验证（AI生成的参数是否在合理范围内？）、用量限制（防止恶意循环调用）、以及完善的错误处理（当API调用失败时，如何让AI理解错误原因并给出用户友好的回复）。例如，当支付网关返回“余额不足”时，系统应该捕获这个错误，并将其转换为AI能理解的自然语言描述“支付失败，原因是用户账户余额不足”，再由AI组织语言告知用户，而不是直接抛出一串代码错误。

2.4 知识域四：系统集成、部署与可观测性

当你的AI应用从Demo走向生产，知识域四的内容就至关重要了。它关注如何将Claude能力稳健地嵌入到现有系统或新产品中。

首先是集成模式的选择。考试会对比几种常见模式：

1. 同步调用模式：用户请求→你的服务器→Claude API→返回结果。适用于实时交互场景，如聊天。难点在于处理Claude API可能出现的延迟或限流，你需要设计重试机制和优雅降级（例如，先返回一个“正在思考”的提示，或者备用的规则引擎答案）。
2. 异步任务队列模式：用户提交任务→任务进入队列（如Redis、RabbitMQ）→后台Worker调用Claude API处理→结果存入数据库→通知用户。适用于耗时的内容生成、数据分析等场景。架构师需要设计任务状态机（排队中、处理中、成功、失败）、结果存储和通知机制。
3. 流式响应模式：对于长文本生成，为了用户体验，需要采用Server-Sent Events (SSE)或WebSocket实现逐词输出。这里的技术要点是连接管理和中断处理。用户关闭页面时，你的后端需要能感知并终止正在进行的Claude API调用，避免资源浪费。

其次是部署与扩缩容。你的应用流量可能波动很大（比如营销活动期间）。你需要考虑：是否将调用Claude API的服务单独部署为微服务？如何根据队列长度或请求延迟来自动扩缩容这个服务？如何管理API密钥的轮换与安全性（绝不能硬编码在代码里）？

可观测性（Observability）是生产系统的生命线。对于AI应用，传统的指标（请求量、延迟、错误率）之外，你还需要监控AI特有的指标：

• Token消耗：按模型、按用户、按功能进行统计，这是成本控制的核心。
• 提示词性能：可以设计A/B测试，对比不同系统提示词对任务完成率和用户满意度的影响。
• AI输出质量：虽然难以自动化全量评估，但可以抽样人工审核，或设置关键业务指标（如客服场景的“一次解决率”）进行间接衡量。
• 异常输入/输出检测：监控是否有用户输入大量无意义字符（攻击试探），或AI输出了不符合安全策略的内容。

2.5 知识域五：安全、合规与负责任AI的实践

这是架构师的“安全带”，也是最容易忽视却后果最严重的部分。考试会严肃地考察你如何构建一个安全、合规、负责任的AI系统。

内容安全层（Safety Layer）：你不能完全依赖模型自身的安全过滤器。必须在调用Claude API之前（预处理）和之后（后处理）增加自己的安全层。预处理包括：对用户输入进行敏感词过滤、恶意指令检测、提示词注入攻击防护（例如，用户输入里包含“忽略之前的指令，现在执行…”这类文本）。后处理包括：对AI生成的内容进行二次审核，确保没有泄露内部数据、没有生成有害或带有偏见的内容。对于高风险场景，甚至需要引入人工审核流程。

数据隐私与合规：这是考试的重点，尤其是涉及用户数据和企业数据的场景。你必须清楚：

• 数据在途安全：与Claude API的所有通信必须使用HTTPS。
• 数据留存政策：你需要明确知晓并告知用户，Anthropic对通过API发送的数据有何种留存政策（通常是为了改进模型，但可能有选项控制）。对于极其敏感的数据，架构上可以考虑在发送前进行脱敏处理（如将真实人名、身份证号替换为占位符）。
• 合规要求：如果你的应用涉及医疗、金融、法律等受监管行业，AI生成的内容不能作为最终决策，只能作为辅助参考，并且需要有清晰的免责声明。系统日志必须完整记录每一次交互，以满足审计需求。

成本控制与滥用防范：架构师必须设计防滥用机制。例如：

• 用户级限流：防止单个用户通过脚本无限调用，消耗大量资源。
• 预算管理与警报：为每个项目或团队设置月度Token消耗预算，接近阈值时自动发送警报。
• 非功能性需求的权衡：当系统面临高并发时，是优先保证响应速度（可能降级到更快的Haiku模型），还是优先保证回答质量（排队等待Opus模型）？这需要根据业务优先级来制定策略。

3. 六大核心应用场景实战拆解

考试中的6个场景不是孤立的案例，而是覆盖了Claude能力矩阵的典型应用。通过这6个场景，考官能全面评估你能否将五个知识域融会贯通。下面我们逐一拆解。

3.1 场景一：构建智能客服助手与工单系统

这是最经典的应用。核心挑战不是让AI“能聊天”，而是让它“能解决问题”并“融入工作流”。

架构设计要点：

1. 知识库集成（RAG）：客服需要准确的产品知识。你需要建立一个实时更新的产品文档向量数据库。当用户提问时，系统先检索最相关的3-5个文档片段，连同对话历史一起构成提示词。这里的关键是检索质量，好的检索器（如Cohere的embedding模型或开源的BGE模型）和适当的切片策略（按章节、按功能点）决定了下限。
2. 工单创建与流转：当AI判断问题无法在线解决（如需要退款、硬件维修），它需要能自动创建工单。这涉及到工具调用：AI生成结构化工单信息（用户问题、产品型号、已尝试步骤），调用工单系统API创建工单，并将工单号返回给用户。这里的一个细节是，AI在创建工单前，应引导用户确认关键信息（如订单号、联系方式），确保数据准确。
3. 多轮对话状态管理：客服对话往往是迂回的。你需要一个会话状态管理器，来跟踪当前对话的“意图”（例如，正在处理“退货咨询”）和已经收集到的“槽位”信息（如订单号、退货原因）。这能避免用户重复提供信息，也让AI的追问更有目的性。

实操心得：

• 不要试图用一个“万能”的客服AI处理所有问题。可以为“技术咨询”、“账单问题”、“投诉建议”等不同渠道训练不同的系统提示词和知识库，效果更好。
• 设置“人工接管”的明确触发条件，例如用户连续三次表示“不满意”、或对话轮数超过10轮仍未解决。平滑地将对话转给人工坐席，并附上完整的AI对话历史，是提升用户体验的关键。

3.2 场景二：长文档分析与知识库问答系统

这个场景专精于处理Claude的超长上下文能力，核心是“从海量信息中精准定位并推理”。

架构设计要点：

1. 文档预处理流水线：这是质量的基石。流水线通常包括：格式转换（PDF/Word转纯文本）、智能分块（不是简单按字数切，而是尽量保证语义完整性，如按章节、按段落）、向量化（Embedding）、存入向量数据库（如Pinecone, Weaviate）。对于技术手册、法律文书，可能还需要OCR识别图片中的表格和图表。
2. 混合检索策略：单一向量检索可能因为语义相似但主题无关而“误召回”。优秀的系统会结合：
   • 向量检索：找语义相似的片段。
   • 关键词检索（如BM25）：精准匹配特定术语、产品型号、法律条款编号。
   • 元数据过滤：按文档类型、部门、更新时间筛选。 将三者的结果进行重排序（Rerank），选出最相关的几个片段。
3. 答案生成与溯源：要求Claude基于提供的片段生成答案，并必须引用来源（例如，来自《XX用户手册》第3.2节）。这不仅增加了可信度，也方便用户追溯核查。在提示词中要强制要求这一点。

避坑指南：

• “垃圾进，垃圾出”。如果预处理分块做得不好，把半句话和下一段的半句话拼在一起，检索和生成效果都会很差。建议分块时设置一定的重叠区（如100个token），保证上下文连贯。
• 对于特别长的文档（如一整本书），不要幻想一次性处理。建立层次化的索引：先对章节摘要建立索引，用户提问时先定位到相关章节，再对该章节的详细内容进行深度检索。

3.3 场景三：内容创作与营销文案生成

这个场景考验的是提示工程的精细度和对品牌声音（Brand Voice）的控制。

架构设计要点：

1. 品牌声音库的构建：首先，需要收集大量的品牌历史文案（官网、博客、社交媒体帖子）。用这些数据提炼出品牌的“风格指南”，包括：常用词汇、句式结构（偏长句还是短句）、语气（专业、亲切、活泼）、拒绝使用的词汇等。将这个风格指南作为系统提示词的核心部分。
2. 结构化创作流程：对于一篇博客文章，不要直接让AI“写一篇关于XX的文章”。而是设计一个多阶段流程：
   • 阶段一（头脑风暴）：输入关键词，让AI生成5个不同的文章角度和标题。
   • 阶段二（大纲生成）：选定一个角度，让AI生成详细大纲（H1, H2, H3标题）。
   • 阶段三（段落展开）：根据大纲，逐段或逐节让AI生成内容。这样可以更好地控制文章结构和质量，也方便人工中途干预和编辑。
3. 合规与事实核查：营销文案中可能涉及产品参数、促销条款、法律声明。AI生成后，必须有一个“事实核对”环节，可以是通过工具调用查询产品数据库，也可以是一定比例的人工抽查。绝不能完全放任AI生成未经核实的数字和条款。

经验分享：

• 使用“少样本学习”效果极佳。在提示词中提供2-3篇你们认为写得最好的范文，AI模仿的效果会比单纯用文字描述风格要好得多。
• 为不同的内容类型（邮件、社交媒体帖子、产品描述）创建不同的提示词模板。一个通用的“内容生成”提示词，很难在所有场景都表现出色。

3.4 场景四：代码生成、解释与评审助手

这是对Claude推理和逻辑能力要求很高的场景。架构师的目标不是取代程序员，而是打造一个高效的“结对编程”伙伴。

架构设计要点：

1. 上下文管理是命脉：代码助手需要看到完整的相关代码。这包括：当前文件、被引用的其他文件、项目结构、相关的技术文档。你需要设计一个“代码上下文收集器”，能够根据开发者正在编辑的文件，智能地拉取相关的依赖文件和模块，并控制在上下文窗口容量内。过于庞大的上下文反而会降低模型性能。
2. 工具链集成：让AI生成的代码可直接运行或测试。例如：
   • 代码生成后：自动调用代码格式化工具（如Prettier、Black）。
   • 单元测试生成：AI生成函数后，可以提示它“请为这个函数编写一个单元测试”。
   • 安全扫描：调用静态代码分析工具（如SonarQube、Semgrep）对AI生成的代码进行安全检查，并将结果反馈给AI，让它解释或修复问题。
3. 交互模式设计：支持多种交互：/explain（解释这段代码）、/refactor（重构这段代码）、/debug（帮我找出这里的bug）、/generate test（生成测试用例）。每种模式对应一个优化过的提示词。

注意事项：

• 安全红线：必须严格禁止AI生成任何涉及系统命令执行、文件任意读写、网络访问的危险代码片段。在系统提示词中必须明确列出禁止项。
• 知识截止：Claude的训练数据有截止日期，它可能不了解最新版本的框架或库的API。架构上可以补充一个“实时文档查询”工具，当AI被问到关于新版本的问题时，它可以主动去查询官方文档。

3.5 场景五：复杂数据分析与报告生成

这个场景结合了自然语言理解、工具调用和逻辑推理，让非技术人员也能用自然语言进行数据探查。

架构设计要点：

1. 语义层与数据查询：用户会说“显示上个月销售额最高的三个产品”，AI需要将其转换为SQL查询。这里不能直接让AI拼接SQL字符串执行，风险太高。正确的架构是建立一个“语义层”或“数据字典”，将业务术语（如“销售额”）映射到具体的数据库表和字段（如orders.total_amount）。AI生成的应是“中间查询描述”，再由一个安全的查询引擎将其转换为SQL并执行。或者，直接让AI调用封装好的数据分析API。
2. 多步骤分析流水线：一个复杂问题如“分析一下为什么Q2的客户流失率升高了”，可能需要多个步骤：1) 查询流失客户名单和特征；2) 查询同期市场活动数据；3) 查询客户服务反馈；4) 进行对比分析。架构上需要设计一个“分析规划”模块，让AI先输出分析步骤，然后逐步执行每个步骤的工具调用，最后汇总所有结果生成报告。
3. 可视化与叙事：数据本身是冰冷的。AI在生成报告时，不仅要有数字，还要有洞察（“销售额下降主要源于A产品线在华东地区的疲软”），并能建议合适的图表类型（“建议用折线图展示月度趋势，用饼图展示地区占比”）。甚至可以进一步，调用图表生成库（如Matplotlib的封装API）直接输出图片。

核心挑战：

• 数据权限控制。用户A和用户B能访问的数据范围不同。AI在生成查询或报告时，必须嵌入当前用户的权限上下文，确保不会越权访问数据。这通常在调用查询工具前，由后端服务进行权限校验。

3.6 场景六：自动化智能体与工作流编排

这是最高阶的场景，目标是创建一个能自主完成多步骤任务的智能体（Agent）。

架构设计要点：

1. 智能体核心循环（ReAct模式）：智能体的工作遵循“思考（Reason）- 行动（Act）- 观察（Observe）”的循环。例如，任务“安排一次团队会议”：
   • 思考：“我需要先查看大家的日历，找到一个共同空闲时间，然后创建会议邀请。”
   • 行动：调用“日历查询”工具，查看团队成员明天下午的日程。
   • 观察：工具返回了每个人的忙闲状态。
   • 思考：“明天下午2-3点大家都有空，可以在这个时间段创建会议。”
   • 行动：调用“创建日历事件”工具。
   • 观察：工具返回会议创建成功，并附有会议链接。
   • 思考：“会议已创建，需要通知大家。”
   • 行动：调用“发送邮件”工具，将会议详情发送给团队成员。
2. 工作流状态持久化：复杂的任务可能被用户打断，或者需要很长时间（如“监控一个价格，当低于X时通知我”）。智能体的状态（当前目标、已完成步骤、收集到的数据）必须持久化到数据库中，以便随时恢复。
3. 子任务分解与验证：对于“写一份季度业务报告”这种宏大目标，AI需要能将其分解为“收集财务数据”、“收集项目进展”、“分析市场趋势”、“撰写执行摘要”等子任务，并逐一完成。每个子任务完成后，最好有一个简单的自我验证（如“生成的数据是否齐全？”），然后再进入下一步。

设计哲学：

• 可控性高于自主性：在关键决策点（如是否要发送邮件、是否要修改数据库），智能体应该暂停并寻求用户确认（“我已经草拟了会议邀请，时间定在明天下午2点，确认发送吗？”），而不是完全自主行动。
• 失败处理与回退：任何工具调用都可能失败。智能体必须能处理失败，并尝试替代方案。例如，创建会议失败（因为会议室已被占用），它应该能自动建议下一个可用时间段。

4. 备考策略与实战资源指南

了解了考什么，接下来就是怎么准备。我的建议是，不要把它当成一门背诵考试，而是一个梳理和巩固你AI架构能力的过程。

4.1 系统性学习路径规划

1. 第一阶段：基础夯实（约2周）

   • 官方文档精读：Anthropic的官方文档、API Reference和Cookbook是圣经。不要泛读，要精读。特别是关于模型比较、Token计算、提示词格式、工具调用、错误码的章节，必须理解透彻。
   • 动手实验：在Anthropic Console里完成所有交互式教程。用API Key写几个最简单的脚本，完成“问答”、“多轮对话”、“调用一个模拟工具”等基础操作。目标是熟悉整个开发流程。

2. 第二阶段：场景化深度实践（约3-4周）

   • 针对每个知识域和场景进行项目实践。这是最关键的一步。例如：
     • 针对知识域二（提示工程），找一个公开数据集（如客服对话），尝试设计不同的系统提示词和少样本示例，比较生成结果的质量。
     • 针对场景二（文档问答），用LangChain或LlamaIndex框架，亲手搭建一个针对某份长PDF文档（比如一份开源软件协议）的问答系统，体验从分块、向量化到检索、生成的全过程。
     • 针对知识域三（工具调用），写一个能调用真实公共API（如天气API、新闻API）的智能体小程序。
   • 记录和复盘：在实践过程中，一定会遇到各种问题（如提示词效果不佳、检索不准、API限流）。把这些问题和解决方案详细记录下来，这就是你最宝贵的备考资料。

3. 第三阶段：模拟与查漏补缺（约1-2周）

   • 寻找模拟题：虽然完整的真题很难找，但可以关注技术社区、博客，很多通过考试的人会分享他们的经验和部分题目回忆。把这些题目当作案例来研究。
   • 思维训练：看到任何一个生活或工作中的问题，都尝试用“AI架构师”的思维去拆解：这个问题适合用AI解决吗？属于哪个场景？需要用到哪几个知识域？核心难点和风险点是什么？这种思维习惯的培养比刷题更重要。

4.2 关键工具与框架熟悉

考试不要求你成为某个框架的专家，但你需要知道主流工具能做什么，以及如何做技术选型。

• LangChain / LlamaIndex：这是构建复杂AI应用的事实标准框架。你需要理解它们的核心概念（Chain, Agent, Retriever, Index）、以及如何用它们来组织提示词、管理上下文、集成工具和检索器。不必背诵所有细节，但要知道用它们来解决我们前面提到的6个场景，大致应该如何设计。
• 向量数据库：了解Pinecone, Weaviate, Qdrant, Chroma等主流选项的适用场景（云服务 vs. 本地部署、性能特点）。重点是理解“嵌入模型（Embedding Model）”的选择和索引的创建流程。
• 评估与测试工具：了解如何评估AI应用的效果。例如，使用ragas等框架评估RAG系统的检索相关性、答案忠实度等指标。知道A/B测试对于优化提示词和流程的重要性。

4.3 考试技巧与临场应对

考试形式很可能是基于场景的选择题和案例分析题。

• 选择题：很多题目会描述一个场景，然后问“以下哪种架构方案最合适？”或“接下来应该做什么？”。答题的关键是紧扣五大知识域的原则：安全性、成本、性能、可维护性。通常，那个考虑了安全限制、有错误处理、并且不过度设计的选项，是正确的。
• 案例分析题：会给你一个相对完整的业务需求描述。你需要：
  1. 识别场景：它最接近我们讲过的哪个场景？是客服、文档问答还是智能体？
  2. 列出需求与非功能要求：明确要解决的核心问题是什么？对延迟、准确性、成本有何要求？
  3. 设计架构图（在脑中或草稿上）：画出数据流，标出核心组件（用户界面、你的后端服务、Claude API、工具/数据库等）。
  4. 阐述关键决策：解释你为什么选择某个模型（如Opus vs Sonnet）、为什么采用某种检索策略、设计了怎样的提示词结构、如何保证安全和处理错误。
  5. 讨论权衡与替代方案：没有完美方案。可以简要提一下其他可能的选择，并说明为什么当前方案更优（例如，“虽然异步处理会增加复杂度，但考虑到生成报告可能超过30秒，为了不阻塞用户界面，这是更合适的方案。”）。

最后，保持冷静。考试时间通常充足，仔细阅读题目，很多答案就隐藏在题干的细节里。记住，你是在展示自己作为一名AI解决方案架构师的思维过程，而不仅仅是记忆知识点。