Cert Dojo — 考試日

English English (STE) 繁體中文 简体中文 廣東話

涵蓋四項認證全部 25 個 Train 模組的考試早晨濃縮版。在考場外再讀一次難題取捨原則，快速瀏覽所考認證的必記清單，然後相信流程，而不是腎上腺素。本頁為正式繁體書面中文版本。

全部四項認證 · 請讀兩遍

通用難題取捨原則——無法確定時如何選擇

每項規則都會在其後標示的認證中反覆出現：AO 助理級 · DV 開發者 · AR-F 基礎架構師 · AR-P 專業架構師。

一看便應排除

  • 崇尚規格（Prestige）——把「使用最大／能力最強的模型」當作第一步或通用修正。應先處理 effort、設定與診斷；升級模型需要評估（eval）證據，以及成本和延遲範圍。 AO · DV · AR-F · AR-P
  • 絕對化答案——「一律」、「絕不」、「禁止所有 Connector」、「允許所有寫入」、「所有介面只用一個 SLO」。按比例、帶條件、分層級的答案較佳。 AO · DV · AR-F · AR-P
  • 只靠提示詞執行政策——把 system prompt、CLAUDE.md 或 Project instruction 中的一句話當成控制措施。真正的控制措施是 hooks、拒絕權限、allowlists、伺服器端授權和 schema validation。 AO · DV · AR-F · AR-P
  • 以自我評估作關卡——「問 Claude 是否有信心」、模型 confidence、沒有程式碼斷言的 judge 分數，或只例行蓋章的審核佇列。虛假的人工介入（HITL）在每一項考試都不成立。 AO · DV · AR-F · AR-P
  • 「平台會替你記住」——Messages API 是無狀態的；subagent 不會繼承上層歷史或共享記憶（只有自己的 system prompt、你傳入的內容，以及它自行用工具讀取的內容）；摘要會遺失精確數字；Memory 和知識也會過時。凡是假設介面會保留其未曾承諾之狀態的選項，都是錯的。 AO · DV · AR-F · AR-P
  • 以自然語句作控制信號——解析「I'm done!」、「looks good」或流暢文字，而不是使用 stop_reason、isError、schema 檢查或 claim map。 AO · DV · AR-F · AR-P
  • 盲目重試、盲目信任——重試 401 就像重試 429；把工具結果或擷取到的 HTML 當成指令；逾時後把 [] 解讀為「沒有相符結果」；把引用當成驗證。 AO · DV · AR-F · AR-P
  • 不可逆操作前沒有關卡——自動寄送、寫入 CRM／工單／退款、刪除、部署或移動款項之前，沒有確認、冪等鍵（idempotency key）或回滾路徑。 AO · DV · AR-F · AR-P
  • 憑空捏造——捏造文件從未出現的旗標、參數或值（CLAUDE_HEADLESS、--batch），以及 KPI、負責人或引用。應標記為 UNKNOWN 或升級處理。 AO · DV · AR-F · AR-P
  • 「供應商已包辦」——以 model card、Constitutional AI、ZDR 或「這是 frontier model」取代你自己的控制措施、評估、資料保留政策及問責機制。 AO · DV · AR-P
  • 對抗防護欄——以 jailbreak 框架或更換模型規避拒絕；在存有 production credentials 的手提電腦上繞過權限；把安全拒絕視為程式錯誤。 AO · DV · AR-F · AR-P
  • 一次改動所有東西——同時升級 tier、重寫 prompt、重排工具箱，或不做 canary 而直接 100% rollout。其後任何問題都無法診斷。 AO · DV · AR-F · AR-P
  • 同一類措施的兩種版本出現在「選擇兩項」的題目中——正確的一對應跨越兩個層面（執行＋分發、機制＋量度、控制＋披露）。 AO · AR-P
  • 無界限迴圈——agent 沒有回合、工具、支出或實際時間預算，也沒有真正的停止條件或進度判斷式。迭代上限只是最後防線，絕不是成功信號。 DV · AR-F · AR-P
  • 「已啟用等於可存取」——marketplace listing、管理員啟用或 model-garden 開關並不會授予驗證、授權、scope 或區域可用性。必須檢查完整鏈路。 AO · DV · AR-F · AR-P

兩項之間難以抉擇時優先選擇

  • 最小而足夠的 X——模型、scope、權限、自主類別、context。先試點再擴展；只有評估證據支持時才擴大範圍。 AO · DV · AR-F · AR-P
  • 明確勝過隱含——固定的 model ID、明確傳入的 context、allowlists、輸出合約與 schema、冪等鍵，以及附日期的具名負責人。 AO · DV · AR-F · AR-P
  • 行動之前先分類——哪一類錯誤（401、429 或 529）、哪一層（準則 → 輸入 → 設定 → prompt → 模型）、依模組本身尺度屬於哪個風險級別（AO 的 L1–L4、AR-P 的 T0–T4），以及 coordinator 還是 worker。 AO · DV · AR-F · AR-P
  • 結構化信號勝過感覺——使用 stop_reason、isError、schema 檢查、claim map 和評估結果；絕不依賴流暢度、語氣或 confidence。 AO · DV · AR-F · AR-P
  • 每項檢查使用合適工具——以程式碼斷言檢查副作用與 schema、以 eval 檢查品質、以校準後的 judge 評核 rubric、由人類作判斷及審批不可逆影響。 AO · DV · AR-F · AR-P
  • 每次只改一個變數，並備有回滾路徑，且在查看結果之前預先設定成功門檻。 AO · DV · AR-F · AR-P
  • 把人工關卡正好放在影響接縫——在外部或不可逆效果發生之前，按風險調整關卡；過度驗證瑣事則是與其成對的錯誤答案。 AO · DV · AR-F · AR-P
  • 失敗時封閉，附帶脈絡升級——交付已嘗試的查詢與部分結果、UNKNOWN 與負責人、加註說明的衝突；絕不默默丟棄，也絕不把兩個來源取平均。 AO · DV · AR-F · AR-P
  • 明列取捨——價值與限制、成本與品質、彈性與可稽核性。只有好處的選項通常是干擾項。 AO · DV · AR-F · AR-P
  • 完整而可測試的 brief——輸入、成功準則、格式與驗證，比角色的威望和形容詞（「要有洞見」）更重要。 AO · DV · AR-F · AR-P
  • 先分解、再排序，然後平行化——把有重大影響的工作拆成階段，依序執行相依階段，只把互相獨立的工作平行處理；單一巨大 prompt 或 agent 是干擾項。 AO · DV · AR-F · AR-P
  • 分段結果勝過混合平均——按 intent、tenant 與文件類型切分品質和安全結果；量度 outcome，而非 token、seat 或 volume。 DV · AR-F · AR-P
閱讀題幹的固定步驟：① 找出題幹設定的硬性限制（residency、latency、risk tier、budget、「沒有等待中的人員」）——正確答案會遵守它；② 找出題幹所屬的模組與領域，用該模組的機制和詞彙作答——同一情境可能需要 claim map（m23）、schema 或 idempotency 修正（m02/m13），也可能需要 pattern 與 governance 決策（m31/m33）；切勿只憑認證名稱推斷作答層次；③ 遵照考試指定的術語；④ 若題幹出現引號內字句，答案通常會直接處理該字句；⑤ 干擾項經常是兩個相反極端——答案就在兩者之間。
CCAO-F · 基礎助理級（業務使用者）

判斷輸出，管控風險

（L1–L4、claim map、poisoned-number scan 和 4D 名稱都是本教材的記憶口訣；考試測試的是判斷力，而非這些標籤）

輸出評估與驗證21%
工作流程整合與方案設計16%
治理、風險與負責任使用15%
提示詞與任務執行14%
產品與模型選擇12%
設定與知識管理12%
故障排查與最佳化10%

這些內容值得押上考試成績

  • 風險級別 L1–L4：L1 快速查看，保留 draft 標籤 · L2 抽查 claims 與完整性 · L3 完整 claim map 加同儕審核 · L4 專家加第一手來源。具有實際後果的法律、醫療、財務、人力資源／就業影響及安全工作屬於 L4（公開的 10-K 摘要並非投資建議）——專家關卡是強制的。外部承諾、公開發布、款項移動及 system of record 至少屬於 L3。
  • 主張圖（Claim map）：擷取關鍵 claims（數字、名稱、日期、引句、承諾）→ 標記 SUPPORTED / UNSUPPORTED / CONTRADICTED / AMBIGUOUS / OUT_OF_SCOPE → 保留、重寫、刪除或升級處理。最後才潤飾文字。
  • 有毒數字掃描（Poisoned-number scan）：先檢查數字，再檢查名稱、日期和意見——考題會在流暢文字中藏入一個錯誤數字。
  • 引用不等於驗證：404 連結或真實但不相關的連結，與沒有引用同樣不合格。
  • 審閱文字不等於授權執行——Connector 寫入（電郵、CRM、工單）需要明確授權步驟；審閱草稿並不代表批准寄出。
  • 介面（Surfaces）：Chat＝快速來回 · Projects＝持久知識＋指令 · Artifacts＝自包含交付物 · Skills＝Claude 在相關時載入的程序（Projects 負責保存知識——把兩者職責對調是經典陷阱）· Connector＝即時資料，upload＝快照 · Incognito＝單一機密任務 · Memory＝每位使用者的脈絡（在 Settings → Memory 編輯）。
  • 模型階梯：選擇可交付成果的最輕量模型；在升級 tier 前先提高 effort。
  • Domain 1 行動手冊：分析：rubric＋FACTS 對 INFERENCES；研究：scope、timeframe、來源規則、citations；草擬：已核准事實＋語調樣本＋禁用字句；腦力激盪：先發散再收斂。指出缺陷，每次改一個變數；兩次收緊後仍失敗 → 更換處理層，不要只改形容詞。Temperature／fine-tuning 是錯誤方向。
  • 辨識調查動詞：「我們作過甚麼決定？」→ 尋找保存紀錄的介面（Project knowledge、Memory 或 connector），而非依賴聊天記憶；有公開引用的概覽 → Research（付費＋啟用 web search；絕不為單一已上載 PDF 使用）；總計／樞紐分析／Excel-PPT → code execution。Chat 不會「計算」10k 行資料。
  • 三個具名 tier：Haiku（擷取／分類／大量處理）· Sonnet（日常預設）· Opus（較輕量模型或更佳 brief 失敗後使用）。「升級至 Opus 以上」是崇尚規格的干擾項。
  • 政策階梯：禁止事項 → 拒絕；高風險 → 有防護措施才允許（人工關卡＋披露＋評估）；一般事項 → 仍須最小化；不確定 → 升級至負責人。就業／財務／法律屬於「有防護措施才允許的高風險」，不是直接拒絕。
  • 增強或重新設計，以及脈絡處理：受監管／外部／不可逆流程先採用增強；重新設計需要高浪費、低風險、願意承擔的負責人及試點。重新開始（漂移）· 摘要（handoff brief）· 持久保存（Project instructions＋knowledge）。Memory 是使用者層級（Settings → Memory）；Project knowledge＋instructions 是專案層級儲存；incognito 不等於隱形（Enterprise 仍會保留／匯出）。
  • 治理：把 PII 最小化，並依組織分類選擇使用場所；組織／商業資料通常預設不會用於訓練，但應查證即時私隱文件，不要重複辦公室傳聞；客戶與 AI 對話時須披露；法律狀況不確定時，升級至政策／合規負責人，絕不自行判斷。個人／消費者帳戶依個人的訓練／保留設定處理——這更說明它們不適合存放公司資料（請查證即時文件）。
  • 診斷階梯：成功準則 → 輸入 → 設定（過時知識、過時 Memory）→ prompt → context（對話串漂移：摘要＋重新開始）→ 到此仍未解決才改模型／effort。針對最差指標使用成本最低的槓桿。

本考試中不確定時……

  • 在「直接交付」和「先檢查」之間：按風險級別相稱地檢查。常見的錯誤答案組合是一邊崇尚規格並跳過檢查，另一邊過度驗證瑣事。
  • 題幹引用安全拒絕 → 遵從拒絕是正確政策行為；「程式錯誤」、「tier 問題」或 jailbreak 選項都是錯的。
  • 「哪種判斷可發現此問題？」→ Discernment 發現不安全輸出；Diligence 依風險調整審查規模。（題幹若寫Skill，指的是產品功能——可重用指令——而非這些標籤。）
  • 若輸出下一步會輸入試算表或系統 → 應選結構化格式，而非散文。
  • brief 要求的數字不存在 → 標記 UNKNOWN 或升級處理；絕不捏造看似精確的 KPI。
  • 新檔案出現後仍反覆套用錯誤範本風格 → 屬於設定債務（清除或重新設定知識優先次序），不是模型問題。
  • 任何「在全組織開放編輯，以免阻礙任何人」的選項 → 錯誤；應採最小權限（least privilege），區分 Can view／Can edit。
CCDV-F · 基礎開發者

以確定方式整合，有意識地運用資源

應用程式與整合33.1%
模型選擇與最佳化16.8%
代理與工作流程14.7%
提示詞與脈絡工程11.0%
工具與 MCP10.6%
保安與安全8.1%
Claude Code3.1%
評估、測試與除錯2.6%

這些內容值得押上考試成績

  • 三軸框架：能力 × 成本 × 延遲——找出題幹硬性限制的頂點，排除忽略它的選項。應最佳化每項成功任務的成本，而非每個 token 的成本。
  • 先調 effort，後升 tier：effort 是同一模型內的調節項。Adaptive thinking 從 4.6 開始；sampling params 會傳回 400，適用型號包括 Opus 4.7/4.8/5、Sonnet 5 和 Fable，而 4.6 接受它們。把「降低 temperature」當作可靠性修正是干擾項：應選 schema／structured output。（此處模型時效性敘述未與即時文件核對——指南本身只點名 Haiku、Sonnet、Opus。）
  • 在 production 固定版本：aliases 會漂移；CI 和 production 應固定 model ID。固定套件＝模型＋prompt＋工具版本；prompt 變更應像程式碼一樣發布（PR diff → eval suite → canary → 記錄 prompt_version）。
  • 提示詞快取（Prompt caching）：穩定 prefix 在前（工具 → system → examples），易變內容在後；重排工具或打亂 examples 會令 cache 失效。
  • Message Batches：成本低 50% · 最長 24 h · 不支援 streaming · 不支援多回合工具迴圈 · 用 custom_id 關聯並只重新提交失敗項；互動式 UX 使用 streaming（SSE）。
  • 工具設計門檻：以任務為單位的工具勝過萬能工具（run_sql、自由格式 action 字串＝錯誤）；讀寫分離；寫入使用冪等鍵（逾時後模型重試會重複收費）；失敗時封閉。
  • 配對規則：每個 tool_use 都需要一個 tool_result——傳回全部結果，並保留 assistant 的 tool-use 回合。API 沒有狀態：每次重新傳送完整交替歷史。
  • 代理迴圈：依 stop_reason 驅動，絕不解析自然語句；設定預算和停止條件；max-turn 上限是安全停止機制，而非主要停止機制。
  • 保安：以縱深防禦抵禦 injection；把不受信任內容框定為證據；在擁有資源的伺服器端接縫執行授權；秘密放入 secret manager 或環境變數——絕不放在前端 JS、prompts、CLAUDE.md 或 repo。MCP 不會自動安全。
  • 評估（Evals）：凍結的 golden set＋副作用斷言＋adversarial pack；canary 配合回滾準則；為凌晨 3am 成本爆升設置 kill switch。
  • 除錯迴圈：重現 → 比較固定套件的差異 → 分類所在層 → 每次改一個變數。未讀 trace 便升級 tier 是題目明示的錯誤答案。
  • Claude Code 操作：.claude/commands/<name>.md 屬於專案並受版本控制；~/.claude/commands/ 屬於個人。.claude/agents/*.md 定義自訂 subagents；plugins 使用組織管理的 marketplace。Headless：claude -p --output-format json --json-schema；--continue 延續最近工作，--resume 選擇工作；settings：managed → CLI → project local → project shared → user。
  • 快速模式（Fast mode）：同一模型，輸出速度約快 2.5×，價格較高；只限 Opus 5/4.8，並只在 Claude API 和 Managed Agents 提供。不適用於 Batch、Bedrock、Vertex 或 Priority Tier；有獨立 rate limit；切換速度會令 cache 失效；絕不要為節省費用而選擇。
  • Adaptive-thinking 型號陣容：Fable 永遠開啟；Opus 5 預設開啟；4.7/4.8 選擇性開啟；建議 4.6 使用 adaptive，而 budget_tokens 已屬舊式；Haiku 4.5 使用舊式 extended thinking，context window 為 200K。
  • 客戶端與伺服器端工具：client tools 由你執行並傳回 tool_result；web search、web fetch 和 code execution 是在 Anthropic 基礎設施上執行的 API server tools，並在同一 response 中傳回 content blocks（Claude Code 的 Bash／file tools 在本機執行）。跨 app 重用 → MCP；本機邏輯 → custom tool；程序 → Skill；檔案／shell → built-in。
  • 託管方式的首要問題：工具執行和 session artifacts 是否必須留在你的邊界內？→ self-hosted execution（Agent SDK、自訂 loop 或 Managed Agents self-hosted environment）；否則採 Anthropic-hosted（或者邊界屬於第三方雲端供應商時採 Bedrock／Vertex）。「使用 Claude」不等於 Managed Agents；託管方式絕不免除評估或 allowlists。
  • 串流安全：Messages 使用 HTTP SSE（message_start → deltas → message_stop）；WebSockets 是 UI↔backend 的雙工通道；polling 用來檢查 batch 狀態。只有完整取得 tool_use 後才執行工具；cancel 必須阻止寫入；重新連線絕不重複套用操作。
  • 軟件工程控制平面：branch＋PR、受保護 main、secrets、authZ、migrations 及不可逆 scripts 均設人工關卡。Refactor＝plan → tests first → small diffs；「Claude 寫的」只是草稿，不等於可以 merge。
  • 除錯分流：integration-layer failure（bad request、遺漏 tool_result、schema drift、固定版本錯誤）→ 修正程式碼；model-output failure → prompt／eval。用 usage.cache_read_input_tokens 驗證 caching；breakpoints 不超過 4 個；短 prefix 不會 cache；cache 依模型劃分。
  • Claude Code 中的 MCP 信任：已提交的 .mcp.json project servers 需要 workspace trust；permissions 格式為 mcp__server__tool；絕不把 secrets 放入 .mcp.json；只公開五個必要工具，而非 80 個。

本考試中不確定時……

  • 錯誤處理：401/403 → 修正設定，不要重試 · 429 → backoff＋jitter＋queue · 529-class → 在預算內重試，其後 shed load · 400 → 修正 request。
  • 「Cache hits 下降」→ 某些易變內容進入 prefix（動態 tool descriptions、timestamps）。每次 request 的資料應放在user turn，而非已快取的 system prefix。
  • 「Claude 忘記上一回合」→ 應用程式沒有重新傳送 history。在 Anthropic API 上，伺服器端不會替你記住任何內容。
  • 選擇框架：若要在不重寫 loop 下更換 Bedrock 模型或供應商 → 選 vendor-agnostic framework；「任何 async 工作」不等於 Managed Agents；Batches 不等於 agents（它是沒有本機或託管工具 loop 的離線非同步模型呼叫）。
  • 兩個答案看似都合理 → 選擇在產生副作用前用程式碼驗證輸出的答案，不要選相信模型已遵從的答案。
  • 「Managed agent deployment models」指兩種 Managed Agents 環境：Anthropic cloud 和 self-hosted；Agent SDK 不代表「Anthropic 代我託管 sandbox」。
  • 把「降低 temperature」作為可靠性修正是干擾項——應選 schema／structured output。
CCAR-F · 基礎架構師  ·  Bedrock/Vertex 設定模組不在範圍內 · Claude 101／AI Fluency 模組屬背景內容

協調代理，以程式碼執行政策

D1 · 代理式架構與協調27%
D3 · Claude Code 設定與工作流程20%
D4 · 提示詞工程與結構化輸出20%
D2 · 工具設計與 MCP 整合18%
D5 · 脈絡管理與可靠性15%

這些內容值得押上考試成績

  • 脈絡隔離：只有 spawn prompt 會把 context 帶入 subagent——沒有共享 memory，也沒有隱含傳遞。明確傳入 context；只平行處理互相獨立的工作。
  • Q7 題型：worker logs 顯示工作正確，但 coverage 不完整 → 問題在coordinator 的分解，不是 specialists。
  • 正確停止：以 stop_reason == "end_turn" 驅動 loop；絕不解析「I'm done!」。--resume <session> 延續之前的 conversation；fork_session 建立分支——history 複製到新的 session ID，原本 session 不變。
  • 建議性與強制性：prompts 屬概率性；hook 或程式化 prerequisite gate 會拒絕下游呼叫，直至上游完成。升級處理是結構化交接（structured handoff）（已嘗試的查詢＋部分結果），絕不是默默丟棄或空白升級。存取失敗不等於空結果——逾時後的 [] 是無聲抑制（silent suppression）。
  • Claude Code（D3）：CLAUDE.md hierarchy 中 user／project／directory 會串接（CONCATENATES）；user-level 不會透過 VCS 共享。@import 用於模組化 standards；面對散落檔案，使用 .claude/rules/ 配合 paths: globs，勝過逐目錄 CLAUDE.md。.claude/commands/ 會隨 clone 分發；~/.claude/commands/ 屬於個人。SKILL.md：context: fork、allowed-tools、argument-hint。Plan mode 適合多方案／架構工作；direct 適合單一檔案修正。Explore 負責詳細探索。-p 修正 CI 停滯；--output-format json＋--json-schema 產生可貼進 PR 的 findings。/memory 顯示已載入內容；hooks：PreToolUse deny、PostToolUse normalize。
  • 結構化輸出與提示詞（D4）：明確的 categorical criteria 勝過「保守一點」；對模稜兩可情況使用 2–4 個 few-shots，並解釋原因。tool_use＋JSON input_schema（文件類型未知時用 tool_choice: any 強制執行；使用具名工具強制先擷取）可消除 syntax errors，但不能消除 semantic errors。Nullable／optional fields＋enum unclear／other＋detail 可停止捏造。Retry＝原始文件＋失敗的 extraction＋具名 validation errors；它只修正格式，絕不補出不存在的資訊。加入 calculated_total 對 stated_total、conflict_detected、detected_pattern。
  • 批次與審查（D4）：成本低 50% · 不超過 24 h · 沒有 latency SLA · 不支援多回合 tool calling · 用 custom_id 關聯並只重新提交失敗項。阻塞 merge 前流程＝sync；隔夜處理＝batch。由獨立第二個 instance 審查；採用逐檔 pass 再加跨檔 integration pass，絕不只是擴大 context window。
  • 工具設計與 MCP（D2）：descriptions 是主要選擇信號——先擴充 inputs、examples、edge cases 和 boundaries，再考慮 few-shots、routers 或 consolidation；拆分／重新命名重疊工具。每個 agent 使用 4–5 個工具，而非 18 個。Structured errors：errorCategory（transient／validation／business／permission）、isRetryable、供人閱讀的文字；存取失敗不等於有效空結果。有明確 scope 的跨角色 verify_fact 處理 85% 情況；其餘由 coordinator 處理。.mcp.json＋${GITHUB_TOKEN} 可共享；~/.claude.json 屬於個人。Resources＝內容目錄；Grep 搜尋內容／Glob 搜尋路徑／Edit 不保證唯一 → Read＋Write；isError 位於 result 內。
  • 升級處理與校準（D5）：人類明確要求 → 立即升級（若事項簡單可提出一次；再次要求便升級）；policy 沉默／模糊 → 升級；沒有進度 → structured handoff；多個 identity matches → 要求 identifiers。Sentiment 和 self-confidence 都是錯誤 routers——第一項修正是明確 criteria＋few-shots。「整體 97%」可以掩蓋某一 stratum 只有 60%：按 document type × field 分段、分層抽樣，並在標記資料集上校準 per-field confidence。
  • 脈絡可靠性：摘要以外，每個回合重新傳送 case-facts block（amounts／dates／IDs）；lost-in-the-middle 確實存在——重複不等於位置恰當；crash manifests 把損失限制在一個 phase；互相衝突的 sources 應加註說明，絕不取平均。

本考試中不確定時……

  • 任何「subagent 會記住／繼承」的選項都是錯的——它沒有 parent history 或 memory，只有 spawn prompt 加上它自己的工具所讀內容（Read／Grep／web-search worker 仍能透過工具看見外部資訊）。
  • 風格或偏好問題 → prompt 層。「絕不允許／compliance／dollar caps」→ hook 或 deny 層。多項規則同時觸發時，deny 優先。
  • 「哪個檔案／在哪裏」題幹 → 依指南機制作答：commands dir、rules globs、SKILL.md keys、-p、@import；CLAUDE.md 各層會串接而不是覆寫（managed settings 則會覆寫 user／project settings）。
  • spawn「就是無法運作」→ 先檢查 tool allowlist 和 AgentDefinition，再歸咎模型。
  • 兩次摘要後遺失一個精確數字 → 答案是重新傳送 case-facts block，而非更大的 context window 或「請精確」。
CCAR-P · 專業架構師

設計系統，管控影響範圍

整合19%
方案設計與架構17%
評估、測試與最佳化16%
治理、安全與風險14%
持份者溝通與生命週期14%
Claude 模型、提示詞與脈絡工程13%
開發者生產力與賦能7%

這些內容值得押上考試成績

  • 模式選擇：workflow（固定步驟、可稽核 transition）對 agent（動態）；混合 intents 使用 router；獨立 subtasks 使用 parallelization；重複改進直至合格使用 evaluator–optimizer。Graph 編碼允許的 transitions，以便控制與稽核；free loops 彈性最大，但不符合 compliance 題幹。只有角色分工清晰時才採 multi-agent（read-only researcher＋有核准程序的 write executor）。
  • 誰執行客戶端工具？你的 runtime。絕不是模型，也絕不是供應商。授權應位於擁有資源的接縫。
  • 大規模 RAG：retrieval 應配合資料形態與查詢模式（查詢混合精確 token 和語義時使用 hybrid BM25＋vector）、section-aware chunking、強制 citations、如實處理空 retrieval、index tenancy，並在 retrieval 接縫執行 authz。fetch／MCP 設 SSRF guard。
  • 評估機制：gold／adversarial／regression／slice sets；code judge 檢查 schema 與 exact-match；model judge 應依相同 rubric 對照至少 2 位人類校準，以 blind 方式執行，並像程式碼一樣版本化；若沒有 code assertions，judge score 絕不能成為唯一 production gate；查看結果前先登記 thresholds。
  • 最佳化次序（只在品質可接受後）：量度 → 縮減 context＋cache prefixes → 把簡單流量路由至較便宜模型 → 平行處理獨立工作 → 非同步 UX。
  • 安全架構：針對 injection、indirect injection、insecure output handling、over-privilege、leakage、supply chain（MCP／Skills）建立 threat model。工具控制是最強硬的煞車；Constitutional AI 不等於你的應用程式安全——供應商特性並不涵蓋你的工具權限、資料流或 UX 風險，問責仍由你承擔。
  • 漸進自主：只有可逆＋影響小＋有記錄的操作才自動執行；不熟悉或不可逆的寫入交由人類或雙重控制；只有評估錯誤率對該影響範圍可接受時，才擴大自動類別。虛假 HITL（例行蓋章的佇列、自行評分）不合格。
  • ZDR 不等於你的資料保留政策：它是供應商的政策姿態；你的 logs、warehouses 和 eval stores 仍須最小化。刪除涵蓋 SQL rows 以外的 indexes、caches 和 embeddings。
  • 持份者與生命週期：選擇 pattern 前先定 discovery metrics（跳過此步直接選模式會被扣分）；ADR＝context、decision、alternatives、consequences、date；列明 non-goals；分階段擴大自主（「目前只建議；metric ≥ T 持續兩週後才自動寄送」）；公布殘餘 miss rates；絕不承諾用字完全相同或零錯誤；handoff＝runbook＋dashboards＋RACI＋有結束日期的具名 DRI；model EOL 是 lifecycle event（固定 inventory、migration owners、compat evals、comms plan）。
  • 賦能：paved road＝組織管理的 settings＋精選 marketplace＋CLAUDE.md＋Skills＋hooks；分開 builder 與 production credentials——IDE 不得有 god keys；break-glass 透過 PAM 並留下 audit。
  • 快取與價值：cached 不等於 evicted——cached tokens 仍佔用 context window；caching 只改變價格／TTFT。五項價值支柱是 efficiency、transformation、productivity、cost、performance SLAs；「quality」是 evaluation 題幹，不是價值支柱。
  • 依據約束（Grounding）：空 retrieval → 拒絕／澄清／升級；cited IDs ⊆ retrieved IDs；tenant isolation＝與已驗證 token 綁定的 hard filter。
  • 寫入可靠性：使用伺服器端冪等鍵；絕不從部分 streamed plan 執行 commit；chat memory 不是 ledger。
  • 路由事實：AWS 上的 Claude Platform 不等於 Bedrock；各 route 的 IDs 不同，所以使用 provider adapter；residency pin 也因 route 而異。
  • 考試動詞範本：implement → mechanism；identify → risk＋where；ensure → control＋measurement；design → layers＋owners；recommend → 一個選項及其 trade-offs。答案＝mechanism＋metric＋owner。
  • 信心與正式推出（GA）：confidence 是系統信號——retrieval score、validator pass、classifier margin——絕不是「我很有信心」；不可逆／受監管寫入仍由人類處理。不論 weighted average 多高，只要 critical safety／privacy red 或 HITL-staffing red，便會阻止 GA；demo 不等於 GA。
  • 合規與診斷：GDPR → minimization、DPIA、刪除（包括 embeddings／eval caches／backups）；HIPAA → BAA、minimum-necessary、PHI 不使用 web tools、clinician HITL；FedRAMP → boundary、logging、residency。來源錯誤 → retrieval；來源正確但捏造 → grounding／cite／refuse；格式錯誤 → schema／few-shot；困難案例 → tier／thinking。

本考試中不確定時……

  • 題幹有合規限制（類似 FedRAMP、residency、authorized clouds）→ 先按限制排除，再在餘下選項內設計。
  • 「能夠運作的最簡方案」勝過令人印象深刻的架構——最小而足夠的模型；先 augmented LLM，後 workflow；先 workflow，後 agent；先單一 agent，後 swarm。
  • 升級或更新問題 → 需要證據＋成本／延遲範圍，絕不基於聲望或對型號系列的忠誠。
  • 高階主管在場 → 交付物應是一頁式 decision brief，包含建議和 review date，而非講課或原始表格。
  • 「選擇兩項」的強制執行題幹 → 組織管理的設定＋managed marketplace：執行政策，並只分發已核准工具（絕不選同一控制措施的兩種版本）。（practice-exam pattern，不是指南原文）
  • Cache 或 latency 題幹 → 穩定 prefix 之前出現易變內容（或 thinking／config 切換）就是原因；在對 latency 敏感的路徑上保持設定穩定。