[架構師觀點] 開發人員該如何看待 AI 帶來的改變?

問題與答案 (FAQ)

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

A-Q1: 什麼是 GPTs（OpenAI 的客製化 GPT）？

• A簡: 基於 ChatGPT 的客製化體，能設定角色、知識庫與自定義 API（Custom Actions）。
• A詳: GPTs 是建立在 ChatGPT 之上的客製化代理，透過角色設定（指示語）、知識庫（上傳檔案即用，不需自行實作 RAG 細節）與 Custom Actions（依 OpenAPI 規格描述即可）整合外部系統。它可在對話中理解意圖，自行決定何時呼叫 API 並彙整結果回覆用戶。典型應用包含客服、電商導購、內部流程助理等。文章的「安德魯小舖 GPT」即是以 GPTs 為「店長」協作網店 API，完成瀏覽、加購、結帳、查單等工作。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q8, B-Q1, C-Q1

A-Q2: 什麼是 LLM（大型語言模型）？

• A簡: 能理解與生成自然語言的模型，擅長意圖理解與語境推理。
• A詳: LLM 透過大量語料訓練，具備語意理解、文本生成與多步推理能力，能把自然語言轉為結構化操作（如 API 呼叫），或將資料（JSON、文件）轉譯為人類可讀的摘要與分析。文章指出 LLM 的成熟打破了「電腦需明確指令」的限制，特別在意圖理解與對話式協作上重塑 UX 與系統架構，使其能成為應用流程的中控（Orchestrator）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q2, B-Q14

A-Q3: 什麼是 API First？

• A簡: 先定義清楚領域 API 規格，再實作前後端與流程。
• A詳: API First 主張在系統設計初期就以業務領域為中心，先定義清晰、一致的 API 合約（含資源模型、狀態轉移、錯誤碼、認證流程），再據此開發 UI、流程與資料層。對 LLM 時代尤其重要，因為 API 將由 AI 呼叫，需可理解、可預測且容錯。文章的 PoC 成功關鍵在合理的 API 設計與 OpenAPI 描述，讓 GPTs 能「望文生義」正確使用。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, B-Q6, C-Q2

A-Q4: 什麼是 AI Friendly 的 API？

• A簡: 一致、可理解、容錯的 API，利於 LLM 正確呼叫。
• A詳: AI Friendly API 強調一致命名與資源模型、清楚的狀態機、對錯誤與特例的嚴謹處理、標準化認證（OAuth2/API Key）、完整的 OpenAPI 文件與描述。由於呼叫方是 LLM，無法假設其行為固定或可被約束，API 必須「可自我解釋」且對異常具備保護欄與冪等性，避免誤用造成副作用。文章指出「設計合理勝過補文件」，否則需大量 Prompt 才能彌補。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q13, D-Q5

A-Q5: 使用者「意圖」與「操作」有何差異？

• A簡: 意圖是想達成的目標；操作是為達目標的具體步驟。
• A詳: 傳統 UX 優化多著重把操作變簡單（按鈕、流程、手勢），但常無法跨越使用者「不知道該怎麼操作以達成意圖」的鴻溝。LLM 能理解語意與脈絡，直接接住「意圖」，並代表使用者規劃操作（選擇與調度 API）。文章指出這是「降維打擊」：意圖理解一旦可行，傳統只優化操作的 UX 套路便難以比肩。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q2, B-Q20

A-Q6: 為什麼 LLM 會改變 UX？

• A簡: 它能理解意圖、整合多資訊，自行規劃操作回應需求。
• A詳: LLM 能將自然語言、上下文、外部文件與系統回應綜合判斷，並生成可執行的工具使用（API 呼叫序列）。因此 UX 不再僅是更好的按鈕與流程，而是「對話即操作」：用戶以語言表達需求，LLM 擔當中控串聯系統。文章中，GPTs 自主呼叫購物 API、試算折扣、調整購物車、結帳與彙整訂單，即展現了 UX 的質變。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q1, B-Q4

A-Q7: 傳統 Chatbot 與 LLM 驅動的 Copilot 差異？

• A簡: 前者像 CLI 指令；後者理解意圖，能主動規劃與調度。
• A詳: 傳統 Chatbot 依規則或關鍵字轉指令，語境理解弱且難泛化；LLM Copilot 理解語意與脈絡，可依需要動態規劃多步驟、判斷與外部工具整合，並能彙整回覆。文章直言過去 Chatbot 易「雞同鴨講」，而 GPTs 展現了意圖理解與自動工具使用能力，足以代替大量流程導引與 UI 邏輯。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q14, C-Q8, D-Q6

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

• A簡: 讓模型輸出結構化工具呼叫，將語言轉為函式/API。
• A詳: Function Calling 是模型以結構化格式返回要調用的函式名稱與參數（如 JSON），平台據此執行外部函式或 API 並回饋結果，再交由模型生成後續回應或下一步計畫。它是「語言→動作」的橋樑，賦予 LLM 可操作性。文中 GPTs 依 OpenAPI 描述理解 API 能力，動態決定呼叫 timing 與參數。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, C-Q1, C-Q6

A-Q9: 為什麼未來 API 的主要使用者會是 LLM？

• A簡: AI 會代替人規劃與執行操作，直接呼叫 API。
• A詳: 當 LLM 成為中控，便由它負責把意圖轉為 API 調用序列。呼叫者不再是人類開發者或固定流程，而是會推理、嘗試、修正的模型代理。因此 API 必須自描述、嚴謹、容錯並具一致性。文章主張：不 AI-Friendly 的 API 將成落伍武器；相反，AI 能力將放大「好 API」的價值。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, B-Q6, B-Q18

A-Q10: 什麼是 Domain API／Business Model 對應？

• A簡: 以業務語彙與規則建模，API 精準映射領域行為。
• A詳: Domain API 是以領域核心概念（商品、購物車、訂單、折扣規則、結帳狀態）與不變式為中心的服務合約。它以正確的邊界與狀態機呈現真實世界運作，避免技術細節滲入。對 LLM 來說，語意友善、規則穩定、流轉清晰的 Domain API，能顯著提升理解與使用成功率。文章 PoC 即以此為關鍵。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q3, A-Q11, B-Q8

A-Q11: 為何在 API 設計中強調「有限狀態機」？

• A簡: 限定可到達狀態與轉移，確保流程正確與可控。
• A詳: 有限狀態機（FSM）將流程拆為有限狀態（如 CartCreated→CheckoutStarted→Paid）及允許的轉移，能避免非法順序與錯誤操作，讓系統可判斷「此時不能那樣做」。當呼叫者是 LLM 時，FSM 成為保護欄與自我校驗機制，減少誤用與副作用。文章以結帳流程強調狀態機的重要性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, D-Q5, C-Q5

A-Q12: 什麼是 Semantic Kernel（SK）？

• A簡: 微軟的 AI 原生應用開發框架，讓 LLM 協作插件與記憶。
• A詳: Semantic Kernel 提供 Kernel、Plugins/Skills、Planner、Memory、Connectors 等元件，協調模型、記憶與外部能力。它將「對話驅動的應用」抽象化，使 LLM 能作為 Orchestrator 呼叫程式插件、查詢知識、規劃步驟。文中作者預期 SK 會成為 AI 應用的主流框架之一，並計畫以 SK 重構電商 PoC。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, C-Q6, B-Q20

A-Q13: Semantic Kernel 與 LangChain 有何差異？

• A簡: SK 偏 .NET/C# 生態；LangChain 偏 Python 生態。
• A詳: 兩者皆為 LLM 應用框架，提供工具調用、記憶、規劃與鏈式推理能力。差異在語言與生態：SK 與微軟平台（.NET、VS、Azure）整合密切；LangChain 在 Python、資料科學與研究社群普及。選擇重點在技術棧、團隊能力與部署環境，概念上都在落實「LLM 為核心的 Orchestration」。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q12, B-Q11, C-Q6

A-Q14: 什麼是 AI OS／AI PC？

• A簡: 內建 LLM 能力與 NPU 的作業系統與終端設備。
• A詳: AI OS 將 LLM 視為作業系統級服務，統一管理本地與雲端 AI 資源，並提供標準化擴充（如 Copilot、插件）。AI PC 則配備 NPU/GPU 等加速器，讓本地 LLM 執行成為常態。文章預期 Wintel 式組合新變體與「Copilot 成為主要入口」將成趨勢，OS、硬體與開發框架相互加成。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, B-Q12, B-Q19

A-Q15: Copilot 在 OS 中的角色與核心價值？

• A簡: 作為主要用戶入口與中控，協調本地與雲端能力。
• A詳: Copilot 不僅是聊天視圖，而是系統級的指令中心：理解使用者意圖，決定搜尋、啟動應用、呼叫 API 或調用裝置能力（視覺、語音、檔案、行事曆）。當多數服務以插件/API 形式提供，Copilot 便能統籌路由與彙整結果，成為「對話即操作」的核心體驗承載者。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q12, C-Q9, A-Q6

A-Q16: 為何 OAuth2／標準認證對 AI 整合重要？

• A簡: AI 需安全存取受保護資源，標準化減少摩擦與錯誤。
• A詳: 當呼叫者是 LLM/代理，認證與授權須可自動化、安全且可觀測。OAuth2（或 API Key）能界定資源範圍、權限與有效期，並可在平台層處理 Token 管理與更新。文章的教訓是：不合規的自製認證阻礙 AI 理解與穩定呼叫，改用標準 OAuth 後立即順暢，顯示「流程可機械化」的重要性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, C-Q4, D-Q3

A-Q17: 如何區分「計算任務」與「意圖任務」？

• A簡: 計算需精確高效；意圖需靈活推理與探索。
• A詳: 計算任務（交易、核算、資料一致性）應以傳統程式與 API 嚴格保障正確性；意圖任務（規劃、建議、彙整、對話導引）適合交由 LLM。文章示例：折扣試算可讓 LLM探索，但若需「精準與可驗證」，應下沉為 API 供 LLM 呼用。架構師需制定邊界，讓 LLM 用在「刀口」、API 守住「底線」。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q8, D-Q2

A-Q18: 什麼是 RAG 與知識庫在 GPTs 的角色？

• A簡: 用外部知識增補模型，提升正確性與可控性。
• A詳: RAG（檢索增強生成）在回應前先從知識庫取回相關內容，再交由模型生成答案，既可降低幻覺、也利於更新知識。GPTs 把文件上傳即用，平台會在背後做檢索與整合。對應用而言，離線政策、產品規格、流程 SOP 等皆可入庫，LLM 便能沿此「可審核的依據」回答。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, B-Q15, C-Q3

A-Q19: Microsoft 的 AI 佈局包含哪些核心？

• A簡: Azure OpenAI、Copilot、Semantic Kernel 三者相扣。
• A詳: Azure OpenAI 提供雲端模型能力（與本地加速相輔）；Copilot 成為 OS/工具的主要入口與中控；Semantic Kernel 則是開發框架，協調模型、記憶、插件與規劃。三者相互加成：有模型（能力）、有入口（體驗）、有框架（生態），加速 AI 原生應用的普及。文章推演此路線將逐步下沉到 OS/PaaS/SaaS。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q19, A-Q12, A-Q15

A-Q20: 架構師與開發者在 AI 時代如何轉變？

• A簡: 架構師定邊界與框架；開發者強化 API 與 AI 工具實作。
• A詳: 架構師需引領系統邁向 AI Ready：界定 LLM 與 API 邊界、以 FSM 把關流程、選定框架（如 SK）、定義可觀測性與安全策略。開發者則應善用 Copilot/ChatGPT 提效、精進 Domain API/DDD、熟悉 OpenAPI/OAuth、學會 Prompt 工程與（向量）資料存取，並能在框架下組裝插件。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q6, C-Q7, D-Q8

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

B-Q1: GPTs 如何整合與呼叫外部 API？

• A簡: 透過 OpenAPI 讀懂能力，模型在對話中動態決定何時調用。
• A詳: GPTs 讀取你提供的 OpenAPI 規格與描述，將端點、參數與回應模型映射為可用工具。對話時，模型先判斷是否需外部資料，若需要，則輸出結構化的工具呼叫（函數名/路徑與參數），平台代為發送 HTTP 請求，回傳結果再由模型解讀、摘要、或觸發後續步驟。核心組件：OpenAPI、函數呼叫、工具執行代理。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q8, C-Q1

B-Q2: LLM 將自然語言轉為 API 呼叫的步驟為何？

• A簡: 解析意圖→規劃步驟→參數抽取→調用→彙整回覆。
• A詳: 流程通常包含：1) 意圖理解與任務分類；2) 規劃需要的工具與順序（多步）；3) 自前後文抽取參數（含命名對齊、單位換算、同義詞映射）；4) 執行 API；5) 驗證/校對回應；6) 彙整與生成最終答案。核心組件：Parser（解析）、Planner（規劃）、Toolformer/Tool Use（工具調用）、Verifier（自檢）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, C-Q8, D-Q1

B-Q3: Function Calling 的技術機制是什麼？

• A簡: 模型輸出結構化工具呼叫（名稱＋參數 JSON），平台執行。
• A詳: 訓練時賦能模型在生成過程「選工具」，並以 JSON 或特定 schema 返回函式名與參數；執行層（如 GPTs 平台或你自建的代理層）據此實際呼叫 API/函式並回傳結果給模型。重點是對工具功能、參數格式與限制的描述（相當於 Prompt 的一部分），避免錯參或誤用。核心組件：工具描述、Schema、執行代理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, C-Q6, C-Q1

B-Q4: LLM 如何把 JSON 回應轉為自然語言摘要？

• A簡: 先抽取欄位與結構，再依指示生成摘要／表格回覆。
• A詳: 模型先辨識 JSON 結構與關鍵欄位（如品名、單價、折扣），將其轉為內部表示，再依系統／使用者提示（包含格式約束）生成文字或表格。若需統計（加總、分組），模型會先在文字層建立「推導步驟」再輸出結果。核心組件：Schema 對齊、抽取與映射、格式化生成（Markdown/自然語言）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q8, D-Q7, A-Q6

B-Q5: 安德魯小舖 PoC 的系統架構為何？

• A簡: GPTs＋網店 API（產品/購物車/結帳）＋標準認證＋OpenAPI。
• A詳: 前端由 GPTs 作為「店長」對話入口；後端提供產品查詢、購物車操作、折扣試算、結帳等 API，透過 OpenAPI 描述給 GPTs；認證改為標準 OAuth2 或 API Key；資料暫存於服務記憶體。GPTs 在對話中依需求呼叫 API、整合結果並回覆。核心：AI 中控＋Domain API＋標準化協定。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q2, C-Q4, C-Q1

B-Q6: OpenAPI／Swagger 在此扮演何種角色？

• A簡: 自描述介面契約，讓 LLM 理解可用端點與參數規則。
• A詳: OpenAPI 提供端點、方法、參數、回應 schema、錯誤碼與描述的標準規格。對 LLM 而言，它是「工具使用說明書」，模型可據此理解功能範圍與正確參數，減少誤用。越完整清晰的描述（尤其是 description 與示例），越利於工具選擇與正確填參。核心組件：Schema、Examples、Description。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q1, A-Q4, D-Q1

B-Q7: OAuth2 與 GPTs Custom Actions 的授權流程？

• A簡: 依 OAuth2 流程取得 Token，再攜帶至 API 呼叫。
• A詳: Custom Actions 可設定 OAuth2（或 API Key）。流程：1) 平台觸發授權流程（如 Authorization Code）；2) 取得 Access Token；3) 在每次 API 呼叫於 Header 帶上 Bearer Token；4) Token 失效時自動 Refresh。關鍵在遵循標準端點（/authorize、/token）、Scope 與錯誤處理。核心：授權伺服器、Token 管理、Scope。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, C-Q4, D-Q3

B-Q8: 如何以有限狀態機設計結帳流程？

• A簡: 定義狀態與轉移，限制非法操作，保證流程正確。
• A詳: 典型狀態：CartEmpty/Created→ItemsAdded→CheckoutStarted→PaymentPending→Paid/Failed→Closed。為各狀態定義允許操作與轉移（如 Paid 後不得再修改購物車），並透過 API 驗證當前狀態。核心組件：狀態存儲、轉移規則、錯誤回饋（含復原策略），提升 AI 調用安全。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, C-Q5, D-Q5

B-Q9: 預算與折扣試算的規則如何設計？

• A簡: 規則引擎或明確演算法，提供估算與最適建議。
• A詳: 將折扣條件（如第二件六折）形式化，提供估算端點（/estimate）輸入候選品項與數量，返回明細與總價。若需最適化，可用啟發式或動態規劃演算法。也可交由 LLM 探索方案，但要能由 API 驗證與糾偏。核心：規則建模、估算 API、與 LLM 的互補分工。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q17, C-Q2, C-Q8

B-Q10: 知識庫／上傳文件與 RAG 的運作機制？

• A簡: 植入可檢索的語意索引，回覆時先取證再生成。
• A詳: 文件經過切片與嵌入向量化，存入向量索引。詢問時以查詢向量檢索最相關片段，連同問題一併餵給模型生成回答。可指定引用片段、限制模型不得編造。GPTs 對使用者而言是「上傳即用」，平台抽象了嵌入與向量檢索細節。核心：Chunking、Embedding、Vector Store、Retriever。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, B-Q15, C-Q3

B-Q11: Semantic Kernel 的核心元件如何協作？

• A簡: Kernel 協調 Model、Plugins、Planner、Memory、Connectors。
• A詳: Kernel 作為中樞，負責調度；Plugins/Skills 封裝外部能力（API/函式）；Planner 依目標規劃多步驟；Memory 儲存對話與長期知識；Connectors 連接不同模型或資料來源。運行時：接收意圖→規劃→調用插件→讀寫記憶→迭代修正→輸出結果。此即「LLM 作為 Orchestrator」的具體化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q6, B-Q14

B-Q12: Copilot 作為 OS 入口的技術設計構想？

• A簡: 系統級代理，統一調度應用、服務與裝置能力。
• A詳: OS 提供標準「行為註冊／插件」機制，應用安裝即宣告能力；Copilot 憑此決定呼叫哪個工具（本機或雲端），並處理安全授權、隱私、資源配額與可觀測性。需支援多模態（語音、影像）、背景任務、意圖切換與回溯。核心：系統插件框架、權限模型、觀測管線。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q15, C-Q9, B-Q19

B-Q13: AI Friendly API 的錯誤處理與容錯原理？

• A簡: 明確錯誤碼與可復原指引，支援冪等與重試。
• A詳: 提供標準錯誤格式（如 RFC7807 Problem+JSON）、清晰訊息與修正建議；關鍵操作（建立訂單、扣款）設計為冪等，避免重試造成副作用；對常見誤用（缺參、非法狀態）給出結構化診斷。API 可返回「下一步建議」以促使 LLM 自我糾偏。核心：錯誤語意、冪等鍵、重試策略、狀態校驗。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q1, D-Q5, C-Q7

B-Q14: LLM Orchestrator 的 Planner 原理？

• A簡: 將目標拆解為可執行步驟，迭代調整與驗證。
• A詳: Planner 解析任務、比對可用插件與資料，產生計畫（含工具順序與參數來源），執行過程根據回饋修正（Replanning）。複雜任務可採樹狀或自一致性檢查（Self-Consistency）。核心：目標分解、工具選擇、資料綁定、回饋修正、停止條件。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: C-Q8, B-Q2, B-Q11

B-Q15: 向量資料庫與語意檢索的基本機制？

• A簡: 文本嵌入成向量，近鄰檢索找相似片段。
• A詳: 以嵌入模型將文本轉為向量，存入向量索引（如 HNSW、IVF）。查詢時計算相似度（cosine/內積），取回 Top-K 片段供模型生成。需處理切片策略、更新同步與權限。核心：Embedding、ANN Index、相似度、Chunking 策略、Metadata Filter。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, C-Q3, D-Q7

B-Q16: LLM＋API 系統的可觀測性如何設計？

• A簡: 記錄對話、工具呼叫、參數與回應，支持追蹤與審計。
• A詳: 需串接分散式追蹤（TraceId 貫穿）、記錄 Prompt/工具選擇/參數/回應、統計成功率與延遲、採集成本與錯誤分類，並在敏感操作實施審核（人審／風控）。核心：日誌結構化、追蹤上下文、紅藍綠指標（SLI/SLO）、隱私去識別化。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q10, D-Q8, C-Q7

B-Q17: Prompt 設計如何影響工具使用？

• A簡: 清晰角色與規則，限制或引導模型選擇與參數填充。
• A詳: 在系統提示中明確宣告：何時該用哪個 API、參數格式、錯誤時的修正策略、輸出格式。為每個端點撰寫有意圖導向的描述與示例。必要時加入「禁止事項」與「優先原則」。核心：系統提示、工具描述、格式約束、示例驅動。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q8, B-Q6, D-Q6

B-Q18: API 合理性與一致性如何影響 AI 使用？

• A簡: 設計越一致，模型越易推斷與泛化，成功率更高。
• A詳: 不一致的命名、特例與混亂流程會迫使大量補救提示且仍易出錯；相反，統一的資源模型、清楚的狀態與錯誤語意，可讓模型「舉一反三」。文章強調「改 API 比訓練專屬模型更便宜」，顯示設計合理性對最終體驗的關鍵影響。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q4, D-Q1, C-Q2

B-Q19: 微軟三層 AI 佈局如何互相支援？

• A簡: 模型能力（Azure OpenAI）＋入口（Copilot）＋框架（SK）。
• A詳: Azure OpenAI 供應模型與雲端算力；Copilot 作為 OS/工具入口統籌能力；Semantic Kernel 將 AI 應用開發標準化。三者使「從模型到體驗到生態」閉環成形，並可下沉至 OS 與上升到 PaaS/SaaS，支援企業級落地（權限、合規、觀測、可擴展）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q19, B-Q12, A-Q14

B-Q20: MVC 與 LLM 驅動架構的差異？

• A簡: MVC 由 UI 驅動；LLM 架構由對話與意圖驅動、AI 編排。
• A詳: MVC 以 View 操作觸發 Controller 邏輯、綁定 Model 資料；LLM 架構以模型為 Orchestrator，接收自然語言與上下文、規劃步驟、調用插件/API、維護記憶。UI 不再是唯一入口，對話與多模態共同驅動。核心：Orchestration、Plugins、Memory、Planner 取代傳統 Controller。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, C-Q6, C-Q9

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

C-Q1: 如何用 OpenAPI 讓 GPTs 使用內部 API（Custom Actions）？

• A簡: 提供完整 OpenAPI 規格，含端點、參數與描述，即可掛用。
• A詳: 步驟：1) 為 API 撰寫 OpenAPI（YAML/JSON）；2) 於 GPTs 設定中上載或連結規格；3) 確認認證方式（OAuth2 或 API Key）；4) 在端點 description 寫清用途與限制。範例（片段）: paths: /api/products: get: description: 取得商品清單，含名稱、價格、描述 /api/carts/{id}/estimate: post: description: 試算折扣與結帳金額 注意：提供示例（examples）、錯誤格式、狀態碼。最佳實踐：一致命名、精簡資源模型。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, A-Q4, D-Q1

C-Q2: 如何為電商情境設計 Domain API（商品／購物車／結帳）？

• A簡: 以資源為中心定端點，對應狀態與不變式，清楚錯誤語意。
• A詳: 步驟：1) 明確資源：Products、Carts、Orders、Payments；2) 端點示例：
  • GET /api/products
  • POST /api/carts
  • POST /api/carts/{id}/items
  • POST /api/carts/{id}/estimate
  • POST /api/checkout/create
  • POST /api/checkout/{id}/confirm 關鍵：以 FSM 定義合法轉移；提供冪等等號；錯誤用 problem+json 返回。最佳實踐：以業務語彙命名、避免動詞式 RPC、保持一致性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q8, B-Q9

C-Q3: 如何在 GPTs 設定角色與知識庫，做出「店長助理」？

• A簡: 撰寫角色指示語，上傳產品/政策文件，限制回答依據。
• A詳: 步驟：1) 角色指示語（如：你是專業店長，先詢問預算與需求，必要時使用 API）；2) 上傳產品規格、折扣政策、退換貨規範；3) 要求「需引用文件證據」與格式回應；4) 測試意圖提問與多輪對話。注意：文件切片與更新頻率；避免機密外洩。最佳實踐：指示語描述工具使用時機與禁止事項。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q18, B-Q10, B-Q17

C-Q4: 如何配置 OAuth2 讓 GPTs 安全訪問受保護 API？

• A簡: 遵循標準端點與流程，平台代管 Token，API 校驗。
• A詳: 步驟：1) 部署認證伺服器（/authorize、/token）；2) 設定 Client（client_id、redirect_uri、scopes）；3) GPTs 設為 Authorization Code/PKCE；4) API 端驗證 Bearer Token。設定片段（概念）： { “auth_type”: “oauth2”, “auth_url”: “…/authorize”, “token_url”: “…/token”, “scopes”: [“cart.read”,”order.write”] } 注意：Scope 最小化、Token 期限、Refresh 機制。最佳實踐：錯誤回應清晰，便於模型修正。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, A-Q16, D-Q3

C-Q5: 如何設計結帳流程的有限狀態機（FSM）？

• A簡: 列舉狀態與轉移，API 層檢查與阻擋非法請求。
• A詳: 步驟：1) 定義狀態：Created→ItemsAdded→CheckoutStarted→PaymentPending→Paid/Failed→Closed；2) 為每個端點檢查當前狀態；3) 使用狀態轉移表；4) 返回明確錯誤與「下一步」。示例（偽碼）： if state != CheckoutStarted: return 409 with “start checkout first” 注意：冪等鍵、防重複扣款。最佳實踐：以事件溯源或工作流引擎管理轉移。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q8, D-Q5

C-Q6: 如何用 Semantic Kernel 建立插件供模型調用（C#）？

• A簡: 以方法標註為函式，註冊至 Kernel 供 LLM 調用。
• A詳: 步驟：1) 建立 Plugin 類別與方法；2) 用屬性描述用途與參數；3) 於程式啟動註冊；4) 以 Planner 規劃使用。 [KernelFunction(“add_item”), Description(“加入購物車”)] Task AddItem(string cartId, string productId, int qty) 啟動： var kernel = Kernel.CreateBuilder().Build(); kernel.Plugins.AddFromObject(new CartPlugin()); 注意：描述清楚、參數命名一致。最佳實踐：以單一職責拆分方法。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, B-Q11, B-Q14

C-Q7: 如何設計 AI Friendly 的錯誤訊息與格式？

• A簡: 使用 Problem+JSON，附修正建議與可機械化的代碼。
• A詳: 步驟：1) 採 RFC7807 格式： { “type”:”https://…/errors/illegal_state”, “title”:”Illegal state”, “detail”:”Checkout not started.”, “instance”:”/carts/123”, “suggestion”:”POST /api/checkout/create” } 2) 錯誤碼與類型可機械判別；3) 提供「下一步建議」。注意：避免含糊訊息。最佳實踐：針對常見誤用設計專屬錯誤類型。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q13, D-Q1, D-Q5

C-Q8: 如何用 Prompt 引導 LLM 進行多步購物與折扣試算？

• A簡: 明確任務、工具時機、驗證步驟，要求結構化回覆。
• A詳: 步驟：1) 系統提示：你需在預算內建議購買方案；2) 工具守則：估算前先取得商品→組合方案→用 /estimate 驗證→若不符預算則調整；3) 輸出格式（表格＋API 呼叫紀錄）；4) 失敗時重試策略。示例片段：「先列出三種組合，逐一估價並比較，最後選最優解。」注意：避免過度自由。最佳實踐：少量範例（few-shot）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q14, D-Q2

C-Q9: 如何規劃 Copilot/對話與傳統 UI 的分工？

• A簡: 對話負責意圖導引與探索，UI 承載高精準、重互動任務。
• A詳: 步驟：1) 盤點任務：探索型/規劃型交由對話；精準輸入/批次操作交由 UI；2) UI 提供可視化校驗（表單、圖表），Copilot 協助填值與說明；3) 定義雙向跳轉（從對話開啟 UI、從 UI 呼叫建議）；4) 以事件匯流讓雙方共享上下文。最佳實踐：避免只留對話、不留 UI 的「單通道」體驗。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q12, B-Q20

C-Q10: 如何將 PoC 部署到 Azure App Service 並公開 Swagger？

• A簡: 容器或程式部署至 App Service，啟用 Swagger UI 路徑。
• A詳: 步驟：1) 建置 API（含 Swagger 產生器，如 Swashbuckle）；2) 建立 Azure App Service（或容器 App）；3) 設定環境變數（連線、金鑰）；4) 佈署程式與開放路徑 /swagger/index.html；5) 設定 CORS 與 TLS；6) 驗證健康檢查。最佳實踐：用 Slot 做藍綠佈署、啟用 Application Insights 觀測。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q16, D-Q10

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

D-Q1: GPTs 呼叫 API 參數錯誤怎麼辦？

• A簡: 提供結構化錯誤與修正建議，優化 OpenAPI 描述。
• A詳: 症狀：400/422、缺少必填、型別不符。可能原因：OpenAPI 描述不清、命名不一致、缺示例。解法：1) 補充 description/例子；2) 啟用 Problem+JSON，指明缺哪些參數與正確格式；3) 在提示中加入參數規則；4) 增加伺服器端寬容解析與預設值。預防：維持一致命名與 schema 測試。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, C-Q7, C-Q1

D-Q2: LLM 回答不穩定或建議不最佳的原因？

• A簡: 本質機率模型；需規劃驗證、重試與降溫機制。
• A詳: 症狀：方案品質飄忽、偶有錯漏。原因：溫度過高、指示不明、工具描述不足、缺驗證步驟。解法：1) 降低溫度；2) 加強系統提示與示例；3) 強制「先試算再決策」；4) 多回合自我檢查或最佳化比對；5) 將關鍵部分下沉為 API。預防：明確邊界（計算 vs 意圖）、設計驗證循環。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q17, B-Q14, C-Q8

D-Q3: GPTs 總是無法通過 OAuth 認證怎麼辦？

• A簡: 檢查 OAuth 流程與端點，改用標準授權型別與 Scope。
• A詳: 症狀：401/403、Token 無效或不可用。原因：自訂流程不符合標準、Redirect/Scope 錯、Token 過期。解法：1) 使用標準 Authorization Code/PKCE；2) 確認 /authorize、/token、Scope；3) 設 Token 壽命與 Refresh；4) 檢查時鐘偏移。預防：優先選現成 IdP、文件清楚、沙箱測試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q7, C-Q4

D-Q4: 折扣試算結果不一致如何處理？

• A簡: 明確化規則並以 API 試算，模型用作探索而非最終裁決。
• A詳: 症狀：不同回覆對金額與組合判斷不一。原因：規則歧義、模型推理差異、未經 API 驗證。解法：1) 以 API 提供單一事實來源（/estimate）；2) 在提示強制「先估再決」；3) 將關鍵規則寫入知識庫；4) 對齊單位與四捨五入。預防：規則版本化、回應附估算依據。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q8, C-Q2

D-Q5: LLM 重複呼叫 API 造成副作用怎麼辦？

• A簡: 設計冪等、去重機制與狀態校驗，限制重試副作用。
• A詳: 症狀：重複下單、重複扣款。原因：LLM 重試、網路抖動、回覆超時。解法：1) 冪等鍵（Idempotency-Key）；2) 以 FSM 驗證當前狀態；3) 伺服器端去重與樂觀鎖；4) 明確返回「已處理」訊息。預防：為關鍵端點強制冪等、設計單次性 Token。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q13, C-Q5

D-Q6: 自然語言歧義導致錯誤操作如何避免？

• A簡: 要求確認與回述、使用結構化表單與關鍵詞澄清。
• A詳: 症狀：把「啤酒」當作「飲料」統稱，未過濾酒精品項。原因：語意歧義、上下文不足。解法：1) 設置二次確認（回述理解與清單）；2) 要求關鍵欄位（是否含酒精）明確化；3) 在知識庫定義類別與禁忌。預防：提示中加入「易混淆詞」澄清規則。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q17, C-Q8, A-Q7

D-Q7: JSON 結構變更導致解析失敗怎麼辦？

• A簡: 版本化回應 Schema，提供向後相容與嚴格示例。
• A詳: 症狀：模型或程式端無法對齊欄位。原因：未版本化、缺少範例、欄位語意變更。解法：1) 引入 /v1,/v2；2) 提供 JSON Schema 與示例；3) 新增欄位預設值；4) 廢棄策略與過渡期。預防：契約測試、文件自動化、模型前置正規化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q15, C-Q1

D-Q8: 效能不佳：LLM 成本與延遲如何優化？

• A簡: 降模型規格、分層快取、下沉計算到 API、減少輪詢。
• A詳: 症狀：回應慢、成本高。原因：過高模型、冗長上下文、重複呼叫。解法：1) 任務分級，小任務用小模型；2) Prompt 與上下文裁剪；3) 在 API 層聚合查詢與計算；4) 啟用結果快取；5) 批次化處理。預防：成本監控、SLI/SLO、配額與退化策略。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q16, C-Q2, A-Q17

D-Q9: 安全問題：如何限制敏感操作與資料外洩？

• A簡: 最小權限、敏感動作門閘、人審、資料脫敏與稽核。
• A詳: 症狀：越權操作、敏感資料外傳。原因：Scope 過寬、提示注入、缺稽核。解法：1) 最小權限與細粒度 Scope；2) 高風險動作需人審或二次確認；3) 敏感資料脫敏；4) 日誌審計與異常警示。預防：提示防注入、出網控制、資料分類與治理。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q7, B-Q16, C-Q4

D-Q10: 可觀測性不足：如何追蹤 LLM 決策與 API 呼叫？

• A簡: 建立端到端追蹤，記錄 Prompt、工具選擇與結果。
• A詳: 症狀：無法重現問題、定位困難。原因：缺追蹤與結構化日誌。解法：1) 導入分散式追蹤（鏈接對話與 API）；2) 記錄 Prompt/參數/回應；3) 指標化（成功率、延遲、成本）；4) 例外分類與告警。預防：落地 Observability 標準、預先插桿（Instrumentation）。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q16, C-Q10, D-Q8

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 GPTs（OpenAI 的客製化 GPT）？
  • A-Q2: 什麼是 LLM（大型語言模型）？
  • A-Q5: 使用者「意圖」與「操作」有何差異？
  • A-Q6: 為什麼 LLM 會改變 UX？
  • A-Q7: 傳統 Chatbot 與 LLM 驅動的 Copilot 差異？
  • A-Q15: Copilot 在 OS 中的角色與核心價值？
  • A-Q19: Microsoft 的 AI 佈局包含哪些核心？
  • B-Q1: GPTs 如何整合與呼叫外部 API？
  • B-Q4: LLM 如何把 JSON 回應轉為自然語言摘要？
  • B-Q6: OpenAPI／Swagger 在此扮演何種角色？
  • C-Q1: 如何用 OpenAPI 讓 GPTs 使用內部 API（Custom Actions）？
  • C-Q3: 如何在 GPTs 設定角色與知識庫，做出「店長助理」？
  • C-Q10: 如何將 PoC 部署到 Azure App Service 並公開 Swagger？
  • D-Q1: GPTs 呼叫 API 參數錯誤怎麼辦？
  • D-Q6: 自然語言歧義導致錯誤操作如何避免？
• 中級者：建議學習哪 20 題
  • A-Q3: 什麼是 API First？
  • A-Q4: 什麼是 AI Friendly 的 API？
  • A-Q10: 什麼是 Domain API／Business Model 對應？
  • A-Q11: 為何在 API 設計中強調「有限狀態機」？
  • A-Q16: 為何 OAuth2／標準認證對 AI 整合重要？
  • A-Q17: 如何區分「計算任務」與「意圖任務」？
  • A-Q18: 什麼是 RAG 與知識庫在 GPTs 的角色？
  • B-Q2: LLM 將自然語言轉為 API 呼叫的步驟為何？
  • B-Q3: Function Calling 的技術機制是什麼？
  • B-Q5: 安德魯小舖 PoC 的系統架構為何？
  • B-Q7: OAuth2 與 GPTs Custom Actions 的授權流程？
  • B-Q8: 如何以有限狀態機設計結帳流程？
  • B-Q9: 預算與折扣試算的規則如何設計？
  • B-Q10: 知識庫／上傳文件與 RAG 的運作機制？
  • B-Q11: Semantic Kernel 的核心元件如何協作？
  • B-Q18: API 合理性與一致性如何影響 AI 使用？
  • C-Q2: 如何為電商情境設計 Domain API？
  • C-Q4: 如何配置 OAuth2 讓 GPTs 安全訪問受保護 API？
  • C-Q5: 如何設計結帳流程的有限狀態機（FSM）？
  • C-Q8: 如何用 Prompt 引導 LLM 進行多步購物與折扣試算？
• 高級者：建議關注哪 15 題
  • A-Q12: 什麼是 Semantic Kernel（SK）？
  • A-Q14: 什麼是 AI OS／AI PC？
  • B-Q12: Copilot 作為 OS 入口的技術設計構想？
  • B-Q14: LLM Orchestrator 的 Planner 原理？
  • B-Q15: 向量資料庫與語意檢索的基本機制？
  • B-Q16: LLM＋API 系統的可觀測性如何設計？
  • B-Q19: 微軟三層 AI 佈局如何互相支援？
  • B-Q20: MVC 與 LLM 驅動架構的差異？
  • C-Q6: 如何用 Semantic Kernel 建立插件供模型調用？
  • C-Q7: 如何設計 AI Friendly 的錯誤訊息與格式？
  • C-Q9: 如何規劃 Copilot/對話與傳統 UI 的分工？
  • D-Q2: LLM 回答不穩定或建議不最佳的原因？
  • D-Q5: LLM 重複呼叫 API 造成副作用怎麼辦？
  • D-Q8: 效能不佳：LLM 成本與延遲如何優化？
  • D-Q10: 可觀測性不足：如何追蹤 LLM 決策與 API 呼叫？