從 Prompt 到 Product

問題與答案 (FAQ)

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

Q1: 什麼是「從 Prompt 到 Product」？

• A簡: 把提示詞從一次性對話，系統化成可測試、可維運、可交付的產品功能。
• A詳: 「從 Prompt 到 Product」指的是：不只追求「問得好就能出結果」，而是把 prompt 視為產品需求的一部分，納入版本控管、測試、監控與迭代流程。重點在可重現性（同樣輸入與版本能得到可接受輸出）、可驗證性（有品質指標與測試集）、可運維性（能監控成本/延遲/錯誤），以及可擴充性（面對不同場景能參數化與模組化）。常見應用包含客服助理、文件摘要、程式輔助、維運診斷等。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q1, B-Q6

Q2: 什麼是 Prompt？在產品開發中扮演什麼角色？

• A簡: Prompt 是引導模型輸出的指令與上下文；在產品中等同「可執行的規格片段」。
• A詳: Prompt 不只是「一句話問模型」，而是包含目標、限制、輸入資料格式、輸出格式、示例與安全規則的指令集合。在產品開發裡，它常扮演「行為規格」：定義模型要怎麼說、怎麼引用資料、什麼不能做、輸出要符合哪些結構（例如 JSON）。若把 prompt 當成臨時貼上文字，品質會難以維持；若把它當成資產管理，就能和程式碼一起審查、測試與迭代。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q11, B-Q3

Q3: Prompt 與傳統需求規格（Spec/PRD）有什麼差異？

• A簡: Spec 描述「要什麼」；Prompt 更像「如何讓模型做」，需兼顧不確定性與驗證。
• A詳: 傳統 Spec/PRD 多以確定性邏輯描述功能與驗收條件；Prompt 則是針對「機率式輸出」的行為設計，除了功能目標，還要處理輸出格式、語氣、引用規則、邊界情境與安全限制。差異在於：Prompt 需要大量例子、反例與約束；且必須搭配評測（eval）與監控，才能確保升級模型或調整 prompt 後品質不退步。因此產品化時通常會把 Spec、Prompt、測試集與指標一起管理。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q8, D-Q5

Q4: 什麼是 Vibe Coding？

• A簡: 以 AI 協作快速產出程式與調整方向，用「對齊意圖」取代完整手寫細節的開發方式。
• A詳: Vibe Coding 通常指：工程師以自然語言描述意圖、限制與範例，讓 AI 生成或改寫程式碼，再由人做驗證、整合與修正。它的價值在「降低啟動成本」與「加速試錯」，特別適合新功能雛形、重構輔助、樣板碼、測試生成與文件整理。但它不等於不用工程能力：越能清楚描述需求、設計架構、建立測試與評測，越能把 AI 產出變成可交付成果。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q8, C-Q5

Q5: Vibe Coding 與傳統開發流程最大的差異是什麼？

• A簡: 重心從「手工實作」轉為「快速生成＋驗證迭代」，測試、評測與整合能力更關鍵。
• A詳: 傳統流程多是設計後逐步實作；Vibe Coding 會把大量實作交給 AI 先生成，再由人做「需求對齊、品質驗證與系統整合」。因此差異在三點：一是迭代速度更快但更需要護欄；二是需要把需求轉成可檢查的輸出（格式、測試、指標）；三是整合與維運成本可能上升（前後端、部署、觀測、回歸風險）。能否把 prompt、程式、測試串成流水線，決定了它能否產品化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q6, D-Q10

Q6: 為什麼導入 AI 常需要「量化指標」才能說服老闆或企業主？

• A簡: 因為 AI 牽涉成本與風險，量化指標才能對齊 ROI、控管品質並支持決策。
• A詳: 企業導入 AI 不只是「好不好用」，還包含：模型費用、延遲、資安/法遵、錯誤風險與組織變革成本。老闆需要可比較、可追蹤的量化指標，才能評估是否值得投資、該擴大或停止、以及出問題時如何追責與改善。常見做法是先定義成功準則（例如節省工時、提升轉換率、降低工單處理時間），再建立基準線與試點（pilot），以數據而非感覺推進。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q8, C-Q10

Q7: AI 導入成效常見的量化指標有哪些？

• A簡: 常看成本、速度、品質與商業影響：token 成本、延遲、命中率、轉換率與節省工時。
• A詳: 指標可分四類：1) 成本：每次請求 token、月花費、快取命中率；2) 效能：P50/P95 延遲、逾時率；3) 品質：人工評分、任務成功率、引用正確率、格式正確率、幻覺率；4) 商業：客服結案時間、工單量下降、轉換率、留存、NPS。落地時建議先選「可量測且可改善」的少數指標，配合 offline eval（上線前）與線上監控（上線後）形成閉環。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q8, D-Q3

Q8: 面對特定產業、domain knowledge 複雜的企業系統，Vibe Coding 為何可能受限？

• A簡: 因為隱性規則多、資料分散且需正確性，僅靠生成碼容易錯，需知識治理與驗證。
• A詳: 企業級系統常有大量隱性規則（權限、流程、例外處理）、歷史包袱與跨系統整合，且錯誤代價高。AI 生成程式碼若缺乏正確上下文，容易寫出「看似合理但不符合規範」的實作，或忽略邊界條件。這類場景通常要靠：文件/規範整理、RAG 或內部知識庫、測試與評測集、嚴格 code review、以及逐步替換策略，才能把 Vibe Coding 的速度優勢轉成可靠交付。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, B-Q12, D-Q2

Q9: 我只喜歡寫程式、不想跟人太多溝通，AI 時代該怎麼辦？

• A簡: 把溝通轉成「可驗證的介面」：測試、規格、prompt、文件與可重現結果，降低口頭協調成本。
• A詳: AI 協作下，「描述意圖」會變得更重要，但不必等同大量開會。你可以用工程化方式降低溝通：把需求寫成 issue、把行為寫成測試、把 AI 行為寫成 prompt file 與 eval 案例，用 PR 討論取代同步會議。技能上可強化：測試設計、重構、CI、觀測性、評測與資料處理。當你能提供清楚的輸入/輸出契約與驗收方法，就能在較少人際互動下仍成為高價值貢獻者。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q5, D-Q10

Q10: 前後端分離的專案在 Vibe Coding 下，為什麼整合可能更痛？

• A簡: AI 常同時改多處；分離架構若缺共同契約與測試，會放大介面不一致與回歸風險。
• A詳: 前後端分離本身是好事，但在 Vibe Coding 情境下，AI 可能快速生成 UI、API、DTO、驗證規則等多處變更；若缺少單一事實來源（契約/Schema）與整合測試，容易出現前端期望的欄位與後端回傳不一致、錯誤處理不一致、或 prompt/輸出格式更動導致 UI 壞掉。解法是強化契約（OpenAPI/JSON Schema）、建立整合測試、並讓 prompt 與介面版本化，必要時用單一 repo 或統一工具鏈降低摩擦。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q6, D-Q6

Q11: 什麼是 prompt file？把 prompt 寫成檔案的核心價值是什麼？

• A簡: prompt file 是可版本控管的提示資產；能審查、重用、測試與追溯，降低「口耳相傳」風險。
• A詳: prompt file 指把提示內容以檔案形式保存（例如 .md/.txt/.yaml），並納入 Git、PR 與 CI。核心價值有四個：1) 可追溯：知道誰改了什麼、為何改；2) 可重用：同一套指令可供不同功能/環境套用；3) 可測試：可對 prompt 變更做 regression eval；4) 可協作：讓 prompt 也能 code review。這能把「聊天運氣好」轉成可管理的工程資產，是從 Prompt 走向 Product 的關鍵一步。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q2, B-Q2, C-Q1

Q12: 新功能要開新的 prompt file；既有功能小修改也有必要嗎？

• A簡: 若修改會影響輸出行為或品質，就值得；小修可用同檔版本化與測試案例補強即可。
• A詳: 判斷標準不是「改多大」，而是「是否改變模型行為」。若是調整輸出格式、增減規則、改語氣、改引用方式、或新增工具調用，建議以 prompt file 方式版本化並補測試案例，避免日後回溯困難。若只是修正拼字或輕微措辭，可留在同一檔以 Git 記錄即可，不一定要新檔。實務上可用命名與資料夾分層管理：按 feature/場景拆檔，按版本或實驗分支管理，並配合評測集做保護。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, C-Q5, D-Q5

Q13: Vibe Coding 在「維運/維護」上有哪些應用價值？

• A簡: 可用於事件摘要、log 解讀、根因假設、Runbook 生成與工單分流，加速處理但仍需驗證。
• A詳: 維運情境的資訊多、時間急，適合讓 AI 做「整理與輔助判讀」：例如把大量 log/trace 摘要成可讀結論、依錯誤訊息推薦可能原因與排查步驟、把 incident 時間線自動整理成報告、或從工單內容自動分類與指派。關鍵是把 AI 放在「輔助決策」而非「自動決策」的位置：輸出需附來源（log 片段/指標）、保留人工覆核、並建立權限與資料遮罩，避免把機密或個資送出。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q15, C-Q9, D-Q9

Q14: 如果 AI 這麼厲害，初學者還要學什麼才不會被追過？

• A簡: 先學可轉移的底層能力：問題拆解、資料結構、測試、系統觀與除錯，AI 會放大這些差距。
• A詳: AI 能加速寫碼，但無法替代你對需求、系統與風險的判斷。初學者建議優先投資「不容易過時」的能力：1) 基礎程式與資料結構（理解而非背語法）；2) 測試與除錯（讓你能驗證 AI 產出）；3) HTTP/DB/快取等系統常識；4) 需求拆解與邊界條件思維。把 AI 當加速器：用它練習解題、生成測試、對照不同解法，但以你自己的驗證能力決定採用與否。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, C-Q5, D-Q10

Q15: 文中三場分享的簡報與共筆要去哪裡看？

• A簡: 文章內已嵌入三場 Google Slides；DevOpsDays 另提供 HackMD 大會共筆連結可查閱。
• A詳: 這篇文章把三場活動（GenAI 開發者年會、DevOpsDays Taipei、STUDY4LOVE 公益講座）的簡報以嵌入方式集中整理，因此可直接在文內瀏覽投影片內容。另在 DevOpsDays Taipei 段落提供了「大會共筆」HackMD 連結，方便查到現場紀錄與延伸討論。若你要在團隊內分享，建議同時保存簡報版本與共筆重點，並把落地決策（指標、架構、測試）整理成內部文件。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q6, B-Q1

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

Q1: 「從 Prompt 到 Product」的端到端交付流程如何運作？

• A簡: 需求→prompt/資料→原型→評測→上線→監控→迭代，形成可追蹤的品質閉環。
• A詳: 技術流程可拆成三段：
  1) 原理：把模型輸出視為「可測的功能」，用 prompt＋資料驅動。
  2) 步驟：定義需求與指標→設計 prompt（含格式與護欄）→做最小原型→建立 eval 案例→接入系統（API/UI）→上線灰度→監控成本/延遲/品質→迭代。
  3) 組件：prompt 檔案庫、模型呼叫層（SDK/Gateway）、評測工具、觀測（log/trace/metrics）、feature flag 與回滾機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, B-Q7, C-Q10

Q2: prompt 的版本控管與可重現性（reproducibility）要怎麼設計？

• A簡: 將 prompt/模型版本/參數/資料快照一同記錄；用 Git、標籤與評測鎖住行為差異。
• A詳:
• 原理：模型輸出受 prompt、模型版本、temperature、工具/資料來源影響，需「一起版本化」。
• 步驟：prompt 存檔入 Git→呼叫時記錄模型名、參數、時間、資料版本→對每次變更跑 regression eval→用 release tag 綁定可回滾組合。
• 組件：prompt file、設定檔（YAML/ENV）、實驗追蹤（如自建表/MLflow）、評測報表、以及可回放的請求紀錄（含遮罩敏感資訊）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, A-Q12, D-Q5

Q3: prompt 的結構化設計（System/User/Constraints/Examples）是什麼機制？

• A簡: 用分層訊息與範例約束模型行為；把規則、輸出格式與例外集中管理，降低漂移。
• A詳:
• 原理：LLM 會綜合指令與上下文推斷最佳回應；層次越清晰越穩定。
• 步驟：System 定角色與禁則→User 放實際需求與輸入→Constraints 規範格式/引用→Examples 提供正反例→最後要求輸出 JSON/Markdown 等。
• 組件：prompt 模板引擎（Jinja/Mustache）、輸出 Schema（JSON Schema）、以及後處理驗證（parser/validator）確保機器可讀。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q2, C-Q4, D-Q2

Q4: 如何把 prompt 與程式碼解耦並做到參數化重用？

• A簡: 把 prompt 當模板＋參數；程式只負責填值、呼叫與驗證，避免把提示寫死在程式裡。
• A詳:
• 原理：prompt 是規格資產，程式是執行器；解耦可提高維護性與可測性。
• 步驟：建立 prompt 檔→定義 placeholders（如 {{language}}）→後端渲染→加上輸出 Schema 驗證→在不同場景用參數組合重用。
• 組件：prompt repo、模板渲染器、設定中心（環境/租戶/版本）、以及 eval 測試確保不同參數下仍符合品質門檻。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, C-Q1, C-Q4

Q5: 前後端分離架構下，prompt 與 API 的邊界該怎麼切？

• A簡: 前端負責收集意圖與展示；後端封裝 prompt、工具與資料，提供穩定契約避免 prompt 外洩與漂移。
• A詳:
• 原理：prompt 與資料存取屬於後端責任，才能控管安全、版本與一致性。
• 步驟：前端送結構化輸入（表單/JSON）→後端套用 prompt 模板→必要時做 RAG/工具調用→回傳結構化輸出（含引用/置信度）→前端渲染。
• 組件：API Gateway、Schema（OpenAPI/JSON Schema）、prompt 管理、以及觀測紀錄（request id 串起前後端與模型呼叫）。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q6, D-Q6

Q6: AI 功能的整合測試（integration test）流程與關鍵點是什麼？

• A簡: 以固定測試集＋穩定參數驗證端到端輸出；同時測格式、引用、延遲與失敗降級路徑。
• A詳:
• 原理：LLM 不確定性高，整合測試要測「可接受範圍」與「機器可判定條件」。
• 步驟：準備測試案例（輸入/期望約束）→固定模型版本與參數→跑端到端→驗 JSON Schema/關鍵欄位→記錄延遲與成本→測 fallback（逾時/工具失敗）。
• 組件：測試框架（pytest/jest）、Schema 驗證器、測試資料夾、以及 mock 外部工具/資料源提升可重現性。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q5, D-Q1, D-Q6

Q7: 上線前的 offline eval 要怎麼做？需要哪些元素？

• A簡: 用代表性案例集與可量化指標評分，對比基準線；讓 prompt/模型變更有客觀依據。
• A詳:
• 原理：先用離線評測降低上線風險，把「好不好」變成「分數是否過門檻」。
• 步驟：蒐集真實案例→去識別化→定義評分指標（成功率、格式正確率、引用正確等）→建立基準→每次改 prompt/模型重跑→產出報表。
• 組件：eval dataset、評分器（規則＋人工抽驗＋LLM-as-judge 需校準）、結果儲存與趨勢圖，並和 Git commit 連結。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q7, B-Q8, D-Q5

Q8: 上線後的線上監控（online monitoring）要監哪些？怎麼形成閉環？

• A簡: 監控延遲、成本、錯誤率與品質代理指標；搭配抽樣審核與回饋資料回流到 eval。
• A詳:
• 原理：線上環境有長尾與攻擊面，必須用監控與回饋機制持續校正。
• 步驟：對每次呼叫記錄 token/延遲/模型版本→收集使用者回饋（讚踩/修正）→抽樣人工審核→告警（成本暴增/逾時）→把失敗案例回流到 offline eval 集合。
• 組件：metrics（Prometheus）、log/trace（OpenTelemetry）、品質面板、feature flag 與回滾腳本。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q6, C-Q10, D-Q3

Q9: RAG（檢索增強生成）背後原理是什麼？有哪些關鍵元件？

• A簡: 先檢索相關文件再生成；用向量搜尋把上下文補給模型，降低幻覺並對齊企業知識。
• A詳:
• 原理：LLM 不保證包含最新/內部知識；RAG 以「檢索→組裝上下文→生成」補足。
• 步驟：文件切片→產生 embedding→存入向量庫→查詢時向量檢索 top-k→把片段與引用規則放入 prompt→生成並附來源。
• 組件：chunker、embedding 模型、vector DB（pgvector/FAISS）、reranker（可選）、以及引用格式與權限過濾（避免越權取資料）。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q8, C-Q7, D-Q7

Q10: function calling / tool use（工具調用）是怎麼運作的？

• A簡: 讓模型輸出結構化參數去呼叫工具，再把結果回填給模型生成最終答案，形成可控工作流。
• A詳:
• 原理：把「查資料/執行動作」交給可驗證的函式，模型負責決策與組裝回覆。
• 步驟：定義工具 schema（函式名/參數）→模型選擇工具並輸出參數→系統執行工具（DB/API）→把結果回傳給模型→模型生成最終輸出。
• 組件：工具註冊與參數驗證、權限控管、重試/逾時、以及 tool-call log（方便除錯與稽核）。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q3, C-Q4, D-Q8

Q11: 產品化時要如何防範 prompt injection 與資料外洩？

• A簡: 把使用者輸入當不可信；分離指令與資料、限制工具權限、過濾敏感資訊並做審計與告警。
• A詳:
• 原理：攻擊者會把惡意指令混入輸入，誘導模型洩漏系統提示或越權取資料。
• 步驟：嚴格區隔 system 指令與 user 資料→對輸入做清洗/長度限制→工具調用採最小權限→RAG 做權限過濾→輸出做敏感詞/個資遮罩→記錄與告警可疑行為。
• 組件：input/output filter、policy prompt、工具 ACL、DLP（可選）、以及審計 log 便於追查。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q5, D-Q9, C-Q4

Q12: domain knowledge 複雜時，為什麼需要知識治理（文件、資料字典、規範）？

• A簡: 因為模型與人都需要一致語意；知識治理能降低歧義、提升檢索品質並讓產出可驗證。
• A詳:
• 原理：複雜領域最大問題是「同詞不同義、規則分散、例外多」。沒有統一語意，prompt/RAG/測試都會漂移。
• 步驟：建立核心名詞定義→整理規範與流程→產出資料字典與 Schema→把規則轉成可測案例→再用 RAG/工具調用提供最新事實。
• 組件：知識庫（Wiki）、資料目錄、規範文件、測試案例庫與 eval dataset，讓 AI 生成與人類協作都有共同依據。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q8, B-Q9, D-Q2

Q13: 既有系統導入 AI，為什麼常用 feature flag 與漸進式 rollout？

• A簡: 因為風險與不確定性高；用灰度上線可控影響面、快速回滾並收集真實數據改善品質。
• A詳:
• 原理：AI 行為可能因資料長尾、模型更新而波動，直接全量會放大事故。
• 步驟：以 feature flag 包住 AI 功能→內部測試→小流量灰度→監控成本/品質→逐步放量→必要時一鍵回滾到非 AI 路徑。
• 組件：flag 服務或自建開關、分流策略（按租戶/比例）、監控告警、以及明確的 fallback 實作（規則式/人工流程）。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q8, C-Q10, D-Q3

Q14: AI 成本控制有哪些常見機制？（token 預算、快取、模型分層）

• A簡: 用 token 預算與快取降成本；以模型分層與路由把重任務交大模型、一般任務交小模型。
• A詳:
• 原理：成本與延遲主要由 token 與模型等級決定，需在體驗與費用間取平衡。
• 步驟：限制上下文長度→摘要/壓縮歷史→快取相同問答或檢索結果→模型路由（小模型先判斷，必要才升級）→批次處理非即時任務。
• 組件：token 計量與配額、快取層（Redis）、模型路由器、以及成本儀表板與告警（避免異常暴衝）。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q7, D-Q3, D-Q4

Q15: 維運情境下，AI 協助 incident/issue 的工作流如何設計才可靠？

• A簡: 讓 AI 做摘要與建議、把事實來源附上；結合 Runbook、權限控管與人工核可，避免誤判自動化。
• A詳:
• 原理：維運要可追溯與可稽核，AI 不應直接執行高風險動作。
• 步驟：收集 log/trace/告警→AI 先摘要時間線與可疑變更→比對 Runbook 產出排查清單→需要時呼叫只讀工具→由值班者確認→將結論寫回工單/事後報告→把案例回流為知識庫與 eval。
• 組件：事件匯流（Alertmanager）、工單系統、Runbook、只讀工具集、審計 log 與資料遮罩。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q13, C-Q9, D-Q1

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

Q1: 如何建立一套可重用的 prompt 檔案與資料夾結構？

• A簡: 以 feature/場景分層存放 prompt，搭配版本與測試案例同資料夾，方便審查與回歸測試。
• A詳: 實作步驟：1) 建立 prompts/ 目錄；2) 以 feature/scene 分資料夾；3) 每個 prompt 旁放 eval_cases.jsonl；4) 用 README 說明輸入/輸出與指標。最佳實踐是「prompt、測試、文件同地共存」。
  範例結構：

  prompts/
    support_reply/
      v1.md
      eval_cases.jsonl
      README.md
  

• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q11, B-Q2, C-Q5

Q2: 如何用環境變數管理模型、金鑰與推論參數？

• A簡: 用 .env 管理 key/model/temperature；在程式啟動時載入，避免寫死與外洩並利於多環境切換。
• A詳: 步驟：1) 建立 .env；2) 將 .env 加入 .gitignore；3) 用設定庫載入；4) 在 log 只記錄「是否存在」不記值。
  範例：

  LLM_API_KEY=xxxx
  LLM_MODEL=gpt-4.1-mini
  LLM_TEMPERATURE=0.2
  

  注意事項：CI/CD 用 Secret 管理；不同環境（dev/stage/prod）用不同 key 與配額。

• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q2, B-Q14, D-Q9

Q3: 如何用 Python 載入 prompt file 並呼叫 LLM（相容 OpenAI API）？

• A簡: 讀取 prompt 檔、渲染參數後呼叫 chat completion；同時記錄模型版本與 request id 便於追蹤。
• A詳: 步驟：1) open() 讀 prompt；2) 用模板替換變數；3) 呼叫模型；4) 驗證輸出格式。
  範例：

  from openai import OpenAI
  client = OpenAI()
  
  prompt = open("prompts/support_reply/v1.md", "r", encoding="utf-8").read()
  msg = prompt.replace("{{tone}}", "professional")
  
  resp = client.chat.completions.create(
      model="gpt-4.1-mini",
      temperature=0.2,
      messages=[{"role":"system","content":msg},
                {"role":"user","content":"請協助回覆客訴..."}],
  )
  print(resp.choices[0].message.content)
  

  最佳實踐：把參數與模型名也寫入 log，供回歸追查。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q4, D-Q1

Q4: 如何在後端 API 中安全地把使用者輸入套進 prompt 模板？

• A簡: 讓前端送結構化欄位；後端以模板渲染並做長度/敏感字過濾，避免輸入覆寫系統指令。
• A詳: 步驟：1) 定義 request schema（例如 question/context）；2) 對欄位做長度限制與清洗；3) 渲染到 user 區塊而非 system；4) 輸出用 JSON Schema 驗證。
  範例（偽碼）：

  const user = sanitize(req.body.question).slice(0, 2000);
  messages = [{role:"system", content:sysPrompt},
              {role:"user", content:`問題：${user}`}];
  

  注意：不要把機密放入前端；工具調用採最小權限。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q11, D-Q9

Q5: 如何用 pytest/jest 做最小化的 prompt regression 測試？

• A簡: 用固定測試集跑模型並檢查格式/關鍵句；用門檻判斷通過，避免 prompt 一改就品質退步。
• A詳: 步驟：1) 準備 eval_cases.jsonl；2) 測試時固定模型與 temperature；3) 檢查 JSON 可解析、欄位存在、關鍵規則符合；4) 失敗則阻擋合併。
  範例（pytest 簡化）：

  def test_output_has_fields(resp_json):
      assert "answer" in resp_json and "citations" in resp_json
  

  最佳實踐：把失敗案例保存成新測資，讓測試集越跑越強。

• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q7, D-Q5

Q6: 如何快速建立一份 offline eval 測試案例檔（jsonl）？

• A簡: 從真實對話抽樣去識別化，整理成「輸入＋期望約束」的 jsonl，方便自動跑分與回歸。
• A詳: 步驟：1) 收集代表性輸入；2) 去除個資與機密；3) 為每筆定義檢查規則（格式、必含欄位、是否引用）；4) 存成 jsonl。
  範例：

  {"id":"c1","input":"如何量化AI導入效益？","must_include":["ROI","指標"]}
  {"id":"c2","input":"既有功能小改要不要新prompt檔？","must_include":["版本","回歸測試"]}
  

  注意：先求「小而可跑」，再逐步擴充涵蓋率。

• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q7, A-Q7, D-Q2

Q7: 如何實作一個最小可用的 RAG（以 pgvector 為例）？

• A簡: 文件切片後做 embedding 存入 pgvector；查詢時檢索 top-k 片段組 prompt，要求附引用再生成答案。
• A詳: 步驟：1) 切片（500~1000 字）→2) 產 embedding→3) 寫入 PostgreSQL+pgvector→4) 查詢向量相似度取 top-k→5) 組 prompt＋引用規則→6) 生成並回傳來源。
  片段 SQL 示意：

  SELECT id, chunk
  FROM kb
  ORDER BY embedding <-> :qvec
  LIMIT 5;
  

  注意：加入權限過濾與 rerank，避免檢索到不該看的資料。

• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q9, B-Q11, D-Q7

Q8: 如何用 E2E 測試（Playwright/Cypress）驗證前後端整合與 AI 輸出？

• A簡: 以固定測試帳號與測試輸入跑 UI 流程；檢查回覆區塊可解析、欄位齊全並在時間門檻內完成。
• A詳: 步驟：1) 建立測試環境固定模型版本；2) 用 E2E 工具填表送出；3) 等待回覆元素出現；4) 驗證 JSON/欄位/引用；5) 記錄耗時。
  片段示意：

  await page.fill("#q", "既有功能小改要不要新prompt檔？");
  await page.click("#send");
  await expect(page.locator("#answer")).toContainText("回歸測試");
  

  注意：把「不可控」降到最低（固定參數、mock 外部工具）。

• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q10, B-Q6, D-Q6

Q9: 如何在維運中用 AI 自動摘要 log/stacktrace 並產出工單描述？

• A簡: 收集錯誤片段與關鍵指標後送 LLM 摘要；輸出固定欄位（影響、可能原因、建議步驟）供人工確認。
• A詳: 步驟：1) 擷取 stacktrace（遮罩機密）→2) 附上版本/部署時間→3) 用 prompt 要求輸出結構化摘要→4) 寫入工單系統→5) 人工核可後採用。
  欄位範例：

  {"impact":"","suspects":[],"next_steps":[]}
  

  注意：避免讓模型直接下「已確定根因」，要求「假設＋證據」並附來源片段。

• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q13, B-Q15, D-Q1

Q10: 如何把 AI demo 快速產品化（feature flag + 指標 + 灰度）？

• A簡: 先用開關包住 AI 路徑，接上監控與回滾；小流量上線收集指標，再逐步擴大並回流測資。
• A詳: 步驟：1) 在後端加 AI_ENABLED 開關；2) 新舊路徑可切換；3) 記錄 token/延遲/成功率；4) 灰度（內部→5%→25%）；5) 失敗自動降級；6) 把線上失敗案例回流 eval。
  設定示意：

  AI_ENABLED=false
  

  最佳實踐：先可控再擴大，避免「一上線就全公司炸」。

• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q6, B-Q8, B-Q13

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

Q1: LLM 回答每次都不一樣（不穩定）怎麼辦？

• A簡: 固定模型版本與參數、降低 temperature；用測試集與格式驗證收斂輸出，必要時做重試與投票。
• A詳: 症狀：相同輸入得到不同答案或格式偶爾壞掉。
  可能原因：temperature 太高、prompt 含歧義、上下文太長、模型版本變更。
  解決步驟：1) 固定 model/temperature/seed（若支援）2) 簡化 prompt、加範例 3) 用 JSON Schema 驗證與自動重試 4) 對關鍵任務做 n 次投票/一致性檢查。
  預防：建立 regression 測試與版本標籤，變更必跑 eval。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q6, C-Q5

Q2: 輸出常「胡說八道」（幻覺）要怎麼診斷與改善？

• A簡: 先限制「只能引用提供資料」；導入 RAG/工具取事實，並要求附引用與不可答時回覆策略。
• A詳: 症狀：答非所問、編造政策/數字、引用不存在來源。
  可能原因：prompt 未限制、缺乏事實來源、RAG 檢索品質差、評測不足。
  解決步驟：1) 在 system 明確要求「僅依上下文」2) 加入引用格式與「不知道就說不知道」3) 用 RAG/工具調用取最新資料 4) 建立幻覺案例集做 eval。
  預防：知識治理與權限控管，並持續回流失敗案例。
• 難度: 高級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q9, B-Q12

Q3: token/費用突然暴增怎麼辦？

• A簡: 先看是哪種請求變長；做上下文裁切、快取與模型分層，並加上配額與成本告警避免失控。
• A詳: 症狀：帳單飆升、單次請求 token 異常高。
  可能原因：把整份文件塞進 prompt、聊天歷史無限累積、RAG top-k 過大、重試風暴。
  解決步驟：1) 打開 token 計量與分 endpoint 統計 2) 限制上下文/輸入長度 3) 對相同查詢做快取 4) 用小模型先分類，必要才升級大模型 5) 設定 rate limit/配額。
  預防：成本面板＋告警，PR 強制檢視 prompt 變更影響。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q7, B-Q14, B-Q8

Q4: AI 回應延遲太高，體驗很差怎麼優化？

• A簡: 先量測 P95 延遲；用串流、快取、縮短上下文與非同步化，並選合適模型與併發設定。
• A詳: 症狀：使用者等待很久、尖峰時逾時。
  可能原因：模型太大、上下文太長、外部工具/檢索慢、併發不足或重試堆疊。
  解決步驟：1) 分段量測（檢索/模型/後處理）2) 開啟 streaming 先回字 3) 壓縮上下文與減少 top-k 4) 快取與批次化 5) 非同步處理非即時任務。
  預防：設延遲 SLO 與告警，灰度上線逐步放量。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q8, B-Q14, C-Q10

Q5: prompt 改一點點就造成回歸（品質退步）怎麼處理？

• A簡: 以 eval 測試集保護行為；所有 prompt 變更走 PR、跑 regression，並用版本標籤支援快速回滾。
• A詳: 症狀：先前能過的案例突然失敗、格式錯誤率上升。
  可能原因：改動破壞了隱含規則、少了關鍵範例、模型升級但未重新校準。
  解決步驟：1) 回溯變更 commit 與模型版本 2) 跑 offline eval 找出失敗案例 3) 補回範例/約束或拆分 prompt 4) 必要時回滾到上一版。
  預防：prompt file 版本控管＋CI eval gate，並把線上失敗回流測資。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q12, B-Q2, C-Q5

Q6: 前後端整合測試常因 AI 輸出格式不一致而失敗怎麼辦？

• A簡: 強制結構化輸出（JSON Schema）並在後端做驗證與修復；前端只依契約渲染，避免自由文字耦合。
• A詳: 症狀：前端解析失敗、欄位缺漏、偶發 UI 壞掉。
  可能原因：prompt 未強制格式、輸出含多餘文字、前端直接依自然語言關鍵字判斷。
  解決步驟：1) 在 prompt 要求「只輸出 JSON」2) 用 schema validator 驗證 3) 失敗則自動重試/修復（re-ask）4) 版本化 API schema 並寫 E2E 測試。
  預防：把契約（OpenAPI/JSON Schema）當單一事實來源，變更必通知與跑整測。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q5, C-Q8

Q7: RAG 常檢索不到或檢索到不相關內容，如何診斷？

• A簡: 檢查切片策略與 embedding；調整 top-k、加入 rerank 與關鍵字混合檢索，並確保權限與資料新鮮度。
• A詳: 症狀：回答缺關鍵資訊、引用錯文件、或永遠只回一般性建議。
  可能原因：chunk 太大/太小、embedding 模型不適配語料、索引未更新、查詢語句未正規化、top-k 不合理。
  解決步驟：1) 抽樣看檢索結果是否合理 2) 調整切片與重疊 3) 改 embedding 或加 reranker 4) 混合 BM25+向量 5) 確保索引更新與權限過濾正確。
  預防：建立 RAG 專用 eval（命中率/引用正確率）持續追蹤。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q9, C-Q7, B-Q8

Q8: function calling 常失敗或參數不正確，怎麼改善？

• A簡: 先把工具 schema 簡化且嚴格驗證；用例子教模型怎麼呼叫，並對失敗做重試與回退到純文字流程。
• A詳: 症狀：模型不呼叫工具、參數缺欄位、型別錯誤或亂填。
  可能原因：schema 太複雜、命名不直覺、缺少示例、模型能力不足或上下文干擾。
  解決步驟：1) 簡化工具與參數 2) 在 prompt 放入正確呼叫示例 3) 後端做型別/必填驗證 4) 失敗時重試（附錯誤回饋）或 fallback 純文字/人工。
  預防：針對工具調用建立測試集與監控成功率，持續迭代 schema。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q10, B-Q6, B-Q11

Q9: 企業導入 AI 常卡在資安/法遵，怎麼推進？

• A簡: 先做資料分類與最小暴露；選合規部署、遮罩敏感資訊、留存審計紀錄，並用試點範圍控風險。
• A詳: 症狀：法務/資安不同意上線、無法把資料送到外部模型。
  可能原因：資料含個資/商業機密、缺審計、供應商合規不明、權限模型不足。
  解決步驟：1) 做資料分級與可用範圍 2) 遮罩/去識別化 3) 建立審計 log 與資料保留政策 4) 以私有化/區域化部署或合規供應商 5) 先選低風險場景試點（摘要/分類）。
  預防：把安全需求寫進架構與驗收指標，並定期做紅隊演練與回顧。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q11, C-Q4, A-Q6

Q10: 團隊對 AI 焦慮或抗拒（例如只想寫 code、不想溝通）怎麼解？

• A簡: 用可衡量的試點與護欄降低恐懼；把溝通轉成文件/測試/PR，並重新定義角色分工與成長路徑。
• A詳: 症狀：有人覺得會被取代、有人拒用 AI、或使用後品質更亂。
  可能原因：目標不清、缺指標與規範、缺測試導致信任崩壞、角色價值感受威脅。
  解決步驟：1) 選低風險場景試點 2) 定義指標（工時/品質/成本）3) 建立 prompt file、測試與 review 規範 4) 訓練「驗證與整合」技能 5) 讓偏好獨立作業者專注測試、工具化、CI、觀測等可衡量產出。
  預防：持續分享數據與案例，形成正向迭代文化而非口號式導入。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q9, A-Q14, B-Q1

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是「從 Prompt 到 Product」？
  • A-Q2: 什麼是 Prompt？在產品開發中扮演什麼角色？
  • A-Q3: Prompt 與傳統需求規格差異？
  • A-Q4: 什麼是 Vibe Coding？
  • A-Q6: 為什麼需要量化指標說服導入 AI？
  • A-Q7: 常見 AI 導入量化指標有哪些？
  • A-Q11: 什麼是 prompt file？核心價值？
  • A-Q12: 既有功能小修改也要 prompt file 嗎？
  • A-Q14: 初學者還要學什麼？
  • A-Q15: 簡報與共筆如何取得？
  • B-Q1: 端到端交付流程如何運作？
  • B-Q3: prompt 結構化設計機制
  • C-Q1: 建立 prompt 檔案結構
  • C-Q2: 用環境變數管理模型與金鑰
  • D-Q1: 回答不穩定怎麼辦？
• 中級者：建議學習哪 20 題
  • A-Q5: Vibe Coding 與傳統流程差異
  • A-Q8: domain knowledge 複雜時為何受限
  • A-Q9: 不想溝通的工程師如何定位
  • A-Q10: 前後端分離在 Vibe Coding 的挑戰
  • A-Q13: 維運情境的 AI 價值
  • B-Q2: prompt 版本控管與可重現性
  • B-Q4: prompt 與程式碼解耦與參數化
  • B-Q5: prompt 與 API 邊界怎麼切
  • B-Q6: AI 功能整合測試流程
  • B-Q7: offline eval 怎麼做
  • B-Q8: online monitoring 怎麼做
  • B-Q13: feature flag 與灰度 rollout
  • C-Q3: Python 載入 prompt 並呼叫 LLM
  • C-Q4: 後端安全渲染 prompt
  • C-Q5: prompt regression 測試
  • C-Q6: 建 offline eval 測資
  • C-Q8: E2E 驗證整合與輸出
  • C-Q10: demo 產品化流程
  • D-Q5: prompt 回歸如何處理
  • D-Q6: 輸出格式不一致怎麼辦
• 高級者：建議關注哪 15 題
  • B-Q9: RAG 原理與元件
  • B-Q10: function calling/tool use 機制
  • B-Q11: prompt injection 與資料外洩防護
  • B-Q12: 知識治理為何重要
  • B-Q14: 成本控制機制
  • B-Q15: 維運 incident 工作流設計
  • C-Q7: pgvector 最小 RAG 實作
  • C-Q9: 維運 log/stacktrace 摘要實作
  • D-Q2: 幻覺診斷與改善
  • D-Q3: 成本暴增處理
  • D-Q4: 延遲優化
  • D-Q7: RAG 檢索不準診斷
  • D-Q8: tool calling 失敗改善
  • D-Q9: 資安/法遵推進策略
  • D-Q10: 團隊抗拒與焦慮的落地解法