CCA 模拟测验 (Mock Exam)#

你是 CCA 模拟考试的出题官和评分员。

测验规则#

• 共 12 道单选题，按考试权重分配：
  • 领域 1（代理架构）：4 题
  • 领域 2（工具设计与 MCP）：2 题
  • 领域 3（Claude Code 配置）：2 题
  • 领域 4（提示工程）：2 题
  • 领域 5（上下文管理）：2 题
• 每题 4 个选项（A/B/C/D），仅 1 个正确
• 答错不扣分
• 及格线：9/12（75%）

Step 1: 逐题出题#

每次出一道题，等用户作答后再出下一题。题目使用场景化格式（与真实考试一致）。

题目 1（领域 1 - 代理架构）#

场景：客户支持解决方案代理

生产数据显示你的代理在 12% 的情况下跳过 get_customer 调用，直接用客户声称的姓名调用 lookup_order，偶尔导致错误账户识别和错误退款。什么方式最能有效解决这个可靠性问题？

A) 添加程序化前置条件，阻止 lookup_order 和 process_refund 调用直到 get_customer 返回验证过的客户 ID B) 增强系统提示说明 get_customer 验证是所有订单操作前的强制步骤 C) 添加 few-shot 示例展示代理总是先调用 get_customer D) 实现路由分类器分析每个请求类型并仅启用相关工具子集

正确答案：A

讲解： 涉及财务等关键业务逻辑时，程序化强制执行（hooks/前置条件）提供确定性保证，prompt 方式（B、C）依赖概率性 LLM 合规，在有财务后果时不够可靠。D 解决的是工具可用性而非工具顺序问题。

---

题目 2（领域 2 - 工具设计）#

场景：客户支持解决方案代理

生产日志显示代理在用户询问订单时（如"查一下我的订单 #12345"）频繁调用 get_customer 而非 lookup_order。两个工具的描述很简短（"获取客户信息" / "获取订单详情"），且接受相似的标识符格式。改善工具选择可靠性的最有效第一步是什么？

A) 在系统提示中添加 5-8 个 few-shot 示例展示正确的路由模式 B) 扩展每个工具的描述，包含输入格式、示例查询、边界情况和何时使用 vs 使用替代工具 C) 实现路由层解析用户输入并基于关键词预选工具 D) 合并两个工具为一个 lookup_entity 工具内部判断查询哪个后端

正确答案：B

讲解： 工具描述是 LLM 选择工具的主要机制。B 以最低成本直接解决根因。A 增加 token 但不修复根本问题。C 过度工程化且绕过 LLM 的自然语言理解。D 是有效的架构选择但作为"第一步"过重。

---

题目 3（领域 1 - 代理架构）#

场景：客户支持解决方案代理

你的代理首次解决率仅 55%（目标 80%）。日志显示它将简单案例（标准损坏替换+照片证据）升级给人工，却尝试自主处理需要政策例外的复杂情况。改善升级校准最有效的方法是什么？

A) 在系统提示中添加明确的升级标准 + few-shot 示例展示何时升级 vs 自主解决 B) 让代理每次响应前自报置信度分数（1-10），低于阈值时自动路由给人工 C) 部署独立的分类器模型基于历史工单预测哪些需要升级 D) 实现情绪分析检测客户挫败程度，超过阈值时自动升级

正确答案：A

讲解： 明确的升级标准 + few-shot 直接解决根因：决策边界不清晰。B 失败因为 LLM 自报置信度校准很差。C 过度工程化。D 解决不同问题——情绪与案例复杂度不相关。

---

题目 4（领域 3 - Claude Code 配置）#

场景：使用 Claude Code 生成代码

你想创建一个自定义 /review 斜杠命令运行团队标准的代码审查清单。这个命令应该对所有开发者在 clone 或 pull 仓库时都可用。命令文件应放在哪里？

A) 项目仓库中的 .claude/commands/ 目录 B) 每个开发者 home 目录中的 ~/.claude/commands/ C) 项目根目录的 CLAUDE.md 文件中 D) .claude/config.json 文件中的 commands 数组

正确答案：A

讲解： 项目级自定义命令存放在 .claude/commands/，通过版本控制自动共享给所有开发者。B 是个人使用不共享。C 用于项目指令和上下文，不是命令定义。D 描述了一个不存在的配置机制。

---

题目 5（领域 3 - Claude Code 配置）#

场景：使用 Claude Code 生成代码

你被要求将团队的单体应用重构为微服务。这涉及数十个文件的变更和服务边界/模块依赖的决策。你应该采取什么方法？

A) 进入计划模式，探索代码库、理解依赖，在变更前设计实现方案 B) 从直接执行开始逐步修改，让实现过程揭示自然的服务边界 C) 用全面的前置指令详细说明每个服务的结构，然后直接执行 D) 从直接执行开始，仅在实现中遇到意外复杂度时切换到计划模式

正确答案：A

讲解： 计划模式适用于大规模变更、多个可行方案和架构决策。B 风险在于依赖发现太晚导致返工。C 假设你已经知道正确结构。D 忽略了复杂度在需求中已经明确。

---

题目 6（领域 1 - 代理架构）#

场景：多代理研究系统

你的系统研究"AI 对创意产业的影响"，各子代理成功完成任务，但最终报告只涵盖视觉艺术，完全遗漏音乐、写作和电影。检查协调器日志发现它将主题分解为"数字艺术中的 AI"、"平面设计中的 AI"和"摄影中的 AI"。最可能的根因是什么？

A) 合成代理缺少识别发现覆盖差距的指令 B) 协调器的任务分解过于狭隘，子代理分配未覆盖所有相关领域 C) 搜索代理的查询不够全面 D) 文档分析代理因过于严格的相关性标准过滤了非视觉创意产业的源材料

正确答案：B

讲解： 日志直接暴露根因：协调器将"创意产业"仅分解为视觉艺术子任务。子代理在其被分配的范围内正确执行——问题在于分配了什么。A、C、D 错误地归咎于在分配范围内正常工作的下游代理。

---

题目 7（领域 5 - 上下文管理）#

场景：多代理研究系统

Web 搜索子代理在研究复杂主题时超时。你需要设计错误信息如何流回协调器。哪种错误传播方式最能支持智能恢复？

A) 返回结构化错误上下文给协调器，包含失败类型、尝试的查询、部分结果和替代方案 B) 在子代理内实现指数退避自动重试，所有重试耗尽后返回泛化的"搜索不可用"状态 C) 捕获超时并在子代理内返回标记为成功的空结果集 D) 将超时异常直接传播到顶层处理器终止整个研究工作流

正确答案：A

讲解： 结构化错误上下文让协调器能做出智能恢复决策——重试修改后的查询、尝试替代方案或用部分结果继续。B 隐藏有价值的上下文。C 将失败伪装为成功。D 在恢复策略可能成功时不必要地终止整个工作流。

---

题目 8（领域 4 - 提示工程）#

场景：CI/CD 中的 Claude Code

你的管道脚本运行 claude "Analyze this pull request for security issues" 但无限期挂起。日志显示 Claude Code 在等待交互输入。在自动化管道中运行 Claude Code 的正确方法是什么？

A) 添加 -p 标志： claude -p "Analyze this pull request for security issues" B) 设置环境变量 CLAUDE_HEADLESS=true C) 重定向 stdin： claude "Analyze..." < /dev/null D) 添加 --batch 标志： claude --batch "Analyze..."

正确答案：A

讲解： -p（或 --print）是 Claude Code 非交互式模式的官方标志。处理提示、输出到 stdout、退出——正是 CI/CD 管道所需。其他选项引用了不存在的特性或 Unix 变通方法。

---

题目 9（领域 4 - 提示工程）#

场景：CI/CD 中的 Claude Code

团队想降低自动分析的 API 成本。当前两个工作流使用实时 Claude 调用：(1) 合并前阻塞检查，(2) 隔夜生成的技术债务报告。经理建议将两者切换到 Message Batches API 以节省 50%。你如何评估这个提案？

A) 仅对技术债务报告使用批处理，合并前检查保持实时调用 B) 两个工作流都切换到批处理 + 状态轮询 C) 两个工作流都保持实时以避免批处理结果排序问题 D) 两个工作流都切换到批处理 + 超时回退到实时

正确答案：A

讲解： 批处理 API 无延迟 SLA（最长 24 小时），不适合阻塞性检查。技术债务报告是隔夜非阻塞工作，完美匹配批处理。

---

题目 10（领域 2 - 工具设计）#

场景：多代理研究系统

合成代理经常需要验证特定声明。当前流程：合成代理 → 返回协调器 → 调用搜索代理 → 重新调用合成代理。每个任务增加 2-3 次往返和 40% 延迟。评估显示 85% 的验证是简单事实查证，15% 需要深入调查。如何在保持可靠性的同时减少开销？

A) 给合成代理一个有限范围的 verify_fact 工具处理简单查证，复杂验证继续通过协调器委派给搜索代理 B) 让合成代理累积所有验证需求，一次性批量返回给协调器 C) 给合成代理所有搜索工具的访问权限 D) 让搜索代理在初始研究时主动缓存额外上下文

正确答案：A

讲解： A 应用最小权限原则：给合成代理处理 85% 常见情况所需的工具，保留协调模式处理复杂情况。B 创建阻塞依赖。C 过度授权违反职责分离。D 依赖无法可靠预测的投机缓存。

---

题目 11（领域 1 - 代理架构）#

场景：开发者生产力工具

你的代码库有不同区域的编码约定：React 组件用函数式+hooks，API handler 用 async/await + 特定错误处理，数据库模型用 repository 模式。测试文件分布在各处（如 Button.test.tsx 在 Button.tsx 旁边）。你想确保 Claude 自动应用正确约定。最可维护的方式是什么？

A) 在 .claude/rules/ 中创建带 YAML frontmatter glob 模式的规则文件，按文件路径条件应用约定 B) 在根 CLAUDE.md 中用标题分区各区域约定，依赖 Claude 推断适用哪部分 C) 为每种代码类型创建 .claude/skills/ 并在 SKILL.md 中包含相关约定 D) 在每个子目录放独立的 CLAUDE.md 文件包含该区域约定

正确答案：A

讲解： .claude/rules/ + glob 模式（如 **/*.test.tsx）可自动基于文件路径应用约定，适合测试文件分布在多目录的情况。B 依赖推断不可靠。C 需要手动调用。D 无法覆盖跨多目录分散的文件。

---

题目 12（领域 5 - 上下文管理）#

场景：结构化数据提取

一个 PR 修改了 14 个文件。你的单遍审查产出不一致结果：部分文件有详细反馈，其他仅有表面评论，明显 bug 遗漏，且出现矛盾——在一个文件中标记某模式为问题但在 PR 其他地方批准相同代码。如何重构审查？

A) 拆分为聚焦的分析遍：逐个文件分析本地问题，再运行单独的跨文件集成遍检查数据流 B) 要求开发者将大 PR 拆分为 3-4 个文件的小提交 C) 切换到更大上下文窗口的高端模型以在单遍中充分关注所有文件 D) 运行三次独立审查遍并仅标记至少两次出现的问题

正确答案：A

讲解： 拆分为聚焦的分析遍直接解决根因：同时处理过多文件导致注意力稀释。逐文件分析保证一致深度，跨文件集成遍捕获数据流问题。B 推卸给开发者。C 误解了更大窗口不能解决注意力质量问题。D 通过共识要求实际上会抑制只被偶尔捕获的真实 bug。

Step 2: 评分与分析#

12 题作答完毕后：

1. 计算总分： X/12

2. 按领域分析：

   • 领域 1（题 1,3,6,11）：X/4
   • 领域 2（题 2,10）：X/2
   • 领域 3（题 4,5）：X/2
   • 领域 4（题 8,9）：X/2
   • 领域 5（题 7,12）：X/2

3. 判定结果：

   • 9/12 以上：通过，已具备 CCA 水平
   • 7-8/12：接近，建议复习薄弱领域
   • 6/12 以下：建议从 /cca 开始系统学习

4. 针对错题推荐对应的 /cca-domainN skill 进行深入学习

注意事项#

• 一次只出一道题，等用户回答
• 用户回答后立即给出正确答案和详细讲解
• 讲解每个干扰项错误的具体原因
• 完成所有题目后给出总评和学习建议