含解析的考题示例
题目1（场景：客服智能体）
情境： 数据显示，在12%的情况下，智能体跳过 get_customer 而仅使用客户姓名调用 lookup_order，导致错误退款。
哪种变更最有效？
- A) 添加程序化前提条件，在从
get_customer获得ID之前阻止lookup_order和process_refund[正确] - B) 改进系统提示词
- C) 添加少样本示例
- D) 实现路由分类器
为什么选A： 当关键业务逻辑需要特定工具顺序时，软件提供确定性保证，而基于提示词的方法（B、C）无法做到。D解决的是可用性问题，而非工具排序。
题目2（场景：客服智能体）
情境： 智能体对订单相关问题经常调用 get_customer 而非 lookup_order。工具描述最简化且相似。
第一步应该做什么？
- A) 少样本示例
- B) 用输入格式、示例和边界扩展每个工具的描述 [正确]
- C) 添加路由层
- D) 合并工具
为什么选B： 工具描述是模型的主要选择机制。这是成本最低、影响最大的修复。A增加了令牌但没有解决根本原因。C是过度设计。D需要付出比合理情况更多的努力。
题目3（场景：客服智能体）
情境： 智能体只解决了55%的问题，目标是80%。它升级了简单案例，同时试图自主处理复杂的策略例外。
如何改善校准？
- A) 添加带有少样本示例的显式升级标准 [正确]
- B) 自评置信度（1-10分）并自动升级
- C) 在历史数据上训练的单独分类器
- D) 情感分析
为什么选A： 它直接解决了根本原因——不明确的决策边界。B不可靠（模型可能自信地犯错）。C是过度设计。D解决的是不同的问题（情绪≠复杂性）。
题目4（场景：使用Claude Code生成代码）
情境： 你需要一个自定义 /review 命令用于标准代码审查，当团队成员克隆仓库时需要自动可用。
应该在哪里创建命令文件？
- A) 在项目仓库的
.claude/commands/中 [正确] - B)
~/.claude/commands/ - C) 根目录
CLAUDE.md - D)
.claude/config.json
为什么选A： 存储在 .claude/commands/ 中的项目命令受版本控制，对所有人自动可用。B用于个人命令。C用于指令，不用于命令定义。D不存在。
题目5（场景：使用Claude Code生成代码）
情境： 你需要将单体应用重构为微服务（涉及数十个文件、服务边界决策）。
应该使用什么方法？
- A) 规划模式：探索代码库、理解依赖关系、设计方案 [正确]
- B) 渐进式直接执行
- C) 带有详细预先指令的直接执行
- D) 直接执行，遇到困难时切换到规划
为什么选A： 规划模式专为大型变更、多种可行方案和架构决策而设计。B有高代价返工的风险。C假设你已经了解结构。D是被动反应式的。
题目6（场景：使用Claude Code生成代码）
情境： 代码库在不同区域有不同的约定（React、API、数据库）。测试与代码并存。你希望约定被自动应用。
应该使用什么方法？
- A) 带有YAML前置内容和glob模式的
.claude/rules/文件 [正确] - B) 将所有内容放入根目录CLAUDE.md
- C)
.claude/skills/中的技能 - D) 在每个目录中放置CLAUDE.md
为什么选A： 带有glob模式的 .claude/rules/（例如，**/*.test.tsx）可以基于文件路径自动应用约定——非常适合分散在代码库中的测试。B依赖模型推断。C是手动/按需的。D在相关文件分布于多个目录时效果不好。
题目7（场景：多智能体研究系统）
情境： 系统研究"AI对创意产业的影响"，但报告只涵盖视觉艺术。协调者将主题分解为："数字艺术中的AI"、"平面设计中的AI"、"摄影中的AI"。
原因是什么？
- A) 综合智能体没有检测到缺口
- B) 协调者分解任务过于狭窄 [正确]
- C) 网络搜索智能体搜索不够彻底
- D) 文档分析智能体过滤掉了非视觉来源
为什么选B： 日志显示协调者只将"创意产业"分解为视觉子主题，完全忽略了音乐、文学和电影。子智能体执行正确——问题在于分配给它们的任务。
题目8（场景：多智能体研究系统）
情境： 一个网络搜索子智能体在研究复杂主题时超时。你需要设计如何将错误信息传回协调者。
哪种错误传播方式最能实现智能恢复？
- A) 向协调者返回结构化错误上下文：故障类型、查询、部分结果和替代方案 [正确]
- B) 在子智能体内部使用指数退避实现自动重试，然后返回通用的"搜索不可用"状态
- C) 在子智能体内部捕获超时并返回标记为成功的空结果集
- D) 将超时异常传播到终止整个工作流的顶层处理程序
为什么选A： 结构化错误上下文使协调者能够决定是否以修改后的查询重试、尝试替代方案，还是继续使用部分结果。B将上下文隐藏在通用状态后面。C将失败掩盖为成功。D不必要地中止整个工作流。
题目9（场景：多智能体研究系统）
情境： 综合智能体在合并结果时经常需要验证特定声明。目前，当需要验证时，综合智能体将控制权交回协调者，协调者调用网络搜索智能体，然后用新结果重新运行综合。这为每个任务增加了2-3次额外的往返，延迟增加了40%。你的评估显示85%的检查是简单的事实核查（日期、名称、统计数据），15%需要更深入的调查。
如何在保持可靠性的同时减少开销？
- A) 为综合智能体提供有限的
verify_fact工具用于简单检查，并继续通过协调者路由复杂验证 [正确] - B) 将所有验证需求积累到批次中，最后统一返回给协调者
- C) 给综合智能体完整访问所有网络搜索工具的权限
- D) 主动缓存每个来源周围的额外上下文
为什么选A： 这应用了最小权限原则：综合智能体获得85%常见情况（简单事实检查）所需的工具，同时保留了协调者中介的路径用于复杂调查。B引入了阻塞依赖（后续综合步骤可能依赖先前验证的事实）。C破坏了职责分离。D依赖于无法可靠预测需求的投机性缓存。
题目10（场景：CI中的Claude Code）
情境： 管道运行 claude "分析此拉取请求的安全问题"，但挂起等待交互式输入。
正确的方法是什么？
- A) 使用
-p标志：claude -p "分析此拉取请求的安全问题"[正确] - B) 设置
CLAUDE_HEADLESS=true - C) 从
/dev/null重定向stdin - D) 使用
--batch
为什么选A： -p（或 --print）是以非交互模式运行Claude Code的文档化方式。它处理提示词，打印到stdout并退出。其他选项要么是不存在的功能，要么是Unix变通方案。
题目11（场景：CI中的Claude Code）
情境： 团队希望降低自动化分析的API成本。Claude目前实时服务两个工作流：（1）阻塞性的合并前检查，必须在开发者合并PR之前完成；（2）每晚生成的技术债务报告，供早晨查阅。一位经理提议将两者都迁移到Message Batches API以节省50%。
你应该如何评估这个提议？
- A) 仅对技术债务报告使用批处理；保留合并前检查的实时调用 [正确]
- B) 将两个工作流都迁移到批处理，并轮询完成状态
- C) 两者都保留实时调用以避免批处理结果中的排序问题
- D) 将两者都迁移到批处理，如果批处理耗时过长则回退到实时
为什么选A： Message Batches API节省50%，但处理时间最长可达24小时，没有保证的延迟SLA。这使其不适合开发者等待的阻塞性合并前检查，但非常适合技术债务报告等隔夜批处理工作负载。
题目12（场景：多文件代码审查）
情境： 一个拉取请求更改了库存跟踪模块中的14个文件。对所有文件的单次审查产生了不一致的结果：一些文件有详细评论，另一些却只有表面性评论，遗漏了明显的错误，并且反馈矛盾（一个模式在一个文件中被标记为有问题，但在另一个文件中相同代码却被批准）。
应该如何重构审查？
- A) 拆分为聚焦检查：分别分析每个文件的本地问题，然后对跨文件数据流运行单独的集成检查 [正确]
- B) 要求开发者将大型PR拆分为3-4个文件的提交
- C) 切换到具有更大上下文窗口的高级模型，一次性审查所有14个文件
- D) 运行三次独立的完整PR审查，只报告至少在两次中发现的问题
为什么选A： 聚焦检查直接解决了根本原因——同时处理多个文件时的注意力分散。每文件分析确保深度一致，独立的集成检查捕获跨文件问题。B将负担转移给开发者而不改善系统。C是误解：更大的上下文不能修复注意力质量。D通过要求不一致检测之间的共识来抑制真实的错误。