prompt 與 context engineering 的考法：十張證照怎麼問，跟實務差在哪

🌏 English version

本文是從官方資料建出來的備考材料，不是應考實錄 —— 作者沒有報考這些考試。所有「考什麼」都指回各家官方 exam guide 或 study guide，來源逐條列在文末。查證日期：2026-08-18。

這是 AI 證照備考系列的技術深潛篇，接在多 agent 架構的考點交集後面。

先講最反直覺的一件事：prompt 在這些證照裡佔的比例，比大家想的小。

CCAO-F 是四張 Claude 認證裡唯一不要求寫程式的一張，直覺上應該最像「prompt 證照」——結果它的 Prompting and Task Execution 只有 14%，而 Output Evaluation and Validation 有 21%。CCDV-F 的 Prompt and Context Engineering 是 11.0%，比 Applications and Integration 的 33.1% 小了三倍。

更關鍵的是這 11% 到 20% 裡面裝的是什麼。翻開官方條目，裡面幾乎沒有「怎麼寫出好句子」，全是 token 預算、compaction、context 隔離、JSON schema、版本控制、注入防禦。這些是 context engineering 與軟體工程，不是寫作。

十張證照，prompt 與 context 各佔多少

讀這張表要注意兩件事。

第一，只有 NCP-GENL 有一個叫「Prompt Engineering」的獨立領域（13%）。其他九張都把 prompt 拆散進別的領域——這代表你在考綱目錄裡搜 "prompt" 找不到東西，不等於它不考。

第二，CCAO-F 的 14% 嚴重低估了實際比重。它把 prompt 相關能力拆到四個地方：Prompting 14% 只有兩條（為商業與技術任務寫 prompt、用任務分解結構化複雜請求），但 Output Evaluation（21%）裡有「迭代 prompt 以改善品質」與「依任務型態調整策略」，Configuration and Knowledge Management（12%）裡有「撰寫有效的系統層級指示」，Product and Model Selection（12%）裡有「理解與管理 context 限制與記憶考量（何時該重開、摘要或持久化）」。加起來遠超過 14%，但沒有一條在考句子怎麼寫。

要點回指：CCAR-F Domain 4（20%）+ Domain 5（15%）、CCAO-F Prompting（14%）、CCDV-F Prompt and Context Engineering（11.0%）、NCP-GENL Prompt Engineering（13%）、AI-500 Develop（30–35%）、AIF-C01 第 2–3 章（24% + 28%）、AIP-C01 第 1 章（31%）。

共同核心：六件所有考綱都在問的事

一、結構化輸出，不是「請用 JSON 回我」

CCAR-F 的 Domain 4 名字裡就有 Structured Output，而且給了最具體的答案：用 tool_use 加 JSON schema，不要求 Claude 輸出 JSON 字串。tool_choice 三個選項各有適用場景——"auto" 讓模型自己決定（可能回純文字）、"any" 保證會呼叫某個工具、{"type": "tool", "name": ...} 強制特定工具。

這個 domain 最容易被漏掉的一句是：tool_use 消除 JSON 語法錯誤，但不消除語意錯誤（例如 line items 加總不等於 total），語意驗證要另外實作，並配 validation-retry loop。

其他家的等價考點：

• AIP-C01 把「JSON Schema 結構化輸出」放進 3.1 的降低幻覺組合拳裡——官方要的是 Knowledge Base grounding + 事實查核 + 信心分數 + 結構化輸出四件一起，不是單一技巧
• NCP-GENL 用的是完全不同的詞：設計包住 LLM 的模組，內建驗證與受限解碼，以提升一致性、減少幻覺。「受限解碼」（constrained decoding）這個詞只有 NVIDIA 這張用
• AI-500 沒有「結構化輸出」這個措辭，最接近的是工具生態那條的工具結果驗證與品質檢查

要點回指：CCAR-F Domain 4（20%）、AIP-C01 第 3 章（20%）、NCP-GENL Prompt Engineering（13%）、AI-500 Develop（30–35%）。

二、防禦性 prompt：注入、越獄、輸入清洗

四家都考，措辭各自不同，但講的是同一個信任邊界問題。

• AWS AIF-C01 把 prompt 的風險逐一命名：曝露（exposure）、poisoning、hijacking、jailbreaking，這組四字詞在其他家考綱裡找不到
• AIP-C01 要求得更細：3.1 的 prompt injection 與 jailbreak 偵測、輸入清洗、安全分類器、自動化對抗測試，以及縱深防禦的四層（Comprehend 前置過濾、模型端 guardrail、Lambda 後處理、API Gateway 回應過濾）
• AI-500 的措辭是進階 prompt 工程裡的防禦性準則，只有短短一詞，但它同一塊還有 shift-left 安全與 AI Red Teaming Agent
• AB-100 從架構師角度切：分析方案與 AI 的漏洞與緩解，含 prompt manipulation
• CCDV-F 的 Security and Safety（8.1%）寫的是 prompt injection 的認知與緩解、jailbreak 防禦、不可信輸入處理；輸入清洗則被放在 Prompt and Context Engineering 那 11% 的 prompt 原則裡

注意 CCDV-F 這個切法：輸入清洗被歸類成 prompt 原則而不是安全機制。這是個很值得記的分類——它把「怎麼組 prompt」跟「怎麼防注入」當成同一件事的兩面。站內的 agent 安全：prompt injection 與信任邊界有實務脈絡。

要點回指：AIF-C01 第 3 章（28%）與第 5 章（14%）、AIP-C01 第 3 章（20%）、AI-500 Develop（30–35%）與 Secure（20–25%）、AB-100 Deploy（40–45%）、CCDV-F Security and Safety（8.1%）。

三、動態 context 注入與 grounding

AI-500 的措辭最直接：進階 prompt 工程那條裡明列動態 context 注入，同一塊的記憶與 context 管理則要求掌握 context 的累積、檢索、注入、壓縮四個動作，加上供多 agent 消費的知識整合（搜尋、RAG、MCP 可取得的來源、語意搜尋）。

其他家：

• AIP-C01 的 1.6 有一組「互動式脈絡」的具體做法：Step Functions 的澄清流程、Comprehend 意圖辨識、DynamoDB 存對話歷史
• CCAR-F 給的是反面教訓——subagent 不會自動繼承 coordinator 的對話歷史，必須在 prompt 裡明確傳入；以及 Domain 5 的 structured facts block：客服情境裡日期、金額、訂單號碼、狀態這類事實性資料不該被摘要掉，要以未壓縮的區塊每次附上
• AIF-C01 是唯一把 context engineering 直接列成一條目標的（2.1.5），而且是 2026 年 4 月 30 日 v1.1 才新增的——目錄裡沒有這個詞的教材就是舊版

站內的 context engineering 指南與 Stanford CS146S 的 context engineering是這塊最直接的背景補充。

要點回指：AI-500 Develop（30–35%）、AIP-C01 第 1 章（31%）、CCAR-F Domain 5（15%）、AIF-C01 第 2 章（24%）。

四、壓縮、修剪與快取——這塊實際上是成本考題

這是本文最想強調的一節：多數人把 context 管理當成品質問題，但考綱把它當成本與可靠性問題。

• CCDV-F 的 11% 裡，第一條是 token 預算與成本管理（用量追蹤、成本建模、prompt caching 與 cache check-pointing），第二條是防止 context 漂移與膨脹（工具輸出修剪、compaction），第三條是用 subagent 或多步流程做 context 隔離。三條有兩條半在講成本
• AIP-C01 的 4.1 更明確：token 估算與追蹤、context window 最佳化、回應長度控制、prompt 壓縮與 context pruning，加上語意快取、結果指紋、邊緣快取、確定性請求雜湊、prompt caching
• AI-500 的編排塊列了三種快取：prompt caching、語意快取、回應快取；可觀測性塊則有 token 用量最佳化（token 上限、迴圈控制、工具呼叫）
• AIF-C01 在 FM 選擇準則裡把 prompt caching 列為選型因素之一，並在 v1.1 新增 token 計價與成本效能關係
• CCAR-F 的做法偏操作：/compact 壓縮、把關鍵發現存 scratchpad 檔案、用 subagent 探索只回傳摘要

三家用三個詞講同一件事：Anthropic 說 compaction，AWS 說 prompt 壓縮與 context pruning，微軟說壓縮。看到任何一個，另外兩個就不用重讀。

要點回指：CCDV-F Prompt and Context Engineering（11.0%）、AIP-C01 第 4 章（12%）、AI-500 Develop（30–35%）與 Evaluate（20–25%）、AIF-C01 第 2–3 章。

五、prompt 的生命週期：版控、library、審核

這是考綱明顯領先多數團隊實務的一塊。 考試把 prompt 當成一個有版本、有審核流程、有儲存庫的資產，而不是程式碼裡的字串常數。

• AIP-C01 的 1.6 給了最完整的一份：參數化模板、審核流程、S3 儲存庫、CloudTrail、CloudWatch Logs，以及 Bedrock Prompt Flows 的 prompt 鏈、條件分支與可重用元件
• AIF-C01 用 Bedrock Prompt Management 做 prompt 版本管理（3.2.5）
• AI-500 的措辭是 prompt 生命週期管理
• AB-100 從治理角度：提供 prompt library 的建立準則（Plan 那塊）
• CCDV-F 把 prompt 版控列在設定管理裡，跟 CLAUDE.md、settings.json、模型版本釘選並列

AB-620 的角度不一樣，值得單獨標：它的自訂 prompt 是產品裡的一個可設定物件——在 topic 裡用自訂 prompt 設定進階回應，以及讓自訂 prompt 使用 Foundry model catalog。低程式碼線考的是「在哪個 UI 設定它」，不是「怎麼管理它的版本」。

要點回指：AIP-C01 第 1 章（31%）、AIF-C01 第 3 章（28%）、AI-500 Develop（30–35%）、AB-100 Plan（25–30%）、CCDV-F Applications and Integration（33.1%）、AB-620 Plan and configure（30–35%）與 Integrate（40–45%）。

六、prompt 改了，怎麼證明它變好

四家都要求你能回答「這個 prompt 改動有沒有效」，而且都不接受「看起來比較好」。

• AI-500 的措辭最乾淨：針對記憶、知識、工具、prompt 分別做評估——四個維度分開評，不混在一起
• AIP-C01：prompt 的 QA 與回歸測試（1.6）、prompt 測試框架與版本比較（5.2）、用 Prompt Management 與 Prompt Flows 做 A/B、LLM-as-a-judge 自動評估（3.4），以及 CloudWatch 追蹤 prompt 有效性與幻覺率
• CCAO-F 把「迭代 prompt 以改善品質」放在權重最高的 Output Evaluation（21%）而不是 Prompting（14%）——這個歸類本身就是考點的暗示
• CCDV-F 的 Eval, Testing, and Debugging 只有 2.6%，是八個領域裡最小的一塊

最後那條要小心解讀：CCDV-F 的 eval 權重低，不代表 Anthropic 認為 eval 不重要——官方對這張的 Intended Audience 描述裡就寫了「設計並執行 eval」是應具備能力。它只是不在這張考試的計分重心上。

站內的 prompt 迭代方法可以補這塊的實作流程。

要點回指：AI-500 Evaluate（20–25%）、AIP-C01 第 1 章（31%）／第 3 章（20%）／第 5 章（11%）、CCAO-F Output Evaluation（21%）、CCDV-F Eval, Testing, and Debugging（2.6%）。

同一件事，四家四個名字

NVIDIA 那欄大量「未點名」不是疏漏，是 NCP-GENL 的 Prompt Engineering 只有三條目標：模板設計（含 CoT 與 prompt learning）、zero／one／few-shot、受限解碼模組。官方 PDF 在這塊還跳過了 2.3 這個編號、沒公布內容——這是一份不完整的考綱，準備時要有心理準備。

考試怎麼問，跟實務怎麼做

這一節是本文的重點。前面六件事在實務上都成立，但考試問它們的方式跟你平常做事的方式不一樣。

一、考試給症狀要你選診斷，不會給你 prompt 讓你改。 AI-500 把四種 context window 失效模式逐一命名（sliding-window amnesia、summary drift、vector-only recall、entity continuity），命名的用途就是出題：給你「跨輪次的人名指涉接不上」，要你答 entity continuity。這種題型獎勵詞彙，不獎勵手感。

二、「先改 prompt」通常是錯誤選項。 這是 CCAR-F 最重要的一條，也是最反工程師直覺的一條：當某個工具呼叫順序是業務邏輯的必要條件時，正確答案是用程式碼強制執行，不是在 prompt 裡加更多指示。 官方的例子是「必須先驗證客戶身分才能退款」——只在 prompt 寫「請先呼叫 get_customer」，一定機率會被跳過；正確做法是在 lookup_order 與 process_refund 的 hook 裡檢查 get_customer 是否執行過。

這條在實務上同樣成立，而且是本文所有內容裡最該直接搬進工作的一條。 prompt 是機率性的，業務規則需要確定性；能用程式碼保證的事，不要交給 prompt。

三、模糊指示無效，明確標準才有效。 CCAR-F 明講「只回報高信心的問題」或「保守一點」不會降低 false positive 率，要改成逐條列舉：REPORT 什麼、SKIP 什麼、什麼算 HIGH、什麼算 MEDIUM。這條考試與實務完全一致，可以直接用。

四、工具選錯的 root cause 是描述不清，不是缺 routing classifier。 這是 CCAR-F sample question 反覆出現的陷阱——看到「agent 選錯工具」的情境，先想工具描述，不要先加一層分類器。站內的 自動最佳化工具描述是同一個主題的實作面。

五、考綱把 prompt 當受治理的資產，多數團隊還把它當字串常數。 AIP-C01 要求 S3 儲存庫、審核流程、CloudTrail 稽核、回歸測試；AB-100 要求你能訂出 prompt library 的建立準則。這塊是考綱領先實務的地方——如果你的團隊 prompt 散在程式碼裡沒有版本，考試會問到你沒做過的事。

六、沒有任何一張要你現場寫 prompt。 這十張全是選擇題（CCAR-F 是單選與複選混合，每題標明選幾個）。所以「prompt 寫得好」不加分，「說得出為什麼這樣寫」才加分。 準備方式要跟著改：與其收集提示詞模板，不如針對每個技巧問自己「它解決哪個失效模式、什麼時候不該用」。

要點回指：AI-500 Evaluate（20–25%）、CCAR-F Domain 1（27%）與 Domain 4（20%）、AIP-C01 第 1 章（31%）、AB-100 Plan（25–30%）。

不能互相取代的部分

AI-500 獨有：四種 context window 失效模式的名詞、「prompt 生命週期管理」這個措辭、prompt／語意／回應三種快取的分法、「針對記憶、知識、工具、prompt 分別評估」的四維切法。

AWS 獨有：Bedrock Prompt Management 與 Bedrock Prompt Flows 這兩個產品（版本管理、prompt 鏈、條件分支、可重用元件）、prompt 風險四詞（曝露／poisoning／hijacking／jailbreaking）、「prompt 壓縮與 context pruning」這個條目、以及把 context engineering 直接列成一條考試目標（AIF-C01 2.1.5，v1.1 新增）。

NVIDIA 獨有：受限解碼（constrained decoding）、prompt learning（小資料集或專門領域）、以及把 Prompt Engineering 當成一個 13% 的獨立領域這件事本身。

Anthropic 獨有：tool_choice 的三個選項與各自語意、「tool_use 消除語法錯誤但不消除語意錯誤」、validation-retry loop、structured facts block（不該被摘要的事實區塊）、/compact、context: fork、以及 provenance 要求——兩個來源數字衝突時不要選一個，兩個都保留並標注來源。這些多半是 SDK 與產品層細節，換平台就不成立。

微軟低程式碼線獨有：prompt action、prompt 與回應型 agent 這個 agent 分類（跟任務型、自主型並列）、以及讓自訂 prompt 綁 Foundry model catalog。

一份練習清單

這份清單對應上面六件事，做完能蓋掉共同核心，蓋不掉獨有那節：

1. 拿一個抽取任務，用 JSON schema 強制結構化輸出，再刻意餵一份會讓總和對不上的資料，確認語法正確但語意錯誤會發生 →（一）
2. 在同一個抽取器外面加 validation-retry loop，最多重試三次，記錄每次失敗原因 →（一）
3. 對自己的 agent 做一次注入測試：把惡意指示藏在工具回應裡，看它會不會照做；再加輸入清洗與輸出過濾各測一次 →（二）
4. 把一段長對話拆成「不可摘要的事實區塊」與「可壓縮的歷史」，比較兩種做法在第 20 輪的事實正確率 →（三）
5. 對同一個工作負載量測三種成本：無快取、prompt caching、語意快取，並寫下各自的失效條件 →（四）
6. 把所有 prompt 移出程式碼，放進一個有版本號的儲存庫，改動走 review；至少留一次「回滾到前一版」的紀錄 →（五）
7. 為一個 prompt 建 10–20 題的回歸測試集，改動前後各跑一次，用 LLM-as-a-judge 加人工抽查，說得出「變好」的證據 →（六）
8. 最後做一次反向練習：找一個你目前**用 prompt 指示模型「一定要先做 X」**的地方，改成程式碼強制執行 →（考試怎麼問那節的第二條）

補獨有考點的最短路徑：AWS 線讀 AIF-C01 與 AIP-C01 的官方 exam guide；微軟線讀 AI-500 study guide；NVIDIA 線只有認證頁與 PDF；Claude 線讀 Agent SDK 文件。

只讀一份的話，讀哪一份

AIP-C01 的官方 exam guide。 理由是它把 prompt 的治理面寫得最完整——1.6 一節就涵蓋參數化模板、審核流程、儲存庫、稽核日誌、QA 與回歸測試、prompt 鏈，這些在其他家考綱裡是散落的一兩個詞。而且它是免費公開網頁。

但它的偏誤也最明顯：整份繞著 Bedrock 的產品名轉。想要不綁產品的版本，讀 CCAR-F 的 Domain 4 與 Domain 5——那兩塊的概念（結構化輸出、lost-in-the-middle、事實區塊、provenance）換平台仍然成立，只有 API 名稱要換。

會過期的東西（下次複查看這裡）

參考資料

• AWS AIF-C01 官方 exam guide（五章權重與逐條目標）
• AWS AIF-C01 exam guide 修訂紀錄（v1.1 新增條目）
• AWS AIP-C01 官方 exam guide（含 1.6 prompt 工程與治理）
• 微軟 AI-500 官方 study guide（進階 prompt 工程與 context 管理條目）
• 微軟 AB-100 官方 study guide（prompt library 建立準則）
• 微軟 AB-620 官方 study guide（自訂 prompt 與 Foundry model catalog）
• NVIDIA NCP-GENL 官方認證頁（十個領域與 Prompt Engineering 13%）
• NVIDIA NCA-GENL 官方認證頁（五塊權重）
• Claude Certified Associate – Foundations 官方認證頁（含 exam guide 下載）
• Claude Certified Architect – Foundations 官方認證頁（含 exam guide 下載）
• Claude Certified Developer – Foundations 官方認證頁（含 exam guide 下載）
• Claude Agent SDK 文件

站內相關

• 多 agent 架構的考點交集
• 2026 年工程師 AI 證照有哪些
• Claude Certified Associate（CCAO-F）備考路徑
• Claude Certified Architect Foundations 考試完整指南
• Claude Certified Developer（CCDV-F）備考路徑
• 微軟 AI-500 備考路徑
• AWS AIF-C01 備考路徑
• AWS AIP-C01 備考路徑
• NVIDIA NCP-GENL 備考路徑
• context engineering 指南
• prompt engineering 迭代方法
• Stanford CS146S：context engineering
• 當 prompting 不再有效
• agent 安全：prompt injection 與信任邊界
• 自動最佳化工具描述
• agent 的 context 與記憶失效