模拟测试
涵盖4个场景的60道题。格式和难度与真实考试相匹配。
场景：多智能体研究系统
第1题（场景：多智能体研究系统）
情境： 文档分析智能体发现两个可信来源对一个关键指标的统计数据直接矛盾：政府报告显示40%的增长，而行业分析显示12%。两个来源都看起来可信，这种差异可能从根本上影响研究结论。文档分析智能体应该如何最有效地处理这种情况？
哪种方法最有效？
- A) 应用可信度启发式选择最可能正确的数字，用该值完成分析，并添加脚注提及差异。
- B) 在分析输出中包含两个数字，不标记它们为冲突，让综合智能体根据更广泛的上下文决定使用哪个。
- C) 停止分析并立即升级给协调者，在继续之前请它决定哪个来源更权威。
- D) 用两个数字完成分析，明确注释冲突和来源归因，在传递给综合之前让协调者决定如何调和数据。[正确]
为什么选D： 这种方法保持了职责分离：分析智能体不阻塞地完成其核心工作，保留两个冲突值及清晰归因，并正确将调和工作传递给拥有更广泛上下文的协调者。
第2题（场景：多智能体研究系统）
情境： 网络搜索智能体和文档分析智能体已完成任务并将结果返回给协调者。创建综合研究报告的下一步是什么？
哪个下一步最合适？
- A) 每个智能体直接将结果发送给报告编写智能体，绕过协调者。
- B) 文档分析智能体请求网络搜索结果并在内部合并它们。
- C) 协调者将两组结果传递给综合智能体进行统一整合。[正确]
- D) 协调者将两个智能体的原始输出连接起来并作为最终结果返回。
为什么选C： 在协调者-子智能体架构中，协调者将两组结果集转发给综合智能体进行集中整合，保持控制并确保高质量的合并。
第3题（场景：多智能体研究系统）
情境： 文档分析子智能体在处理PDF文件时经常失败：一些有损坏的部分会触发解析异常，另一些受密码保护，有时解析库在大文件上挂起。目前，任何异常都会立即终止子智能体并向协调者返回错误，协调者必须决定是否重试、跳过或使整个任务失败。这导致协调者过度介入常规错误处理。哪种架构改进最有效？
哪种改进最有效？
- A) 创建专用的错误处理智能体，通过共享队列监控所有失败，并直接向子智能体发送重启命令来决定恢复操作。
- B) 配置子智能体始终返回带成功状态的部分结果，将错误详情嵌入元数据；协调者将所有响应视为成功。
- C) 让协调者在将文档发送给子智能体之前进行验证，拒绝可能导致失败的文档。
- D) 在子智能体中对瞬时失败实现本地恢复，只向协调者升级无法解决的错误，包含已尝试的步骤和部分结果。[正确]
为什么选D： 在最低能够解决问题的层级处理错误。本地恢复减少了协调者的工作负担，同时仍然以完整上下文和部分进度升级真正无法恢复的问题。
第4题（场景：多智能体研究系统）
情境： 在"AI对创意产业的影响"主题上运行系统后，你观察到每个子智能体都成功完成：网络搜索智能体找到了相关文章，文档分析智能体正确总结了它们，综合智能体产生了连贯的文本。然而，最终报告只涵盖视觉艺术，完全遗漏了音乐、文学和电影。在协调者日志中，你看到它将主题分解为三个子任务："数字艺术中的AI"、"平面设计中的AI"和"摄影中的AI"。最可能的根本原因是什么？
最可能的根本原因是什么？
- A) 综合智能体缺少检测覆盖缺口的指令。
- B) 文档分析智能体因过于严格的相关性标准而过滤掉了非视觉来源。
- C) 协调者的任务分解过于狭窄，给子智能体分配的工作没有涵盖所有相关领域。[正确]
- D) 网络搜索智能体的查询不足，应该扩大以覆盖更多行业。
为什么选C： 协调者将一个宽泛的主题只分解为视觉艺术子任务，完全遗漏了音乐、文学和电影。由于子智能体正确执行了分配的任务，狭窄的分解是显而易见的根本原因。
第5题（场景：多智能体研究系统）
情境： 网络搜索子智能体仅返回5个请求来源类别中3个的结果（竞争对手网站和行业报告成功，但新闻档案和社交feed超时）。文档分析子智能体成功处理了所有提供的文档。综合子智能体必须从混合质量的上游输入中生成摘要。哪种错误传播策略最有效？
哪种错误传播策略最有效？
- A) 仅使用成功来源继续综合，生成输出而不提及哪些数据不可用。
- B) 综合子智能体向协调者返回错误，由于数据不完整触发完整重试或任务失败。
- C) 综合子智能体请求协调者在开始综合之前以更长的超时重试超时的来源。
- D) 用覆盖注释结构化综合输出，指示哪些结论有充分支撑，哪里因不可用来源存在缺口。[正确]
为什么选D： 覆盖注释实现了透明的优雅降级，保留了已完成工作的价值，同时传播不确定性以实现有知情的置信度决策。
第6题（场景：多智能体研究系统）
情境： 文档分析子智能体遇到了一个无法解析的损坏PDF文件。在设计系统的错误处理时，处理这种失败最有效的方式是什么？
哪种方法最有效？
- A) 向协调者智能体返回带上下文的错误，使其能够决定如何继续。[正确]
- B) 静默跳过损坏的文档并继续处理剩余文件，以避免中断工作流。
- C) 在报告失败之前自动以指数退避重试解析文档三次。
- D) 抛出终止整个研究工作流的异常。
为什么选A： 向协调者返回带上下文的错误是最有效的方法，因为它让协调者能够做出明智的决定——跳过文件、尝试替代解析方法或通知用户——同时保持对失败的可见性。
第7题（场景：多智能体研究系统）
情境： 生产日志显示持续的模式：像"分析上传的季度报告"这样的请求有45%的时间被路由到网络搜索智能体，而非文档分析智能体。查看工具定义，你发现网络搜索智能体有一个工具 analyze_content，描述为"分析内容并提取关键信息"，而文档分析智能体有一个工具 analyze_document，描述为"分析文档并提取关键信息"。应该如何修复路由错误问题？
应该如何修复路由错误问题？
- A) 在协调者决定委派之前添加预路由分类器，检测用户是指上传的文件还是网络内容。
- B) 将网络搜索工具重命名为
extract_web_results，并将其描述更新为"处理并返回从网络搜索和URL检索到的信息"。[正确] - C) 在协调者提示词中添加少样本示例，显示正确的路由："用户上传季度报告→文档分析智能体"和"用户询问网页→网络搜索智能体"。
- D) 用"用于上传的PDF、Word文档和电子表格"等使用示例扩展文档分析工具描述，保持网络搜索工具不变。
为什么选B： 将网络搜索工具重命名为 extract_web_results，并将其描述更新为明确引用网络搜索和URL，通过消除两个工具名称和描述之间的语义重叠直接消除了根本原因。这使每个工具的目的明确无误，使协调者能够可靠地区分文档分析和网络搜索。
第8题（场景：多智能体研究系统）
情境： 一位同事提议文档分析智能体应该直接将其结果发送给综合智能体，绕过协调者。保持协调者作为所有子智能体间通信的中央枢纽的主要优势是什么？
保持协调者作为中央枢纽的主要优势是什么？
- A) 协调者可以观察所有交互，统一处理错误，并决定每个子智能体应该接收哪些信息。[正确]
- B) 协调者将多个对子智能体的请求批量处理，减少总API调用次数和整体延迟。
- C) 通过协调者路由可以实现自动重试逻辑，而直接智能体间调用无法支持。
- D) 子智能体使用隔离内存，直接通信需要只有协调者才能执行的复杂序列化。
为什么选A： 协调者模式提供了对所有交互的集中可见性、系统范围内统一的错误处理，以及对每个子智能体接收哪些信息的精细控制——这些是星型通信拓扑的主要优势。
第9题（场景：多智能体研究系统）
情境： 网络搜索子智能体在研究复杂主题时超时。你需要设计如何将有关此失败的信息返回给协调者。哪种错误传播方式最能实现智能恢复？
哪种错误传播方式最能实现智能恢复？
- A) 向协调者返回结构化错误上下文，包括故障类型、执行的查询、任何部分结果和潜在的替代方法。[正确]
- B) 在子智能体内捕获超时并返回标记为成功的空结果集。
- C) 在子智能体内实现自动指数退避重试，在耗尽重试后只返回通用的"搜索不可用"状态。
- D) 将超时异常直接传播到顶层处理程序，终止整个研究工作流。
为什么选A： 返回结构化错误上下文——包括故障类型、执行的查询、部分结果和替代方法——为协调者提供了做出智能恢复决策所需的一切（例如，以修改后的查询重试或继续使用部分结果）。它为明智的协调级决策保留了最大上下文。
第10题（场景：多智能体研究系统）
情境： 在系统设计中，你为文档分析智能体提供了通用工具 fetch_url，使其可以通过URL下载文档。生产日志显示该智能体现在频繁下载搜索引擎结果页面进行临时网络搜索——这种行为应该通过网络搜索智能体路由——导致结果不一致。哪种修复最有效？
哪种修复最有效？
- A) 将
fetch_url替换为验证URL指向文档格式的load_document工具。[正确] - B) 从文档分析智能体中移除
fetch_url，通过协调者将所有URL获取路由到网络搜索智能体。 - C) 实现过滤，阻止对已知搜索引擎域的
fetch_url调用，同时允许其他URL。 - D) 在文档分析智能体提示词中添加指令，说明
fetch_url只应用于下载文档URL，而非搜索。
为什么选A： 将通用工具替换为在接口级别验证URL格式的文档特定工具，通过在接口级别约束能力来修复根本原因。这遵循了最小权限原则，使不期望的搜索行为不可能发生，而不仅仅是受到阻止。
第11题（场景：多智能体研究系统）
情境： 在研究广泛主题时，你观察到网络搜索智能体和文档分析智能体调查相同的子主题，导致其输出中出现大量重复。令牌使用量几乎翻倍，而研究广度或深度没有相应增加。解决这个问题最有效的方法是什么？
解决这个问题最有效的方法是什么？
- A) 让两个智能体并行完成，然后让协调者在将结果传递给综合智能体之前去重重叠结果。
- B) 协调者在委派之前明确划分研究空间，给每个智能体分配不同的子主题或来源类型。[正确]
- C) 实现共享状态机制，智能体记录其当前关注区域，以便其他智能体在执行期间动态避免重复。
- D) 切换到顺序执行，文档分析在网络搜索完成后才运行，使用网络搜索结果作为上下文以避免重复。
为什么选B： 在委派之前让协调者明确划分研究空间最有效，因为它在任何工作开始之前就解决了根本原因——不清晰的任务边界。它在防止重复工作和浪费令牌的同时保留了并行性。
第12题（场景：多智能体研究系统）
情境： 在研究过程中，网络搜索子智能体对三个来源类别进行查询，结果各不相同：学术数据库返回15篇相关论文，行业报告返回"0个结果"，专利数据库返回"连接超时"。在设计向协调者的错误传播时，哪种方式能最好地实现恢复决策？
哪种方式能最好地实现恢复决策？
- A) 将结果汇总为单一成功率指标（例如，"67%来源覆盖率"），按需提供详细日志。
- B) 将"超时"和"0个结果"都报告为需要协调者干预的失败。
- C) 在内部重试瞬时失败，只报告持续性错误。
- D) 区分需要重试决策的访问失败（超时）和代表成功查询的有效空结果（"0个结果"）。[正确]
为什么选D： 超时（访问失败）和"0个结果"（有效空结果）是语义上不同的结果，需要不同的响应。区分它们允许协调者重试专利数据库，同时接受行业报告的"0个结果"作为有效的信息性发现。
第13题（场景：多智能体研究系统）
情境： 生产监控显示综合质量不一致。当汇总结果约为75K令牌时，综合智能体可靠地引用前15K令牌（网络搜索标题/摘要）和后10K令牌（文档分析结论）中的信息，但经常遗漏中间50K令牌中的关键发现——即使它们直接回答了研究问题。应该如何重构汇总输入？
应该如何重构汇总输入？
- A) 在汇总之前将所有子智能体输出摘要到20K令牌以下，使内容保持在模型的可靠处理范围内。
- B) 将子智能体结果增量流式传输给综合智能体，先完整处理网络搜索结果，再添加文档分析结果。
- C) 在汇总输入的开头放置关键发现摘要，并用明确的章节标题组织详细结果以便导航。[正确]
- D) 实现轮换，在各研究任务中交替哪个子智能体的结果首先出现，以确保两个来源随时间获得平等的顶部位置。
为什么选C： 在开头放置关键发现摘要利用了首要效应，使关键信息位于最可靠处理的位置。在整个过程中添加明确的章节标题帮助模型导航和关注中间输入内容，直接缓解了"中间迷失"现象。
第14题（场景：多智能体研究系统）
情境： 在测试中，网络搜索智能体（85K令牌，含页面内容）和文档分析智能体（70K令牌，含思维链）的组合输出总计155K令牌，但综合智能体在50K令牌以下的输入中表现最佳。哪种解决方案最有效？
哪种解决方案最有效？
- A) 修改上游智能体以返回结构化数据（关键事实、引用、相关性分数）而非详细内容和推理。[正确]
- B) 添加中间摘要智能体，在传递给综合之前压缩发现。
- C) 让综合智能体分批顺序处理发现，在调用之间维护状态。
- D) 将发现存储在向量数据库中，给综合智能体搜索工具以便在工作期间查询。
为什么选A： 修改上游智能体以返回结构化数据通过在来源减少令牌量同时保留必要信息来修复根本原因。它避免了传递臃肿的页面内容和推理痕迹，这些内容会膨胀令牌而不改善综合步骤。
第15题（场景：多智能体研究系统）
情境： 在测试中，你观察到综合智能体在合并结果时经常需要验证特定声明。目前，当需要验证时，综合智能体将控制权返回给协调者，协调者调用网络搜索智能体，然后用结果重新调用综合。这为每个任务增加了2-3次额外循环，延迟增加了40%。你的评估显示85%的验证是简单事实核查（日期、名称、统计数据），15%需要更深入的研究。哪种方法在保持系统可靠性的同时最有效地减少开销？
哪种方法最有效？
- A) 给综合智能体访问所有网络搜索工具的权限，使其可以直接处理任何验证需求，不需要协调者循环。
- B) 让综合智能体积累所有验证需求，最后作为批次返回给协调者，协调者一次性将它们全部发送给网络搜索智能体。
- C) 让网络搜索智能体在初始研究期间主动缓存每个来源周围的额外上下文，预期综合需要验证。
- D) 给综合智能体提供有限范围的
verify_fact工具用于简单检查，同时通过协调者将复杂验证路由到网络搜索智能体。[正确]
为什么选D： 有限范围的事实验证工具让综合智能体直接处理85%的简单检查，消除了大多数循环，同时保留了协调者委派路径用于15%的复杂验证。这应用了最小权限同时显著降低了延迟。
场景：Claude Code用于持续集成
第16题（场景：Claude Code用于持续集成）
情境： 你的CI管道在 --print 模式下运行Claude Code CLI，使用CLAUDE.md提供代码审查的项目上下文，开发者普遍认为审查内容翔实。然而，他们报告将发现整合到工作流中很困难——Claude输出的叙述性段落必须手动复制到PR评论中。团队希望将每个发现自动发布为代码中相关位置的单独内联PR评论，这需要包含文件路径、行号、严重性级别和建议修复的结构化数据。哪种方法最有效？
哪种方法最有效？
- A) 在CLAUDE.md中添加"审查输出格式"部分，带有结构化发现示例，让Claude从项目上下文中学习预期格式。
- B) 使用CLI标志
--output-format json和--json-schema强制结构化发现，然后解析输出通过GitHub API发布内联评论。[正确] - C) 在审查提示词中包含明确的格式指令，要求每个发现遵循可解析的模板，如
[FILE:path] [LINE:n] [SEVERITY:level] ...。 - D) 保留叙述性审查格式，但添加摘要步骤，使用Claude生成发现的结构化JSON摘要。
为什么选B： 使用 --output-format json 和 --json-schema 在CLI级别强制结构化输出，保证具有所需字段（文件路径、行号、严重性、建议修复）的格式良好的JSON，可以可靠地解析并通过GitHub API发布为内联PR评论。它利用了专为结构化输出设计的内置CLI功能。
第17题（场景：Claude Code用于持续集成）
情境： 你的团队使用Claude Code生成代码建议，但你注意到一个模式：不明显的问题——破坏边缘情况的性能优化、意外改变行为的清理——只有当另一名团队成员审查PR时才会被发现。Claude在生成过程中的推理显示它考虑了这些情况但认为其方法是正确的。哪种方法直接解决了这种自检限制的根本原因？
哪种方法直接解决了根本原因？
- A) 运行Claude Code的第二个独立实例，在没有生成器推理的情况下审查变更。[正确]
- B) 为生成阶段启用扩展思维模式，在产生建议之前允许更彻底的审议。
- C) 在生成提示词中添加明确的自我审查指令，要求Claude在最终确定输出之前批评自己的建议。
- D) 在提示词上下文中包含完整的测试文件和文档，使Claude在生成期间更好地理解预期行为。
为什么选A： 没有生成器推理访问权限的第二个独立Claude Code实例通过避免确认偏差直接解决了根本原因。这种"新鲜视角"反映了人工同行评审，另一位审查者会发现作者合理化了的问题。
第18题（场景：Claude Code用于持续集成）
情境： 你的代码审查组件是迭代的：Claude分析修改的文件，然后可能通过工具调用请求相关文件（导入、基类、测试）以在提供最终反馈之前理解上下文。你的应用程序定义了一个让Claude请求文件内容的工具；Claude调用该工具，获取结果，并继续分析。你正在评估批处理以降低API成本。在考虑此工作流的批处理时，主要技术限制是什么？
主要技术限制是什么？
- A) 批处理不包含关联ID来将输出映射回输入请求。
- B) 异步模型无法在请求中途执行工具并返回结果以便Claude继续分析。[正确]
- C) Batch API不支持请求参数中的工具定义。
- D) 批处理最长24小时的延迟对于PR反馈来说太慢，尽管工作流在其他方面可以运行。
为什么选B： "即发即忘"的异步Batch API模型没有机制在请求中拦截工具调用、执行工具并返回结果供Claude继续分析。这与需要在单个逻辑交互中进行多轮工具请求/响应的迭代工具调用工作流从根本上不兼容。
第19题（场景：Claude Code用于持续集成）
情境： 你的CI/CD系统运行三种基于Claude的分析：（1）每个PR上的快速风格检查，在完成之前阻止合并；（2）每周对整个代码库进行全面安全审计；（3）最近修改模块的夜间测试用例生成。Message Batches API提供50%的节省，但处理时间最长可达24小时。你希望在保持可接受的开发者体验的同时优化API成本。哪种组合正确地将每个任务与API方式匹配？
哪种组合是正确的？
- A) 对三个任务都使用Message Batches API以最大化50%的节省，配置管道轮询批次完成情况。
- B) 对PR风格检查使用同步调用；对每周安全审计和夜间测试生成使用Message Batches API。[正确]
- C) 对三个任务都使用同步调用以保持一致的响应时间，依靠提示词缓存降低跨工作负载的成本。
- D) 对PR风格检查和夜间测试生成使用同步调用；只对每周安全审计使用Message Batches API。
为什么选B： PR风格检查阻止开发者，需要通过同步调用立即响应，而每周安全审计和夜间测试生成是有灵活截止期限的定时任务，可以容忍最多24小时的批处理窗口——两者都能获得50%的节省。
第20题（场景：Claude Code用于持续集成）
情境： 你的自动审查发现了真实问题，但开发者报告反馈不可操作。发现包含"复杂的工单路由逻辑"或"潜在的空指针"等短语，没有指定具体需要改变什么。当你添加"始终包含具体修复建议"等详细指令时，模型仍然产生不一致的输出——有时详细，有时模糊。哪种提示词技术最可靠地产生一致可操作的反馈？
哪种提示词技术最可靠？
- A) 进一步细化指令，对反馈格式的每个部分（位置、问题、严重性、建议修复）提出更明确的要求。
- B) 扩展上下文窗口以包含更多周边代码库，使模型有足够信息提出具体修复。
- C) 实现两步骤方法，一个提示词识别问题，另一个生成修复，允许专业化。
- D) 添加3-4个少样本示例，显示所需的确切格式：识别的问题、代码中的位置、具体修复建议。[正确]
为什么选D： 当指令单独产生可变结果时，少样本示例是实现一致输出格式最有效的技术。提供3-4个显示确切所需结构（问题、位置、具体修复）的示例，为模型提供了比抽象指令更可靠的具体模式。
第21题（场景：Claude Code用于持续集成）
情境： 你的CI管道包括两种基于Claude的代码审查模式：合并前提交钩子（在完成之前阻止PR合并）和"深度分析"（隔夜运行，轮询批次完成情况，并将详细建议发布到PR）。你想使用Message Batches API降低API成本，它提供50%的节省但需要轮询且最长可达24小时。哪种模式应该使用批处理？
哪种模式应该使用批处理？
- A) 只有合并前提交钩子。
- B) 只有深度分析。[正确]
- C) 两种模式。
- D) 两种模式都不使用。
为什么选B： 深度分析是批处理的理想候选，因为它已经隔夜运行，容忍延迟，并在发布结果之前使用轮询模型——与Message Batches API的异步、基于轮询的架构相匹配，同时获得50%的节省。
第22题（场景：Claude Code用于持续集成）
情境： 你的自动审查分析注释和文档字符串。当前提示词指示Claude"检查注释是否准确和最新"。发现经常标记可接受的模式（TODO标记、简单描述），同时遗漏描述代码不再实现的行为的注释。哪种变更解决了这种不一致分析的根本原因？
哪种变更解决了根本原因？
- A) 包含
git blame数据，使Claude能够识别早于近期代码变更的注释。 - B) 添加误导性注释的少样本示例，帮助模型识别代码库中的类似模式。
- C) 在分析之前过滤TODO、FIXME和描述性注释模式以减少噪音。
- D) 指定显式标准：仅当注释声明的行为与代码的实际行为矛盾时才标记。[正确]
为什么选D： 显式标准——仅在声明的行为与实际代码行为矛盾时标记注释——通过用问题的精确定义替换模糊指令直接解决了根本原因。这减少了对可接受模式的误报和对真正误导性注释的遗漏。
第23题（场景：Claude Code用于持续集成）
情境： 你的自动代码审查系统显示不一致的严重性评级——类似的空指针风险问题在某些PR中被评为"严重"，而在其他PR中只被评为"中等"。开发者调查显示信任度下降——许多人开始不阅读就忽视发现，因为"有一半是错的"。高误报类别侵蚀了对准确类别的信任。哪种方法在改善系统的同时最好地恢复开发者信任？
哪种方法最好地恢复开发者信任？
- A) 临时禁用高误报类别（风格、命名、文档），在改善提示词的同时只保留高精度类别。[正确]
- B) 保持所有类别启用，但为每个发现显示置信度分数，以便开发者决定调查什么。
- C) 保持所有类别启用，在接下来几周内为每个类别添加少样本示例以提高准确性。
- D) 在所有类别中均匀降低严格性以降低总体误报率。
为什么选A： 临时禁用高误报类别通过删除导致开发者忽视一切的嘈杂发现立即阻止信任侵蚀，同时保留来自安全和正确性等高精度类别的价值。它还为在重新启用之前改善有问题类别的提示词创造了空间。
第24题（场景：Claude Code用于持续集成）
情境： 你的自动审查为每个PR生成测试用例建议。审查一个添加课程完成跟踪的PR时，Claude建议了10个测试用例，但开发者反馈有6个重复了现有测试套件已覆盖的场景。哪种变更最有效地减少重复建议？
哪种变更最有效？
- A) 在上下文中包含现有测试文件，使Claude能够确定哪些场景已经被覆盖。[正确]
- B) 将请求的建议数量从10个减少到5个，假设Claude首先优先考虑最有价值的案例。
- C) 添加指令，指导Claude专门关注边缘情况和错误条件，而非成功路径。
- D) 实现后处理，通过关键词重叠过滤描述与现有测试名称匹配的建议。
为什么选A： 包含现有测试文件修复了重复的根本原因：Claude只有在知道已有哪些测试的情况下才能避免建议已覆盖的场景。这为Claude提供了提出真正新的、有价值测试所需的信息。
第25题（场景：Claude Code用于持续集成）
情境： 初始自动审查识别出12个发现后，开发者推送新提交以解决问题。重新运行审查产生8个发现，但开发者报告有5个重复了对新提交中已修复代码的先前评论。在保持彻底性的同时消除这种冗余反馈的最有效方法是什么？
消除冗余反馈最有效的方法是什么？
- A) 只在创建PR和最终合并前状态时运行审查，跳过中间提交。
- B) 添加后处理过滤器，在发布评论之前删除通过文件路径和问题描述匹配先前发现的内容。
- C) 将审查范围限制在最近推送中更改的文件，排除早期提交中的文件。
- D) 在上下文中包含先前的审查发现，指示Claude只报告新问题或仍未解决的问题。[正确]
为什么选D： 在上下文中包含先前的审查发现使Claude能够区分新问题和最近提交中已解决的问题。这在使用Claude的推理避免对已修复代码提供冗余反馈的同时保持了审查彻底性。
第26题（场景：Claude Code用于持续集成）
情境： 你的管道脚本运行 claude "分析此拉取请求的安全问题"，但作业无限期挂起。日志显示Claude Code在等待交互式输入。在自动化管道中运行Claude Code的正确方法是什么？
正确的方法是什么？
- A) 添加
--batch标志：claude --batch "分析此拉取请求的安全问题"。 - B) 添加
-p标志：claude -p "分析此拉取请求的安全问题"。[正确] - C) 从
/dev/null重定向stdin：claude "分析此拉取请求的安全问题" < /dev/null。 - D) 在运行命令之前设置环境变量
CLAUDE_HEADLESS=true。
为什么选B： -p（或 --print）标志是以非交互方式运行Claude Code的文档化方式。它处理提示词，将结果打印到stdout，并退出而不等待用户输入——非常适合CI/CD管道。
第27题（场景：Claude Code用于持续集成）
情境： 一个拉取请求更改了库存跟踪模块中的14个文件。对所有文件一起分析的单次审查产生了不一致的结果：对一些文件的详细反馈，对另一些的表面评论，遗漏了明显的错误，以及矛盾的反馈（一个模式在一个文件中被标记，但在同一PR的另一个文件中相同代码被批准）。应该如何重构审查？
应该如何重构审查？
- A) 运行三次独立的完整PR审查，只标记至少在三次中两次出现的问题。
- B) 拆分为聚焦检查：分别审查每个文件的本地问题，然后运行独立的集成导向检查来检查跨文件数据流。[正确]
- C) 要求开发者在运行自动审查之前将大型PR拆分为3-4个文件的较小提交。
- D) 切换到更大的具有更大上下文窗口的模型，使其能够在一次检查中对14个文件给予足够的注意。
为什么选B： 聚焦的每文件检查通过确保一致的深度和可靠的本地问题检测直接解决了根本原因——注意力分散。然后，独立的集成导向检查涵盖了跨文件的问题，如依赖关系和数据流交互。
第28题（场景：Claude Code用于持续集成）
情境： 你的自动代码审查每个PR平均有15个发现，开发者报告误报率为40%。瓶颈是调查时间：开发者必须点击每个发现阅读Claude的推理后才决定是否修复或忽视。你的CLAUDE.md已经包含了可接受模式的全面规则，利益相关者拒绝了任何在开发者看到之前过滤发现的方法。哪种变更最好地解决调查时间问题？
哪种变更最好地解决调查时间？
- A) 要求Claude在每个发现中直接包含其推理和置信度估计。[正确]
- B) 添加后处理器，分析发现模式，自动抑制匹配历史误报特征的发现。
- C) 将发现分类为"阻塞问题"vs"建议"，按级别设置不同的审查要求。
- D) 配置Claude只显示高置信度发现，在开发者看到之前过滤不确定的标记。
为什么选A： 在每个发现中直接包含推理和置信度通过让开发者快速分类而无需打开每个发现来减少调查时间。它满足"不过滤"约束，因为所有发现仍然可见，同时加速了开发者的决策。
第29题（场景：Claude Code用于持续集成）
情境： 对你的自动代码审查的分析显示，按发现类别的误报率存在较大差异：安全/正确性发现有8%的误报，性能发现18%，风格/命名发现52%，文档发现48%。开发者调查显示信任度下降——许多人开始不阅读就忽视发现，因为"有一半是错的"。高误报类别侵蚀了对准确类别的信任。哪种方法在改善系统的同时最好地恢复开发者信任？
哪种方法最好地恢复开发者信任？
- A) 临时禁用高误报类别（风格、命名、文档），在改善提示词的同时只保留高精度类别。[正确]
- B) 保持所有类别启用，但为每个发现显示置信度分数，以便开发者决定调查什么。
- C) 保持所有类别启用，在接下来几周内为每个类别添加少样本示例以提高准确性。
- D) 在所有类别中均匀降低严格性以降低总体误报率。
为什么选A： 临时禁用高误报类别通过删除导致开发者忽视一切的嘈杂发现立即阻止信任侵蚀，同时保留来自安全和正确性等高精度类别的价值。它还为在重新启用之前改善有问题类别的提示词创造了空间。
第30题（场景：Claude Code用于持续集成）
情境： 你的团队希望降低自动化分析的API成本。目前，同步Claude调用支持两个工作流：（1）阻塞性的合并前检查，必须在开发者合并之前完成；（2）每晚生成的技术债务报告，供次日早晨审阅。你的经理提议将两者都迁移到Message Batches API以节省50%。应该如何评估这个提议？
应该如何评估这个提议？
- A) 将两者都迁移到批处理，如果批次耗时过长则回退到同步调用。
- B) 将两个工作流都迁移到批处理，带状态轮询以验证完成情况。
- C) 仅对技术债务报告使用批处理；保留合并前检查的同步调用。[正确]
- D) 对两个工作流都保留同步调用以避免批处理结果排序问题。
为什么选C： Message Batches API处理最长可达24小时，没有延迟SLA，这对于隔夜技术债务报告是可接受的，但对于开发者等待的阻塞性合并前检查是不可接受的。这根据延迟要求将每个工作流与正确的API匹配。
场景：使用Claude Code生成代码
第31题（场景：使用Claude Code生成代码）
情境： 你要求Claude Code实现一个将API响应转换为内部标准化格式的函数。经过两次迭代，输出结构仍然不符合预期——一些字段的嵌套方式不同，时间戳格式不正确。你用散文描述了需求，但Claude每次都以不同方式解读。
下一次迭代哪种方法最有效？
- A) 编写描述预期输出结构的JSON Schema，并在每次迭代后验证Claude的输出。
- B) 提供2-3个具体的输入输出示例，显示代表性API响应的预期转换。[正确]
- C) 用更高的技术精度重写需求，指定确切的字段映射、嵌套规则和时间戳格式字符串。
- D) 要求Claude解释其对需求的当前理解，以确定解释在哪里产生分歧。
为什么选B： 具体的输入输出示例通过向Claude展示确切的预期转换结果消除了散文描述中固有的歧义。这直接解决了根本原因——对文本需求的误解——通过提供字段嵌套和时间戳格式的明确模式。
第32题（场景：使用Claude Code生成代码）
情境： 你需要添加Slack作为新的通知渠道。现有代码库对邮件、短信和推送渠道有清晰、成熟的模式。然而，Slack的API提供了根本不同的集成方式——传入webhooks（简单、单向）、bot tokens（支持投递确认和程序化控制）或Slack Apps（双向事件，需要工作区审批）。你的任务说"添加Slack支持"，没有指定集成方法或要求投递跟踪等高级功能。
应该如何处理这个任务？
- A) 以直接执行模式开始，使用传入webhooks匹配现有的单向通知模式。
- B) 切换到规划模式探索集成选项和架构影响，然后在实现之前提出建议。[正确]
- C) 以直接执行模式开始，使用现有模式搭建Slack渠道类，推迟集成方法决策。
- D) 以直接执行模式开始，使用bot-token方法确保可能的投递确认。
为什么选B： Slack集成有多种有效方法，架构影响显著不同，需求也不明确。规划模式让你在实现之前评估webhooks、bot tokens和Slack Apps之间的权衡并对方法达成一致。
第33题（场景：使用Claude Code生成代码）
情境： 你的CLAUDE.md文件已增长到400+行，混合了编码标准、测试约定、详细的PR审查清单、部署指令和数据库迁移程序。你希望Claude始终遵循编码标准和测试约定，但仅在执行这些任务时应用PR审查、部署和迁移指导。
哪种重构方式最有效？
- A) 将所有指导移入按工作流类型组织的独立技能文件，在CLAUDE.md中只留下简短的项目描述。
- B) 在CLAUDE.md中保留所有内容，但使用
@import语法按类别整理到单独维护的文件中。 - C) 将CLAUDE.md拆分为
.claude/rules/下带有路径绑定glob模式的文件，使每个规则只对相关文件类型加载。 - D) 在CLAUDE.md中保留通用标准，为工作流特定指导（PR审查、部署、迁移）创建带有触发关键词的技能。[正确]
为什么选D： CLAUDE.md内容在每次会话中加载，确保编码标准和测试约定始终适用，而技能在Claude检测到触发关键词时按需调用——非常适合PR审查、部署和迁移等工作流特定指导。
第34题（场景：使用Claude Code生成代码）
情境： 你的任务是将团队的单体应用重构为微服务。这涉及到跨数十个文件的变更，以及关于服务边界和模块依赖关系的决策。
应该选择哪种方式？
- A) 切换到规划模式探索代码库、理解依赖关系，并在进行变更之前设计实现方法。[正确]
- B) 以直接执行模式开始，只在实现过程中遇到意外复杂性时切换到规划。
- C) 以直接执行模式开始，进行渐进式变更，让实现揭示自然的服务边界。
- D) 使用指定每个服务结构的详细预先指令进行直接执行。
为什么选A： 规划模式是复杂架构重构（如拆分单体）的正确策略：它允许在提交到跨多个文件的潜在高代价变更之前进行安全探索和明智的边界决策。
第35题（场景：使用Claude Code生成代码）
情境： 你的团队创建了一个 /analyze-codebase 技能，执行深度代码分析——依赖扫描、测试覆盖率计数和代码质量指标。运行该命令后，团队成员报告Claude在会话中变得不那么响应，并失去了原始任务的上下文。
在保留完整分析能力的同时，如何最有效地解决这个问题？
- A) 在技能前置内容中添加
context: fork，以在隔离的子智能体上下文中运行分析。[正确] - B) 在前置内容中添加
model: haiku，使用更快、更便宜的模型进行分析。 - C) 将技能拆分为三个较小的技能，每个产生较少的输出。
- D) 在技能中添加指令，在显示之前将所有结果压缩为简短摘要。
为什么选A： context: fork 在隔离的子智能体上下文中运行分析，使大量输出不污染主会话的上下文窗口，Claude不会失去原始任务的轨迹。它在保持完整分析能力的同时保持主会话的响应性。
第36题（场景：使用Claude Code生成代码）
情境： 你的团队在 .claude/skills/commit/SKILL.md 中使用 /commit 技能。一位开发者想为他们的个人工作流定制它（不同的提交消息格式、额外检查），而不影响队友。
你的建议是什么？
- A) 在
~/.claude/skills/下以不同名称创建个人版本，例如/my-commit。[正确] - B) 在项目技能前置内容中基于用户名添加条件逻辑。
- C) 在
~/.claude/skills/commit/SKILL.md中创建同名的个人版本。 - D) 在个人技能前置内容中设置
override: true以优先于项目版本。
为什么选A： 项目技能优先于同名的个人技能。为了在团队技能旁边保留个性化变体，开发者应该在他们的个人 ~/.claude/skills/ 目录中创建一个不同名称的技能（例如 /my-commit）。
第37题（场景：使用Claude Code生成代码）
情境： 你的团队使用Claude Code已有几个月。最近，三位开发者报告Claude遵循"始终包含全面的错误处理"指导，但一位刚加入的第四位开发者说Claude不遵循它。所有四人都在同一个仓库工作，代码是最新的。
最可能的原因和解决方法是什么？
- A) 指导存在于原始开发者的用户级
~/.claude/CLAUDE.md文件中，而非项目.claude/CLAUDE.md中。将指令移到项目级文件，使所有团队成员都能接收到它。[正确] - B) 新开发者的
~/.claude/CLAUDE.md包含覆盖项目设置的冲突指令；他们应该删除冲突的部分。 - C) Claude Code随时间学习每用户偏好；新开发者必须重复该要求直到Claude"记住"它。
- D) Claude Code在首次读取后缓存CLAUDE.md；原始开发者使用缓存版本。所有人应该清除Claude Code缓存。
为什么选A： 如果指导只添加到原始开发者的用户级配置而非项目级 .claude/CLAUDE.md，新团队成员将不会接收到它。将其移到项目级配置确保所有当前和未来的团队成员自动获得指导。
第38题（场景：使用Claude Code生成代码）
情境： 你发现在生成新API端点时，将2-3个完整的端点实现示例作为上下文包含显著提高了一致性。然而，这些上下文只在创建新端点时有用——不适用于调试、代码审查或API目录中的其他工作。
哪种配置方式最有效？
- A) 将端点示例和模式文档添加到项目CLAUDE.md，使其始终可用。
- B) 通过将代码复制到提示词中，在每次生成请求中手动引用端点示例。
- C) 在
.claude/rules/api/中配置路径特定规则，包含端点示例并在API目录中工作时激活。 - D) 创建引用端点示例并包含模式遵循指令的技能，通过斜杠命令按需调用。[正确]
为什么选D： 按需调用的技能只在生成新端点时加载示例上下文，而非在调试或审查等不相关任务中。这在需要时保留高质量生成的同时保持主上下文清洁。
第39题（场景：使用Claude Code生成代码）
情境： 你的团队创建了一个 /migration 技能，通过 $ARGUMENTS 接受迁移名称生成数据库迁移文件。在生产中你观察到三个问题：（1）开发者经常在没有参数的情况下运行技能，导致命名不好的文件；（2）技能有时使用来自无关先前对话的数据库Schema详情；（3）一位开发者在技能拥有广泛工具访问权限时意外运行了破坏性测试清理。
哪种配置方式修复了所有三个问题？
- A) 使用位置参数
$1和$2而非$ARGUMENTS来强制特定输入，通过@语法包含显式Schema文件引用以控制上下文，并添加关于破坏性操作的前置内容描述警告。 - B) 在前置内容中添加
argument-hint以请求必要参数，使用context: fork隔离执行，并将allowed-tools限制为文件写入操作。[正确] - C) 拆分为
/migration-create和/migration-apply技能，如果缺少迁移名称则添加验证指令请求，并为每个使用不同的allowed-tools范围。 - D) 在技能SKILL.md中添加验证指令确保
$ARGUMENTS是有效名称，添加提示词忽略先前对话上下文，并列出禁止操作以避免。
为什么选B： 这使用三个独立的配置功能来解决每个问题：argument-hint 改善参数输入并减少缺失参数，context: fork 防止来自先前对话的上下文泄漏，allowed-tools 将技能约束到安全的文件写入操作，防止破坏性操作。
第40题（场景：使用Claude Code生成代码）
情境： 你的代码库在不同区域有不同的编码约定：React组件使用带hooks的函数式风格，API处理程序使用带特定错误处理的async/await，数据库模型遵循仓库模式。测试文件分布在代码库中，与被测试的代码相邻（例如，Button.test.tsx 在 Button.tsx 旁边），你希望所有测试无论位置如何都遵循相同的约定。
确保Claude在生成代码时自动应用正确约定最受支持的方式是什么？
- A) 将所有约定放在根目录CLAUDE.md中按区域标题分组，依靠Claude推断哪个部分适用。
- B) 在
.claude/skills/中为每种代码类型创建技能，在每个SKILL.md中嵌入约定。 - C) 在每个子目录中放置包含该区域约定的独立CLAUDE.md文件。
- D) 在
.claude/rules/下创建带有YAML前置内容指定glob模式的规则文件，根据文件路径条件性地应用约定。[正确]
为什么选D： 带有YAML前置内容和glob模式的 .claude/rules/ 文件（例如，**/*.test.tsx、src/api/**/*.ts）无论目录结构如何都能实现确定性的、基于路径的约定应用。这是处理分布式测试文件等跨领域模式最受支持的方式。
第41题（场景：使用Claude Code生成代码）
情境： 你想创建一个自定义斜杠命令 /review，运行团队的标准代码审查清单。当开发者克隆或更新仓库时，它应该对每位开发者可用。
应该在哪里创建命令文件？
- A) 在每个开发者主目录的
~/.claude/commands/中。 - B) 在项目仓库的
.claude/commands/下。[正确] - C) 在
.claude/config.json中作为命令数组。 - D) 在根项目CLAUDE.md中。
为什么选B： 在项目仓库内 .claude/commands/ 下放置自定义斜杠命令确保它们受版本控制，并对每个克隆或更新仓库的开发者自动可用。这是Claude Code中项目级自定义命令的预期位置。
第42题（场景：使用Claude Code生成代码）
情境： 你的团队CLAUDE.md增长到500+行，混合了TypeScript约定、测试指导、API模式和部署程序。开发者觉得很难找到和更新正确的部分。
Claude Code支持什么方式将项目级指令整理为聚焦的主题模块？
- A) 定义将文件模式映射到CLAUDE.md内特定部分的
.claude/config.yaml映射文件。 - B) 在
.claude/rules/中创建独立的Markdown文件，每个覆盖一个主题（例如，testing.md、api-conventions.md）。[正确] - C) 在相关子目录的README.md文件中拆分指令，Claude自动将其作为指令加载。
- D) 在目录树的不同级别创建多个名为CLAUDE.md的文件，每个覆盖父级指令。
为什么选B： Claude Code支持 .claude/rules/ 目录，你可以在那里为主题指导（例如，testing.md、api-conventions.md）创建独立的Markdown文件，允许团队将大型指令集整理为聚焦的、可维护的模块。
第43题（场景：使用Claude Code生成代码）
情境： 你创建了一个自定义技能 /explore-alternatives，团队用它在选择方案之前集思广益和评估实现方法。开发者报告运行技能后，后续Claude响应受到替代方案讨论的影响——有时引用被拒绝的方法或保留干扰实际实现的探索上下文。
应该如何最有效地配置这个技能？
- A) 在技能中使用
!前缀将探索逻辑作为bash子进程运行。 - B) 在技能前置内容中添加
context: fork。[正确] - C) 拆分为两个技能——
/explore-start和/explore-end——以标记何时应该丢弃探索上下文的边界。 - D) 在
~/.claude/skills/而非.claude/skills/中创建技能。
为什么选B： context: fork 在隔离的子智能体上下文中运行技能，使探索讨论不污染主对话历史。这防止了被拒绝的方法和集思广益上下文影响后续的实现工作。
第44题（场景：使用Claude Code生成代码）
情境： 你的团队想添加一个GitHub MCP服务器，通过Claude Code搜索PR和检查CI状态。六位开发者每人有自己的个人GitHub访问令牌。你希望在团队中保持一致的工具，不将凭证提交到版本控制。
哪种配置方式最有效？
- A) 让每位开发者通过
claude mcp add --scope user在用户范围内添加服务器。 - B) 创建一个从
.env文件读取令牌并智能体GitHub API调用的MCP服务器包装器，然后将包装器添加到项目.mcp.json。 - C) 使用环境变量替换（
${GITHUB_TOKEN}）进行身份验证，将服务器添加到项目.mcp.json，并在项目README中记录所需的环境变量。[正确] - D) 在项目范围内用占位令牌配置服务器，然后告诉开发者在其本地配置中覆盖它。
为什么选C： 带有环境变量替换的项目 .mcp.json 是惯用方式：它提供了一个版本控制的MCP配置单一来源，同时让每位开发者通过环境变量提供凭证。在README中记录变量使入职变得容易，而不提交密钥。
第45题（场景：使用Claude Code生成代码）
情境： 你正在120个文件的代码库中添加外部API调用的错误处理包装器。工作分三个阶段：（1）发现所有调用点和模式；（2）协作设计错误处理方法；（3）一致地实现包装器。在第一阶段，Claude生成列出数百个带上下文的调用点的大量输出，在发现完成之前快速填满上下文窗口。
在保持实现一致性的同时完成任务哪种方式最有效？
- A) 使用探索子智能体进行第一阶段，隔离详细的发现输出并返回摘要，然后在主对话中继续第2-3阶段。[正确]
- B) 在主对话中完成所有阶段，在处理文件时定期使用
/compact减少上下文使用。 - C) 切换到带
--continue的无头模式，在批处理调用之间传递明确的上下文摘要以保持连续性。 - D) 在CLAUDE.md中定义错误处理模式，然后跨多个会话批量处理文件，依靠共享记忆文件保持一致性。
为什么选A： 探索子智能体将详细的发现输出隔离在独立上下文中，只向主对话返回简洁摘要。这为协作设计和一致实现阶段保留了主上下文窗口，这些阶段中保留的上下文最有价值。
场景：客服智能体
第46题（场景：客服智能体）
情境： 在测试中，你注意到智能体在用户询问订单状态时经常调用 get_customer，即使 lookup_order 更合适。解决这个问题应该首先检查什么？
应该首先检查什么？
- A) 实现预处理分类器，检测与订单相关的请求并直接路由到
lookup_order。 - B) 减少智能体可用的工具数量以简化选择。
- C) 在系统提示词中添加少样本示例，涵盖所有可能的订单请求模式以改善工具选择。
- D) 检查工具描述，确保它们清楚地区分每个工具的目的。[正确]
为什么选D： 工具描述是模型用来决定调用哪个工具的主要输入。当智能体持续选择错误的工具时，第一个诊断步骤是验证工具描述是否清楚地分离了每个工具的目的和使用边界。
第47题（场景：客服智能体）
情境： 你的智能体处理单一问题请求的准确率为94%（例如，"我需要订单#1234的退款"）。但当客户在一条消息中包含多个问题时（例如，"我需要订单#1234的退款，还想更新订单#5678的配送地址"），工具选择准确率降至58%。智能体通常只解决一个问题，或者将参数混合在不同请求中。哪种方法最有效地提高多问题请求的可靠性？
哪种方法最有效？
- A) 实现预处理层，使用单独的模型调用将多问题消息分解为单独请求，独立处理每个请求，然后合并结果。
- B) 将相关工具合并为较少的通用工具。
- C) 在提示词中添加少样本示例，演示多问题请求的正确推理和工具排序。[正确]
- D) 实现响应验证，检测不完整的答案并自动重新提示智能体解决遗漏的问题。
为什么选C： 演示多问题请求的正确推理和工具排序的少样本示例最有效，因为智能体在单个问题上已经表现良好——它需要的是关于分解和路由多个问题以及分离参数模式的指导。
第48题（场景：客服智能体）
情境： 生产日志显示，对于"订单#1234的退款"等简单请求，你的智能体以91%的成功率在3-4次工具调用中解决问题。但对于"我被重复收费，折扣没有应用，我想取消"等复杂请求，智能体平均超过12次工具调用，成功率仅54%——通常顺序调查问题并为每个问题获取冗余客户数据。哪种变更最有效地改善复杂请求的处理？
哪种变更最有效？
- A) 在阶段之间添加显式验证检查点，要求智能体在进入下一个问题之前记录每个解决的问题的进度。
- B) 通过将
get_customer、lookup_order和与账单相关的工具合并为单个investigate_issue工具来减少工具数量。 - C) 将请求分解为独立问题，然后使用共享客户上下文并行调查每个问题，然后综合最终解决方案。[正确]
- D) 在系统提示词中添加少样本示例，演示各种多方面账单场景的理想工具调用序列。
为什么选C： 分解为独立问题并使用共享客户上下文并行调查同时修复了两个关键问题：它通过在问题间重用共享上下文消除了冗余数据检索，并通过在综合单一解决方案之前并行化调查减少了总工具调用循环。
第49题（场景：客服智能体）
情境： 你的智能体首次联系解决率为55%，远低于80%的目标。日志显示它升级了简单案例（有照片证明的损坏商品标准替换），同时试图自主处理需要策略例外的复杂情况。最有效地改善升级校准的方法是什么？
最有效地改善升级校准的方法是什么？
- A) 要求智能体在每次响应前自评置信度（1-10分），当置信度低于阈值时自动路由到人工。
- B) 部署一个在历史工单上训练的单独分类器模型，在主智能体开始处理之前预测哪些请求需要升级。
- C) 在系统提示词中添加显式升级标准，带有显示何时升级versus自主解决的少样本示例。[正确]
- D) 实现情感分析来确定客户沮丧程度，当负面情感超过阈值时自动升级。
为什么选C： 带有少样本示例的显式升级标准直接解决了根本原因——简单和复杂案例之间不清晰的决策边界。这是最适度、最有效的首次干预，教导智能体何时升级和何时自主解决，不需要额外的基础设施。
第50题（场景：客服智能体）
情境： 调用 get_customer 和 lookup_order 后，智能体拥有所有可用的系统数据，但仍面临不确定性。哪种情况是调用 escalate_to_human 最合理的触发器？
哪种情况最合理地需要升级？
- A) 客户想取消昨天发货明天到达的订单。智能体应该升级，因为客户收到包裹后可能会改变主意。
- B) 客户声称没有收到订单，但跟踪显示三天前已在其地址签收。智能体应该升级，因为呈现矛盾证据可能损害客户关系。
- C) 客户要求竞争对手价格匹配。你的策略允许在14天内对你自己网站的降价进行价格调整，但对竞争对手价格只字未提。智能体应该为策略解读升级。[正确]
- D) 客户消息同时包含账单问题和产品退货。智能体应该升级，以便人工可以在一次交互中协调两个问题。
为什么选C： 这是真正的策略缺口：公司规则涵盖了你自己网站的降价，但没有涉及竞争对手价格匹配。智能体不得自行创造策略，应该升级以便人工判断如何解读或扩展现有规则。
第51题（场景：客服智能体）
情境： 生产日志显示，在12%的情况下，你的智能体跳过 get_customer，仅使用客户提供的姓名直接调用 lookup_order，有时导致账户误识别和错误退款。哪种变更最有效地修复这个可靠性问题？
哪种变更最有效？
- A) 添加少样本示例，显示智能体即使在客户自愿提供订单详情时也始终先调用
get_customer。 - B) 实现路由分类器，分析每个请求并只启用该请求类型适合的工具子集。
- C) 添加程序化前提条件，在
get_customer返回经过验证的客户标识符之前阻止lookup_order和process_refund。[正确] - D) 加强系统提示词，说明在任何订单操作之前通过
get_customer进行客户验证是必须的。
为什么选C： 程序化前提条件提供了确定性保证，确保遵循所需的排序。这是最有效的方法，因为它消除了跳过验证的可能性，无论LLM的行为如何。
第52题（场景：客服智能体）
情境： 生产指标显示，在解决复杂账单纠纷或多订单退货时，客户满意度评分比简单案例低15%——即使解决方案在技术上是正确的。根本原因分析显示智能体提供准确的解决方案，但不一致地解释推理：有时省略相关策略详情，有时遗漏时间线信息或后续步骤。具体的上下文缺口因情况而异。你想在不增加人工监督的情况下改善解决方案质量。哪种方法最有效？
哪种方法最有效？
- A) 添加自我批评阶段，智能体评估草稿响应的完整性——确保它解决了客户的问题，包含相关上下文，并预测后续问题。[正确]
- B) 添加确认阶段，智能体在关闭之前询问"这完全解决了你的问题吗？"，允许客户在需要时请求更多信息。
- C) 对于复杂案例将模型从Haiku升级到Sonnet，根据定义的复杂性指标进行路由。
- D) 在系统提示词中实现少样本示例，为五种常见复杂案例类型显示完整解释，演示如何包含策略上下文、时间线和后续步骤。
为什么选A： 自我批评阶段（评估者-优化器模式）通过强制智能体在呈现之前根据具体标准（如策略上下文、时间线和后续步骤）评估自己的草稿直接解决了不一致的解释完整性。这捕获了特定案例的缺口，不需要人工监督。
第53题（场景：客服智能体）
情境： 生产指标显示你的智能体每次解决平均超过4次API循环。分析显示Claude经常在即使最初两者都需要时，也在单独的顺序轮次中请求 get_customer 和 lookup_order。减少循环次数最有效的方法是什么？
减少循环次数最有效的方法是什么？
- A) 实现投机执行，自动与任何请求的工具并行调用可能需要的工具，无论请求什么都返回所有结果。
- B) 增加
max_tokens给Claude更多空间进行规划并自然地合并工具请求。 - C) 创建复合工具如
get_customer_with_orders，将常见的查找组合捆绑为单次调用。 - D) 在提示词中指示Claude将工具请求捆绑到一个轮次中，并在下一次API调用之前一起返回所有结果。[正确]
为什么选D： 提示Claude将相关工具请求捆绑到单个轮次中利用了其原生的一次请求多个工具的能力。它以最小的架构变更直接修复了顺序调用模式。
第54题（场景：客服智能体）
情境： 生产日志显示一个模式：客户引用具体金额（例如，"我提到的15%折扣"），但智能体以错误的值响应。调查显示这些细节是在20+轮之前提到的，被压缩为"讨论了促销定价"等模糊摘要。哪种修复最有效？
哪种修复最有效？
- A) 将摘要阈值从70%提高到85%，使对话在触发摘要之前有更多空间。
- B) 在外部存储中存储完整的对话历史，当智能体检测到"如我所说"等引用时实现检索。
- C) 将事务性事实（金额、日期、订单号）提取到在摘要历史之外每个提示词中包含的持久化"案例事实"块中。[正确]
- D) 修改摘要提示词，明确保留所有数字、百分比、日期和客户陈述的期望原文。
为什么选C： 摘要本质上会失去精确细节。将事务性事实提取到摘要历史之外的结构化"案例事实"块中保留了关键信息，使其在每个提示词中都可靠地可用，不管已经摘要了多少轮。
第55题（场景：客服智能体）
情境： 你的 get_customer 工具在按姓名搜索时返回所有匹配项。目前，当有多个结果时，Claude选择有最近订单的客户，但生产数据显示对于模糊匹配15%的时间选择了错误的账户。应该如何解决这个问题？
应该如何解决这个问题？
- A) 实现置信度评分系统，在置信度85%以上自主行动，低于阈值时请求澄清。
- B) 指示Claude在
get_customer返回多个匹配时，在采取任何客户特定操作之前请求额外标识符（邮件、电话或订单号）。[正确] - C) 修改
get_customer基于排名算法只返回单个最可能匹配，消除歧义。 - D) 在提示词中添加少样本示例，演示模糊匹配的正确推理和工具排序。
为什么选B： 要求用户提供额外标识符是解决歧义最可靠的方式，因为用户对自己的身份有确定性知识。多一次对话轮次是消除因选择错误账户导致的15%错误率的小代价。
第56题（场景：客服智能体）
情境： 生产日志显示一个一致的模式：当客户消息中包含"账户"这个词时（例如，"我想查看我昨天下的订单的账户"），智能体78%的时间首先调用 get_customer。当客户以不含"账户"的方式措辞类似请求时（例如，"我想查看我昨天下的订单"），它93%的时间首先调用 lookup_order。工具描述清晰且没有歧义。造成这种差异最可能的根本原因是什么？
最可能的根本原因是什么？
- A) 系统提示词包含基于"账户"等术语引导行为的关键词敏感指令，创建了意外的工具选择模式。[正确]
- B) 模型的基础训练在"账户"术语和客户相关操作之间创建了关联，覆盖了工具描述。
- C) 模型需要更多关于多概念消息的训练数据，应该在同时包含账户和订单术语的示例上进行微调。
- D) 工具描述需要额外的负面示例，指定何时不使用每个工具，以防止这种关键词诱导的混淆。
为什么选A： 系统性的关键词驱动模式（78% vs 93%）强烈表明系统提示词中有明确的路由逻辑对"账户"这个词做出反应，并将智能体引导向客户相关工具。由于工具描述已经清晰，这种差异指向提示词级别的指令创建了意外的行为引导。
第57题（场景：客服智能体）
情境： 生产日志显示，当用户询问订单时（例如，"查看我的订单#12345"），智能体经常调用 get_customer 而非调用 lookup_order。两个工具都有最简化的描述（"获取客户信息"/"获取订单详情"），并接受看起来相似的标识符格式。提高工具选择可靠性的最有效第一步是什么？
最有效的第一步是什么？
- A) 实现路由层，在每个轮次之前分析用户输入，并基于检测到的关键词和ID模式预选正确的工具。
- B) 将两个工具合并为单个
lookup_entity，接受任何标识符并在内部决定查询哪个后端。 - C) 在系统提示词中添加少样本示例，演示正确的工具选择模式，带有5-8个将与订单相关的查询路由到
lookup_order的示例。 - D) 扩展每个工具的描述，包含输入格式、示例查询、边缘情况以及解释何时使用它vs类似工具的边界。[正确]
为什么选D： 用输入格式、示例查询、边缘情况和清晰边界扩展工具描述直接修复了根本原因——没有给LLM提供足够信息来区分类似工具的最简化描述。这是提高LLM用于工具选择的主要机制的低成本、高影响的第一步。
第58题（场景：客服智能体）
情境： 你正在为支持智能体实现智能体循环。每次Claude API调用后，你必须决定是继续循环（运行请求的工具并再次调用Claude）还是停止（向客户呈现最终答案）。什么决定这个决策？
什么决定这个决策？
- A) 检查Claude响应中的
stop_reason字段——如果是tool_use则继续，如果是end_turn则停止。[正确] - B) 解析Claude的文本中"我完成了"或"我还能帮什么吗？"等短语——自然语言信号表示任务完成。
- C) 设置最大迭代计数（例如，10次调用），达到时停止，无论Claude是否表示需要更多工作。
- D) 检查响应是否包含助手文本内容——如果Claude生成了解释性文本，循环应该终止。
为什么选A： stop_reason 是Claude用于循环控制的显式结构化信号：tool_use 表示Claude想运行一个工具并接收返回的结果，而 end_turn 表示Claude已完成其响应，循环应该结束。
第59题（场景：客服智能体）
情境： 生产日志显示智能体误解了MCP工具的输出：get_customer 返回Unix时间戳，lookup_order 返回ISO 8601日期，数字状态码（1=待处理，2=已发货）。一些工具是你无法修改的第三方MCP服务器。哪种数据格式规范化方法最可维护？
哪种方法最可维护？
- A) 使用PostToolUse钩子拦截工具输出，在智能体处理之前应用格式转换。[正确]
- B) 修改你控制的工具以返回人类可读的格式，并为第三方工具创建包装器。
- C) 创建一个
normalize_data工具，智能体在每次数据检索后调用以转换值。 - D) 在系统提示词中添加详细的格式文档，解释每个工具的数据约定。
为什么选A： PostToolUse钩子提供了一个集中的、确定性的点来拦截和规范化所有工具输出——包括第三方MCP服务器数据——在智能体处理之前。它更可维护，因为转换存在于代码中并统一应用，而非依赖LLM解读。
第60题（场景：客服智能体）
情境： 生产日志显示智能体有时在 lookup_order 更合适时选择 get_customer，特别是对于"我需要帮助处理最近的购买"等模糊查询。你决定在系统提示词中添加少样本示例以改善工具选择。哪种方法最有效地解决问题？
哪种方法最有效？
- A) 在每个工具描述中添加明确的"何时使用"和"何时不使用"指导，涵盖模糊情况。
- B) 按工具分组添加示例——所有
get_customer场景在一起，然后所有lookup_order场景。 - C) 添加4-6个针对模糊场景的示例，每个都有为什么选择一个工具而非可能的替代品的推理说明。[正确]
- D) 添加10-15个针对每个工具的典型场景的清晰、明确的请求示例，演示正确的工具选择。
为什么选C： 将少样本示例针对发生错误的特定模糊场景，并带有明确的为什么一个工具比替代品更优的推理说明，教导模型边缘情况所需的比较决策过程。这比通用示例或声明性规则更有效。