翼王資訊社
知識分享 · AI 系統設計
史丹佛的 AI 系統課在教什麼？從強化一顆 LLM，到蓋一套會做事的系統
換更強的模型是廠商的事，你能施力的是縱軸：提示詞工程、RAG、agentic workflow 與 eval。這篇把一堂兩小時的史丹佛課程整理成一條路線圖，最後用一個客服 agent 案例把全部串起來。
先看整張圖：橫軸是廠商的事，縱軸才是你的
這幾年最搶手的職缺之一是 AI Engineer／AI Builder —— 會把 AI 技術組合成實際能用的工具的人。想入行的人很多，但資源不是太破碎就是太艱澀。這支影片整理的是史丹佛一堂約兩小時的課程，講者認為它是「目前最接近答案的東西」：從 LLM 的本質一路帶到 Prompt Engineering、RAG、Fine-Tuning、Agentic Workflow 與 Multi-Agent，每項技術的存在理由與適用情境都交代清楚。
整堂課的定位，一張圖就講完。LLM 要變強有兩條路：橫軸是換更強的 base model（基礎模型）—— 那是 OpenAI 與 Anthropic 這些廠商的事，一般人沒有能力也沒有錢自己訓練模型；縱軸是在現有模型上疊工程技術（課程稱 Augmenting LLM）—— 這才是你能施力的地方，也是整堂課唯一在講的事。
課程路線圖。這篇文章由下往上，一層一層爬。
Base model 的四個限制
為什麼光會用 ChatGPT 不夠？因為只用 base model，在商業場景一定撞牆。教授整理了四個限制：
- 缺乏領域知識。課堂上有學生做農業設備，要用相機判斷作物病害 —— 這種資料集市面上根本找不到。你公司的內部文件、產品規格，模型一樣不知道。
- 資訊落後。模型不可能每幾個月重新訓練一次，新事件、新公司、年輕人的流行語，它通通不認識。
- 控制很難。LLM 是機率性輸出，同樣的提示詞跑兩次結果可能不同。聊天無所謂；但客服系統對「能不能退費」一下說可以一下說不行，公司就麻煩了。教授直言：連資金人才最多的團隊都還沒把這件事完全解決。
- 內容太長就退步。就算窗口拉到百萬 Token，把一句「Gary 午餐吃了一顆蘋果」藏進一整年的會議記錄裡再問，模型有時還是答不出來 —— 這現象叫 lost in the middle，近年已明顯改善，但還在。
第一層：提示詞工程 —— 半人馬、生化人與 Chaining
教授的定位很清楚：提示詞工程不會是一個職業，但是每個工程師用一輩子的基本功，像九九乘法表。這一節最有意思的是一個真實實驗：管理顧問公司 BCG 與哈佛學者把顧問分成三組 —— 沒有 AI、有 ChatGPT、有 ChatGPT 加提示詞訓練 —— 得到三個發現：
- 鋸齒邊界（Jagged Frontier）：AI 不是所有任務都行。有些任務加 AI 顯著加分，有些反而扯後腿 —— 能力的邊界是鋸齒狀的，不是一條直線。
- 在方向盤前打瞌睡（Falling asleep at the wheel）：碰到 AI 不擅長的任務卻照單全收、直接送出，結果比不用 AI 還慘。你得知道它的邊界在哪。
- 半人馬與生化人（Centaurs & Cyborgs）：用法分兩種 —— 半人馬是分工委派型，丟一個長提示詞叫它做完整份簡報，自己去忙別的；生化人是高頻來回型，一句一句對話協作。重複性高、流程清楚的任務用半人馬；要判斷、要創意、要來回校正的任務用生化人。沒有好壞，重點是有意識地切換。
教授最推的一招：Prompt Chaining
寫好單一提示詞的公式是三件事：給誰看、產出格式、重點是什麼。但教授說最常用也最重要的技巧是 Prompt Chaining —— 注意，跟 Chain of Thought（叫模型一步一步想）不一樣，Chaining 是把一個複雜任務拆成多個獨立的提示詞，前一個的輸出餵給下一個：
# 單一提示詞（黑盒子）：出了問題不知道該調哪裡
讀這封投訴信，寫一封專業的回應。
# Prompt Chaining：拆成三段，每段可以獨立測試、獨立除錯
① 從這封投訴信裡，抽出客戶抱怨的具體問題
② 針對上面抽出的問題，起草回信大綱
③ 照這份大綱，寫出完整的回信Chaining 不只讓輸出更穩，還讓你獲得可觀察性（observability）：哪一段出錯，一眼就看得出來。用過 n8n 這類流程工具的人，對這個模式會很有既視感。
第二層：Fine-Tuning —— 能不做就不做
教授對微調（fine-tuning）的立場只有一句：能不做就不做。四個理由：
| 理由 | 白話說明 |
|---|---|
| 資料成本高 | 要大量高品質、標注好的資料，一般人負擔不起 |
| 容易 overfit | 特定任務變強，通用能力反而退步，失去 base model 原本的廣度 |
| 時效性差（最傷） | 花兩個月調完上線，下個月新一代 base model 直接打贏你調的版本 |
| 提示詞多半就夠 | 效果常常一樣，成本低得多；而且換新模型時提示詞大多帶得走，微調過的模型帶不走 |
例外是法律、科學這類需要重複、高精度輸出的領域，或 base model 在某個領域明顯吃力 —— 這些情況微調有幫助。但對多數人來說，想把領域知識塞進模型，答案不是微調，是下一節的 RAG。
第三層：RAG —— 幫模型補知識的標準解法
RAG 是 AI 工程師面試最常考的題目之一，面試官還常要求「用五歲小孩聽得懂的方式解釋」。它解的痛點：模型缺你的資料、資料有時效性、整份餵進去太貴又抓不準。做法用一個需要高度準確的場景 —— 藥物副作用查詢 —— 來走一遍：
RAG 全流程。找的是「語意最接近」，不是關鍵字比對。
細節上還有兩件事：文件太長（例如一種藥 50 頁）不能整份轉成一個向量，要先切塊（chunking）；更進階的做法是多層次儲存 —— 同時保留整篇、每章、每段的向量，檢索時先找到章、再鑽到段，大文件的命中率更高。至於「長上下文模型成熟後 RAG 會不會死」的辯論，教授的判斷是理論上對、實務上錯：每次提問都叫模型把整個雲端硬碟重讀一遍，沒人等得了 —— 就像搜尋引擎靠的是預先建好的索引，不是每次查詢都重爬整個網路。
第四層：Agentic Workflow —— 工程心態要翻面
這個詞是吳恩達（Andrew Ng，Coursera 共同創辦人、Google Brain 創始負責人）提的。因為「AI Agent」已經被用到爛掉 —— 一段長提示詞也叫 agent、複雜的多代理系統也叫 agent —— 他改用 agentic workflow 精確描述一件事：把提示詞、外部工具與各種元件，組進一個有結構的工作流程，成為一套系統。RAG 在這套系統裡降級成工具之一：使用者說要退訂單，RAG 只能丟政策文件給你；agent 則會用 RAG 查政策、主動問訂單編號、用工具查訂單、確認退費、告訴你幾個工作天會處理。
四個面向，傳統軟體與 agentic 系統完全相反
- 資料：傳統吃結構化資料（JSON、資料庫、表單）；agentic 吃自由文字、圖片、音訊，沒有固定格式。
- 邏輯：傳統是確定性的（deterministic）—— 同樣輸入永遠同樣輸出；agentic 是模糊的（fuzzy）—— 模型有隨機性，沒有唯一答案。
- 架構心態（最重要）：傳統思維是精確控制每一步執行路徑；agentic 思維是 think like a manager —— 給 AI 目標和限制，讓它自己決定怎麼完成。你管方向和邊界，不管每一行程式。
- 測試：傳統跑一百次結果一樣；agentic 是迭代探索式的，你沒辦法窮舉所有情況。
第一條落地原則：能 deterministic 就 deterministic
教授拿自己團隊做的技能測驗系統當例子：選擇題、配對題有標準答案，用一般程式算分；語音題沒有標準答案，才交給 LLM 做模糊評分（fuzzy scoring）。而模糊的部分一定會犯錯，所以要配護欄 —— 他們做了申訴功能（Appeal）：受測者對 AI 的判分不服，由真人介入審查。護欄的精神不是讓 AI 零錯誤，而是它出錯時有人接得住。
打造一個 agent 的三要素與三層自主性
用「訂機票去巴黎」當例子，agent 需要三樣東西：Prompts（角色、能做不能做什麼）、Context Management（把對的資訊在對的時間給它 —— 高頻的 working memory 記「這次要去巴黎」，低頻的 archival memory 放五年訂房紀錄，要用再撈）、Tools（做事的：訂票、付款；查資料的：撈 CRM、查訂單）。自主性則分三層：
- 寫死步驟：流程全固定，安全但僵硬，遇到預期外的情況就卡住。
- 固定工具、放手步驟：給一組工具，怎麼組合它自己決定 —— 目前 production 最常見、教授推薦的起點。
- 完全自主：自己決定步驟、甚至自己寫程式造工具。能力最強、風險也最高 —— 判斷錯了自己訂 100 張機票，你就完蛋了。
工具接入的標準化（MCP）與「把別人的 agent 當工具呼叫」的 agent-to-agent 想像，在系列第一篇已經講過，這裡不重複。
Eval —— 系統的命脈
上線前都要回答同一個問題：怎麼知道它真的有用？答案是 eval（評估），教授稱之為 production 系統的命脈。他給的框架是三個維度交叉：
| 維度 | 一邊 | 另一邊 |
|---|---|---|
| 看哪裡 | End-to-End：整體體驗，使用者用完給幾分 | Component-based：拆開每一步看 —— 光看整體知道壞、不知道為什麼壞 |
| 怎麼判 | Objective：有標準答案，寫個腳本自動比對（訂單編號寫進資料庫對不對） | Subjective：沒有標準答案（語氣好不好、有沒有同理心），靠人工或 LLM 當評審 |
| 看什麼 | Quantitative：數字 —— 成功率、延遲 | Qualitative：感覺 —— 哪裡幻覺、哪一步讓使用者卡住；要人工一筆一筆看，沒有捷徑 |
LLM-as-Judge：讓另一個模型當評審
主觀項目常用的做法是 LLM-as-Judge，有四種主流玩法，可以混用：兩個答案比高下（pair-wise）、直接打一到五分（single-answer grading）、附標準答案再比（reference-guided）、照你定義的評分表打分（rubric-based，例如「五分＝一百字內、含三個重點、第一句是總覽」）。
實際跑一輪主觀評估的四個步驟，教授用「旅行社 agent 的禮貌度」示範：① 錯誤分析 —— 從一千個對話抽二十個人工讀，先知道問題長什麼樣（這步不能省）；② 設計 eval —— 把發現的問題翻譯成評分表，交給 LLM 評審；③ A/B 測模型 —— 固定提示詞、換底層模型，同一批對話跑分；④ A/B 測提示詞 —— 固定模型、改一個詞，看差多少。核心原則只有一條：先人工掃出問題再自動化，而且模型與提示詞一次只動一個，不然你不知道差異是誰造成的。
案例：一個客服 agent 從零到上線
課程用一個案例把全部串起來：做一個客服 agent，處理「我要改 A127 訂單的地址，因為我搬家了」這類請求。課堂上一個學生的回答讓教授很喜歡：「我會先去客服旁邊坐一到兩天，看他們實際怎麼處理。」—— 要先理解人怎麼做這件事，才知道怎麼讓 AI 做。觀察之後你會發現客服走了五步，這就是 task decomposition（任務拆解）：
五步拆解＋工具對應。最後再依三個維度建 eval，一套系統就成形了。
收尾的 eval 把前一節的框架全用上：End-to-end 看回覆正確性與滿意度；component-based 看抽資訊準度、API 錯誤率、政策遵守率；objective 的自動驗證（訂單編號對不對）、subjective 的靠評審（回信有沒有禮貌）；quantitative 看成功率與延遲、qualitative 看哪裡幻覺、使用者哪一步困惑。拆任務 → 設計流程 → 建評估，三步，就這樣。
Multi-Agent，與臺灣讀者的編按
一個 agent 已經能拆步驟、呼叫工具、寫信了，為什麼還要多個？主因是平行處理 —— 訂機票時，找航班、找飯店、查天氣沒理由排隊，拆給三個專職 agent 同時跑；次因是可復用 —— 公司的設計 agent 可以給行銷用也給產品用。互動模式以階層式（使用者只跟一個總管 agent 講話，由它派工）為主，後台再讓少數 agent 之間直接水平溝通省成本。把每個 agent 當成一個工具來呼叫，結構就乾淨了 —— multi-agent 聽起來複雜，其實只是把你已經懂的東西多疊一層。
一句話總結
縱軸由下往上：提示詞工程是基本功、微調預設不碰、RAG 是補知識的標準解、agentic workflow 是把工具組成系統、multi-agent 是再疊一層。心態上只有一個轉變 —— 從精確控制每一步，變成給目標、給邊界、建評估，像個經理人一樣管理 AI。
互動實驗室：這個需求該用哪一招？
四個常見需求，點選看課程框架會把你帶到哪一層、為什麼：
參考與引用來源 (References & Sources)
- 1. 原影片來源 (Original Video) https://www.youtube.com/watch?v=eKW9ITaltWw
- 2. Centaurs and Cyborgs on the Jagged Frontier（BCG 實驗的第一手整理） https://www.oneusefulthing.org/p/centaurs-and-cyborgs-on-the-jagged
- 3. 吳恩達談 Agentic Workflow（The Batch） https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/
- 4. Model Context Protocol（MCP 官方網站） https://modelcontextprotocol.io/