從 API First 到 AI First

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是 API First？

• A簡: 以領域服務為核心設計穩健介面，優先規劃 API 再落地應用與 UI。
• A詳: API First 是一種開發策略，先從業務領域與狀態機出發，設計「穩健、可授權、可重用」的 API 規格（含資源模型、認證與授權 SCOPE、錯誤與狀態碼），再由前端或其他應用消費。它避免 UI 需求牽動 API 走向，確保介面能長期重用與擴充，也是 AI 時代讓 LLM 能安全高效使用後端能力的前提。良好的 API First 能帶來更好的 DX 與 AI DX。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q14, B-Q7, B-Q15

A-Q2: 什麼是 AI First？

• A簡: 把 LLM 等 AI 能力視為一等公民，主動規劃 AI 角色與位置。
• A詳: AI First 指在產品與架構規劃期就把 AI（LLM、RAG、推薦等）視為關鍵元件，規劃其在流程、介面、資料與服務中的角色，例如在 MVC 中引入 Copilot/Agent、以對話驅動任務（tool use）、用 RAG 補全知識、以 AI Pipeline 管理模型與資料。它不是取代工程，而是重構分工：精確計算交給服務，意圖理解交給 LLM。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, B-Q5, B-Q16

A-Q3: API First 與 AI First 有何差異與關係？

• A簡: API First打底可重用介面；AI First在其上疊加智能與對話能力。
• A詳: API First著重以領域驅動設計出「正確可重用」的服務界面；AI First則是在成熟介面上引入 LLM 推理、工具使用（function calling）、RAG 與 Copilot/Agent，使應用能用對話理解意圖並調用服務。兩者並非取代關係：API First保證邊界與一致性，AI First賦予感知與推理，組成可被 AI 高效利用的系統。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q5, B-Q15

A-Q4: 為什麼在 AI 時代，基礎功夫更重要？

• A簡: AI 量產程式碼，抽象設計、架構決策與工程紀律更關鍵。
• A詳: 當 AI 能加速樣板與重複程式撰寫，競爭力轉移到抽象化設計品質與架構治理。若 API 設計鬆散、授權邏輯含糊、狀態機不明，LLM 只會放大不確定性。基礎包含：良好 API 設計、清楚的 Pipeline、可測可觀測、資料與模型治理，以及正確把精確計算與意圖理解分工。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q14, B-Q7, B-Q16

A-Q5: 什麼是 AI DX（面向 AI 的開發者體驗）？

• A簡: 讓 AI 易懂、易用、可預測使用你的 API 的設計品質集合。
• A詳: AI DX 是讓 LLM（而非人類）作為你的 API 消費者時，也能「讀懂與正確使用」的體驗品質，包括：規格清晰（OpenAPI/描述充分）、資源/動詞/狀態碼一致、錯誤可判斷、授權與邊界明確、原子化狀態轉移、範例豐富。AI DX 越好，越能降低提示複雜度、減少幻覺與錯用、提升工具使用成功率。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, B-Q3, A-Q14

A-Q6: 為何以 LLM 改善 UX 被稱作「降維打擊」？

• A簡: LLM 直接理解意圖與脈絡，越過傳統 UI 引導限制達成目標。
• A詳: 傳統 UX 仰賴介面引導與流程優化，常靠行為數據事後推測意圖；LLM 能在當下理解自然語言意圖、推理上下文，並主動組合行動（API）代客操作。對「意圖理解」這一維度，LLM 的能力與傳統方法不在同個維度，比喻為「降維打擊」。最佳策略是讓 AI 與 UI 互補，該用對話就對話，該用控件仍用控件。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q17, B-Q18

A-Q7: 「提出要求」與「下指令」有何不同？

• A簡: 提出要求重意圖推理；下指令重精確命令與已知動作。
• A詳: 下指令是假設使用者已知命令與參數；提出要求則讓使用者描述目標與脈絡，LLM 先推理意圖，再選擇與組合工具（API）完成任務。前者像傳統表單/指令系統；後者依賴 LLM 的語意理解、規劃與 function calling 能力。AI First 的關鍵，就在將「要求」轉譯為可執行行動序列。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q3, B-Q4

A-Q8: 為何「抽象化設計」是決勝點？

• A簡: 高品質抽象能被高效重用，AI 量產碼也難取代設計優勢。
• A詳: AI 可快速產出實作，但不會自動給你正確的抽象邊界與組合。設計清晰的 Domain、狀態轉移、服務界面與協作模式，能讓人與 AI 都更有效率。抽象決定了可擴充性、可測試性、可組裝性，也決定 LLM 是否能穩定地「用對工具」。劣質抽象只會放大不確定性與維運成本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q7, B-Q5

A-Q9: 當 coding 不再是瓶頸，架構決策為何成關鍵？

• A簡: 架構決定分工、部署、治理與成本，影響 AI 成效極大。
• A詳: 架構：定義了精確計算與意圖理解的邊界、AI 的佈局（Copilot/Agent、RAG）、資料與模型的生命週期、效能與成本模型（Token/GPU/NPU）、安全治理與可觀察性。錯誤架構會讓 AI 成本暴衝、不確定性上升且難以測試；良好架構則可漸進擴張與風險可控。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q16, B-Q21

A-Q10: Copilot 與 Agent 的差異是什麼？

• A簡: Copilot輔助正駕駛（控制器）；Agent主動規劃與執行任務。
• A詳: Copilot 在既有流程旁提供建議、解說、代辦部分任務，仍以 Controller/使用者為主；Agent 則能自行規劃步驟、多步推理、選擇工具、對話協商，必要時再請人類確認。現階段多採 Copilot 優先、Agent 漸進導入；何時翻轉，取決於模型推理、成本與可靠性成熟度。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q5, B-Q4, A-Q2

A-Q11: 什麼是 Function Calling／Tool Use？

• A簡: 讓 LLM 自行判斷並帶參數呼叫外部「工具」完成任務。
• A詳: Function Calling（OpenAI）或 Tool Use（Anthropic）是一種機制：你宣告可用工具（API 規格、參數約束），LLM 依對話意圖產生計劃，組裝工具呼叫並填好參數，執行後再吸收結果續推理。它把純對話轉成可執行行為，是從聊天到行動的關鍵橋樑。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3, B-Q4, C-Q4

A-Q12: 什麼是 RAG（檢索增強生成）？

• A簡: 先檢索相關知識，再把片段餵給 LLM 彙整回答。
• A詳: RAG 的核心流程：對查詢與文件做嵌入、在向量庫檢索最相關片段、把片段＋問題包入提示，交給 LLM 生成答案。它能用外部專屬知識補全模型訓練的缺口，降低幻覺與更新成本，常見於知識庫問答、內規查詢、文件助理等場景。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, B-Q10, C-Q7

A-Q13: 什麼是 Prompt Engineering？

• A簡: 以可重用模板化提示，驅動 LLM 穩定輸出與正確行動。
• A詳: 提示工程包含：角色/任務界定、輸入輸出格式（如 JSON Mode）、分步思考、Few-shot 示例、工具清單、約束與驗收規則。實作上常做模板化與參數化，搭配系統/開發者/使用者三層訊息與記憶策略，讓輸出可預期、可驗證、可維護。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q13, B-Q1, C-Q3

A-Q14: 什麼是「狀態機導向」的 API 設計？

• A簡: 以明確狀態與轉移定義原子 API，確保一致性與授權邊界。
• A詳: 先定義資源狀態與合法轉移（如訂單：新建→已付款→完成/取消），每個轉移是一個原子 API；誰能觸發由授權（SCOPE）決定。所有延伸捷徑 API 也必須由基本轉移組合而成。好處：不易被誤用、易測試、易授權與審計，尤其適合 LLM 使用工具。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, C-Q8, D-Q1

A-Q15: APIKEY 與 SCOPE 在 AI 場景扮演何種角色？

• A簡: 定義誰可執行哪些轉移，限制工具使用範圍，預防越權。
• A詳: 當 LLM 代替使用者行動，APIKEY 與 SCOPE 必須精準映射角色與操作權限，例如：僅允許查詢、不可更新；僅在特定狀態可轉移；敏感欄位不可寫。這讓工具清單在 AI 端就有天然邊界，防止錯用或被提示注入誘導越權。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, D-Q9, C-Q2

A-Q16: 為何 CRUD 式 API 不利 AI 使用？

• A簡: 缺乏領域約束與原子轉移，易被誤用并破壞狀態一致性。
• A詳: 通用 CRUD 開放所有欄位讀寫，但缺少「情境與限制」，AI 難以推斷允許行為，容易更新出非法組合（如直接改狀態欄位）。狀態機導向 API 才能提供 LLM 清楚的工具邊界、可恢復的錯誤與可測的行為收斂。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, D-Q1, B-Q15

A-Q17: 「圖靈測試」對本文的啟示是什麼？

• A簡: 把 LLM 視為意圖理解的實作，與真人對話介面等價。
• A詳: 文中將 LLM 視作「意圖理解」這個介面的實作之一，另一種實作是人類客服。當 LLM 逐步接近能以對話被視作真人的程度，應用即可在此介面上替換實作（OOP 思維）。設計上應依賴介面、避免綁死具體實作，才能平滑升級模型。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q5, B-Q4, A-Q10

A-Q18: 什麼是 AI Pipeline？與 CI/CD 三循環關係？

• A簡: 在應用、設定、環境之外，增加資料/模型/算力的流水線。
• A詳: 除 Application/Configuration/Environment 外，AI 引入第四循環：Data/Model/Compute。包括資料收集清洗、嵌入與索引、模型訓練與部署、推論資源調度與版本回滾。以 GitOps 管理，讓 AI 元件像程式碼一樣可追蹤、可回復、可審計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q16, B-Q23, C-Q10

A-Q19: 雲端算力、邊緣算力與本地模型差異？

• A簡: 雲端彈性佳成本按用量；邊緣低延遲隱私佳；本地可控性最高。
• A詳: 雲端（OpenAI、Azure 等）易用、模型強大、按 Token/GPU 小時計價；邊緣（NPU/AI PC/手機）延遲低、隱私強、合適小模型；本地（自建 GPU/混合）可控性與資料安全最高，但需運維與資本。場景常採混合，按任務分流以控成本與可靠性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q21, C-Q9, D-Q6

A-Q20: 什麼是個人化與滿意度萃取的 LLM 應用？

• A簡: 從對話/歷程中擷取喜好與情緒指標，回寫系統活用。
• A詳: 以 LLM 直接解析單次或多次對話上下文，擷取喜好描述、偏好條件與情緒/滿意度分數，寫入客戶或訂單註記，後續推薦與服務再用。相對傳統問卷與統計，屬「當下推理」而非事後估計，新維度補強 UX 與個人化能力。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q17, C-Q5, D-Q3

A-Q21: 為何 LLM 不應負責精確計算？

• A簡: 語言模型偏推理與語義；精算應交由可驗證演算法。
• A詳: LLM 在數值計算上不穩定、成本高且可驗證性差。設計時應把四則運算、折扣試算、會計與合規等精算工作交給服務/函式庫；LLM 專注意圖理解、規劃、說明與協調。這種分工也利於測試與治理，避免把不可預測性帶入關鍵路徑。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q18, D-Q2, C-Q4

A-Q22: 為何「架構師也要 DevOps」在 AI 時代更重要？

• A簡: 架構決策落地到可自動化交付，才能治理 AI 全生命週期。
• A詳: AI 應用多出資料、模型與算力面向，牽涉版本、成本、安全與監管。架構師需把設計轉化成可觀測、可回滾、可審計的 Pipeline 與平臺（GitOps/AIOps），統一道路才可能持續評估與優化 AI 能力，避免成為不可控黑箱。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, B-Q16, C-Q10

Q&A 類別 B: 技術原理類

B-Q1: LLM 如何從對話中解析使用者意圖？

• A簡: 透過上下文語義建模與步驟化推理，抽出目標與限制。
• A詳: 技術原理說明：LLM 以注意力機制捕捉語義關聯，結合系統提示指引任務邊界，將語句映射成隱含意圖向量。關鍵步驟或流程：讀取上下文→抽取任務（如「購物預算內下單」）→辨識必要資訊→缺口追問→產生計畫。核心組件介紹：系統/開發者/使用者提示層、對話記憶、動作候選（工具清單）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, A-Q11, B-Q4

B-Q2: LLM 的 Json Mode 如何保證結構化輸出？

• A簡: 以嚴謹格式提示與模式校驗，引導模型輸出合法 JSON。
• A詳: 技術原理說明：Json Mode 讓模型在解碼時遵循結構約束，降低自然語言噪音。關鍵步驟或流程：定義模式（欄位、型別、選填）→模板化提示（嚴禁多餘文字）→模型輸出→應用層驗證與重試。核心組件介紹：模式定義（JSON Schema）、模型解碼策略、結構驗證器與錯誤處理器。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q3, A-Q13, B-Q3

B-Q3: Function Calling 的執行流程是什麼？

• A簡: 宣告工具→模型規劃→帶參數調用→接收結果續推理。
• A詳: 技術原理說明：在提示中註冊工具（函式名、參數結構、說明），模型基於意圖選擇並產生參數。關鍵步驟或流程：1. 工具註冊 2. 任務解析 3. 參數擬合 4. 執行函式（API） 5. 回傳結果 6. 二次推理或回覆。核心組件介紹：工具目錄、序列化參數、執行器（API 客戶端）、回傳資料接入上下文機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, C-Q4, B-Q4

B-Q4: Workflow／多步推理背後的機制是什麼？

• A簡: 以規劃器拆解子任務，循環「思考—行動—觀察」。
• A詳: 技術原理說明：規劃器（可由 LLM 自身扮演）把複雜任務拆成多步，每步用工具行動得到觀察，再更新內部狀態。關鍵步驟或流程：目標解析→步驟規劃→行動調用→觀察整合→停止條件判定。核心組件介紹：規劃器、記憶體（短/長）、工具集合、停止器（成功/超步/置信度）。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q10, B-Q3, C-Q5

B-Q5: Copilot 架構在 MVC 中如何設計？

• A簡: 以 Controller 為主、Copilot 輔助，並行處理提示與行動建議。
• A詳: 技術原理說明：MVC 中加入 Copilot 通道，UI 事件/遙測餵給 LLM 生 Hint/Task，Controller 掌控關鍵決策。關鍵步驟：事件收集→摘要壓縮→提示生成→建議與工具調用→人機協作確認。核心組件：事件匯流排、提示模板庫、工具代理、權限閘門、觀測/回饋回路。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, C-Q5, B-Q16

B-Q6: 「安德魯小舖 GPTs」的技術構成？

• A簡: 以電商 API + OpenAPI 規格，供 GPTs 以工具使用完成任務。
• A詳: 技術原理說明：以後端電商 API 為域服務，透過 OpenAPI 提供給 GPTs 做 function calling。關鍵步驟：規格清理（AI DX）→權限與狀態機落實→上架 GPTs 串規格→實測意圖到行動閉環。核心組件：Web API、OpenAPI/Swagger、OAuth2、GPTs 工具描述、日誌與審計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, C-Q2, A-Q5

B-Q7: 以狀態機設計 API 的完整流程？

• A簡: 定義狀態與轉移→原子 API→權限映射→測試與審計。
• A詳: 技術原理說明：以有限狀態機將域約束具體化。關鍵步驟：盤點業務狀態→列出合法轉移與前置條件→為每個轉移定義原子 API→把角色/Scope 套到轉移→以契約測試與雙寫審計驗證。核心組件：狀態圖、轉移 API、授權策略、契約測試、事件日誌。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, C-Q8, D-Q1

B-Q8: 如何設計可靠的授權與邊界以保護工具使用？

• A簡: 翻譯角色到 Scope，綁定狀態轉移，建立防逃逸與速率限制。
• A詳: 技術原理說明：以最小權限原則實作 OAuth2/Key+Scope，將操作能與狀態合法性綁定。關鍵步驟：角色權限分析→Scope 與資源動詞對應→邊界檢查（狀態/數據）→速率與異常熔斷。核心組件：授權伺服器、API 閘道、防火牆規則、審計日誌與告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, D-Q9, C-Q2

B-Q9: RAG 的檢索與增強流程原理？

• A簡: 嵌入向量化檢索相關片段，再與問題同餵提示生成答案。
• A詳: 技術原理說明：以語義嵌入把文本轉成向量，近鄰搜尋取回相關片段，拼接成上下文促使 LLM 聚焦事實。關鍵步驟：切塊/清洗→嵌入→索引→查詢→重排序→組 Prompt→生成。核心組件：Embedding 模型、向量資料庫、重排序模型、檢索器與組裝器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q7, D-Q3

B-Q10: 向量化（Embedding）與向量資料庫如何運作？

• A簡: 把語義映射到高維向量空間，透過近鄰搜尋找相似內容。
• A詳: 技術原理說明：Embedding 模型把詞/句/段轉成向量；向量庫用索引（如 HNSW、IVF）加速相似度（餘弦、內積）搜尋。關鍵步驟：分段→向量化→建索引→查相似→取前 K。核心組件：Embedding 模型、ANN 索引、向量存儲、相似度度量與更新策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q7, D-Q3

B-Q11: Ranking/重排序在 RAG 中扮演何種角色？

• A簡: 用較強模型二次判斷相關性，提升取回片段的精準度。
• A詳: 技術原理說明：初排用向量相似度，重排用語言/跨編碼器模型重新評分與排序。關鍵步驟：初取前 N→重排器打分→取前 K→組上下文。核心組件：重排模型（如 Cross-Encoder）、特徵工程、閾值策略與實驗評測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, D-Q3, C-Q7

B-Q12: Prompt 模板化與參數化如何落地？

• A簡: 把角色/任務/格式抽象為模板，實時注入參數與上下文。
• A詳: 技術原理說明：將可重用的提示拆為模板片段，運行時組合上下文、工具清單與輸入參數。關鍵步驟：模板設計→變數定義→組裝→觀測輸出→A/B 與回歸測試。核心組件：模板引擎、提示庫、版本控制、測試治具與遙測。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q13, C-Q3, D-Q7

B-Q13: 如何評估與選型 LLM 模型？

• A簡: 依任務類型、推理力、延遲成本與治理工具綜合評估。
• A詳: 技術原理說明：用標準集（推理、程式、對齊）與業務集（真實任務）評測。關鍵步驟：任務定義→候選模型→離線評測→線上灰度→成本/效能分析。核心組件：評測數據集、指標（正確率、延遲、Token/推論成本）、灰度與觀測平臺。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q21, D-Q6, A-Q19

B-Q14: AI DX 友善的 API 規格要包含什麼？

• A簡: 清晰資源與動詞、狀態碼、錯誤語意、示例、OAuth2 與節流。
• A詳: 技術原理說明：讓 LLM 以規格自主學會何時用哪支 API。關鍵步驟：完善 OpenAPI 描述（含語義說明、示例、約束）→狀態依賴明確→錯誤可判斷→授權與節流可見。核心組件：OpenAPI/Swagger、例外模型、錯誤碼詞彙、Scope 列表與速率限制策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, C-Q2, D-Q1

B-Q15: DevOps + AIOps 的 Pipeline 如何設計？

• A簡: 將資料/模型/算力與應用管線並列，統一 GitOps 治理。
• A詳: 技術原理說明：在既有 CI/CD 上擴充 AI 管線：資料收集清洗→嵌入/索引→模型訓練/部署→推理資源調度。關鍵步驟：版本控制→自動化測試（契約/評測）→灰度釋出→觀測與回滾。核心組件：Git、CI/CD、特徵/嵌入任務、模型倉庫、向量庫、推理集群與監控。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q18, C-Q10, B-Q23

B-Q16: 傳統 UI 與 AI 對話介面如何互補？

• A簡: 控件處理確定性操作；對話處理意圖推理與模糊需求。
• A詳: 技術原理說明：把高確定、低語義負擔的操作留給 UI，把策略、意圖、個人化交給對話/LLM。關鍵步驟：任務分級→路由策略→人機協作點（確認/回退）→資料回寫。核心組件：路由器、Copilot 面板、提示模板、回寫與審計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, C-Q5, B-Q5

B-Q17: 預算約束推理與 API 組合策略如何運作？

• A簡: LLM 拆解目標，試算由服務完成，LLM 綜合規劃與說明。
• A詳: 技術原理說明：LLM 不做精算，僅負責規劃與決策；由後端 API 試算價格、折扣、庫存。關鍵步驟：收束需求→列方案→試算 API→比較→提出建議→執行下單。核心組件：價格/促銷服務、庫存服務、試算端點、規劃提示模板。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q21, C-Q4, D-Q2

B-Q18: 事件溯源與對話上下文如何管理？

• A簡: 將重大事件與摘要化對話持久化，供後續推理與審計。
• A詳: 技術原理說明：對話很長需摘要化，行動需要審計線。關鍵步驟：事件定義→對話壓縮（摘要/檢索片段）→關聯訂單/會員→可追蹤 ID→到期清理。核心組件：事件儲存、對話記憶、向量索引、關聯查詢、隱私控制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q5, D-Q8, B-Q9

B-Q19: 觀測性在 AI 應用中的要點是什麼？

• A簡: 度量提示/輸出、工具成功率、成本與延遲，建立可回溯性。
• A詳: 技術原理說明：將提示、模型回覆、工具調用、成本與錯誤納入遙測。關鍵步驟：定義指標→收集與關聯→SLO/告警→事後分析（提示/模型/規格）。核心組件：日誌與指標系統、追蹤（Trace）關聯、成本匯總、回放與紅藍軍測試。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q6, D-Q7, B-Q15

B-Q20: 成本模型（Token、GPU 小時）如何優化？

• A簡: 任務分流、壓縮上下文、模型分級、批次化與快取。
• A詳: 技術原理說明：用小模型處理檢索/分類，大模型做最終推理；上下文壓縮與片段選擇。關鍵步驟：路由策略→提示壓縮→快取/重用→批量請求→觀測調優。核心組件：模型路由器、RAG、快取層、批處理器、成本儀表板。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, D-Q6, B-Q13

B-Q21: 安全性：越權、提示注入與對抗詐騙如何防護？

• A簡: 最小權限、輸入淨化、工具白名單、輸出驗證與人工確認。
• A詳: 技術原理說明：LLM 容易受注入與社工攻擊，必須有多層控制。關鍵步驟：Scope 最小化→輸入/輸出安全檢查→工具白名單→關鍵操作多因子/人工確認→審計。核心組件：授權系統、內容安全、策略引擎、風控、審計。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q8, D-Q9, A-Q15

B-Q22: 模型與向量庫更新/回滾的機制？

• A簡: 版本化模型與索引，灰度釋出，異常時快速回退。
• A詳: 技術原理說明：將模型/索引視為可部署工件。關鍵步驟：版本編號→相容性測試→灰度→觀測→回滾策略（熱切換/雙寫）→資料遷移。核心組件：模型倉庫、索引倉庫、部署編排、健康檢查與回滾器。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q15, D-Q10, C-Q10

B-Q23: 個人化與情緒萃取的技術機制？

• A簡: 以關鍵句/特徵抽取與規則/小模型判斷，寫回結構化欄位。
• A詳: 技術原理說明：從對話抽取喜好屬性、意圖與情緒，再用結構化模式回寫。關鍵步驟：定義欄位→提示/小模型分類→信心分數→寫回與標注→後續決策使用。核心組件：提示模板、輕量分類模型、欄位規格、註記 API、審核介面。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q20, C-Q5, D-Q3

Q&A 類別 C: 實作應用類（10題）

C-Q1: 如何把既有 Web API 接上 GPTs（OpenAI）？

• A簡: 整理 OpenAPI 規格與授權，於 GPTs 設定工具讓模型調用。
• A詳: 具體實作步驟：1) 完整撰寫 OpenAPI/Swagger（資源、狀態碼、示例）2) 實作 OAuth2/Key 與 Scope 3) 在 GPTs 內新增「Actions」，上傳或連結 OpenAPI JSON 4) 設定驗證方式與環境 URL 5) 測試 function calling。關鍵設定片段：OpenAPI 中以 description 明確約束；OAuth2 flow 指定 tokenUrl。注意事項：限制危險動作、速率限制、審計；最佳實踐：為每支 API 提供成功/失敗範例與語義描述。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q14, D-Q1

C-Q2: 如何撰寫 AI DX 友善的 Swagger？

• A簡: 強描述語意、列明前置條件與狀態轉移，示例齊備。
• A詳: 步驟：1) 在 paths/operations 加上人類可讀描述與前置條件 2) 為每個狀態轉移端點提供 request/response 示例 3) 清楚標明錯誤碼與修復建議 4) OAuth2 scopes 條列化 5) 使用 tags 分類工具。設定片段：OpenAPI 3.0 components/securitySchemes；responses.*.content.application/json.examples。注意：避免 CRUD 漏斗；最佳實踐：描述「何時用」、「不可用時的替代」。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, B-Q14, D-Q1

C-Q3: 如何用 Json Mode 萃取地址為結構化資料？

• A簡: 使用 JSON 模式與明確欄位格式，要求嚴格輸出。
• A詳: 步驟：1) 設計輸出格式（street_address/city/postal_code/country）2) 提示示範輸出 3) API 請求設定 response_format:{type:”json_object”} 4) 驗證與重試。程式碼片段（Node/Python 任擇其一）：
  • OpenAI: response_format={“type”:”json_object”}；解析後做欄位校驗。 注意事項：國際地址差異；最佳實踐：再加地址標準化服務比對郵遞區號。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q2, A-Q13, D-Q5

C-Q4: 如何設計購物清單的 Function Calling？

• A簡: 宣告 add/delete 函式與參數結構，允許模型組裝行動清單。
• A詳: 步驟：1) 定義函式：add(item,quantity)、delete(item) 2) 提示描述「對話→行動」規則與 JSON 格式 3) 啟用工具模式 4) 迭代測試。關鍵程式碼：tools=[{name:”add”,parameters:{item,quantity}},…]；根據 tool_calls 執行 API。注意事項：數量預設與單複數處理；最佳實踐：將最終狀態回饋給模型，生成總結與確認。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q3, B-Q4

C-Q5: 如何實作 Copilot 偵測使用者困難並提示？

• A簡: 蒐集操作事件，摘要成提示，由 LLM 生成 Hint/代辦行動。
• A詳: 步驟：1) 在前端/CLI 收集事件（重覆開說明、停滯）2) 將近端歷程摘要（避免爆 context）3) 以提示模板詢問「是否需協助」，並附工具清單 4) 顯示 hint 或提供代辦 5) 寫回事件與結果。程式碼：事件→隊列→提示組裝→LLM→結果處理。注意：避免過度打擾；最佳實踐：提供一鍵接受/拒絕與回饋按鈕。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q18, A-Q6

C-Q6: 在 .NET 以 Semantic Kernel 呼叫 Azure OpenAI？

• A簡: 建立 Kernel、註冊 Chat/Functions、以 Planner/Steps 執行。
• A詳: 步驟：1) 安裝 Microsoft.SemanticKernel 2) 設定 AzureOpenAI endpoint/key 3) 建 ChatCompletion 與 Functions（或插件）4) 組提示模板 5) 執行並處理 tool calls。程式碼片段：var kernel=Kernel.CreateBuilder().AddAzureOpenAIChatCompletion(…).Build(); 注意：環境機密管理；最佳實踐：將提示模板與函式分離版本化，加入遙測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q5, B-Q12

C-Q7: 如何建置簡易 RAG（爬文→嵌入→查詢→回答）？

• A簡: 切塊與清洗、向量化入庫、檢索片段與問題同餵模型。
• A詳: 步驟：1) 爬取文章與 Markdown 清洗 2) 分段（大小/重疊）3) 以 Embedding 模型生成向量 4) 寫入向量庫（如 FAISS、Qdrant）5) 查詢時向量化問題→取回前K→重排→組提示→生成答案。關鍵程式碼：embedding.encode(chunks)；db.search(query_vec,k)。注意：權限/隱私；最佳實踐：存原文引用，回答附來源。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, B-Q10, D-Q3

C-Q8: 如何設計狀態機並實作 REST API？

• A簡: 以狀態圖定義轉移，為每轉移提供原子端點與授權。
• A詳: 步驟：1) 定義資源狀態（新建/已付/完成/取消）2) 條列合法轉移與前置條件 3) 設計 /orders/{id}/pay、/complete、/cancel 等端點 4) 對應 Scope 5) 契約測試 6) 審計與監控。程式碼：Controller 中每轉移方法檢查狀態與權限。注意：避免直接 PATCH 狀態欄位；最佳實踐：用 409/422 表達違規轉移。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q7, D-Q1

C-Q9: 如何選擇與配置 AI 算力（雲、地端、邊緣）？

• A簡: 依任務與成本分層：強模型雲端，小任務邊緣，敏感用本地。
• A詳: 步驟：1) 任務分類（推理強度/延遲/隱私）2) 估算流量與成本 3) 選型（OpenAI/Azure、開源 LLM、自建 GPU/邊緣 NPU）4) 路由策略（大任務→雲、小任務→邊緣）5) 監控與調優。設定：模型路由表與熔斷降級策略。注意：資料主權；最佳實踐：離線前先降級到 SLM 或規則引擎。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q19, B-Q20, D-Q6

C-Q10: 如何將 AI 納入 CI/CD 與 GitOps 流程？

• A簡: 資料/嵌入/索引/模型全部版本化，灰度釋出可回滾。
• A詳: 步驟：1) 專案化資料管線（ETL、清洗、嵌入任務）2) 建索引/模型倉庫 3) 自動化評測（準確率/延遲/成本）4) 灰度釋出與觀測 5) 異常回滾。設定：多環境變數（dev/stage/prod）、模型/索引 tag。注意：Prompt/工具規格同樣版本化；最佳實踐：以 PR 驗收與回放測試把關。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q18, B-Q15, B-Q22

Q&A 類別 D: 問題解決類（10題）

D-Q1: LLM 誤用 API 造成資料不一致怎麼辦？

• A簡: 症狀：非法狀態與數據錯亂。以狀態機與授權邊界補強。
• A詳: 問題症狀描述：出現越權更新、直接改狀態欄位、非法轉移。可能原因分析：CRUD 式 API、缺少 Scope 與狀態驗證、規格不清。解決步驟：1) 重構為狀態機轉移 API 2) 落實 Scope 與前置條件檢查 3) 錯誤碼明確 4) 審計追蹤與回補工具。預防措施：契約測試、紅隊提示測試、限速與關鍵動作二次確認。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, B-Q7, C-Q8

D-Q2: AI 對「數學/試算」常答錯怎麼處理？

• A簡: 症狀：試算錯、四則出錯。把計算交給服務，AI 僅規劃。
• A詳: 問題症狀描述：總價錯、折扣誤、稅額不對。可能原因分析：LLM 不擅長精確計算、提示未引導用工具。解決步驟：1) 提供試算 API 2) 提示明確要求使用工具 3) 校驗結果與邊界。預防措施：建立規劃模板、使用數學函式庫或規則引擎、對關鍵金額做雙驗證。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q21, B-Q17, C-Q4

D-Q3: RAG 查不到或答非所問？

• A簡: 症狀：空回或幻覺。提升切塊與嵌入品質，重排與來源引用。
• A詳: 問題症狀描述：明明有內容卻檢索不到，或回答無關。可能原因：切塊太大/重疊差、嵌入模型不匹配、索引策略不佳、未重排序。解決步驟：1) 調整切塊/重疊 2) 換更佳嵌入模型 3) 加重排序 4) 提示要求「僅基於片段」並附來源。預防措施：離線評測、片段質量審核、維持索引更新。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, B-Q10, B-Q11

D-Q4: Function Calling 參數缺漏或類型錯誤？

• A簡: 症狀：工具呼叫失敗。強化模式描述與重試/回問機制。
• A詳: 問題症狀描述：字段遺失、型別不符、日期格式錯。可能原因：提示不夠具體、模式未明確、容錯不足。解決步驟：1) 在工具描述中加入必填與範例 2) 服務端做 schema 驗證與自動回問 3) 嚴格錯誤碼回傳觸發重試。預防措施：Few-shot 示例、日期/數量格式統一、工具回傳明確錯誤語義。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q2, C-Q4

D-Q5: Json Mode 偶發輸出非 JSON？

• A簡: 症狀：多餘文字或格式破壞。嚴格模板與結構驗證重試。
• A詳: 問題症狀描述：回覆混入說明文字或缺少花括號。可能原因：提示不夠嚴格、回應長度截斷。解決步驟：1) 明確「只輸出 JSON」 2) 設 response_format 為 json 3) 服務端 schema 驗證→自動重試 4) 降低溫度與長度。預防措施：提供示例、拆任務減少輸出長度、加回覆後處理。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q2, C-Q3, B-Q12

D-Q6: Token 成本暴衝或延遲過高怎麼辦？

• A簡: 症狀：費用超支、回覆慢。任務分流、上下文壓縮與快取。
• A詳: 問題症狀描述：月底花費飆升、請求秒數上升。可能原因：大模型全包、上下文過長、無快取。解決步驟：1) 路由（簡任務→小模型） 2) RAG 片段篩選 3) 上下文摘要與記憶管理 4) 批次化與快取 5) 觀測優化。預防措施：成本門檻告警、配額管理、A/B 測試模型等級。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q20, A-Q19, C-Q9

D-Q7: Prompt 更新導致回歸問題？

• A簡: 症狀：行為突變。版本化提示、回放測試與灰度釋出。
• A詳: 問題症狀描述：原本正確的案例失效、偏離風格。可能原因：提示改動未測、模型更新互動效應。解決步驟：1) 將提示版本化 2) 建立回放測試集 3) 以灰度釋出 4) 觀測指標回退。預防措施：將提示納入 CI、建立評測基準、避免一次性大改。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q12, B-Q15, B-Q19

D-Q8: 使用者個資與隱私外洩風險如何控管？

• A簡: 症狀：敏感資料洩露。資料最小化、遮罩、邊緣推理。
• A詳: 問題症狀描述：對話中外洩電話/地址，或上雲未脫敏。可能原因：輸入未遮罩、缺少資料政策。解決步驟：1) PII 偵測與遮罩 2) 僅傳遞必要欄位 3) 敏感任務用本地或邊緣 4) 對內分權可見。預防措施：資料分類分級、最小必要原則、合規審計與到期刪除。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q21, A-Q19, C-Q9

D-Q9: 權限繞過、越權更新如何防範與修復？

• A簡: 症狀：未授權動作成功。Scope 最小化與狀態檢查雙保險。
• A詳: 問題症狀描述：低權限 Key 做到高風險操作。可能原因：Scope 粗糙、狀態檢查缺漏、順序依賴。解決步驟：1) 細化 Scope 與資源動詞 2) 在服務層強制狀態檢查 3) 加入審計告警與封鎖 4) 事後資料修復。預防措施：紅隊測試、白名單工具、零信任網路。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q8, B-Q21, C-Q2

D-Q10: 模型或向量庫升級後行為變化怎處理？

• A簡: 症狀：答案與風格變動。版本化、灰度、相容性測試。
• A詳: 問題症狀描述：升級後回答偏移或檢索失靈。可能原因：模型特性差異、索引不相容。解決步驟：1) 模型與索引版本化 2) 雙環境 A/B 3) 回放與線上指標監控 4) 快速回滾。預防措施：維持升級日誌、定期再訓練嵌入、相容層與回退策略。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q22, B-Q15, C-Q10

學習路徑索引

• 初學者：建議先學習 15 題
  • A-Q1: 什麼是 API First？
  • A-Q2: 什麼是 AI First？
  • A-Q3: API First 與 AI First 的差異與關係？
  • A-Q6: 為何以 LLM 改善 UX 被稱作「降維打擊」？
  • A-Q7: 「提出要求」與「下指令」有何不同？
  • A-Q10: Copilot 與 Agent 的差異是什麼？
  • A-Q11: 什麼是 Function Calling／Tool Use？
  • A-Q12: 什麼是 RAG（檢索增強生成）？
  • A-Q13: 什麼是 Prompt Engineering？
  • A-Q21: 為何 LLM 不應負責精確計算？
  • B-Q2: LLM 的 Json Mode 如何保證結構化輸出？
  • B-Q3: Function Calling 的執行流程是什麼？
  • C-Q3: 如何用 Json Mode 萃取地址？
  • C-Q4: 如何設計購物清單的 Function Calling？
  • D-Q5: Json Mode 偶發輸出非 JSON？
• 中級者：建議學習 20 題
  • A-Q4: 為什麼在 AI 時代，基礎功夫更重要？
  • A-Q5: 什麼是 AI DX？
  • A-Q14: 狀態機導向 API 設計是什麼？
  • A-Q15: APIKEY 與 SCOPE 的角色是？
  • A-Q16: 為何 CRUD 式 API 不利 AI 使用？
  • B-Q1: LLM 如何解析意圖？
  • B-Q4: Workflow／多步推理背後機制？
  • B-Q5: Copilot 架構在 MVC 中如何設計？
  • B-Q6: 安德魯小舖 GPTs 的技術構成？
  • B-Q7: 以狀態機設計 API 的流程？
  • B-Q9: RAG 的檢索與增強流程？
  • B-Q10: 向量化與向量資料庫如何運作？
  • B-Q12: Prompt 模板化與參數化如何落地？
  • B-Q16: 傳統 UI 與 AI 對話如何互補？
  • B-Q17: 預算約束推理與 API 組合策略？
  • B-Q18: 事件溯源與對話上下文管理？
  • B-Q20: 成本模型如何優化？
  • C-Q1: 既有 WebAPI 接上 GPTs
  • C-Q2: 撰寫 AI DX 友善 Swagger
  • C-Q8: 設計狀態機並實作 REST API
• 高級者：建議關注 15 題
  • A-Q18: 什麼是 AI Pipeline？與 CI/CD 三循環關係？
  • A-Q19: 雲端算力、邊緣算力與本地模型差異？
  • A-Q22: 為何架構師也要 DevOps 在 AI 時代更重要？
  • B-Q11: Ranking/重排序在 RAG 的角色
  • B-Q13: 如何評估與選型 LLM 模型？
  • B-Q15: DevOps + AIOps 的 Pipeline 如何設計？
  • B-Q19: 觀測性在 AI 應用中的要點
  • B-Q21: 安全性：越權、提示注入與對抗詐騙
  • B-Q22: 模型與向量庫更新/回滾機制
  • C-Q6: .NET + Semantic Kernel + Azure OpenAI
  • C-Q7: 建置簡易 RAG
  • C-Q9: 選擇與配置 AI 算力
  • C-Q10: AI 納入 CI/CD 與 GitOps
  • D-Q6: Token 成本暴衝或延遲過高
  • D-Q10: 模型或向量庫升級後行為變化