# Claude 認證架構師 — 基礎認證

## 學習指南（基於官方考試指南）

---

## 簡介

**Claude 認證架構師 — 基礎**認證證明專家能夠在實施基於 Claude 的實際解決方案時做出合理的權衡決策。考試評估 Claude Code、Claude Agent SDK、Claude API 和模型上下文協議（MCP）的基礎知識——這些是使用 Claude 建構生產應用的核心技術。

考題基於真實的產業場景：建構客戶支援代理系統、設計多代理研究管線、將 Claude Code 整合到 CI/CD、建立開發者生產力工具，以及從非結構化文件中提取結構化資料。

---

## 目標候選人

理想候選人是**解決方案架構師**，負責設計和交付基於 Claude 的生產應用。您應具備至少 6 個月的實踐經驗，涵蓋：

- **Claude Agent SDK** — 多代理編排、委派子代理、工具整合、生命週期鉤子
- **Claude Code** — CLAUDE.md、MCP 伺服器、Agent 技能、規劃模式
- **模型上下文協議（MCP）** — 用於後端整合的工具和資源
- **提示工程** — JSON 模式、少樣本範例、資料提取模板
- **上下文視窗** — 處理長文件、多代理上下文傳遞
- **CI/CD 管線** — 自動程式碼審查、測試生成
- **升級與可靠性** — 錯誤處理、人在迴路

---

## 考試格式

| 參數 | 值 |
|---|---|
| 題型 | 單選題（4 選 1） |
| 評分 | 100–1000 分制，及格分數 **720 分** |
| 猜測懲罰 | 無（請回答每道題！） |
| 場景 | 從 8 個可能場景中隨機抽取 4 個 |

---

## 考試內容：5 個領域

| 領域 | 權重 |
|---|---|
| 1. 代理架構與編排 | **27%** |
| 2. 工具設計與 MCP 整合 | **18%** |
| 3. Claude Code 配置與工作流 | **20%** |
| 4. 提示工程與結構化輸出 | **20%** |
| 5. 上下文管理與可靠性 | **15%** |

---

## 考試場景

### 場景 1：客戶支援代理
使用 Claude Agent SDK 建構一個處理退貨、帳單糾紛和帳戶問題的代理。該代理使用 MCP 工具（`get_customer`、`lookup_order`、`process_refund`、`escalate_to_human`）。目標是 80% 以上的首次聯絡解決率和適當的升級處理。

### 場景 2：使用 Claude Code 生成程式碼
使用 Claude Code 加速開發：程式碼生成、重構、除錯、文件編寫。需要將其與自定義斜槓命令和 CLAUDE.md 配置整合，並瞭解何時使用規劃模式。

### 場景 3：多代理研究系統
協調代理將任務委派給專業子代理：網路研究、文件分析、綜合和報告生成。系統必須生成帶有引用的完整報告。

### 場景 4：開發者生產力工具
代理幫助工程師探索陌生程式碼庫、生成樣板程式碼並自動化日常任務。使用內建工具（Read、Write、Bash、Grep、Glob）和 MCP 伺服器。

### 場景 5：用於持續整合的 Claude Code
將 Claude Code 整合到 CI/CD 管線中，用於自動程式碼審查、測試生成和拉取請求回饋。提示必須設計為最小化誤報。

### 場景 6：結構化資料提取
系統從非結構化文件中提取資訊，用 JSON 模式驗證輸出，並保持高精度。必須正確處理邊緣情況。

### 場景 7：對話式 AI 架構模式
您設計多輪對話系統，涵蓋上下文視窗管理、指令在多輪中的永續性、記憶策略、安全執行的工具設計，以及處理模糊或矛盾的使用者輸入。

### 場景 8：Agentic AI 工具 *（內容缺失 — 歡迎貢獻！）*
考生報告在考試中遇到了這一場景，但本指南尚未涵蓋相關內容。如果您在真實考試中遇到過此場景的題目，請在 [GitHub Issues](https://github.com/paullarionov/claude-certified-architect/issues) 中分享，以便我們新增完整內容。您的貢獻將幫助所有備考的人。

---

# 官方文件

| 資源 | URL |
|---|---|
| **Claude API — Messages** | https://platform.claude.com/docs/en/api/messages |
| **Claude API — Tool Use** | https://platform.claude.com/docs/en/build-with-claude/tool-use |
| **Claude API — Message Batches** | https://platform.claude.com/docs/en/build-with-claude/message-batches |
| **Claude Agent SDK — 概述** | https://platform.claude.com/docs/en/agent-sdk/overview |
| **Claude Agent SDK — Hooks** | https://platform.claude.com/docs/en/agent-sdk/hooks |
| **Claude Agent SDK — Subagents** | https://platform.claude.com/docs/en/agent-sdk/subagents |
| **Claude Agent SDK — Sessions** | https://platform.claude.com/docs/en/agent-sdk/sessions |
| **模型上下文協議（MCP）** | https://modelcontextprotocol.io/ |
| **MCP — Tools** | https://modelcontextprotocol.io/docs/concepts/tools |
| **MCP — Resources** | https://modelcontextprotocol.io/docs/concepts/resources |
| **MCP — Servers** | https://modelcontextprotocol.io/docs/concepts/servers |
| **Claude Code — 文件** | https://code.claude.com/docs/en/overview |
| **Claude Code — CLAUDE.md 與記憶體** | https://code.claude.com/docs/en/memory |
| **Claude Code — 技能（含斜槓命令）** | https://code.claude.com/docs/en/skills |
| **Claude Code — Hooks** | https://code.claude.com/docs/en/hooks |
| **Claude Code — 子代理** | https://code.claude.com/docs/en/sub-agents |
| **Claude Code — MCP 整合** | https://code.claude.com/docs/en/mcp |
| **Claude Code — GitHub Actions CI/CD** | https://code.claude.com/docs/en/github-actions |
| **Claude Code — GitLab CI/CD** | https://code.claude.com/docs/en/gitlab-ci-cd |
| **Claude Code — 無頭模式（非互動式）** | https://code.claude.com/docs/en/headless |
| **提示工程指南** | https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview |
| **擴充套件思維** | https://platform.claude.com/docs/en/build-with-claude/extended-thinking |
| **Anthropic Cookbook（程式碼範例）** | https://github.com/anthropics/anthropic-cookbook |

---

# 第一部分：理論基礎

本部分涵蓋成功透過考試所需的全部理論知識。內容按技術和概念組織，而非按考試領域劃分——這有助於您對每個主題建立更深入的理解。

---

# 第 1 章：Claude API — 模型互動基礎

> 文件：[Messages API](https://platform.claude.com/docs/en/api/messages) | [提示工程](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview)

## 1.1 API 請求結構

Claude API 遵循請求-回應模型。對 Claude Messages API 的每個請求包含：

```json
{
  "model": "claude-sonnet-4-6",
  "max_tokens": 1024,
  "system": "你是一個有幫助的助手。",
  "messages": [
    {"role": "user", "content": "你好！"},
    {"role": "assistant", "content": "你好！"},
    {"role": "user", "content": "你好嗎？"}
  ],
  "tools": [...],
  "tool_choice": {"type": "auto"}
}
```

**關鍵欄位：**
- `model` — 模型選擇（`claude-opus-4-6`、`claude-sonnet-4-6`、`claude-haiku-4-5`）
- `max_tokens` — 回應中的最大令牌數
- `system` — 系統提示（定義模型行為）
- `messages` — 對話歷史（**必須傳送完整歷史**以保持連貫性）
- `tools` — 可用工具的定義
- `tool_choice` — 工具選擇策略

## 1.2 訊息角色

`messages` 陣列使用三種角色：
- `user` — 使用者訊息
- `assistant` — 模型回應（傳送歷史時包含）
- `tool` — 工具呼叫結果（角色未明確設定；以 `tool_result` 內容塊的形式出現）

**至關重要：** 每次 API 請求都必須傳送**完整的對話歷史**。模型不會在請求之間保持狀態——每次呼叫都是獨立的。

## 1.3 回應中的 `stop_reason` 欄位

Claude API 回應包含 `stop_reason`，表示模型停止生成的原因：

| 值 | 描述 | 操作 |
|---|---|---|
| `"end_turn"` | 模型完成了回應 | 向使用者顯示結果 |
| `"tool_use"` | 模型想要呼叫工具 | 執行工具並回傳結果 |
| `"max_tokens"` | 達到令牌限制 | 回應被截斷；可能需要增加限制 |
| `"stop_sequence"` | 遇到停止序列 | 根據應用程式邏輯處理 |

對於代理系統，`"tool_use"` 和 `"end_turn"` 最為重要——它們控制代理迴圈。

## 1.4 系統提示

系統提示是定義上下文和行為規則的特殊指令。它：
- 不是 `messages` 陣列的一部分；透過 `system` 欄位單獨傳遞
- 優先於使用者訊息
- 一次載入，在整個對話中有效
- 用於定義角色、約束和輸出格式

**考試重點：** 系統提示的措辭可能建立意外的工具關聯。例如，"始終驗證客戶"之類的指令可能導致模型過度使用 `get_customer`，即使在不必要的時候。

## 1.5 上下文視窗

上下文視窗是模型一次可以處理的文字總量（以令牌為單位）。它包括：
- 系統提示
- 完整的訊息歷史
- 工具定義
- 工具結果

**主要上下文視窗問題：**

1. **中間丟失效應：** 模型可靠地處理長輸入開頭和結尾的資訊，但可能遺漏中間的細節。緩解方法：將關鍵資訊放在開頭或結尾附近。

2. **工具結果積累：** 每次工具呼叫都會將輸出新增到上下文中。如果工具回傳 40 多個欄位但只需要 5 個，大部分上下文就被浪費了。

3. **漸進式摘要：** 壓縮歷史時，數值、百分比和日期往往丟失，變成模糊的表達（"大約"、"差不多"、"幾個"）。

---

# 第 2 章：工具與 `tool_use`

> 文件：[Tool Use](https://platform.claude.com/docs/en/build-with-claude/tool-use)

## 2.1 什麼是 `tool_use`

`tool_use` 是允許 Claude 呼叫外部函式的機制。模型不直接執行程式碼——它生成結構化的工具呼叫請求；您的程式碼執行它並回傳結果。

## 2.2 工具定義

每個工具使用 JSON 模式定義：

```json
{
  "name": "get_customer",
  "description": "透過郵箱或 ID 查詢客戶。回傳客戶檔案，包括姓名、郵箱、訂單歷史和帳戶狀態。使用此工具之前請先於 lookup_order 前驗證客戶身份。接受郵箱（格式：user@domain.com）或數字 customer_id。",
  "input_schema": {
    "type": "object",
    "properties": {
      "email": {"type": "string", "description": "客戶郵箱"},
      "customer_id": {"type": "integer", "description": "數字客戶 ID"}
    },
    "required": []
  }
}
```

**工具描述的關鍵要素：**

1. **描述是主要選擇機制。** LLM 根據工具描述選擇工具。最簡描述（"獲取客戶資訊"）在工具重疊時會導致錯誤。

2. **描述中應包含：**
   - 工具的功能和回傳內容
   - 輸入格式和範例值
   - 邊緣情況和約束
   - 何時使用此工具而非類似替代品

3. **避免** 跨工具使用相同或重疊的描述。如果 `analyze_content` 和 `analyze_document` 描述幾乎相同，模型會混淆它們。

4. **內建工具與 MCP 工具：** 代理可能更偏好內建工具（Read、Grep）而非功能類似的 MCP 工具。為防止這種情況，需強化 MCP 工具描述——突出內建工具無法提供的具體優勢、獨特資料或上下文。

## 2.3 `tool_choice` 參數

`tool_choice` 控制模型如何選擇工具：

| 值 | 行為 | 使用時機 |
|---|---|---|
| `{"type": "auto"}` | 模型決定是否呼叫工具或用文字回答 | 大多數情況的預設值 |
| `{"type": "any"}` | 模型**必須**呼叫某個工具 | 需要保證結構化輸出時 |
| `{"type": "tool", "name": "extract_metadata"}` | 模型**必須**呼叫特定工具 | 需要強制第一步/執行順序時 |

**重要場景：**
- `tool_choice: "any"` + 多個提取工具 → 模型選擇最佳工具，但仍能獲得結構化輸出
- 強制選擇 → 需要保證特定首個操作（例如，在豐富之前執行 `extract_metadata`）

## 2.4 結構化輸出的 JSON 模式

使用帶 JSON 模式的 `tool_use` 是從 Claude 獲取結構化輸出的**最可靠**方式。它：
- 保證語法上有效的 JSON（無缺失括號，無尾隨逗號）
- 強制執行所需結構（必填欄位存在）
- **不**保證語義正確性（值仍可能是錯誤的）

**模式設計 — 關鍵原則：**

```json
{
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": ["bug", "feature", "docs", "unclear", "other"]
    },
    "category_detail": {
      "type": ["string", "null"],
      "description": "category = 'other' 或 'unclear' 時的詳情"
    },
    "severity": {
      "type": "string",
      "enum": ["critical", "high", "medium", "low"]
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "optional_field": {
      "type": ["string", "null"],
      "description": "如果在源中未找到資訊則為 Null"
    }
  },
  "required": ["category", "severity"]
}
```

**模式設計規則：**
1. **必填與可選：** 僅當資訊始終可用時才將欄位標記為必填。必填欄位會促使模型在資料缺失時捏造值。
2. **可空欄位：** 對可能缺失的資訊使用 `"type": ["string", "null"]`。模型可以回傳 `null` 而非產生幻覺。
3. **含 `"other"` 的列舉：** 新增 `"other"` + 詳情字串，避免丟失預定義類別之外的資料。
4. **列舉 `"unclear"`：** 用於模型無法自信選擇類別的情況——誠實的 `"unclear"` 優於錯誤的類別。

## 2.5 語法錯誤與語義錯誤

| 錯誤型別 | 範例 | 緩解措施 |
|---|---|---|
| **語法** | 無效 JSON，欄位型別錯誤 | 使用 JSON 模式的 `tool_use`（可消除） |
| **語義** | 合計不符，值在錯誤欄位中，幻覺 | 驗證檢查，帶回饋的重試，自我糾正 |

---

# 第 3 章：Claude Agent SDK — 建構代理系統

> 文件：[Agent SDK](https://platform.claude.com/docs/en/agent-sdk/overview) | [Hooks](https://platform.claude.com/docs/en/agent-sdk/hooks) | [Subagents](https://platform.claude.com/docs/en/agent-sdk/subagents) | [Sessions](https://platform.claude.com/docs/en/agent-sdk/sessions)

## 3.1 什麼是代理迴圈

代理迴圈是自主任務執行的核心模式。模型不只是回答——它執行一系列操作：

```
1. 向 Claude 傳送帶有工具的請求
2. 接收回應
3. 檢查 stop_reason：
   - "tool_use" -> 執行工具，將結果追加到歷史，回傳步驟 1
   - "end_turn" -> 任務完成，向使用者顯示結果
4. 重複直到完成
```

**這是模型驅動的方法：** Claude 根據上下文和先前的工具結果決定下一個要呼叫的工具。這與動作順序固定的 hard-coded 決策樹不同。

**反模式（避免）：**
- 解析助手文字以檢測完成（"任務已完成"）
- 使用任意疊代限制（例如 `max_iterations=5`）作為主要停止條件
- 檢查助手是否產生文字內容作為完成訊號

**正確方法：** 唯一可靠的完成訊號是 `stop_reason == "end_turn"`。

## 3.2 `AgentDefinition` 配置

`AgentDefinition` 是 Claude Agent SDK 中的代理配置物件：

```python
agent = AgentDefinition(
    name="customer_support",
    description="處理客戶的退貨和訂單問題",
    system_prompt="你是一個客戶支援代理...",
    allowed_tools=["get_customer", "lookup_order", "process_refund", "escalate_to_human"],
    # 對於協調代理：
    # allowed_tools=["Task", "get_customer", ...]
)
```

**關鍵參數：**
- `name` / `description` — 代理的標識和描述
- `system_prompt` — 帶指令的系統提示
- `allowed_tools` — 允許的工具列表（最小權限原則）

## 3.3 輪輻式：協調代理與子代理

多代理架構通常建構為輪輻式拓撲：

```
         協調代理
        /     |      \
   子代理1  子代理2  子代理3
   （搜尋）  （分析）  （綜合）
```

**協調代理負責：**
- 將任務分解為子任務
- 決定需要哪些子代理（動態選擇）
- 將工作委派給子代理
- 聚合和驗證結果
- 處理錯誤和重試
- 向使用者傳達結果

**關鍵原則：子代理有隔離的上下文。**
- 子代理**不會**自動繼承協調代理的對話歷史
- 所有必需的上下文必須在子代理提示中**顯式傳遞**
- 子代理不在呼叫之間共享記憶體
- 所有通訊透過協調代理流動（用於可觀察性和錯誤控制）

## 3.4 用於生成子代理的 `Task` 工具

子代理透過 `Task` 工具生成：

```python
# 協調代理的 allowedTools 必須包含 "Task"
coordinator_agent = AgentDefinition(
    allowed_tools=["Task", "get_customer"]
)
```

**顯式上下文傳遞是強制性的：**

```
# 不好：子代理沒有上下文
Task: "分析文件"

# 好：提示中包含完整上下文
Task: "分析以下文件。
文件：[完整文件文字]
先前搜尋結果：[網路搜尋結果]
輸出格式要求：[模式]"
```

**並行生成：** 協調代理可以在一個回應中呼叫多個 `Task`——子代理並行執行：

```
# 一個協調代理回應包含：
Task 1: "搜尋關於 X 的文章"
Task 2: "分析文件 Y"
Task 3: "搜尋關於 Z 的文章"
# 三個同時執行
```

## 3.5 Agent SDK 中的鉤子

鉤子允許在代理生命週期的特定點進行攔截和轉換。

**PostToolUse** 在工具結果提供給模型之前攔截它：

```python
# 範例：規範化來自不同 MCP 工具的日期格式
@hook("PostToolUse")
def normalize_dates(tool_result):
    # 將 Unix 時間戳轉換為 ISO 8601
    # 將 "Mar 5, 2025" 轉換為 "2025-03-05"
    return normalized_result
```

**出站呼叫攔截鉤子**阻止違反策略的操作：

```python
# 範例：阻止超過 500 美元的退款
@hook("PreToolUse")
def enforce_refund_limit(tool_call):
    if tool_call.name == "process_refund" and tool_call.args.amount > 500:
        return redirect_to_escalation(tool_call)
```

**關鍵區別：鉤子與提示指令**

| 屬性 | 鉤子 | 提示指令 |
|---|---|---|
| 保證 | **確定性**（100%） | **機率性**（>90%，非 100%） |
| 使用時機 | 關鍵業務規則、財務操作、合規性 | 一般偏好、建議、格式 |
| 範例 | 阻止 > $500 的退款 | "嘗試先解決再升級" |

**規則：** 當失敗有財務、法律或安全後果時——使用鉤子，而非提示。

# 第 4 章：模型上下文協議（MCP）

> 文件：[MCP](https://modelcontextprotocol.io/) | [工具](https://modelcontextprotocol.io/docs/concepts/tools) | [資源](https://modelcontextprotocol.io/docs/concepts/resources) | [伺服器](https://modelcontextprotocol.io/docs/concepts/servers)

## 4.1 什麼是 MCP

模型上下文協議（MCP）是一種用於將外部系統連線到 Claude 的開放協議。MCP 定義了三種主要資源型別：

1. **工具** — 代理可以呼叫以執行操作的函式（CRUD 操作、API 呼叫、命令執行）
2. **資源** — 代理可以讀取以獲取上下文的資料（文件、資料庫模式、內容目錄）
3. **提示** — 用於常見任務的預定義提示模板

## 4.2 MCP 伺服器

MCP 伺服器是實現 MCP 協議並提供工具/資源的程序。當您連線到 MCP 伺服器時：
- 所有工具都會自動被發現
- 來自所有已連線伺服器的工具同時可用
- 工具描述決定模型將如何使用它們

## 4.3 配置 MCP 伺服器

**專案配置（`.mcp.json`）** — 供團隊使用：

```json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "jira": {
      "command": "npx",
      "args": ["-y", "mcp-server-jira"],
      "env": {
        "JIRA_TOKEN": "${JIRA_TOKEN}"
      }
    }
  }
}
```

**要點：**
- `.mcp.json` 儲存在專案根目錄並透過版本控制進行管理
- 環境變數（`${GITHUB_TOKEN}`）用於儲存金鑰——令牌本身不會被提交
- 所有專案貢獻者均可使用

**使用者配置（`~/.claude.json`）** — 用於個人/實驗性伺服器：
- 儲存在使用者的主目錄中
- 不透過版本控制共享
- 適合個人實驗和測試

**選擇伺服器：**
- 對於標準整合（Jira、GitHub、Slack），優先使用現有的社群 MCP 伺服器
- 僅為獨特的、團隊專屬的工作流建構自己的伺服器

## 4.4 MCP 中的 `isError` 標誌

當 MCP 工具遇到錯誤時，它在回應中使用 `isError: true`。這向代理發出訊號，表明呼叫失敗。

**結構化錯誤（推薦做法）：**

```json
{
  "isError": true,
  "content": {
    "errorCategory": "transient",
    "isRetryable": true,
    "message": "The service is temporarily unavailable. Timeout while calling the orders API.",
    "attempted_query": "order_id=12345",
    "partial_results": null
  }
}
```

**通用錯誤（反模式）：**

```json
{
  "isError": true,
  "content": "Operation failed"
}
```

通用錯誤不為代理提供任何決策資訊——它應該重試、更改查詢還是升級？

## 4.5 MCP 資源

資源是代理可以請求以獲取上下文而無需執行操作的資料：

- 內容目錄（例如，所有專案任務的列表、層級導航）
- 資料庫模式（瞭解資料結構）
- 文件（API 參考、內部指南）
- 問題/任務摘要

**資源優勢：** 代理無需進行探索性工具呼叫即可瞭解存在哪些資料。資源提供了一個即時的"地圖"。

---

# 第 5 章：Claude Code — 配置與工作流

> 文件：[Claude Code](https://code.claude.com/docs/en/overview) | [記憶體 / CLAUDE.md](https://code.claude.com/docs/en/memory) | [技能](https://code.claude.com/docs/en/skills) | [MCP](https://code.claude.com/docs/en/mcp) | [鉤子](https://code.claude.com/docs/en/hooks) | [子代理](https://code.claude.com/docs/en/sub-agents) | [GitHub Actions](https://code.claude.com/docs/en/github-actions) | [無頭模式](https://code.claude.com/docs/en/headless)

## 5.1 CLAUDE.md 層級結構

CLAUDE.md 是 Claude Code 的指令檔案。它有三個層級：

```
1. 使用者級：~/.claude/CLAUDE.md
   - 僅適用於該使用者
   - 不透過版本控制共享
   - 個人偏好和工作風格

2. 專案級：.claude/CLAUDE.md 或根目錄 CLAUDE.md
   - 適用於所有專案貢獻者
   - 透過版本控制管理
   - 編碼標準、測試標準、架構決策

3. 目錄級：子目錄中的 CLAUDE.md
   - 在處理該目錄中的檔案時適用
   - 特定於程式碼庫該部分的約定
```

**常見錯誤：** 新團隊成員未能收到專案指令，因為這些指令被放在了 `~/.claude/CLAUDE.md`（使用者級）而非 `.claude/CLAUDE.md`（專案級）。

## 5.2 `@path` 語法（檔案匯入）

CLAUDE.md 可以使用 `@path` 引用外部檔案，使配置模組化：

```markdown
# 專案 CLAUDE.md

編碼標準詳見 @./standards/coding-style.md
測試要求詳見 @./standards/testing-requirements.md
專案概述詳見 @README.md，依賴項詳見 @package.json
```

**`@path` 規則：**
- 在檔案路徑前緊跟 `@`（無空格）
- 支援相對路徑和絕對路徑
- 相對路徑相對於包含匯入的檔案進行解析
- 最大匯入巢狀深度為 5

這避免了重複，並使每個包只包含相關標準。

## 5.3 `.claude/rules/` 目錄

`.claude/rules/` 是整體式 CLAUDE.md 的替代方案，用於按主題組織規則：

```
.claude/rules/
  testing.md          -- 測試約定
  api-conventions.md  -- API 約定
  deployment.md       -- 部署規則
  react-patterns.md   -- React 模式
```

**關鍵特性：帶 `paths` 的 YAML 前置後設資料用於條件載入：**

```yaml
---
paths: ["src/api/**/*"]
---

對於 API 檔案，使用帶有顯式錯誤處理的 async/await。
每個端點必須回傳標準回應包裝器。
```

```yaml
---
paths: ["**/*.test.tsx", "**/*.test.ts"]
---

測試必須使用 describe/it 塊。
使用資料工廠而非hard-coded。
不要模擬資料庫——使用測試資料庫。
```

**工作原理：**
- 規則**僅**在 Claude Code 編輯與 `paths` 模式匹配的檔案時載入
- 這節省了上下文和令牌——不相關的規則不會被載入
- Glob 模式讓您可以按檔案型別應用約定，而與位置無關（非常適合分散在整個程式碼庫中的測試）

**何時使用帶 `paths` 的 `.claude/rules/` 與目錄級 CLAUDE.md：**
- 帶 `paths` 的 `.claude/rules/` — 當約定適用於分散在多個目錄中的檔案時（測試、遷移）
- 目錄級 CLAUDE.md — 當約定與特定目錄繫結且在其他地方不需要時

## 5.4 自定義斜槓命令與技能

> **注意：** 在當前 Claude Code 版本中，自定義命令（`.claude/commands/`）與技能（`.claude/skills/`）已統一。兩種格式都會建立 `/名稱` 命令。考試指南引用了 `.claude/commands/` — 該格式仍受支援。

斜槓命令是透過 `/名稱` 呼叫的可複用提示模板：

**`.claude/commands/` 格式（舊版，仍受支援）：**

```
.claude/commands/
  review.md        -- /review -- 標準程式碼審查
  test-gen.md      -- /test-gen -- 測試生成
```

**`.claude/skills/` 格式（當前）：**

```
.claude/skills/
  review/SKILL.md  -- /review -- 帶前置後設資料配置
  test-gen/SKILL.md
```

**專案命令**（`.claude/commands/` 或 `.claude/skills/`）：
- 儲存在版本控制中，克隆倉庫時對所有人可用
- 確保團隊內工作流的一致性

**使用者命令**（`~/.claude/commands/` 或 `~/.claude/skills/`）：
- 不透過版本控制共享的個人命令
- 用於個人工作流

## 5.5 技能 — `.claude/skills/`

技能是透過 SKILL.md 前置後設資料配置的高階命令：

```yaml
---
context: fork
allowed-tools: ["Read", "Grep", "Glob"]
argument-hint: "要分析的目錄路徑"
---

分析指定目錄中的程式碼結構。
輸出關於依賴關係和架構模式的報告。
```

**前置後設資料參數：**

| 參數 | 說明 |
|---|---|
| `context: fork` | 在隔離的子代理中執行技能。詳細輸出不會污染主會話 |
| `allowed-tools` | 限制可用的工具（安全性——例如，如果未被允許，技能無法刪除檔案） |
| `argument-hint` | 在不帶參數呼叫時提示輸入參數的提示語 |

**何時使用技能與 CLAUDE.md：**
- **技能** — 按需呼叫以完成特定任務（審查、分析、生成）
- **CLAUDE.md** — 始終載入的通用標準和約定

**個人技能（`~/.claude/skills/`）：**
- 以不同名稱建立個人變體，不影響隊友

## 5.6 規劃模式與直接執行

**規劃模式：**
- 模型僅進行調查和規劃；不進行更改
- 使用 Read、Grep、Glob 探索程式碼庫
- 生成供使用者審批的實施計劃
- 安全探索，無副作用

**何時使用規劃模式：**
- 大規模更改（數十個檔案）
- 存在多種可行方案（微服務：如何定義邊界？）
- 架構決策（選擇哪個框架？什麼結構？）
- 不熟悉的程式碼庫（更改前必須先理解）
- 影響 45 個以上檔案的庫遷移

**何時使用直接執行：**
- 有明確堆疊跟蹤的單檔案修復
- 新增一個驗證檢查
- 已充分理解、無歧義的更改

**組合方法：**
1. 使用規劃模式進行調查和設計
2. 使用者審批計劃
3. 使用直接執行實施已審批的計劃

**探索子代理** — 用於探索程式碼庫的專用子代理：
- 將詳細輸出與主上下文隔離
- 僅回傳摘要
- 防止多階段任務中上下文視窗耗盡

## 5.7 `/compact` 命令

`/compact` 是用於壓縮上下文的內建命令：
- 彙總先前的歷史記錄以釋放上下文視窗
- 用於上下文被大量工具輸出填滿的長時間調查會話
- 風險：精確的數值、日期和具體細節可能在彙總過程中丟失

## 5.8 `/memory` 命令

`/memory` 是用於管理會話間記憶體的內建命令：
- 開啟 `CLAUDE.md` 檔案進行編輯，允許您儲存筆記、偏好設定和上下文
- 資訊在會話間持久儲存，並在啟動時自動載入
- 適用於儲存專案約定、使用者偏好、常用命令和當前工作上下文
- 無需在每個會話中重複說明相同指令的替代方案

## 5.9 用於 CI/CD 的 Claude Code CLI

**`-p`（或 `--print`）標誌：**

```bash
claude -p "Analyze this pull request for security issues"
```

- 非互動式模式：處理提示，列印到標準輸出，然後退出
- 不等待使用者輸入
- 在 CI/CD 管線中執行 Claude 的唯一正確方式

**用於 CI 的結構化輸出：**

```bash
claude -p "Review this PR" --output-format json --json-schema '{"type":"object",...}'
```

- `--output-format json` — 以 JSON 格式輸出
- `--json-schema` — 根據模式驗證輸出
- 結果可被解析以自動釋出內聯 PR 評論

**會話上下文隔離：**
生成程式碼的同一 Claude 會話在審查該程式碼時通常效果較差（模型保留了其推理上下文，不太可能質疑自己的決策）。使用獨立例項進行審查。

**防止重複評論：**
在新提交後重新審查時，將之前的審查結果包含在上下文中，並指示 Claude 僅報告新問題或未解決的問題。

## 5.10 `fork_session` 與會話管理

**`--resume <session-name>`** 恢復命名會話：

```bash
claude --resume investigation-auth-bug
```

- 繼續之前儲存上下文的對話
- 適用於跨多個會話的長期調查
- 風險：如果自上次會話以來檔案已更改，工具結果可能已過時

**`fork_session`** 從共享上下文建立獨立分支：

```
程式碼庫調查
         |
    fork_session
    /           \
方法 A：         方法 B：
Redux           Context API
```

- 兩個分支繼承分支點之前的上下文
- 之後，它們獨立分叉
- 適用於比較方法或測試策略

**何時啟動新會話而非恢復：**
- 工具結果已過時（檔案已更改）
- 已過很長時間，上下文已降級
- 以"以下是我們發現的簡短摘要：..."重新開始，比用舊工具資料恢復更可靠

---

# 第6章：提示工程——高階技巧

> 文件：[提示工程](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/overview) | [Anthropic Cookbook](https://github.com/anthropics/anthropic-cookbook)

## 6.1 少樣本提示

少樣本提示是在提示中包含2–4個輸入/輸出範例，以演示預期行為。

**為什麼少樣本比文字描述更有效：**
- "更精確"之類的模糊指令可以有多種解讀方式
- 範例能明確展示預期格式和決策邏輯
- 模型將模式泛化到新情況（而不僅僅是重複範例）

**少樣本範例的型別及使用時機：**

1. **針對模糊場景的範例：**

```
請求："我的訂單壞了"
動作：呼叫 get_customer -> lookup_order -> check status。
理由："壞了"可能指商品損壞；需要訂單詳情。

請求："幫我找個經理"
動作：立即呼叫 escalate_to_human。
理由：客戶明確要求人工服務。不要嘗試自主解決。
```

2. **針對輸出格式的範例：**

```
發現範例：
{
  "location": "src/auth/login.ts:42",
  "issue": "使用者名稱參數中存在SQL隱碼攻擊",
  "severity": "critical",
  "suggested_fix": "使用參數化查詢"
}
```

3. **區分可接受程式碼與問題程式碼的範例：**

```
// 可接受（不標記）：
const items = data.filter(x => x.active);

// 問題（標記）：
const items = data.filter(x => x.active == true); // 使用嚴格相等 ===
```

4. **從不同文件格式中提取的範例：**

```
帶內聯引用的文件：
"如研究所示（Smith, 2023），比率為42%。"
-> {"value": "42%", "source": "Smith, 2023", "type": "inline_citation"}

帶參考書目引用的文件：
"比率為42%。[1]"
-> {"value": "42%", "source": "reference_1", "type": "bibliography"}
```

5. **非正式計量的範例：**

```
文字："大約兩把米"
-> {"amount": "~100g", "original_text": "兩把", "precision": "approximate"}

文字："一撮鹽"
-> {"amount": "~1g", "original_text": "一撮", "precision": "approximate"}
```

少樣本對於提取非正式和非標準計量單位尤其有效，因為這些單位種類繁多，純粹基於規則的指令難以覆蓋。

**提示中的格式規範化規則：**
當使用嚴格的JSON模式進行結構化輸出時，在提示中新增規範化規則：

```
規範化：
- 日期：始終使用ISO 8601（YYYY-MM-DD）；"昨天" -> 計算絕對日期
- 貨幣：數字金額+貨幣程式碼；"五塊錢" -> {"amount": 5, "currency": "CNY"}
- 百分比：小數形式；"一半" -> 0.5
```

這可以防止JSON語法有效但值不一致的語義錯誤。

## 6.2 明確標準與模糊指令

**差（模糊）：**

```
檢查程式碼註釋的準確性。
保守一點——只報告高置信度的發現。
```

**好（明確標準）：**

```
僅在以下情況下將註釋標記為有問題：
1. 註釋描述的行為與實際程式碼行為相矛盾
2. 註釋引用了不存在的函式或變數
3. TODO/FIXME註釋所指的bug已在程式碼中修復

不要標記：
- 僅在風格上過時的註釋
- 措辭輕微不準確的註釋
- 缺失的註釋（這是單獨的類別）
```

**用範例定義嚴重性標準：**

```
嚴重：使用者執行時失敗
  範例：處理付款時出現NullPointerException

高：安全漏洞
  範例：SQL隱碼攻擊、XSS、缺少授權檢查

中：無即時影響的邏輯bug
  範例：排序錯誤、差一錯誤

低：程式碼品質
  範例：重複程式碼、小資料量的次優演算法
```

## 6.3 提示鏈

提示鏈將複雜任務分解為一系列聚焦的步驟：

```
步驟1：分析 auth.ts（僅本地問題）
       -> 輸出：auth.ts中的問題列表

步驟2：分析 database.ts（僅本地問題）
       -> 輸出：database.ts中的問題列表

步驟3：整合檢查（跨檔案依賴）
       -> 輸出：模組邊界處的問題
```

**為什麼重要：**
- 避免**注意力稀釋**——當模型同時接收太多檔案時，可能會遺漏某些檔案中的bug，同時對其他檔案只進行淺層評論
- 確保每個檔案的分析品質一致
- 允許單獨分析跨檔案互動

**何時使用提示鏈與動態分解：**
- **提示鏈** — 可預測、可重複的任務（程式碼審查、檔案遷移）
- **動態分解** — 開放式調查，子任務在執行過程中才變得清晰

## 6.4 "訪談"模式

在實施解決方案之前，Claude提出澄清問題：

```
Claude："在為API實現快取之前，有幾個問題：
1. 您偏好哪種快取失效策略——TTL還是基於事件？
2. 當快取不可用時，過時資料是否可以接受？
3. 快取應該是按使用者還是全域的？
4. 預期快取的資料量是多少？"
```

**何時有用：**
- 陌生領域（金融科技、醫療、法律系統）
- 有非顯而易見影響的任務（快取策略、故障模式）
- 存在多種可行方案，最佳選擇取決於上下文

## 6.5 驗證與帶回饋的重試

當提取的資料驗證失敗時：

```
步驟1：從文件中提取資料
步驟2：驗證（Pydantic、JSON Schema、業務規則）
步驟3：如果有錯誤——帶上下文重試：
  - 原始文件
  - 之前（錯誤的）提取結果
  - 具體錯誤："欄位'total' = 150，但 sum(line_items) = 145。請重新檢查值。"
```

**重試有效的情況：**
- 格式錯誤（日期格式不正確）
- 結構錯誤（欄位放置位置錯誤）
- 算術不一致（模型可以重新檢查）

**重試無效的情況：**
- 源文件中不存在該資訊
- 所需上下文是外部的（資料在另一個未提供的文件中）

**Pydantic作為驗證工具：**
Pydantic是一個用於基於模式的資料驗證的Python庫。對於考試，關鍵點是：
- **結構驗證：** 在從Claude接收JSON後，在程式碼中檢查型別、必填項、列舉約束
- **語義驗證：** 自定義驗證器強制執產業務邏輯（條目總和等於合計；start_date < end_date）
- **驗證-重試迴圈：** 在Pydantic驗證失敗時，建構錯誤訊息並帶錯誤上下文重新提示Claude
- **JSON Schema生成：** Pydantic模型可以為`tool_use`生成JSON Schema，提供單一事實來源

## 6.6 自我糾正

檢測內部矛盾的模式：

```json
{
  "stated_total": "$150.00",
  "calculated_total": "$145.00",
  "conflict_detected": true,
  "line_items": [
    {"name": "Widget A", "price": 75.00},
    {"name": "Widget B", "price": 70.00}
  ]
}
```

模型同時提取宣告值和計算值——如果兩者不同，`conflict_detected`允許您處理差異。

---

# 第7章：訊息批處理API

> 文件：[訊息批處理](https://platform.claude.com/docs/en/build-with-claude/message-batches)

## 7.1 概述

訊息批處理API允許您提交批次請求進行非同步處理：

| 屬性 | 值 |
|---|---|
| 節省 | 與同步呼叫相比節省**50%** |
| 處理視窗 | 最長**24小時**（無延遲SLA保證） |
| 多輪工具呼叫 | **不支援**（一個請求=一個回應） |
| 關聯 | `custom_id`欄位用於關聯請求和回應 |

## 7.2 何時使用批處理API與同步API

| 任務 | API | 原因 |
|---|---|---|
| 合併前PR檢查 | **同步** | 開發者在等待；24小時不可接受 |
| 隔夜技術債務報告 | **批處理** | 早上需要結果；節省50% |
| 每週安全審計 | **批處理** | 不緊急；節省50% |
| 互動式程式碼審查 | **同步** | 需要立即回應 |
| 處理10,000個文件 | **批處理** | 批次處理；節省顯著 |

## 7.3 使用 `custom_id`

```json
{
  "custom_id": "doc-invoice-2024-001",
  "params": {
    "model": "claude-sonnet-4-6",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "從以下內容提取資料：..."}]
  }
}
```

`custom_id` 允許您：
- 將結果關聯到原始文件
- 在失敗時，僅重新提交失敗的文件
- 避免重新處理成功的文件

## 7.4 處理批處理中的失敗

1. 提交100個文件的批次
2. 95個成功；5個失敗（超出上下文限制）
3. 透過`custom_id`識別失敗項
4. 修改策略（例如，將長文件分割成塊）
5. 僅重新提交5個失敗的文件

## 7.5 SLA規劃

如果您需要在30小時內得到結果，而批處理API最長需要24小時：
- 提交視窗：30 - 24 = **6小時**
- 批次必須在截止時間前至少24小時提交
- 對於頻繁提交，分割為4小時視窗

---

# 第8章：任務分解策略

## 8.1 固定管線（提示鏈）

每個步驟都預先定義：

```
文件 -> 後設資料提取 -> 資料提取 -> 驗證 -> 富化 -> 最終輸出
```

**何時使用：**
- 任務結構可預測（評審始終遵循相同模板）
- 所有步驟預先已知
- 需要穩定性和可重複性

## 8.2 動態自適應分解

子任務根據中間結果生成：

```
1. "為遺留程式碼庫新增測試"
2. -> 首先：對映結構（Glob、Grep）
3. -> 發現：3個模組無測試，2個覆蓋率不完整
4. -> 優先順序：從支付模組開始（高風險）
5. -> 工作中：發現依賴外部API
6. -> 適應：在編寫測試前為外部API新增mock
```

**何時使用：**
- 開放式調查任務
- 全部範圍事先未知
- 每個步驟依賴前一步驟的結果

## 8.3 多輪程式碼審查

對於包含10個以上檔案的拉取請求：

```
第1輪（逐檔案）：分析 auth.ts -> 列出本地問題
第1輪（逐檔案）：分析 database.ts -> 列出本地問題
第1輪（逐檔案）：分析 routes.ts -> 列出本地問題
...
第2輪（整合）：分析檔案間關係
  -> 跨檔案問題：型別不一致、迴圈依賴
```

**為什麼對14個檔案進行單輪分析效果差：**
- 注意力稀釋：對某些檔案深度分析，對其他檔案淺層分析
- 評論不一致：某個模式在一個檔案中被標記，在另一個檔案中被批准
- 遺漏bug：由於認知過載，明顯錯誤被跳過

---

# 第9章：升級與人工參與

## 9.1 何時升級到人工

**升級觸發條件（明確規則）：**

| 情況 | 動作 |
|---|---|
| 客戶明確要求"幫我找個經理" | 立即升級；不要嘗試解決 |
| 政策未涵蓋該請求 | 升級（例如，政策未規定競爭對手價格匹配） |
| 代理無法取得進展 | 在合理次數嘗試後升級 |
| 財務操作超過閾值 | 升級（最好透過鉤子而非提示強制執行） |
| 搜尋客戶時出現多個匹配 | 請求額外識別符號；不要猜測 |

**不可靠的觸發條件：**

| 不可靠方法 | 失敗原因 |
|---|---|
| 情感分析 | 客戶情緒與案例複雜度不相關 |
| 模型自評置信度（1–10） | 模型可能自信地犯錯；校準效果差 |
| 自動分類器 | 過度工程化；可能需要您沒有的訓練資料 |

## 9.2 升級模式

**立即升級：**

```
客戶："我想和經理談"
代理：[立即呼叫 escalate_to_human]
不應該："我可以幫您解決問題，讓我..."
```

**嘗試解決後升級：**

```
客戶："我的冰箱購買兩天後壞了"
代理：[檢查訂單，提供保修更換]
如果客戶不滿意 -> 升級
```

**細緻的升級（承認 → 解決 → 重申時升級）：**

```
客戶："太過分了，我對品質非常不滿意！"
代理：[承認不滿] "我理解您的不滿。"
       [提供解決方案] "我可以提供更換或退款。"
客戶："不，我要和人說話！"
代理：[客戶再次堅持 -> 立即升級]
```

關鍵原則：先承認情緒，然後提出具體解決方案，只有當客戶再次表達想要人工服務時才升級。不要在第一次表達不滿時就升級（這與請求經理不同）。

**因政策缺口升級：**

```
客戶："競爭對手X的這件商品便宜30%——給我打折"
政策：僅涵蓋本網站的價格調整
代理：[升級——政策未涵蓋競爭對手價格匹配]
```

## 9.3 結構化交接協議

升級時，代理應向人工傳遞結構化摘要：

```json
{
  "customer_id": "CUST-12345",
  "customer_name": "張三",
  "issue_summary": "損壞商品的退款請求",
  "order_id": "ORD-67890",
  "root_cause": "商品到貨時損壞；已附照片",
  "actions_taken": [
    "透過 get_customer 驗證客戶",
    "透過 lookup_order 確認訂單",
    "提供標準更換——客戶堅持要求退款"
  ],
  "refund_amount": "$89.99",
  "recommended_action": "批准全額退款",
  "escalation_reason": "客戶要求與經理交談"
}
```

人工操作員無法訪問完整的對話記錄——他們只看到這份摘要。因此摘要必須完整且自包含。

## 9.4 置信度校準與人工監督

對於資料提取系統：

1. **欄位級置信度評分：** 模型為每個提取欄位輸出置信度評分
2. **校準：** 使用標記的驗證集來調整閾值
3. **路由：**
   - 高置信度+穩定準確率 -> 自動處理
   - 低置信度或來源模糊 -> 人工審查

**分層隨機抽樣：**
- 即使對於高置信度提取，也要定期審計樣本
- 整體97%的準確率可能掩蓋某種文件型別40%的錯誤
- 按文件型別和欄位分析準確率，而不僅僅是整體分析

---

# 第10章：多代理系統中的錯誤處理

## 10.1 錯誤類別

| 類別 | 範例 | 可重試 | 代理動作 |
|---|---|---|---|
| **瞬態** | 超時、503、網路故障 | 是 | 使用指數退避重試 |
| **驗證** | 輸入格式無效、缺少必填欄位 | 否（修復輸入） | 修改請求後重試 |
| **業務** | 違反政策、超過閾值 | 否 | 向使用者解釋；提出替代方案 |
| **權限** | 拒絕訪問 | 否 | 升級 |

## 10.2 錯誤處理反模式

| 反模式 | 問題 | 正確方法 |
|---|---|---|
| 通用狀態"搜尋不可用" | 協調代理無法決定如何恢復 | 回傳錯誤型別、查詢、部分結果、替代方案 |
| 靜默抑制（空結果=成功） | 協調代理認為沒有匹配，但實際是失敗 | 區分"無結果"與"搜尋失敗" |
| 單個失敗時中止整個工作流 | 丟失所有部分結果 | 繼續使用部分結果；註釋缺口 |
| 子代理內無限重試 | 延遲和資源浪費 | 本地恢復（1–2次重試），然後傳遞給協調代理 |

## 10.3 結構化子代理錯誤

```json
{
  "status": "partial_failure",
  "failure_type": "timeout",
  "attempted_query": "AI對音樂產業的影響2024",
  "partial_results": [
    {"title": "AI音樂生成報告", "url": "...", "relevance": 0.8}
  ],
  "alternative_approaches": [
    "嘗試更窄的查詢：'AI音樂創作工具'",
    "使用替代資料來源"
  ],
  "coverage_impact": "未覆蓋：AI對音樂製作的影響"
}
```

這為協調代理提供了決策所需的資訊：
- 用修改後的查詢重試？
- 使用部分結果？
- 委託給不同的子代理？
- 繼續而不包含此部分並註釋缺口？

## 10.4 最終綜合中的覆蓋註釋

```markdown
## 報告：AI對創意產業的影響

### 視覺藝術（完整覆蓋）
[研究結果]

### 音樂（部分覆蓋——搜尋代理超時）
[部分結果]
⚠️ 注意：由於搜尋代理超時，本節覆蓋範圍有限。

### 文學（完整覆蓋）
[研究結果]
```

---

# 第11章：生產系統中的上下文管理

## 11.1 將關鍵事實提取到獨立塊中

與其依賴對話歷史（摘要過程中會退化），不如將關鍵事實提取到結構化塊中：

```
=== 案例事實（每次出現新事實時更新）===
客戶ID：CUST-12345
訂單ID：ORD-67890
訂單日期：2025-01-15
訂單金額：$89.99
問題：交貨時商品損壞
客戶要求：全額退款
狀態：待經理審批
===
```

無論歷史記錄如何被摘要，都應在每個提示詞中包含此塊。

## 11.2 裁剪工具回傳結果

如果 `lookup_order` 回傳40+個欄位，但當前任務只需要其中5個：

```python
# PostToolUse鉤子：只保留相關欄位
@hook("PostToolUse", tool="lookup_order")
def trim_order_fields(result):
    return {
        "order_id": result["order_id"],
        "status": result["status"],
        "total": result["total"],
        "items": result["items"],
        "return_eligible": result["return_eligible"]
    }
```

這能節省上下文空間並減少噪音。

## 11.3 位置感知的輸入

在編寫輸入時，應考慮"中間迷失"效應，將關鍵資訊放在適當位置：

```
[關鍵發現——置於頂部]
發現3個嚴重漏洞...

[詳細結果——置於中間]
=== 檔案 auth.ts ===
...
=== 檔案 database.ts ===
...

[行動項——置於末尾]
優先順序：在合併前修復 auth.ts 中的漏洞。
```

## 11.4 草稿檔案

在長時間調查中，代理可以將關鍵發現寫入草稿檔案：

```
# investigation-scratchpad.md
## 關鍵發現
- src/payments/processor.ts 中的 PaymentProcessor 繼承自 BaseProcessor
- refund() 在3處被呼叫：OrderController、AdminPanel、CronJob
- 外部 PaymentGateway API 的速率限制為每分鐘100次請求
- 遷移#47 新增了 refund_reason（NOT NULL）——2024-12-01
```

當上下文退化（或在新會話中），代理可以查閱草稿檔案，而無需重新執行發現流程。

## 11.5 委託子代理以保護上下文

```
主代理："調查支付模組的依賴關係"
  -> 子代理（探索）：讀取15個檔案，追蹤匯入
  -> 回傳："支付依賴於 AuthService、OrderModel 和外部 PaymentGateway API"

主代理：在上下文中只保留一行，而非15個檔案
```

**獨立上下文層：**
在多代理系統中，每個子代理在有限的上下文預算內執行——它只接收完成任務所需的資訊。協調者充當獨立的上下文層：彙總子代理輸出、儲存全域狀態並分配上下文。這可以防止"上下文洩漏"——即一個代理用與其他代理無關的資訊消耗掉整個視窗。

**為子代理設定受限上下文預算：**
- 傳送最小化上下文：一個具體任務+必要資料
- 指示子代理回傳結構化結果，而非原始資料轉儲
- 使用 `allowedTools` 限制子代理的工具集——工具越少意味著干擾越少，上下文成本越低

## 11.6 結構化狀態持久化（用於崩潰恢復）

每個代理將其狀態匯出到已知位置：

```json
// agent-state/web-search-agent.json
{
  "status": "completed",
  "queries_executed": ["AI music 2024", "AI music composition"],
  "results_count": 12,
  "key_findings": [...],
  "coverage": ["music composition", "music production"],
  "gaps": ["music distribution", "music licensing"]
}
```

協調者在恢復時載入清單：

```json
// agent-state/manifest.json
{
  "web-search": "completed",
  "doc-analysis": "in_progress",
  "synthesis": "not_started"
}
```

---

# 第12章：儲存溯源資訊

## 12.1 歸因丟失問題

在彙總多個來源的結果時，"宣告→來源"的關聯可能會丟失：

```
差：" AI音樂市場估值為32億美元。"（無來源，無年份。）

好：
{
  "claim": "AI音樂市場估值為32億美元。",
  "source_url": "https://example.com/report",
  "source_name": "2024全球AI音樂報告",
  "publication_date": "2024-06-15",
  "confidence": 0.9
}
```

## 12.2 處理衝突資料

當兩個來源提供不同的數值時：

```json
{
  "claim": "AI生成音樂在流媒體平臺的佔比",
  "values": [
    {
      "value": "12%",
      "source": "Spotify 2024年度報告",
      "date": "2024-03",
      "methodology": "自動分類"
    },
    {
      "value": "8%",
      "source": "音樂產業協會調查",
      "date": "2024-07",
      "methodology": "500家廠牌調查"
    }
  ],
  "conflict_detected": true,
  "possible_explanation": "方法論和時間段不同"
}
```

不要隨意選擇其中一個數值。保留兩者並註明歸因，讓協調者來做決定。

## 12.3 包含日期以便正確解讀

沒有日期，時間差異可能被誤解為矛盾：

```
差："來源A顯示10%，來源B顯示15%。存在矛盾。"
好："來源A（2023）顯示10%，來源B（2024）顯示15%。可能是一年增長了5%。"
```

## 12.4 按內容型別渲染

不要將所有內容強制放入一種格式：
- 財務資料 -> 表格
- 新聞和分析 -> 散文
- 技術發現 -> 結構化列表
- 時間序列 -> 按時間順序排列

---

# 第13章：Claude Code內建工具

## 13.1 工具選擇參考

| 任務 | 工具 | 範例 |
|---|---|---|
| 按名稱/模式查詢檔案 | **Glob** | `**/*.test.tsx`, `src/components/**/*.ts` |
| 在檔案內搜尋 | **Grep** | 函式名、錯誤資訊、匯入 |
| 完整讀取檔案 | **Read** | 載入檔案進行分析 |
| 寫入新檔案 | **Write** | 從頭建立檔案 |
| 精確編輯現有檔案 | **Edit** | 透過唯一文字匹配替換特定片段 |
| 執行Shell命令 | **Bash** | git、npm、執行測試、建構 |

## 13.2 漸進式調查策略

不要一次性讀取所有檔案。漸進式建立理解：

```
1. Grep：查詢入口點（函式定義、匯出）
2. Read：讀取找到的檔案
3. Grep：查詢用法（匯入、呼叫）
4. Read：讀取消費者檔案
5. 重複直到獲得完整圖景
```

## 13.3 備用方案：用Read+Write替代Edit

當Edit因文字匹配不唯一而失敗時：
1. Read——載入完整檔案內容
2. 以程式設計方式修改內容
3. Write——寫入更新後的版本

---

# 第二部分：考試領域註釋

---

# 領域1：代理架構與編排（27%）

## 1.1 為自主任務執行設計代理迴圈

### 關鍵知識：
- 代理迴圈生命週期：傳送Claude請求，檢查 `stop_reason`（`"tool_use"` vs `"end_turn"`），執行工具，回傳結果進入下一次疊代
- 工具結果被追加到對話歷史中，以便模型決定下一步行動
- 模型驅動的決策（Claude選擇下一個工具）vs hard-coded 決策樹

### 關鍵技能：
- 流程控制：當 `stop_reason = "tool_use"` 時繼續迴圈，在 `"end_turn"` 時停止
- 在疊代之間將工具結果追加到上下文中
- 需避免的反模式：解析助手文字以判斷完成，將任意疊代次數限制作為主要停止機制

## 1.2 編排多代理系統（協調者-子代理）

### 關鍵知識：
- 中心輻射架構：協調者負責所有代理間通訊、錯誤處理和路由
- 子代理在隔離的上下文中執行——它們不會自動繼承協調者的歷史記錄
- 協調者職責：任務分解、委派、結果彙總、動態選擇子代理
- 協調者分解過於狹窄的風險

### 關鍵技能：
- 在子代理之間分配研究覆蓋範圍以最小化重複
- 實現疊代細化迴圈（協調者評估綜合結果並重新路由任務）
- 透過協調者路由所有通訊以保證可觀測性

## 1.3 配置子代理呼叫、上下文傳遞和生成

### 關鍵知識：
- `Task` 工具生成子代理；協調者的 `allowedTools` 必須包含 `"Task"`
- 子代理上下文必須在提示詞中明確包含；子代理不繼承父上下文
- `AgentDefinition` 配置：描述、系統提示詞、工具約束
- 透過 `fork_session` 進行會話管理以探索替代方案

### 關鍵技能：
- 在子代理提示詞中包含先前代理的完整輸出
- 使用結構化格式在傳遞上下文時分離資料和後設資料
- 透過在協調者的單個輪次中進行多次 `Task` 呼叫來生成並行子代理
- 用目標和品質標準而非逐步指令來編寫協調者提示詞

## 1.4 實現帶有強制執行和交接模式的多步驟工作流

### 關鍵知識：
- **程式化強制執行**（鉤子、前提條件）和**提示詞指導**在工作流排序上的區別
- 當需要確定性保證時（例如，金融操作前的身份驗證），僅靠提示詞是不夠的
- 升級時的結構化交接協議（客戶ID、原因、推薦操作）

### 關鍵技能：
- 在先前步驟完成之前阻止下游呼叫的程式化前提條件（例如，在 `get_customer` 回傳經過驗證的ID之前阻止 `process_refund`）
- 將多方面的客戶請求分解為獨立項
- 升級到人工時產生結構化摘要

## 1.5 用於攔截工具呼叫和規範化資料的代理SDK鉤子

### 關鍵知識：
- 鉤子模式（例如 `PostToolUse`）在模型消費工具結果之前攔截它們
- 攔截出站呼叫的鉤子以強制執行合規規則（例如，阻止超過閾值的退款）
- 鉤子提供**確定性保證**，而提示詞指令提供**機率性合規**

### 關鍵技能：
- `PostToolUse` 鉤子用於規範化資料格式（Unix時間戳、ISO 8601、數字狀態碼）
- 攔截鉤子以阻止違反策略的操作並重定向到升級
- 當業務規則需要保證合規時，選擇鉤子而非提示詞

## 1.6 複雜工作流的任務分解策略

### 關鍵知識：
- **固定管線**（提示詞鏈）vs 基於中間結果的**動態自適應分解**
- 提示詞鏈：順序步驟（分別分析每個檔案，然後執行整合檢查）
- 根據發現的內容生成子任務的自適應調查計劃

### 關鍵技能：
- 對可預測的多方面審查使用提示詞鏈；對開放式調查使用動態分解
- 將大型程式碼審查拆分為每檔案分析加上獨立的跨檔案整合檢查
- 分解開放式任務：先對映結構，再建構優先計劃

## 1.7 會話狀態、恢復和分叉

### 關鍵知識：
- `--resume <session-name>` 用於繼續命名會話
- `fork_session` 從共享上下文建立獨立的調查分支
- 恢復會話時告知代理檔案變更的重要性
- 包含結構化摘要的新會話比恢復過時結果的會話更可靠

### 關鍵技能：
- 使用 `--resume` 繼續命名調查會話
- 使用 `fork_session` 並行比較不同方法
- 在恢復（上下文仍為最新）和開始新會話（結果過時）之間做出選擇

---

# 領域2：工具設計與MCP整合（18%）

## 2.1 設計具有清晰描述的工具介面

### 關鍵知識：
- 工具描述是LLM選擇工具的**主要機制**；最簡描述會導致選擇不可靠
- 包含輸入格式、範例查詢、邊緣情況和適用邊界的重要性
- 模糊或重疊的描述會導致路由錯誤
- 系統提示詞的措辭可能與工具產生意外關聯

### 關鍵技能：
- 編寫能清楚區分每個工具與類似替代品的描述
- 重新命名工具以消除功能重疊（例如，`analyze_content` -> `extract_web_results`）
- 將通用工具拆分為具有清晰輸入/輸出合約的專用工具

## 2.2 為MCP工具實現結構化錯誤回應

### 關鍵知識：
- MCP工具回應中的 `isError` 標誌
- **瞬時錯誤**（超時）、**驗證錯誤**（錯誤輸入）、**業務錯誤**（策略違規）和**訪問/權限錯誤**之間的區別
- 通用錯誤（"操作失敗"）阻止正確的恢復決策
- 可重試和不可重試錯誤之間的區別

### 關鍵技能：
- 回傳結構化後設資料，如 `errorCategory`（瞬時/驗證/權限）、`isRetryable` 和人類可讀的訊息
- 對業務規則違規使用 `retryable: false`，並提供清晰的面向使用者的解釋
- 在子代理內對瞬時失敗進行本地恢復；僅傳播無法解決的錯誤
- 區分訪問失敗（重試決策）和有效的空結果（無匹配）

## 2.3 跨代理分配工具並配置 `tool_choice`

### 關鍵知識：
- 每個代理工具過多（例如18個而非4-5個）**會降低**工具選擇的可靠性
- 擁有超出其專業範圍工具的代理往往會誤用這些工具
- 作用域工具訪問：僅角色相關工具加上有限的跨角色實用工具集
- `tool_choice`：`"auto"`、`"any"` 和強制工具選擇（`{"type": "tool", "name": "..."}`）

### 關鍵技能：
- 將每個子代理的工具集限制在其角色相關的範圍內
- 用受約束的替代品替換通用工具（例如，`fetch_url` -> `load_document`）
- 使用 `tool_choice: "any"` 保證工具呼叫而非文字回答
- 強制特定工具以確保執行順序

## 2.4 將MCP伺服器整合到Claude Code和代理工作流中

### 關鍵知識：
- MCP伺服器作用域：專案（`.mcp.json`）用於團隊 vs 使用者（`~/.claude.json`）用於實驗
- `.mcp.json` 中的環境變數替換（例如，`${GITHUB_TOKEN}`）用於金鑰管理
- 所有連線的MCP伺服器的工具在連線時被發現，同時可用
- MCP資源作為"內容目錄"（任務摘要、資料庫模式）以減少探索性工具呼叫

### 關鍵技能：
- 在專案 `.mcp.json` 中使用基於環境變數的令牌配置共享MCP伺服器
- 在 `~/.claude.json` 中儲存個人/實驗性伺服器
- 對標準整合優先使用社群MCP伺服器而非自定義伺服器

## 2.5 選擇和應用內建工具（Read、Write、Edit、Bash、Grep、Glob）

### 關鍵知識：
- **Grep**：在檔案內容中搜尋（函式名、錯誤訊息、匯入）
- **Glob**：按名稱/副檔名模式查詢檔案
- **Read/Write**：全檔案操作；**Edit**：透過唯一文字匹配進行精確修改
- 如果Edit因非唯一匹配而失敗，則退回到Read + Write

### 關鍵技能：
- 使用Grep進行內容搜尋，使用Glob按模式進行檔案發現
- 漸進式建立理解：Grep入口點，然後Read追蹤流程
- 透過包裝模組追蹤函式用法

---

# 領域3：Claude Code配置與工作流（20%）

## 3.1 配置具有層次結構、作用域和模組化組織的CLAUDE.md

### 關鍵知識：
- CLAUDE.md層次結構：使用者（`~/.claude/CLAUDE.md`）、專案（`.claude/CLAUDE.md` 或根目錄 `CLAUDE.md`）和目錄級（子目錄中的CLAUDE.md）
- 使用者級設定僅適用於一個使用者，不透過版本控制系統共享
- 引用外部檔案的 `@path` 語法（例如，`@./standards/coding-style.md`）用於模組化CLAUDE.md
- 用於主題聚焦規則檔案的 `.claude/rules/` 目錄，而非單一的CLAUDE.md

### 關鍵技能：
- 診斷層次結構問題（新團隊成員因指令位於使用者級而非專案級而遺漏了指令）
- 使用 `@path`（例如，`@./standards/testing.md`）在每個包的CLAUDE.md中有選擇地包含標準
- 將大型CLAUDE.md拆分為多個 `.claude/rules/` 檔案（testing.md、api-conventions.md、deployment.md）

## 3.2 建立和配置自定義斜槓命令與技能

### 關鍵知識：
- `.claude/commands/` 中的**專案命令**（透過版本控制系統共享）vs `~/.claude/commands/` 中的**使用者命令**
- `.claude/skills/` 中的技能，帶有 `SKILL.md` 前置內容：`context: fork`、`allowed-tools`、`argument-hint`
- `context: fork` 在隔離的子代理上下文中執行技能，不污染主會話
- 個人技能變體可以以不同名稱儲存在 `~/.claude/skills/` 中

### 關鍵技能：
- 在 `.claude/commands/` 中儲存專案斜槓命令，以便整個團隊都能使用
- 使用 `context: fork` 隔離具有詳細輸出的技能
- 使用 `allowed-tools` 限制技能可以使用的工具
- 使用 `argument-hint` 提示開發者輸入必要參數

## 3.3 使用路徑特定規則進行條件約定載入

### 關鍵知識：
- `.claude/rules/` 檔案可以包含YAML前置內容中的 `paths`，以根據glob模式啟用規則
- 路徑作用域規則**僅**在編輯匹配檔案時載入，節省上下文和令牌
- 當約定跨越多個目錄時（例如測試），基於glob的路徑規則比目錄級CLAUDE.md更優

### 關鍵技能：
- 建立帶有 `paths: ["terraform/**/*"]` 的 `.claude/rules/` 檔案，僅在處理匹配檔案時載入
- 使用glob模式（`**/*.test.tsx`）按檔案型別應用約定，不受位置限制
- 當約定跨越程式碼庫時，優先使用路徑特定規則而非目錄級CLAUDE.md

## 3.4 決定何時使用規劃模式vs直接執行

### 關鍵知識：
- **規劃模式**：用於變更量大、有多種可行方案和架構決策的複雜任務
- **直接執行**：用於簡單、易於理解的變更（例如，新增單個驗證）
- 規劃模式可在進行修改前安全探索程式碼庫
- 探索子代理隔離詳細的發現輸出

### 關鍵技能：
- 對具有架構影響的任務使用規劃模式（微服務、涉及45+檔案的遷移）
- 對有清晰堆疊跟蹤和單個檔案的修復使用直接執行
- 使用探索子代理防止多階段任務中的上下文視窗耗盡
- 結合兩種方法：規劃用於發現，執行用於實現

## 3.5 漸進式細化以持續改進

### 關鍵知識：
- 具體的輸入/輸出範例是傳達期望最有效的方式
- **測試驅動疊代**：先寫測試，然後根據失敗進行疊代
- "訪談"模式：Claude提問以發現非顯而易見的設計考量
- 何時在一條訊息中提供所有問題（相互依賴）vs 順序提供（獨立）

### 關鍵技能：
- 提供2-3個具體的輸入/輸出範例來闡明轉換需求
- 在實現之前建構包含預期行為、邊緣情況和效能要求的測試集
- 使用訪談模式發現設計方面（快取失效、故障模式）
- 為邊緣情況提供具體測試用例和樣本輸入及預期輸出

## 3.6 將Claude Code整合到CI/CD管線

### 關鍵知識：
- 用於自動化管線非互動模式的 `-p`（或 `--print`）標誌
- CI中結構化輸出的 `--output-format json` 和 `--json-schema`
- CLAUDE.md為CI觸發的Claude Code提供專案上下文（測試標準、審查標準）
- **會話上下文隔離**：生成程式碼的同一會話在審查時比獨立例項效果更差

### 關鍵技能：
- 在CI中使用 `-p` 執行Claude Code以避免掛起在互動式輸入上
- 使用 `--output-format json` + `--json-schema` 獲取結構化結果（例如，內聯PR評論）
- 在新提交後重新執行時包含之前的審查結果（僅報告新問題/未修復問題）
- 在CLAUDE.md中記錄測試標準和可用夾具以提高測試生成品質
- 在生成新測試時將現有測試檔案包含在上下文中，以避免重複並保持風格一致

---

# 領域4：提示詞工程與結構化輸出（20%）

## 4.1 使用顯式標準設計提示詞以提高準確性

### 關鍵知識：
- 顯式標準比模糊指令更有效（例如，"僅在註釋與程式碼矛盾時標記"vs"檢查註釋準確性"）
- "更保守一點"這樣的通用指導比具體的分類標準效果更差
- 誤報對開發者信任的影響：某些類別的高誤報率會破壞對準確類別的信任

### 關鍵技能：
- 定義審查標準：報告什麼（錯誤、安全）vs 忽略什麼（次要風格）
- 臨時禁用誤報率高的類別
- 為每個級別定義帶有程式碼範例的顯式嚴重性標準

## 4.2 使用少樣本提示詞提高輸出一致性

### 關鍵知識：
- 少樣本範例是產生格式一致、可操作輸出的最有效方法
- 少樣本可以演示處理模糊情況的方式（工具選擇、測試覆蓋缺口）
- 少樣本幫助模型泛化到新模式，而不僅僅是重複預設行為
- 少樣本可以減少提取任務中的幻覺

### 關鍵技能：
- 為模糊場景提供2-4個帶有推理說明的針對性範例
- 包含演示輸出格式的少樣本範例（位置、問題、嚴重性、建議修復）
- 提供區分可接受程式碼模式與真實問題的範例
- 提供來自不同結構文件的正確提取範例

## 4.3 使用 `tool_use` 和JSON Schema強制結構化輸出

### 關鍵知識：
- 帶有JSON Schema的 `tool_use` 是保證模式合規輸出並消除JSON語法錯誤的最可靠方式
- 使用 `tool_choice: "auto"` 模型可以回傳文字；使用 `"any"` 時必須呼叫工具；強制選擇會選擇特定工具
- 嚴格的JSON Schema消除語法錯誤，但不能防止語義錯誤（總計不加；值在錯誤欄位中）
- Schema設計：必填vs可選欄位；帶有"其他"加詳情字串的列舉以實現可擴充套件性

### 關鍵技能：
- 使用JSON Schema定義提取工具並從 `tool_use` 結果中解析資料
- 當存在多個Schema時，使用 `tool_choice: "any"` 保證結構化輸出
- 強制特定工具呼叫：`tool_choice: {"type": "tool", "name": "extract_metadata"}`
- 當來源可能不包含資訊時，將欄位設為可選/可空，以避免偽造值
- 使用列舉值如 `"unclear"` 和 `"other"` 加上詳細欄位進行可擴充套件分類

## 4.4 為提取品質實現驗證、重試和回饋迴圈

### 關鍵知識：
- 帶錯誤回饋的重試：在重試提示詞中包含具體的驗證錯誤以指導修正
- 當資訊根本不存在於來源中時，重試無效
- 回饋迴圈設計：追蹤觸發發現的模式（`detected_pattern`）
- 語義錯誤（總計不一致）vs 語法錯誤（由 `tool_use` 解決）

### 關鍵技能：
- 包含原始文件、不正確提取和具體驗證錯誤的後續提示詞
- 識別重試何時無效（所需資訊只在外部文件中）
- 在發現中包含 `detected_pattern` 欄位以分析誤報
- 透過提取 `calculated_total` 和 `stated_total` 來設計自我糾正以檢測差異

## 4.5 設計高效的批處理策略

### 關鍵知識：
- Message Batches API：節省50%，最長24小時處理視窗，無延遲SLA保證
- 批處理適用於非阻塞任務（隔夜報告、審計），不適用於阻塞任務（合併前檢查）
- Batch API不支援單個請求中的多輪工具呼叫
- `custom_id` 欄位在批次內關聯請求/回應

### 關鍵技能：
- 對阻塞檢查使用同步API；對隔夜/每週工作負載使用Batch API
- 根據SLA需求規劃批次提交節奏（例如，對30小時保證使用4小時視窗，含24小時處理）
- 透過重新提交僅失敗的文件（由 `custom_id` 標識）來處理失敗
- 在大規模處理之前使用樣本疊代最佳化提示詞

## 4.6 設計多例項和多輪審查架構

### 關鍵知識：
- 自我審查的侷限性：模型保留其推理上下文，不太可能挑戰自己的決策
- 獨立審查例項（沒有生成上下文）更擅長髮現細微問題
- 多輪審查：每檔案本地分析加上跨檔案整合檢查，以避免注意力分散

### 關鍵技能：
- 使用第二個獨立的Claude例項在沒有生成上下文的情況下審查變更
- 將多檔案審查拆分為每檔案檢查加上整合檢查，用於跨檔案資料流分析
- 使用帶有自評置信度的驗證檢查以校準的方式路由審查

---

# 領域5：上下文管理與可靠性（15%）

## 5.1 管理對話上下文以保留關鍵資訊

### 關鍵知識：
- 漸進式摘要的風險：數字值、百分比和日期在模糊摘要中被壓縮
- 中間迷失效應：模型可靠地處理長輸入的開頭和結尾，但可能錯過中間的發現
- 工具輸出可能在上下文中積累，與相關性不成比例（需要5個欄位時卻有40+個欄位）
- 在後續API請求中傳送完整對話歷史的重要性

### 關鍵技能：
- 將事務性事實提取到摘要歷史之外的持久化"案例事實"塊中
- 將詳細的工具輸出精簡到相關欄位
- 在彙總資料的開頭放置關鍵發現，並使用明確的章節標題
- 要求子代理在結構化輸出中包含後設資料（日期、來源）

## 5.2 設計有效的升級模式並解決歧義

### 關鍵知識：
- 適當的升級觸發器：明確請求人工干預、策略缺口/例外、無法取得進展
- 立即升級（明確請求）vs 嘗試解決（在代理範圍內）
- 情感分析和模型置信度自評是案例複雜性的不可靠代理
- 多個客戶匹配需要請求額外識別符號，而非啟發式猜測

### 關鍵技能：
- 在系統提示詞中使用少樣本範例明確升級標準
- 立即執行人工干預的明確請求，不進行額外調查
- 當策略對特定請求模糊或未明確時升級
- 當工具結果包含多個匹配時請求額外識別符號

## 5.3 在多代理系統中實現錯誤傳播策略

### 關鍵知識：
- 結構化錯誤上下文（故障型別、查詢、部分結果、替代方案）使協調者能夠更智慧地恢復
- 區分訪問失敗（超時需要重試決策）和有效的空結果（無匹配）
- 通用錯誤狀態（"搜尋不可用"）對協調者隱藏了有價值的上下文
- 靜默抑制或在單個失敗時中止整個工作流都是反模式

### 關鍵技能：
- 回傳結構化錯誤上下文：故障型別、嘗試內容、部分結果、可能的替代方案
- 區分訪問失敗和有效的空結果
- 在子代理內對瞬時失敗進行本地恢復；僅傳播無法恢復的錯誤以及部分結果
- 在綜合中註釋覆蓋範圍：哪些內容有充分支撐vs哪裡存在缺口

## 5.4 在調查大型程式碼庫時高效管理上下文

### 關鍵知識：
- 長會話中的上下文退化：模型開始產生不穩定的答案，並提及"典型模式"而非具體類
- 草稿檔案跨上下文邊界保留關鍵發現
- 委託給子代理可以隔離詳細的發現輸出
- 結構化狀態持久化支援崩潰恢復

### 關鍵技能：
- 為具體問題生成子代理，同時在主代理中保持高層協調
- 使用草稿檔案儲存關鍵發現並在後續引用
- 在生成下一階段子代理之前總結關鍵發現
- 在長時間調查中使用 `/compact` 減少上下文使用

## 5.5 設計具有人工監督和置信度校準的工作流

### 關鍵知識：
- 總體指標（例如，97%總體準確率）可能掩蓋特定文件型別或欄位上的差效能
- 分層隨機抽樣測量高置信度提取中的錯誤率
- 使用標註驗證集進行欄位級置信度校準
- 在自動化之前按文件型別和欄位細分驗證準確性

### 關鍵技能：
- 實現分層隨機抽樣以檢測新的錯誤模式
- 按文件型別和欄位分析準確性以驗證穩定效能
- 輸出欄位級置信度分數並使用標註資料校準審查閾值
- 將低置信度或模糊來源的提取路由到人工審查

## 5.6 在多源綜合中儲存溯源資訊並處理不確定性

### 關鍵知識：
- 在摘要期間未保留"宣告→來源"對映時歸因會丟失
- 在聚合期間必須保留結構化對映
- 透過用歸因註釋衝突來處理衝突統計資料，而非任意選擇一個值
- 包含釋出/收集日期以避免將時間差異誤讀為矛盾

### 關鍵技能：
- 要求子代理輸出"宣告→來源"對映（URL、文件名稱、引用）
- 將報告結構化為將穩定發現與有爭議發現分開
- 保留帶有註釋的衝突值，並傳遞給協調者進行調解
- 包含釋出日期以便正確解讀時間順序
- 按型別渲染內容：財務資料用表格，新聞用散文，技術發現用結構化列表

---

# 含解析的考題範例

## 題目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透過要求不一致檢測之間的共識來抑制真實的錯誤。

---

# 模擬測試

> 涵蓋4個場景的60道題。格式和難度與真實考試相匹配。
>
> 或者，您可以透過互動HTML檔案練習這些題目: [模擬測試 (ZH)](practical_test_zh.html)

## 場景：多代理研究系統

---

## 第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` 以優先於專案版本。

**為什麼選C：** 個人技能優先於同名的專案技能。位於 `~/.claude/skills/commit/SKILL.md` 的個人技能將覆蓋團隊的專案技能，允許開發者定製他們的工作流，同時保持熟悉的 `/commit` 命令名稱供個人使用。這種方法比選項A更好，因為它保留了原始命令名稱，改進了開發者的工作流，而不影響隊友。

---

## 第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：** 將少樣本範例針對發生錯誤的特定模糊場景，並帶有明確的為什麼一個工具比替代品更優的推理說明，教導模型邊緣情況所需的比較決策過程。這比通用範例或宣告性規則更有效。

---

## 問題 61（場景：對話式 AI 架構模式）

**情境：** 您的 `remove_team_member` 工具使用 `dry_run: boolean` 參數在執行前預覽影響。生產監控顯示 Agent 透過直接使用 `dry_run=false` 呼叫繞過了預覽步驟。您需要確保每次刪除操作之前都有使用者明確確認的預覽。

**哪種方法最可靠？**

- A) 新增伺服器端驗證，僅在 60 秒內發生過參數相同的 `dry_run=true` 呼叫時才允許 `dry_run=false`。
- B) 將工具標註為需要確認，並配置編排層在轉發呼叫給標註工具前向使用者請求審批。
- C) 在工具描述中新增詳細指令和少樣本範例，要求 Agent 始終先用 `dry_run=true` 呼叫並等待使用者確認後再呼叫。
- D) 替換為兩個工具：`preview_remove_member` 回傳影響詳情和一次性確認令牌；`execute_remove_member` 需要該令牌，將執行與預覽繫結。**【正確】**

**為什麼選 D：** 令牌繫結方案使得在未經預覽的情況下執行在架構上成為不可能——執行工具字面上需要只有預覽工具才能生成的令牌。這是唯一在程式碼層面強制執行約束的方案，而不依賴 LLM 遵守指令 (C)、時間啟發式 (A) 或編排基礎設施 (B)。

---

## 問題 62（場景：對話式 AI 架構模式）

**情境：** 生產監控顯示您的 `search_catalog` 工具 12% 的時間會失敗：8% 是網路超時（重試後成功），4% 是查詢語法錯誤（無論重試多少次都不會成功）。目前兩種錯誤型別的回傳方式相同，導致無效重試。

**您應該如何修改工具的錯誤處理？**

- A) 在系統提示詞中新增少樣本範例，演示如何區分網路錯誤和語法錯誤。
- B) 對所有錯誤統一應用指數退避重試邏輯。
- C) 在工具內部對網路超時實現自動重試並退避；對語法錯誤立即回傳並附帶參數驗證詳情。**【正確】**
- D) 對所有錯誤回傳帶有 `retryable` 布林標誌和錯誤型別詳情的結構。

**為什麼選 C：** 在工具層面處理瞬態錯誤的重試是正確的抽象邊界——工具對錯誤型別有明確瞭解，可以實現確定性重試邏輯，而不依賴 Agent 解釋標誌 (D) 或遵循提示詞指令 (A)。統一退避 (B) 在語法錯誤上浪費時間，而這些錯誤永遠不會成功。

---

## 問題 63（場景：對話式 AI 架構模式）

**情境：** 在多輪討論投資策略的過程中，使用者說了"我的風險承受能力很低"，然後又說"我想最大化回報"。他們現在問："我應該投資什麼？"

**哪種方法最能確保建議與使用者的真實優先順序保持一致？**

- A) 指出矛盾，請使用者澄清哪個更重要。**【正確】**
- B) 分別為兩種情景提供建議。
- C) 按最近表達的偏好繼續。
- D) 在不解決衝突的情況下推薦均衡投資組合。

**為什麼選 A：** 當使用者偏好直接矛盾時，指出衝突並請求澄清是確保建議與使用者真實意圖保持一致的唯一方式。最大化回報和低風險承受能力是根本不相容的目標，需要人工決策。

---

## 問題 64（場景：對話式 AI 架構模式）

**情境：** 使用者在多輪對話中細化播放列表偏好。使用者說"我喜歡爵士樂"後兩條訊息，Claude 問"您喜歡什麼流派？"

**最可能的原因是什麼？**

- A) Claude 需要向量資料庫連線才能維持對話記憶。
- B) 模型的上下文視窗已超出。
- C) Claude API 需要 `session_id` 參數。
- D) 您的應用程式沒有在 `messages` 陣列中包含之前的訊息。**【正確】**

**為什麼選 D：** Claude 沒有伺服器端記憶——每次 API 呼叫都是無狀態的。如果不在每個請求的 `messages` 陣列中包含完整的對話歷史，Claude 就無法知道之前輪次發生了什麼。向量資料庫 (A) 和 `session_id` (C) 不是 Claude 架構的組成部分；兩條訊息的交流不可能超出上下文視窗 (B)。

---

## 問題 65（場景：對話式 AI 架構模式）

**情境：** 經過 40 分鐘的烹飪會話，對話達到 78,000 個令牌。歷史記錄包括過敏資訊、食譜縮放、澄清的烹飪術語和一般討論。您必須在保留重要資訊的同時減少令牌。

**哪種方法最好地平衡了保留與令牌減少？**

- A) 總結整個對話歷史。
- B) 只保留最近的 20,000 個令牌。
- C) 提取關鍵結構化資料（過敏資訊、數量、偏好），總結一般討論，逐字保留最近的交流。**【正確】**
- D) 將完整對話儲存在外部，透過語義搜尋檢索相關部分。

**為什麼選 C：** 混合方法以最低成本保留最高價值的資訊。過敏資訊和食譜數量等關鍵事實被提取到緊湊的結構化塊中（防止摘要過程中的精度損失），一般討論被摘要，最近的交流逐字保留以保持對話連貫性。選項 A 和 B 有丟失關鍵飲食資訊的風險；D 對單次烹飪會話來說過於複雜。

---

## 問題 66（場景：對話式 AI 架構模式）

**情境：** 使用者反映在長時間對話中，助手會失去對早期話題和偏好的追蹤。您當前的實現只保留最後 25 對訊息。

**最有效的解決方案是什麼？**

- A) 混合方法：摘要較舊的訊息，同時逐字保留最近的訊息。**【正確】**
- B) 對完整對話歷史進行向量相似性搜尋。
- C) 將視窗增加到 50 對訊息。
- D) 每輪摘要已刪除的訊息並將執行摘要新增到前面。

**為什麼選 A：** 混合方法解決了問題的兩個維度：保留精確的最近上下文（對對話連貫性至關重要），同時維護對早期偏好的壓縮表示。增加視窗 (C) 只是推遲了同樣的問題。向量搜尋 (B) 可能會錯過與當前查詢語義不相似的重要上下文。

---

## 問題 67（場景：對話式 AI 架構模式）

**情境：** 使用者反映當對話超過 50 輪時，延遲增加，成本上升。

**主要原因是什麼？**

- A) 每個 API 請求都包含完整的對話歷史。**【正確】**
- B) 模型生成越來越長的回應。
- C) 隨著歷史記錄增長，資料庫操作變慢。
- D) 模型建構需要更多處理的內部使用者畫像。

**為什麼選 A：** Claude 的 API 完全無狀態——每個請求必須在 `messages` 陣列中包含完整的對話歷史。隨著對話增長，每個請求攜帶更多令牌，這直接增加了處理延遲和成本。模型不在呼叫之間維護任何內部狀態（D 為假）。

---

## 問題 68（場景：對話式 AI 架構模式）

**情境：** 經過三個月的每週會話，對話歷史增長到 85,000 個令牌。當使用者問"我們關於孤立主題得出了什麼結論？"時，助手給出了通用答案，而不是引用之前的討論。

**最有效的方法是什麼？**

- A) 滾動視窗截斷。
- B) 逐步摘要，捕獲關鍵結論。
- C) 語義嵌入，檢索相關交流。**【正確】**
- D) 新增結構化 XML 標籤標記討論結論。

**為什麼選 C：** 對對話歷史進行語義搜尋是唯一能擴充套件到三個月討論，同時能按需檢索特定相關交流的方法。滾動視窗截斷 (A) 會丟棄大部分歷史。漸進摘要 (B) 將討論壓縮成抽象概念，丟失了使用者詢問的具體結論。

---

## 問題 69（場景：對話式 AI 架構模式）

**情境：** 在 QA 測試期間，Claude 在最初 10–15 輪遵循系統提示詞指南，但後續回應出現偏差。對話仍在令牌限制內。

**最佳解決方案是什麼？**

- A) 將行為指南移至第一條使用者訊息。
- B) 20 輪後開始新的對話。
- C) 在對話斷點處插入強化指南的使用者角色訊息。**【正確】**
- D) 使用回應後驗證來重新生成不合規的回應。

**為什麼選 C：** 定期注入行為提醒直接對抗指令漂移，隨著對話歷史積累在定期間隔重新建立約束。將指南移至第一條使用者訊息 (A) 降低了其權威性。回應後驗證 (D) 是糾正性的而非預防性的，會增加顯著延遲。

---

## 問題 70（場景：對話式 AI 架構模式）

**情境：** 您的 AI 輔導工具有一個 2,800 個令牌的系統提示詞，定義了教學方法和適配規則。12 輪後，助手開始忽略熟練程度級別。

**最有效的修復方案是什麼？**

- A) 每 4–5 輪注入提醒。
- B) 用演示熟練度適配的少樣本範例替換冗長規則。**【正確】**
- C) 將關鍵規則放在系統提示詞末尾。
- D) 評估回應，如果難度級別不匹配則重新生成。

**為什麼選 B：** 帶有宣告性規則的 2,800 令牌系統提示詞容易漂移，因為抽象規則要求模型在每輪都進行推理。將冗長規則替換為演示正確熟練度適配的具體少樣本範例，為模型提供了清晰的行為模式可供匹配——這比多輪抽象指令更可靠地被遵循。

---

## 問題 71（場景：對話式 AI 架構模式）

**情境：** 您的助手必須保持熱情的語氣、解釋推理並提出澄清問題。這些行為指南應該在哪裡定義？

**這些行為指南應該在哪裡定義？**

- A) 新增到每條使用者訊息之前。
- B) 在系統提示詞中。**【正確】**
- C) 在第一條助手訊息中。
- D) 在環境變數中。

**為什麼選 B：** 系統提示詞專門設計用於在整個對話過程中應用的持久行為約束和指南。在每條使用者訊息前新增 (A) 是冗餘的開銷。第一條助手訊息 (C) 不可靠，因為模型可能偏離自己之前的陳述。環境變數 (D) 對模型行為沒有影響。

---

## 問題 72（場景：對話式 AI 架構模式）

**情境：** 使用者報告回應開頭重複，如"當然！"和"我很樂意幫助！"

**最有效的方法是什麼？**

- A) 附加帶有直接回應開頭的部分助手訊息。**【正確】**
- B) 降低溫度設定。
- C) 後處理回應以刪除問候語。
- D) 在系統提示詞中新增指令以避免這些短語。

**為什麼選 A：** 用直接答案的開頭預填助手回應，在生成層面阻止問候模式——模型從預填內容繼續，而不是生成新的開頭短語。系統提示詞指令 (D) 可以有所幫助，但不那麼可靠。後處理 (C) 是一個脆弱的變通方案。溫度 (B) 控制隨機性，而不是特定短語模式。

---

## 問題 73（場景：對話式 AI 架構模式）

**情境：** 當使用者正在聊天時，webhook 通知您的系統使用者的包裹已發貨。您希望助手在下一個回應中自然地融入這一資訊。

**最佳方法是什麼？**

- A) 將發貨狀態新增到系統提示詞。
- B) 傳送立即的合成使用者訊息。
- C) 強制助手每輪呼叫狀態工具。
- D) 將狀態更新作為字首附加到下一條使用者訊息。**【正確】**

**為什麼選 D：** 將狀態更新作為字首附加到下一條使用者訊息，在自然對話邊界注入實時上下文，不會中斷對話流程。修改系統提示詞 (A) 需要重建會話。合成使用者訊息 (B) 可能破壞自然對話流程。每輪強制呼叫工具 (C) 在事件罕見時很浪費。

---

## 問題 74（場景：對話式 AI 架構模式）

**情境：** 使用者經常傳送"為派對預訂一個場地"這樣的請求。助手提出 4 個以上的澄清問題，導致 35% 的放棄率。

**哪種方法最能改善這種權衡？**

- A) 使用隱藏預設值繼續。
- B) 在一條複合訊息中提出所有澄清問題。
- C) 明確說明假設並繼續，同時邀請更正。**【正確】**
- D) 使用結構化接收表單。

**為什麼選 C：** 明確說明假設並繼續，為使用者提供即時有用的回應，同時保留他們糾正錯誤假設的能力。隱藏預設值 (A) 讓使用者不知道做了什麼假設。複合問題列表 (B) 仍然需要使用者的前期努力。結構化表單 (D) 增加了更多摩擦，而不是更少。

---

## 問題 75（場景：對話式 AI 架構模式）

**情境：** 您的助手使用承包商角色系統提示詞。早期輪次遵循規則，但到第 7 輪，助手給出通用建議。對話長度僅 2,500 個令牌。

**最可能的原因是什麼？**

- A) 系統提示詞只建立初始行為。
- B) 隨著輪次積累，模型注意力減弱。
- C) 積累的助手回應稀釋了系統提示詞的影響。**【正確】**
- D) 系統提示詞只傳送一次。

**為什麼選 C：** 隨著助手回應在對話歷史中積累，反映系統提示詞行為約束的文字比例相對於不斷增長的助手生成內容而言在減少。即使在短令牌長度下，模型也越來越多地匹配自己之前的輸出模式，而不是系統提示詞指令，從而加劇了漂移。

---

## 問題 76（場景：對話式 AI 架構模式）

**情境：** 使用者提出模糊請求，如"你能幫忙處理報告嗎？"助手透過提問多個問題（哪份報告？需要什麼幫助？截止日期是什麼？）來回應，導致 40% 的放棄率。

**最佳解決方案是什麼？**

- A) 做出合理假設，明確說明，並提供調整。**【正確】**
- B) 在回應之前用較小的模型對模糊性進行分類。
- C) 使用預定義的解釋，不說明假設。
- D) 限制助手每輪只提一個澄清問題。

**為什麼選 A：** 以合理的明確假設繼續，完全消除了來回交流，同時讓使用者保持知情和掌控。無聲的預定義解釋 (C) 當回應與使用者意圖不符時會讓使用者困惑。每輪一個問題的限制 (D) 仍然需要來回多輪。較小的分類模型 (B) 增加了延遲和基礎設施複雜性，而沒有解決核心 UX 問題。

---

# 實踐練習

## 練習1：帶升級邏輯的多工具代理

**目標：** 設計一個帶有工具整合、結構化錯誤處理和升級的代理迴圈。

**步驟：**
1. 定義3-4個帶詳細描述的MCP工具（包含兩個類似工具以測試工具選擇）
2. 實現一個檢查 `stop_reason`（`"tool_use"` / `"end_turn"`）的代理迴圈
3. 新增結構化錯誤回應：`errorCategory`、`isRetryable`、描述
4. 實現一個攔截器鉤子，阻止超過閾值的操作並路由到升級
5. 使用多方面請求進行測試

**領域：** 1（代理架構），2（工具和MCP），5（上下文和可靠性）

---

## 練習2：為團隊開發配置Claude Code

**目標：** 配置CLAUDE.md、自定義命令、路徑特定規則和MCP伺服器。

**步驟：**
1. 建立帶有通用標準的專案級CLAUDE.md
2. 為不同程式碼區域建立帶YAML前置內容的 `.claude/rules/` 檔案（`paths: ["src/api/**/*"]`、`paths: ["**/*.test.*"]`）
3. 在 `.claude/skills/` 下建立帶有 `context: fork` 和 `allowed-tools` 的專案技能
4. 在 `.mcp.json` 中配置帶有環境變數的MCP伺服器 + 在 `~/.claude.json` 中配置個人覆蓋
5. 在不同複雜度的任務上測試規劃模式vs直接執行

**領域：** 3（Claude Code配置），2（工具和MCP）

---

## 練習3：結構化資料提取管線

**目標：** JSON Schemas、`tool_use` 用於結構化輸出、驗證/重試迴圈、批處理。

**步驟：**
1. 定義帶JSON Schema的提取工具（必填/可選欄位、帶"其他"的列舉、可空欄位）
2. 建構驗證迴圈：出錯時，用文件、錯誤提取和具體驗證錯誤重試
3. 為不同結構文件新增少樣本範例
4. 透過Message Batches API使用批處理：100個文件，透過 `custom_id` 處理失敗
5. 路由到人工：欄位級置信度分數、文件型別分析

**領域：** 4（提示詞工程），5（上下文和可靠性）

---

## 練習4：設計和除錯多代理研究管線

**目標：** 子代理編排、上下文傳遞、錯誤傳播、帶來源跟蹤的綜合。

**步驟：**
1. 一個協調者帶2+子代理（`allowedTools` 包含 `"Task"`，上下文在提示詞中明確傳遞）
2. 透過在單個回應中進行多次 `Task` 呼叫並行執行子代理
3. 要求結構化子代理輸出：宣告、引用、來源URL、釋出日期
4. 模擬子代理超時：向協調者回傳結構化錯誤上下文，並繼續使用部分結果
5. 使用衝突資料測試：保留兩個值及歸因；分離已確認vs有爭議的發現

**領域：** 1（代理架構），2（工具和MCP），5（上下文和可靠性）

---

# 附錄：技術和概念

| 技術 | 關鍵方面 |
|---|---|
| **Claude Agent SDK** | AgentDefinition、代理迴圈、`stop_reason`、鉤子（PostToolUse）、透過Task生成子代理、`allowedTools` |
| **模型上下文協議（MCP）** | MCP伺服器、工具、資源、`isError`、工具描述、`.mcp.json`、環境變數 |
| **Claude Code** | CLAUDE.md層次結構、帶glob模式的 `.claude/rules/`、`.claude/commands/`、帶SKILL.md的 `.claude/skills/`、規劃模式、`/compact`、`--resume`、`fork_session` |
| **Claude Code CLI** | 非互動模式的 `-p` / `--print`、`--output-format json`、`--json-schema` |
| **Claude API** | 帶JSON Schema的 `tool_use`、`tool_choice`（"auto"/"any"/強制）、`stop_reason`、`max_tokens`、系統提示詞 |
| **Message Batches API** | 50%節省、最長24小時視窗、`custom_id`、不支援多輪工具呼叫 |
| **JSON Schema** | 必填vs可選、可空欄位、列舉型別、"其他"+詳情、嚴格模式 |
| **Pydantic** | Schema驗證、語義錯誤、驗證/重試迴圈 |
| **內建工具** | Read、Write、Edit、Bash、Grep、Glob——目的和選擇標準 |
| **少樣本提示詞** | 模糊情況的針對性範例、對新模式的泛化 |
| **提示詞鏈** | 順序分解為聚焦檢查 |
| **上下文視窗** | 令牌預算、漸進摘要、"中間迷失"、草稿檔案 |
| **會話管理** | 恢復、`fork_session`、命名會話、上下文隔離 |
| **置信度校準** | 欄位級評分、標註集校準、分層抽樣 |

---

# 考試範圍外的主題

以下相鄰主題**不會**出現在考試中：

- 微調Claude模型或訓練自定義模型
- Claude API認證、計費或帳戶管理
- 特定程式語言或框架中的詳細實現（超出工具/Schema配置所需）
- 部署或託管MCP伺服器（基礎設施、網路、容器編排）
- Claude的內部架構、訓練過程或模型權重
- 憲法AI、RLHF或安全訓練方法
- 嵌入模型或向量資料庫實現細節
- 計算機使用（瀏覽器自動化、桌面互動）
- 影象分析能力（視覺）
- 流式API或伺服器傳送事件
- 速率限制、配額或詳細的API成本計算
- OAuth、API金鑰輪換或認證協議細節
- 雲供應商特定配置（AWS、GCP、Azure）
- 效能基準或模型比較指標
- 提示詞快取實現細節（超出瞭解其存在）
- 令牌計數演算法或分詞細節

---

# 備考建議

1. **使用Claude Agent SDK建構代理** — 實現包含工具呼叫、錯誤處理和會話管理的完整代理迴圈。練習子代理和明確的上下文傳遞。

2. **為真實專案配置Claude Code** — 使用CLAUDE.md層次結構、`.claude/rules/` 中的路徑特定規則、帶 `context: fork` 和 `allowed-tools` 的技能，以及MCP伺服器整合。

3. **設計和測試MCP工具** — 編寫區分類似工具的描述，回傳帶類別和重試標誌的結構化錯誤，並針對模糊使用者請求進行測試。

4. **建構資料提取管線** — 使用帶JSON Schema的 `tool_use`、驗證/重試迴圈、可選/可空欄位，以及透過Message Batches API進行批處理。

5. **練習提示詞工程** — 為模糊場景新增少樣本範例、明確的審查標準，以及大型程式碼審查的多輪架構。

6. **研究上下文管理模式** — 從詳細輸出中提取事實、使用草稿檔案，以及將發現委託給子代理以處理上下文限制。

7. **理解升級和人在環中** — 何時升級（策略缺口、使用者明確請求、無法取得進展）以及基於置信度的路由工作流。

8. **在真正考試前參加模擬考試** — 它使用相同的場景和格式。