← → 翻页 · ESC 索引
生成式 AI 職訓實務應用班 140hr · 弄一下工作室
D16 / 20
Day 16 · Part 6 收束 · PRAC6-2 + PRAC6-3 + PRAC6-4

Evals · Guardrails · Cost

讓你的 AI 應用跑得準、守得住、付得起

Part 6 進階開發到了收尾——從 API、Function、Agent、RAG、Streaming 一路寫下來，今天回答三個你不能逃避的問題：怎麼知道它會穩？怎麼擋住爆炸？怎麼別把錢燒光？

Vol.16·Eval Sets · Guardrails Middleware · Cost Dashboard·2026
Duration · 5-6 小時授課 · D16 / 20 · Part 6 收束
Contact·sky8697@gmail.com
本日為 Part 6 · AI 應用開發進階的收束日
— D16 / 20 —
The Premise · 為什麼今天不能跳過
02 / 32
The Premise · 本日主張
沒有 Evals 的 LLM 應用， 是蒙著眼睛在改 prompt。

Demo 跑得起來不算數。能重複測、能擋越獄、能算清成本，
才叫「上線」。今天把這三件事一次做掉。

— D16 核心主張·從 Vibe-check 升級到 Production-ready
Page 02 · The Premise
— · —
D16 · Learning Outcomes
03 / 32 講義 · PRAC6-2
OUTCOMES · 今天結束你會做到

三件事

不是「概念聽懂」，而是「離開教室能直接套自己的產品」。

Outcome 01 · Evals
寫得出 Eval Set
為自家產品建 10–20 題 golden set + pass/fail JSON 報告，能跑能比版本。
Outcome 02 · Guardrails
擋得住四類風險
PII / 越獄 / 倫理紅線 / 出範圍——四種安檢門寫成 middleware，可逐層測。
Outcome 03 · Cost
算得清三方帳
日成本 / 延遲 p95 / 月度燃燒——三套 dashboard + 三條警報，給財務、產品、工程看。
Page 03 · 學習目標 · 5-6 hours
3 Acts · D16
第一幕 · Evals · 品質驗收
Act I · 04 / 32
Act I · PRAC6-2 · 約 100 分鐘

看得見變好

沒有 Eval Set，「改 prompt 之後比較好」永遠是錯覺

四種應用：客服 / 摘要 / 分類 / RAG，
各自寫一份 golden set + 評分規則 + JSON 報告。

Act I 開幕
— PRAC6-2 · Evals 實作 —
Why Evals · 為什麼非寫不可
05 / 32 講義 · PRAC6-2
The Trap · 大家最常踩的坑

「感覺變好了」
不是工程語言。

改完 prompt 跑兩個 case 看起來好像不錯，上線後使用者在另一批 case 上爆炸——
因為你根本不知道改完之後 30 個 case 裡有幾個變差。

Eval Set 把「覺得」翻譯成「30 題裡 27 題 pass」——
這是工程能對話的語言。
— D16 · Evals 動機
Therefore · 所以

Eval Set 給你三件事：

  • 可重跑：改 prompt / 換模型，馬上重測
  • 可比較：v1 vs v2 哪題退步、哪題進步
  • 可上 CI：commit 自動跑，回歸不漏網

沒這三件事，每次改動都是賭運氣。

Page 05 · The Trap
Act I · §1
Four Cases · 四種 LLM 應用
06 / 32 講義 · PRAC6-2
Different Tests for Different Jobs

不同應用，不同 eval 寫法

客服 / 分類 · 結構化任務

用 ground truth 比對

  • 客服：問題 → 預期 intent / 預期回應骨架
  • 分類：文字 → 預期 label（exact match）
  • 用 string-match / regex / 結構化欄位比對
  • 客觀，不需要 LLM-as-judge
摘要 / RAG · 開放式任務

用 rubric + LLM 評分

  • 摘要：忠實度 / 涵蓋度 / 簡潔度（1-5 rubric）
  • RAG：是否引用 chunk / 答案是否來自 chunk
  • 用 LLM-as-judge 給分（小心 judge bias）
  • 主觀，但 rubric 寫死後可重複
第一步永遠是「先分類」：你的應用是哪一型？選錯 eval 方法，努力跑出來的數字也是廢紙。
Page 06 · Four Cases
Act I · §2
Eval Pipeline · 三層次架構
07 / 32 講義 · PRAC6-2
The Three Layers · 一份完整 Eval 的三層

從 dataset 到報告，三步走完

Layer 01 · Dataset

Golden Set

10–20 題涵蓋常見 + 邊界 + 錯誤情境，
每題附 expected / metadata。
這是「真理的版本」。

Layer 02 · Scorer

評分函式

結構化任務：exact / regex / schema match。
開放式任務：rubric + LLM-as-judge。
回 {pass, score, reason}。

Layer 03 · Report

JSON 報告

總分 / 通過率 / 每題明細 / 退步題列表。
可 diff 兩個版本，
可上 CI 自動跑。

Layer 01 是一次寫完養一輩子，Layer 02-03 是每次改 prompt 都跑。golden set 的品質決定一切。
Page 07 · Pipeline
Act I · §2
Schema · pass/fail 報告範本
08 / 32 講義 · PRAC6-2
Reference Schema · 照抄起手式

Eval Report 的標準格式

// Eval Report · pass/fail JSON schema
{
  "eval_set": "hr-bot-v3",
  "prompt_version": "2026-05-09",
  "model": "claude-3.7-sonnet",
  "summary": { "total": 20, "pass": 17, "fail": 3, "pass_rate": 0.85 },
  "items": [
    {
      "id": "q-007",
      "question": "客戶酒後騎車出事，理賠嗎？",
      "expected": { "intent": "reject", "cite": "§3.2" },
      "actual":   { "intent": "reject", "cite": "§3.2" },
      "pass": true, "score": 1.0
    }
  ]
}
關鍵欄位：summary 給 PM 看趨勢，items 給 RD 看回歸。必含 prompt_version + model，否則 diff 不出來是哪改動造成。
Page 08 · Schema
Act I · §3 · 照抄
Case A · 客服 Intent 分類
09 / 32 講義 · PRAC6-2
Worked Example · 客服機器人

結構化任務的 eval 怎麼寫

Golden Set
20 題涵蓋：退貨 / 換貨 / 出貨進度 / 折扣 / 投訴 / 閒聊 / 越界。每題附 expected_intent + expected_action。
Scorer
exact match expected_intent；action 用 schema 驗（type / required fields）。LLM 不參與評分。
判讀重點
看「閒聊」「越界」這類 edge case 是否退化成主流程；intent confusion matrix 找哪兩類常被搞混。
常見漏洞
只測常見問題、不測「貌似常見其實越界」（例：問「你們老闆幾歲」），上線後客訴炸開。
底線：結構化任務一定要有 ground truth。如果你寫不出 expected，就是這題還沒搞清楚要做什麼。
Page 09 · Case A · 客服
Act I · §3
Case B · RAG 文件問答
10 / 32 講義 · PRAC6-2
Worked Example · 保險條款 RAG

開放式任務的 eval 怎麼寫

Golden Set
15 題分三層：直接命中（單一條款）/ 跨條款（要組合）/ 越界（文件沒提到）。每題附 expected_chunk_ids。
Scorer · 兩段
① 檢索層：retrieved_chunks ∩ expected_chunk_ids 的 recall@3。② 生成層：rubric（忠實度 / 引用條號 / 沒幻覺）+ LLM judge。
判讀重點
檢索 fail 但生成 pass = 模型「腦補」，最危險；越界題沒回「文件沒提到」= RAG 失效，要改 system prompt。
常見漏洞
把 LLM judge 當神諭——同一題跑三次給三種分。要固定 judge prompt + temperature=0 + 必要時 multi-judge 取中位數。
底線：RAG 一定要分「檢索」和「生成」兩層測。否則改 chunking 改半天，分數沒動，根本不知道是哪段沒救起來。
Page 10 · Case B · RAG
Act I · §3
Hands-on · Eval Set 起手式
11 / 32 講義 · PRAC6-2
Now You Try · 25 分鐘動手

替自家產品寫 10 題 eval

Step 1
先決定你的應用是「結構化」還是「開放式」——選錯整份 eval 都白寫。
Step 2
10 題分三層：6 題常見、3 題邊界、1 題明確越界。每題寫下 expected。
Step 3
跑當前 prompt 一次、把 fail 的題目原文貼出來，這就是你下一輪的改動目標。
Step 4 · A/B
改 prompt 後再跑一次，diff 兩份 JSON，看哪題進步、哪題退步——這才叫「我有改善」。
講師提醒：別追求一次寫完美，先寫 10 題能跑就好。Eval Set 是養出來的，不是設計出來的。
End of Act I · Evals·下一幕 · Guardrails 安檢門
Page 11 · Hands-on
Act I 收幕 → Act II
第二幕 · Guardrails · 輸入輸出安檢
Act II · 12 / 32
Act II · PRAC6-3 · 約 100 分鐘

守得住邊界

四種風險、兩道安檢門、一個 middleware

PII 洩漏 / 越獄注入 / 倫理紅線 / 出範圍——
四種你不擋會上新聞的風險，今天通通寫成可重複測的 middleware。

Act II 開幕
— PRAC6-3 · Guardrails 實作 —
Why Guardrails · 為什麼 prompt 不夠
13 / 32 講義 · PRAC6-3
The Reality · 你以為的安全

「我有在 system prompt 寫不要⋯⋯」

system prompt 是「請求」不是「強制」。
越獄者一句「忽略前面所有指令」就破了，
PII 用戶不小心貼了，模型就照單全收一起學去了。

Guardrail 是程式碼裡的真鎖——
不依賴模型「願意守規矩」，而是進不來、出不去。
— D16 · Guardrails 動機
Therefore · 兩道門

所有請求必須過兩道：

  • Input Guardrail：進 LLM 之前，擋 PII / 越獄
  • Output Guardrail：出 LLM 之後，擋紅線 / 出範圍

兩道缺一不可——只擋輸入會被 LLM 自己腦補違規，只擋輸出會白燒一堆 token。

Page 13 · The Reality
Act II · §1
Two Gates · 輸入 / 輸出兩道門
14 / 32 講義 · PRAC6-3
The Pipeline · 一次請求的完整旅程

進來 → 主 LLM → 出去，三段都要守

Gate 01 · Input

PII + 越獄

身分證 / 信用卡 / 手機正則 +
越獄五模式偵測器。
擋下 / 軟擋 / 放行三段判決。

Core · Main LLM

主邏輯

原本的 system prompt + tools。
這層假設「進來的已經乾淨」——
所以 Gate 01 一定要先擋好。

Gate 02 · Output

紅線 + 範圍

倫理紅線（醫療 / 投資 / 自傷）+
out-of-scope（非業務話題）。
再判一次：擋下 / 改寫 / 放行。

每道 Gate 都回 {pass, reason, mutated_input}——讓主 pipeline 能看到每層攔了什麼，事後可稽核。
Page 14 · Pipeline
Act II · §2
Case A · PII 過濾
15 / 32 講義 · PRAC6-3
Worked Example · 個資外洩防線

正則 + LLM 複核，兩層一起跑

擋下（硬拒）
正則命中身分證 / 信用卡（Luhn 過）→ 直接拒絕，不進 LLM。
軟擋（mask 後放行）
手機 / 地址 / Email → 用 [PHONE] / [ADDR] 取代後進下一步，原文只留 encrypted_vault。
放行
LLM 複核 risk=LOW 且無正則命中 → 原文進下一步，不走 mask。
常見漏洞
只做正則 → 「A123 456 789」中間加空格逃過；只做 LLM → token 爆 + 延遲 +800ms。兩層一起跑。
講師提醒：「擋下」與「軟擋」的差別決定使用者體驗——身分證硬拒，地址 mask 後仍可繼續對話，不要全部 reject。
Page 15 · Case A · PII
Act II · §3
Case B · 越獄注入偵測
16 / 32 講義 · PRAC6-3
Worked Example · 五種越獄模式

不只擋「忽略前面指令」，五種一起守

五種模式
override（覆寫指令）/ role（角色扮演）/ dual（雙重身分）/ encoded（base64 / 摩斯）/ auth（假冒管理者）。
擋下（硬拒）
confidence ≥ 0.7 → 回固定訊息，不進主 LLM，log 到 audit。
軟擋（補防線後放行）
confidence 0.4–0.7 → 進主 LLM，但 system prompt 再注入一次，並縮短 max_tokens 降風險。
常見漏洞
偵測器自己被越獄——必須用 JSON 結構回，不要把攻擊 prompt 當對話回，否則偵測器一起被洗腦。
底線：只擋白話「忽略前面指令」太天真。五種模式都覆蓋，攻擊者改包裝你還守得住。
Page 16 · Case B · Jailbreak
Act II · §3
Case C · 倫理紅線（Output）
17 / 32 講義 · PRAC6-3
Worked Example · 醫療 / 投資 / 自傷

輸入很乾淨，輸出也可能踩線

擋下（HIGH）
「建議現在加碼 NVDA」「吃 2 顆普拿疼 + 1 顆安眠藥」「（對未成年）自傷詳細步驟」→ 丟棄並回安全訊息。
軟擋（MED · 改寫）
「XX 股最近看起來不錯」→ 改成「股市短期波動難預測，請教合格理財顧問」。
放行（LOW）
名詞解釋 / 一般衛教 / 導向專業資源。
常見漏洞
只擋輸入不擋輸出——使用者「我有點憂鬱怎麼辦」很乾淨，LLM 可能回「建議吃 SSRIs」。output side 必擋。
講師提醒：記得 log。事後家屬 / 主管 / 法務問「這次回應為什麼這樣」，沒 log 就完了。
Page 17 · Case C · Ethics
Act II · §3
Case D · Out-of-Scope（Output）
18 / 32 講義 · PRAC6-3
Worked Example · 跨界問題的處理

「不關你事的問題」怎麼回才得體

三層分類
in_scope（業務內）/ adjacent（相鄰但不直接）/ out_of_scope（完全無關）。
擋下（out_of_scope）
不進主 LLM → 回固定模板 + 真實資源 + 留業務回路（「如有訂單問題請說」）。
軟擋（adjacent · 帶模板）
主 LLM 用「同理一句 + 問是否與訂單有關」模板回，保留轉回業務的出口。
常見漏洞
只擋關鍵字（「心情」「法律」）→ 錯殺合理問題。用分類器 + 對話歷史判斷比關鍵字準。
底線：out_of_scope 千萬不要只回「無法回答」。要給真實資源，不然會被罵冷血、上社群媒體。
Page 18 · Case D · Out-of-Scope
Act II · §3
Hands-on · 把 Guardrail 做成 middleware
19 / 32 講義 · PRAC6-3
Now You Try · 30 分鐘動手

Guardrail = 可單元測試的 middleware

挑戰 1 · 紅隊測試
用 3 種攻擊測你自家 bot：直接覆寫 / 角色扮演 / 編碼夾帶——記錄越獄成功率，整理「失分表」。
挑戰 2 · 邊界 10 題
寫 10 題「貌似合理但其實越界」的問題，標 in / adjacent / out，看分類器跟你直覺差距多大。
挑戰 3 · 寫成 middleware
抽出 pii_filter、jailbreak_filter，串成 jailbreak → pii → 主 LLM → output compliance，每層回 {pass, reason, mutated_input}。
驗收
能列出每一次請求通過了哪些 guardrail、在哪一層被擋 / 改寫——這就叫可稽核。
核心觀念：Guardrail 不是「希望模型表現好」，是程式碼把它逼成這樣。能單元測試的 middleware 才靠得住。
End of Act II · Guardrails·下一幕 · Cost 成本控管
Page 19 · Hands-on
Act II 收幕 → Act III
第三幕 · Cost · 成本與延遲控管
Act III · 20 / 32
Act III · PRAC6-4 · 約 100 分鐘

付得起未來

三套儀表板、三條警報、三方對帳

跑得起來不算贏，付得起、追得上、警得到才算贏。
今天把 token / 費用 / 延遲三條線通通接上 dashboard。

Act III 開幕
— PRAC6-4 · Cost Dashboard 實作 —
Three Blind Spots · 大家最常瞎的三個地方
21 / 32 講義 · PRAC6-4
The Blind Spots · 為什麼月底才哀號

「怎麼這個月燒
這麼多？」

因為昨天上線的 agent-tool 進了無限迴圈、
因為向量檢索沒加 cache 每秒打 200 次、
因為某個 power user 用 10 萬 token / req 在玩——你都不知道。

Cost dashboard 不是給財務看的數字，
是給工程看的偵錯工具。
— D16 · Cost 動機
Therefore · 三條軸線

最少要追三軸：

  • Token / Cost：誰在燒、燒在哪個 feature
  • Latency p50 / p95：哪一段卡住、是不是抖動
  • Budget Burn：月度燃燒率 + EOM 外推

三軸缺一，月底就會看不懂帳單。

Page 21 · Blind Spots
Act III · §1
Case A · 日成本儀表板
22 / 32 講義 · PRAC6-4
Worked Example · agent-tool 上線後爆預算

找出誰在燒、燒在哪

四張圖
(1) 日成本 by feature 堆疊柱、(2) 7 日滾動均 vs 當日折線、(3) Top 10 user by cost、(4) tokens vs cost 散點找離群。
警報
info：日花費 ≥ 7 日均 +30%（Slack）；critical：≥ +100% 或單 user 1h > $20 或單 req > 30 萬 token（PagerDuty）。
本案元兇
agent-tool 昨晚上線，tool-loop 沒設 max_iterations，LLM 在「查庫 → 算錯 → 再查庫」無限迴圈，單 req 5–10 萬 token。
修法
加 max_iterations=5、tool 結果 cache、異常 early stop——三招一起上，不靠單點。
關鍵：每小時跑一次 rollup，不要等隔天。等到隔天看帳單，已經燒掉一晚的預算了。
Page 22 · Case A · Cost
Act III · §2
Case B · 延遲拆解儀表板
23 / 32 講義 · PRAC6-4
Worked Example · p95 突然變慢

把 latency拆成四段看

四段
client → edge → ttft（time to first token）→ stream（後續吐字）。每段都有 p50 / p95 兩條線。
視覺化
顏色固定 client=灰 / edge=橘 / ttft=藍 / stream=綠，一眼看哪段爆。中介層加 trace 火焰圖下鑽到 request_id。
警報 + Fallback
critical：total p95 > 5,500ms 持續 5 分鐘，自動切備援 model（claude-3.7-sonnet ↔ gpt-4o）+ Slack 通知。
本案元兇
prompt_build 那層加了同步 RAG 檢索（沒 cache），p95 從 180ms 衝到 2,600ms。改 async + Redis cache + retrieval 限流。
底線：沒拆段的 latency 等於沒監控。「整體變慢了」是現象，「ttft 那段抖動」才是線索。
Page 23 · Case B · Latency
Act III · §2
Case C · Budget Burn · 三方對帳
24 / 32 講義 · PRAC6-4
Three Reports · 同一份 SQL · 三種視角

財務 / 產品 / 工程各看各的圖

Finance · 財務看

月度累積 vs 預算

  • 累積曲線 + 預算基準線 + EOM 外推
  • 過 80% 變橙、95% 變紅
  • 關心「會不會超支」
Product · 產品看

tier 毛利 + 賠錢 user

  • 每 tier 毛利率柱狀
  • cost-per-user 箱型圖找離群
  • 關心「定價對不對、要不要切等級」
底線：三方一起看才不會出現「工程說省了、財務看不到、產品不知道砍哪」——同一份 SQL，不同 view。
Page 24 · Case C · 3-way
Act III · §3
Alerts · 警報三段
25 / 32 講義 · PRAC6-4
Three Levels · 不要只設一條紅線

從提醒到緊急停車三層

Yellow
月中 16 日前累積 ≥ 60% 預算 → PM Slack 提醒，先看趨勢，不馬上動手。
Orange
距月底 > 7 天但已用 ≥ 80% → 啟動 cost saving：降 temperature、關非核心重試、開始談是否要加預算。
Red
≥ 95% → 硬限 per-user quota、切便宜 model、關 free tier agent-tool。再不擋會超預算。
EOM 自動報
每週一寄 EOM 外推給 finance@、eng-lead@、product@——不等月底，提前對齊。
關鍵：警報設計要動作明確。「快超預算了！」沒用，要寫「降 temp 0.7→0.3 / 關 free tier agent」這種具體動作。
Page 25 · Alerts
Act III · §3
Schema · usage_log 表設計
26 / 32 講義 · PRAC6-4
Reference Schema · 一次寫對受用整年

三套儀表板的共同源頭

// usage_log · 每次 LLM 呼叫寫一筆
{
  "request_id": "req_2026050900142",
  "ts": "2026-05-09T14:23:01Z",
  "user_id": "u_4823",
  "feature": "agent-tool",
  "model": "claude-3.7-sonnet",
  "prompt_version": "v3.1",
  "input_tokens": 2840,  "output_tokens": 612,
  "cost_usd": 0.0212,
  "latency_ms": { "client": 18, "edge": 42, "ttft": 410, "stream": 1820 },
  "middleware_trace": ["jailbreak:pass", "pii:mask", "output:rewrite"],
  "tier": "pro"
}
關鍵欄位：feature / prompt_version / latency 拆段 / middleware_trace——缺一就無法事後溯源，要在第一行 SDK wrapper 就寫進去。
Page 26 · Schema
Act III · §3
Hands-on · 接 Grafana / Datadog
27 / 32 講義 · PRAC6-4
Now You Try · 30 分鐘動手

把三條線接上儀表板

挑戰 1 · 三 panel
把 usage_log 匯入 Grafana / Datadog，建：(a) 日成本 by feature 堆疊、(b) 四段延遲 p50/p95、(c) 當月預算燃燒條。
挑戰 2 · 三條警報
(a) 日花費 > 7 日均 +100%、(b) total p95 > 5,500ms 持續 5 分鐘、(c) 月度 ≥ 80% 且距月底 > 7 天。刻意觸發確認有收到。
挑戰 3 · 月報自動寄
cron（GitHub Actions / Make / n8n）每月 25 號跑三份 SQL，渲染 HTML / PDF，寄給 finance / product / engineering。
驗收
三份報表同源、不同欄位；下個月不用人工算 EOM；任何異常 5 分鐘內收到 Slack。
講師提醒：不求美，求看得到 + 算得清 + 寄得出去。Dashboard 上線那天，你的 LLM 應用才真的能放生上線。
End of Act III · Cost·下一段 · Part 6 收束
Page 27 · Hands-on
Act III 收幕 → Closing
Part 6 收束 · D13 → D16 全景
Closing · 28 / 32
Part 6 · AI 應用開發進階 · Complete

從 API 到上線就緒

四天打通：呼叫、推理、串流、把關

D13 API + 後端 → D14 Function + Agent → D15 Streaming + RAG → D16 Evals + Guardrails + Cost。
Part 6 結束，你寫得出能上線、能驗收、能算清的 LLM 應用。

Closing · Part 6 全景
— D13 → D16 完成 —
Recap · 你這四天學了什麼
29 / 32 講義 · Part 6
The Recap · 用一張表確認你拿到什麼

Part 6 學習地圖

D13 · API 基礎
SDK 呼叫、System Prompt 設計、Token 概念、Node / FastAPI 後端中介層、API key 不外洩
D14 · Function + Agent
Tool Schema、ReAct Loop、RAG-as-Tool、無限迴圈 / 工具幻覺 / 失敗未處理三大防禦
D15 · Streaming + RAG
SSE / EventSource 即時回應、chunking 策略、向量檢索、最小文件問答器
D16 · Evals + Guardrails + Cost
golden set + pass/fail JSON、四類風險 middleware、三套 dashboard + 三條警報
底線：Part 6 結束，你能說「我做了一個 LLM 產品」——而不是「我跑了一個 demo」。
Page 29 · Recap
Part 6 · D13 → D16
Three Principles · 帶得走的三句話
30 / 32 講義 · Part 6
Three Principles · 比技術更重要的

離開教室請帶著這三條

原則 01 · Eval First

先寫 eval，再改 prompt

  • 沒 eval 就改 prompt = 賭運氣
  • 10 題 golden set 比 100 行系統提示有用
  • 每次改動都 diff，看誰進步誰退步
原則 02 · Code Over Prompt

能用程式擋的，
就不要靠 system prompt

  • Guardrail 是真鎖，prompt 是請求
  • Middleware 可單元測試，prompt 不行
  • 越獄者一句話就能破 prompt
原則 03 · Observability：沒有 dashboard 的 LLM 應用是黑盒子。token / latency / cost 三軸缺一不可，月底才不會被嚇到。
Page 30 · Principles
Part 6 · 三原則
Map · D16 → D17 接續
31 / 32
What's Next · 明天我們繼續

D17 · Part 7 開幕 · 專題 MVP

D16（今天）
Evals 品質驗收 + Guardrails 安全過濾 + Cost 成本控制 → Part 6 收束
D17 · CH7-1
題目定義與 MVP 拆解 — 從「我想做一個 AI 應用」到「兩週能做完的最小可驗證版本」
D17 · CH7-2
專題開發實作（一）— 把 Part 6 學的全部組起來，做出你自己的 demo 雛形
D18-D20
衝刺、測試、上線、demo day——把今天學的 Eval / Guardrail / Cost 用在你自己的專題
銜接重點：Part 6 給你「能做出可上線 LLM 應用的能力」，Part 7 讓你真的做一個出來、放到履歷上。
Page 31 · Map Forward
D16 → D17
End of D16 · Part 6 Complete
32 / 32
D16 / 20 · Evals + Guardrails + Cost · Complete

To Be
Continued

明天 D17 · Part 7 開幕 · 專題 MVP

你今天從「會寫 Agent」升級成「能驗收、能擋、能算的 LLM 工程師」。
明天我們把這四天學的，全部用在你自己的專題上。

Vol.16·Eval Sets · Guardrails Middleware · Cost Dashboard·2026
弄一下工作室·生成式 AI 職訓 140hr·D16 / 20
Contact·sky8697@gmail.com
感謝今天的投入 · Part 6 收束
— 明天見 · D17 · Part 7 開幕 —