前 27 天，我們一塊一塊地拆解了兩個職務的工作任務。今天要把它們組裝回一個完整的東西。
這也是我對每位讀者的建議：與其收藏 27 篇文章，不如做出一個作品。。
「學了這麼多，但拼不起來。」
會這麼感受很自然，每天我們談的都是一個零件模組，而零件與系統之間隔著一件事——取捨與順序。
今天用一個具體的專題，示範這些零件怎麼組裝、以什麼順序、每個階段驗收什麼。
📊 職缺訊號
「需求分析與系統架構」出現在 15.0% 的生成式 AI 職缺中。比例不高，但它是資深職缺的標配——因為它衡量的不是「會不會做」，而是「知不知道該做什麼、以什麼順序做」。今天這篇就是在練這件事。
專題：企業內部知識助理——員工可以問公司政策、查詢自己的工單，並取得有來源引用的答案。
在寫任何程式碼之前，先回答四個問題（這一步就是 Day 06 說的「回頭 1」的預防）：
| 問題 | 這個專題的答案 |
|---|---|
| 誰用、解決什麼痛點 | 全公司員工；目前查政策要問 HR、查工單要開 IT 單，平均等 4 小時 |
| 成功長什麼樣（業務指標） | HR 與 IT 的例行詢問工單量下降 30%；使用者滿意度 ≥ 4/5 |
| 錯誤的代價 | 回答錯誤的政策 → 員工做錯事；洩漏他人薪資 → 嚴重，不可接受 |
| 不做什麼（範圍界線） | 不處理需要人工判斷的申請核准、不主動發起任何動作、不對外服務 |
第三列決定了整個架構。 「洩漏薪資不可接受」直接推導出：權限必須在檢索階段執行（Day 27）、必須強制引用來源（Day 20）、代理不得有對外傳輸能力（Day 25）。
📌 架構決策紀錄（ADR）
把每個重大決策寫成一頁：背景、選項、決定、理由、後果。例如「為什麼用 RAG 而非微調」「為什麼自建 vLLM 而非用 API」。
它的價值在半年後——當有人問「為什麼當初這樣做」時，你有答案；當情況改變時，你知道原本的假設是什麼、還成不成立。
圖 28-1：企業生成式 AI 平台的分層參考架構（示意架構）。觀測與治理是「橫切層」——它們不在請求路徑的主線上，卻掛在每一層旁邊。
對應到本系列的內容：
| 層 | 元件 | 對應 |
|---|---|---|
| 閘道層 | 認證、限流、路由、稽核入口 | Day 17、27 |
| 編排層 | 對話管理、工作流、agent 迴圈、工具執行 | Day 17、21–22 |
| 模型層 | vLLM 自建 ／ API、模型路由、快取 | Day 26 |
| 檢索層 | 向量庫、BM25、重排序、權限過濾 | Day 18–19、27 |
| 資料層 | 文件來源、索引管線、增量更新 | Day 09、18 |
| 觀測層（橫切） | trace、token 成本、延遲、評測結果 | Day 14、22、24、26 |
| 治理層（橫切） | RBAC、PII 遮罩、audit log、風險登錄 | Day 27 |
圖 28-2：綜合專題的八週里程碑排程（示意排程）。注意 M4 評測與 M3 開發並行——才能持續守住品質門檻。
產出：一頁需求文件、成功指標定義、3–5 份 ADR、風險登錄表（Day 27 的風險矩陣）。
驗收：能用三句話說清楚「誰用、解決什麼、怎麼算成功」，且業務單位同意。
這一週不寫程式碼。 很多人受不了，但跳過這週的專案，通常在第六週才發現方向錯了。
產出：文件載入與結構感知切塊、嵌入與索引、混合檢索、含來源引用的回答。
驗收：
source／dept／level／updated_at
產出：工單查詢工具、ReAct 迴圈（含迭代與成本上限）、trace 紀錄。
驗收：
產出：50 題評測集（含 15% 拒答題）、自動化評測腳本、CI gate、κ 驗證報告。
驗收：
M4 與 M3 並行是刻意的設計。 如果等功能做完才建評測，你會為了「趕快上線」而降低標準。評測要與開發同時長出來。
產出：docker compose 全套（app／向量庫／Langfuse／Prometheus／Grafana）、K8s 部署 YAML、儀表板。
驗收：
# docker-compose.yml（節錄）——一個指令跑起整套
services:
app: { build: ., ports: ["8000:8000"], env_file: .env }
chroma: { image: chromadb/chroma, volumes: ["./data/chroma:/chroma"] }
langfuse: { image: langfuse/langfuse, ports: ["3000:3000"] }
prometheus: { image: prom/prometheus, volumes: ["./ops/prometheus.yml:/etc/prometheus/prometheus.yml"] }
grafana: { image: grafana/grafana, ports: ["3001:3000"] }
產出：RBAC 權限矩陣、PII 遮罩中介層、audit log、使用政策與 AI 揭露說明。
驗收：
| 關卡 | 時間 | 條件 |
|---|---|---|
| MVP 可示範 | 第 3 週 | 能問答、有引用、內部 3–5 人試用 |
| Beta 內部試用 | 第 5 週 | 過品質門檻、有監控、開放一個部門 |
| GA 正式上線 | 第 8 週 | 治理齊備、壓測通過、有回滾機制 |
如果你是為了作品集而做，我建議大幅精簡：
| 完整版 | 作品集版（1–2 週） | 為什麼可以砍 |
|---|---|---|
| 50 份企業文件 | 10 份公開文件（政府法規、開源專案文件） | 重點是流程不是規模 |
| vLLM 自建 | 用 API 或 Ollama | 除非你要展示 LLMOps 能力 |
| K8s 部署 | docker compose | 面試官看的是「有沒有容器化思維」 |
| 50 題評測集 | 20 題（含拒答題） | 這一項絕對不能砍 |
| RBAC 完整權限 | 兩個角色的權限過濾示範 | 展示你知道要在檢索階段做 |
| Langfuse ＋ Prometheus | 一份簡單的成本與延遲統計 | 展示你會量測 |
💡 作品集的關鍵不是功能多，是「你能講出取捨」
面試官不會因為你做了 50 個功能而錄取你，但會因為你能說出這段話而印象深刻：
「我的 RAG 一開始用固定切塊，答對率 0.61。加了查詢改寫到 0.68，改成結構感知切塊到 0.79——最大的提升來自切塊，不是模型。後來加混合檢索到 0.85，重排序到 0.88，但延遲從 180 ms 漲到 620 ms。我最後停在這裡，因為再往上的邊際效益不划算。」
這段話展示了：會量測、懂原理、有判斷力、知道何時停手。這比任何技術清單都有說服力。
iThome鐵人賽
看影片追技術