如何在 6 個月內成為 AI 工程師（資源清單）

AI 工程已迅速成為科技領域中最有價值的技能組合之一

問題在於，大多數初學者根本不確定該從何學起

有些人從機器學習理論開始

有些人則陷入無止盡的觀看教學影片的迴圈

還有人直接跳進提示詞（prompts）和 Agent 的世界，卻不理解 API、後端基礎，或實際產品是如何建構的

結果往往大同小異：充滿困惑，卻缺乏實戰技能

如果你的目標是成為一名 AI 工程師，你不需要精通人工智慧的每一個領域

你需要學習的是如何在真實世界中建構有用的 AI 系統

這意味著你需要學習如何：

• 使用 LLM 建構端到端的應用程式
• 操作模型 API，例如 OpenAI 和 Anthropic
• 正確設計提示詞和上下文
• 使用結構化輸出和工具呼叫
• 在需要時加入檢索功能
• 部署專案，讓別人能實際使用

這份指南旨在為你提供一個實用的 6 個月學習路線圖

這篇文章超過 10,000 字，閱讀可能需要數小時甚至更久

但它的真正價值在於，針對你需要學習的每一項技能，都提供了資源和清晰的行動說明

這樣一來，你在六個月內就能達到 AI 工程的水平，並在最初的一到兩個月內就能開始為自己所運用

撰寫這篇文章耗時超過 40 小時，我與我的朋友 @andy_ai0 共同完成了這項工作

他剛開始在 X（Twitter）上建立個人品牌，但他對 AI 的理解非常深入，並在這篇文章中提供了很多幫助

我認為他在成長的過程中，絕對值得你的關注與支持

現在讓我們開始閱讀這篇文章 ⬇️

AI 工程師實際上在做什麼

很多人聽到「AI 工程師」這個詞，脑海中浮現的是從頭開始訓練巨型模型的人

實際上，現代的 AI 工程師大多在做更實際的事情

他們在現有模型的基礎上建構產品和系統

這通常包括：

• 連接 LLM API
• 設計提示詞和上下文流程
• 建構聊天、搜尋或自動化系統
• 整合工具、資料庫和外部 API
• 處理結構化輸出
• 改善可靠性、成本和延遲
• 將 AI 功能部署到實際應用程式中

所以實際上，AI 工程師的角色通常介於：

• 軟體工程
• 產品工程
• 自動化
• 應用 AI

這就是為什麼這個職位成長如此迅速的原因

公司不僅需要研究人員

他們需要的是能將模型轉化為有用產品的人

這也是為什麼這份路線圖較少著重於艱澀的理論，而更聚焦於實際執行

如果你能建構真正的 LLM 應用、檢索系統、自動化流程，以及可投入生產的工作流程，你已經比大多數初學者更接近就業門檻了

⏩------------------------------------------------------------------------⏪

第一個月：打好紮實的編碼與基礎知識

你這個月的目標：成為一名能實際運作的 Python 開發者

你不必成為專家，只需要不再需要一直搜尋基礎語法，並且能自信地建構簡單的程式

AI 工程首先是軟體工程

後續幾個月的一切，都假設你能撰寫乾淨的 Python 程式碼、使用終端機、呼叫 API 以及管理程式碼庫。這個月就是你的基礎

學些什麼

1. Python

Python 是 AI 工程的語言，沒有之一。在未來六個月內，你遇到的幾乎所有函式庫、API 和教學都使用 Python

如何學習：

從一個能強迫你動手寫程式碼，而不是只看影片的結構化課程開始

初學者最常犯的錯誤就是被動吸收內容：跟著閱讀、點頭贊同，卻從未打開程式碼編輯器

透過親自編寫每一個範例來對抗這個習慣

資源：

1. Python for Everybody（Coursera，可免費旁聽）

連結：https://www.coursera.org/specializations/python

這是絕對初學者最佳的起點。Dr. Chuck 是網路上最親切的 Python 教師之一

2. freeCodeCamp Python 課程（YouTube，免費）

連結：https://www.youtube.com/watch?v=rfscVS0vtbw

一個涵蓋所有基礎知識、長達 4 小時的綜合影片

3. CS50P：使用 Python 進行程式設計入門（哈佛大學，免費）

連結：https://cs50.harvard.edu/python/

更為嚴謹。包含問題集和期末專案。如果你想要有結構化的學習方式，這很適合

4. 官方 Python 文件（教學指南）

連結：https://docs.python.org/3/tutorial/

內容較為生硬但具有權威性，可作為參考資料使用

重點關注：

• 變數、資料型別、迴圈、條件判斷、函式
• 串列（Lists）、字典（Dictionaries）、集合（Sets）、元組（Tuples）
• 檔案輸入輸出及 JSON 處理
• 類別與基本物件導向程式設計（OOP）（足夠理解你所讀的內容即可）
• 使用 try/except 進行錯誤處理
• 虛擬環境（venv）與 pip
• 套件管理——理解 requirements.txt

練習專案：用 Python 建構一個簡單的命令列工具。例如一個個人支出追蹤器，能讀取/寫入 JSON 檔案；或一個能呼叫公開 API（如天氣 API）並列印格式化結果的腳本

2. Git 和 GitHub

Git 是專業開發者儲存和分享程式碼的方式。你會持續需要使用它：為你的專案進行版本控制、協作，以及在 GitHub 上展示你的作品

如何學習：

Git 起初令人困惑，因為它的心智模型並不直觀

不要試圖死記硬背指令，而是理解 Git 解決了什麼問題

（追蹤變更、實現協作、讓你復原錯誤），這樣指令就會變得合理

資源：

1. GitHub Skills（免費，互動式）

連結： https://skills.github.com/

在 GitHub 內部執行的官方互動式課程。從這裡開始

2. Learn Git Branching（免費，互動式）

連結： https://learngitbranching.js.org/

無疑是理解分支和合併的最佳視覺化工具

3. Pro Git 電子書（免費線上書籍）

連結： https://git-scm.com/book/en/v2

全面的參考資料。直接跳到你需要了解的章節

重點關注：

• git init, add, commit, push, pull
• 分支（Branching）與合併（Merging）
• 理解 .gitignore
• 在 GitHub 上建立儲存庫（Repos）並推送本地專案
• 閱讀和撰寫基本的 README 檔案

練習： 從現在開始，你建立的每一個專案，即使是很小的腳本，都應該存放在 GitHub 儲存庫中。這能養成習慣，並為你建立一個作品集

3. 命令列介面（CLI）/ 終端機基礎

身為 AI 工程師，你將完全在命令列中執行腳本、安裝套件、管理伺服器和瀏覽檔案

在終端機中動作緩慢或感到畏懼，會成為真正的瓶頸

資源：

1. 50 個最受歡迎的 Linux 和終端機指令（初學者完整課程）

連結： https://www.youtube.com/watch?v=ZtqBQ68cfJc

非常適合 Linux/Mac 的絕對初學者

2. MIT 遺失的 CS 教育學期（免費）

連結： https://missing.csail.mit.edu/

涵蓋了大多數 CS 課程跳過的 Shell 腳本、終端機工具，以及命令列流暢度

重點關注：

• 導航：cd, ls, pwd, mkdir, rm
• 讀取檔案：cat, less, grep
• 從終端機執行 Python 腳本
• 環境變數
• 基本了解 PATH

4. JSON、API、HTTP 和非同步基礎

你從第二個月第一天開始就會呼叫 LLM API

這意味著在觸及 OpenAI 或 Anthropic 的 SDK 之前，你需要先了解 Web API 是如何運作的

資源：

1. HTTP 基礎 – MDN Web 文件（免費）

連結： https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview

對 HTTP 請求和回應運作方式最清晰的解釋

2. REST API 教學

連結： https://restfulapi.net/

簡短且實用

3. Python requests 函式庫文件

連結： https://requests.readthedocs.io/en/latest/

學習如何在 Python 中呼叫任何 Web API

4. Python async/await（免費）

連結：https://realpython.com/async-io-python/

理解 Async 對於後續處理串流 LLM 回應至關重要

重點關注：

• GET、POST 請求——它們是什麼以及如何在 Python 中發出
• 讀取和寫入 JSON
• HTTP 狀態碼（200, 400, 401, 404, 500 —— 各自代表的意義）
• 什麼是 API 金鑰以及基本的驗證模式
• async def 和 await 的功能及其存在的原因

練習專案： 撰寫一個 Python 腳本，呼叫免費的公開 API（試試看 Open-Meteo 獲取天氣資料——無需 API 金鑰），並將結果格式化為乾淨的 JSON 輸出

5. 基礎 SQL 和 Pandas

你不需要成為資料科學家，但你會需要定期檢查、查詢和操作資料

基本的 SQL 知識和 Pandas 熟練度將持續為你節省時間

資源：

1. SQLBolt（免費，互動式）

連結： https://sqlbolt.com/

從零開始學習 SQL 最快的方式。20 堂簡短課程，附帶瀏覽器內練習題

2. Pandas 官方入門指南

連結： https://pandas.pydata.org/docs/getting_started/index.html

實際操作「10 分鐘入門 Pandas」教學

3. Kaggle Pandas 課程（免費）

連結： https://www.kaggle.com/learn/pandas

動手實作，實用且簡短

重點關注：

• SQL：SELECT, WHERE, GROUP BY, JOIN, ORDER BY
• Pandas：載入 CSV、篩選行、選擇列、基本聚合操作

6. FastAPI

資源：

1. FastAPI 官方教學（免費）

連結：https://fastapi.tiangolo.com/tutorial/

確實在所有框架文件中，其中一份寫得最好的文件

從頭到尾完整閱讀。涵蓋路徑參數、請求主體、Pydantic 驗證以及執行開發伺服器

2. Python API 開發（19 小時課程，freeCodeCamp，YouTube，免費）

連結： https://www.youtube.com/watch?v=ZtqBQ68cfJc

涵蓋 API 設計基礎，包括路由、序列化、模式驗證和 SQL 資料庫整合。從頭開始建構一個完整的社交媒體風格 API

重點關注： 建立 GET 和 POST 端點、路徑和查詢參數、使用 Pydantic 的請求主體、執行 uvicorn，以及使用 FastAPI 內建的 /docs 介面來測試你的 API，而無需撰寫客戶端程式碼

第一個月里程碑

到這個月底，你應該能夠：

• 撰寫能讀取/寫入檔案、呼叫 API 和處理錯誤的 Python 程式
• 使用 Git 為程式碼進行版本控制，並將專案推送到 GitHub
• 能在終端機中毫不猶豫地操作
• 理解 HTTP 請求是什麼，並能用 Python 發出一個
• 使用基本 SQL 查詢 SQLite 資料庫
• 在本地端建立並執行一個簡單的 FastAPI 應用程式

⏩------------------------------------------------------------------------⏪

第二個月：掌握 LLM 應用程式開發

你這個月的目標：使用 OpenAI 和 Anthropic API 建構真正的 AI 驅動應用程式

到月底時，你應該能熟練地撰寫可靠運作的提示詞、從模型中獲取結構化資料、讓模型呼叫你的函式，並處理所有可能出錯的情況

這是 AI 工程的核心。路線圖中後續的所有內容都建立在你這個月所學的基礎之上

學些什麼

1. 提示詞基礎

提示詞不僅僅是好好提問。它是一門撰寫指令的技藝，旨在從本質上具有機率性的模型中，產出一致且可靠的輸出

身為 AI 工程師，你會在這裡花費大量時間

如何學習：

從 Anthropic 的互動式教學開始，因為它最注重實作

然後閱讀 OpenAI 的官方指南。之後，提示詞工程指南（Prompt Engineering Guide）會整合所有概念

依序完成這三個資源——每個都會強化其他的學習

資源：

1. Anthropic 互動式提示詞工程教學（免費，GitHub）

連結： https://github.com/anthropics/prompt-eng-interactive-tutorial

一個分成 9 個章節的逐步課程，附有練習題，旨在為你提供大量練習撰寫和除錯提示詞的機會

使用 Claude API 以 Jupyter notebook 的方式執行

2. Anthropic 提示詞工程文件（免費）

連結： https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview

官方參考資料。涵蓋從基本清晰度到 XML 結構化和代理系統的一切

3. OpenAI 提示詞工程指南（免費）

連結： https://platform.openai.com/docs/guides/prompt-engineering

來自 OpenAI 的官方指南，涵蓋了與其模型配合良好、能產生更有用輸出的提示詞格式

4. [PromptingGuide.ai](//PromptingGuide.ai)（免費）

連結： https://www.promptingguide.ai/

涵蓋從基礎提示到進階策略的 essential 技術，以及函式呼叫、工具整合和代理系統

重點關注： 系統訊息和用戶訊息的區別、為什麼 specificity 很重要、思維鏈提示（一步一步思考）、在提示詞中使用範例（few-shot），以及微小的措辭變化如何能大幅改變輸出品質

練習： 選擇一個實際任務——摘要一份文件、從文字中提取關鍵資訊、分類一條反饋——並為其撰寫 5 個不同的提示詞。比較輸出結果。你會立刻看到提示詞設計對可靠性的影響有多大

3. 結構化輸出 / JSON Schema

在實際應用中，你幾乎從不希望從 LLM 獲得純文字，你需要的是可以在程式碼中解析、儲存和使用的結構化資料

結構化輸出透過強制模型符合你定義的 Schema 來解決這個問題

資源：

1. OpenAI 結構化輸出指南（官方文件，免費）

連結： https://platform.openai.com/docs/guides/structured-outputs

涵蓋了確保模型始終產生符合你 JSON Schema 的回應的功能，讓你無需擔心缺少的鍵值或幻覺值

2. Instructor 函式庫（免費，開源）

連結： https://python.useinstructor.com/

從任何 LLM 供應商獲取結構化輸出最乾淨的方式，使用 Pydantic 模型

使用相同的程式碼介面，適用於 OpenAI、Anthropic、Google 以及 15 個以上的其他供應商，並在驗證失敗時自動重試

這是大多數生產環境中的 AI 工程師實際使用的工具

3. OpenAI Cookbook：結構化輸出介紹（免費）

連結： https://developers.openai.com/cookbook/examples/structured_outputs_intro/

實用範例，涵蓋思維鏈輸出、結構化資料提取和 UI 生成，有助於理解實際使用案例

重點關注： 為你的資料定義 Pydantic 模型、將 Schema 傳遞給 API、理解結構化輸出和 JSON 模式之間的區別，以及優雅地處理模型拒答的情況

練習專案： 建構一個發票或收據解析器。給它原始文字（例如「發票 #123，3 個 widgets $45.99，付款截止日 3 月 30 日」），讓它回傳一個包含 invoice_number、amount、items、due_date 等欄位的結構化 Python 物件

4. 函式 / 工具呼叫

工具呼叫是將 LLM 從文字生成器轉變為能採取行動的東西——搜尋網路、查詢資料庫、呼叫你的 API、執行程式碼。這是本指南中最重要的技能之一

如何理解： 模型實際上並不會執行你的函式

它會檢查提示詞，並在決定應該使用某個工具時，回傳一個包含函式名稱和引數的結構化呼叫

然後你的程式碼執行該呼叫，並將結果回傳給模型

資源：

1. OpenAI 函式呼叫指南（官方文件，免費）

連結： https://platform.openai.com/docs/guides/function-calling

權威參考資料。涵蓋定義工具、5 步驟呼叫流程、並行呼叫和最佳實踐

2. Anthropic 工具使用文件（免費）

連結： https://docs.anthropic.com/en/docs/build-with-claude/tool-use

Anthropic 對應的 Claude 指南。概念相同，語法略有不同

3. OpenAI Cookbook：如何與聊天模型進行函式呼叫（免費，GitHub）

連結： https://github.com/openai/openai-cookbook/blob/main/examples/How_to_call_functions_with_chat_models.ipynb

一個完整的可執行 Notebook，透過實際範例逐步介紹完整的工具呼叫循環

重點關注： 在 JSON Schema 中清晰地描述函式、解析工具呼叫回應、執行函式並將結果回饋給模型、處理不需要工具呼叫的情況，以及 tool_choice: "auto" 的概念

練習專案： 建構一個簡單的助手，它擁有三個工具：get_weather(city)、calculate(expression) 和 search_notes(query)（只需搜尋一個硬編碼的字典）。將它們全部連接起來，觀察模型根據你的提問決定呼叫哪一個

5. 串流回應

串流意味著在模型生成輸出時即時顯示——逐字顯示——而不是等待完整回應。這能讓你的應用程式感覺快得多，也更有生命力

資源：

1. OpenAI 串流文件（官方，免費）

連結： https://platform.openai.com/docs/api-reference/streaming

關於在請求中加入 stream=True 並迭代處理資料區塊的參考資料

2. Anthropic 串流文件（官方，免費）

連結： https://docs.anthropic.com/en/api/messages-streaming

Anthropic 的串流 API 參考資料，附有 Python 範例

3. 串流 LLM API 是如何運作的 – Simon Willison（免費）

連結： https://til.simonwillison.net/llms/streaming-llm-apis

對 OpenAI、Anthropic 和 Google 的 Server-Sent Events 在底層運作方式的清晰技術解析，有助於理解 HTTP 層級實際發生的事情

重點關注： 設定 stream=True、迭代處理 delta 區塊、從各部分組裝完整回應，以及使用 StreamingResponse 將串流整合到 FastAPI 端點

提示： 對於面向用戶的應用程式，串流幾乎總是正確的選擇。沒有人願意盯著旋轉的載入圖示 10 秒鐘，等待完整回應一次性出現

5. 對話狀態

LLM 是無狀態的——它們在呼叫之間沒有記憶。對話歷史是你透過在每次請求中發送完整的訊息列表來管理的。理解這是基礎

資源：

1. OpenAI Chat Completions 指南，管理對話（官方，免費）

連結： https://platform.openai.com/docs/guides/conversation-state

關於 messages 陣列如何運作以及如何管理多輪對話的權威解釋

2. Anthropic Messages API 文件（官方，免費）

連結： https://docs.anthropic.com/en/api/messages

Anthropic 的對應文件。概念相同，值得兩者都閱讀以了解它們的差異

重點關注： messages 陣列結構、為什麼需要同時附加用戶和助手訊息、內容視窗限制以及超出時會發生什麼情況、以及基本的截斷策略（丟棄最舊的訊息、摘要歷史記錄）

練習專案： 在終端機中建構一個簡單的多輪聊天機器人。每一輪都將訊息附加到 messages 列表中。加入一個 /reset 指令來清除歷史記錄，並在每次交換後列印當前的 Token 數量

6. 成本、延遲和 Token 基礎

在不了解成本和 Token 的情況下交付 AI 應用程式，是你最終會收到意外帳單和應用程式緩慢的原因。這很無聊但至關重要

資源：

1. OpenAI 定價頁面（官方）

連結： https://openai.com/api/pricing

了解每個模型的輸入和輸出 Token 成本。將此頁面加入書籤，並在選擇模型時查閱

2. Anthropic 定價頁面（官方）

連結： https://www.anthropic.com/pricing

Claude 模型同理

3. OpenAI Tokenizer 工具（免費，互動式）

連結： https://platform.openai.com/tokenizer

貼上任何文字，即可看到它確切的 Token 數量。在學習過程中持續使用這個工具

4. Tiktoken（Python 函式庫，免費）

連結： https://github.com/openai/tiktoken

OpenAI 的 Tokenizer 函式庫，用於在發送請求前在程式碼中計算 Token 數量

重點關注： 什麼是 Token（大約 4 個字元 / 3/4 個單詞）、輸入和輸出 Token 的定價差異、內容視窗大小如何影響你能做的事情，以及較小、較快的模型與較大、較智能模型之間的延遲取捨

另外：不要什麼都用 GPT-4/Opus——較便宜的模型通常足以勝任簡單任務

7. 故障處理

LLM API 會故障。會遇到速率限制、回應會逾時、模型會回傳格式錯誤的 JSON。優雅地處理故障，是區分展示用 Demo 和生產級應用程式的關鍵

資源：

1. OpenAI 錯誤碼參考（官方，免費）

連結： https://platform.openai.com/docs/guides/error-codes

你會遇到的每一種錯誤類型以及相應的處理方式

2. Anthropic 錯誤處理文件（官方，免費）

連結： https://docs.anthropic.com/en/api/errors

Claude 同理

3. Tenacity（Python 函式庫，免費）

連結： https://tenacity.readthedocs.io/

一個乾淨的函式庫，用於為任何 Python 函式添加帶有指數退避的重試邏輯。一個裝飾器就能處理好重試

重點關注： 速率限制錯誤（429）和指數退避、使用 httpx/requests 處理逾時、在使用前驗證模型輸出、降級策略（使用不同模型重試、回傳快取回應），以及永遠不要因為 LLM 回傳了預期之外的輸出而讓你的應用程式崩潰

8. 提示注入意識

提示注入是 LLM 應用程式中排名第一的安全風險

它發生在不可信的用戶輸入與系統指令結合時，允許用戶更改、覆蓋或將新的行為注入到提示詞中——導致系統執行非預期的操作或生成被操控的輸出

你不需要成為安全專家，但在你交付任何東西之前，你需要知道這個風險的存在

資源：

1. OWASP Top 10 for LLM Apps – LLM01：提示注入（免費）

連結： https://genai.owasp.org/llmrisk/llm01-prompt-injection/

這份權威分類涵蓋了直接注入（越獄）、透過外部內容（如文件或網站）的間接注入，以及真實世界的攻擊場景。

2. OWASP 提示注入預防備忘清單 (免費)

連結： https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html

實用的防禦模式：輸入驗證、權限控制和輸出驗證。

3. Evidently AI：什麼是提示注入 (免費)

連結： https://www.evidentlyai.com/llm-guide/prompt-injection-llm

一篇聚焦開發者的清晰解說，說明了攻擊類型、風險以及用來緩解風險的設計模式。

重點關注： 直接注入與間接注入的區別、為什麼系統提示並非真正「安全」、工具存取的權限最小化原則，以及絕不信任未經驗證的 LLM 輸出以做出關鍵決策。

第二個月里程碑

到這個月底，你應該能夠：

• 為特定任務寫出能產生一致、可靠輸出結果的提示
• 使用 Pydantic + Instructor 從任何模型取得結構化的 JSON 資料
• 設定工具調用，讓模型可以呼叫你的 Python 函式
• 透過 FastAPI 端點即時串流回應
• 正確管理多輪對話歷史
• 在發送請求前估算 Token 成本
• 處理 API 錯誤、超時和不良輸出，而不會導致系統崩潰
• 解釋什麼是提示注入，並應用基本的防禦措施

⏩------------------------------------------------------------------------⏪

第三個月：正確學習 RAG

你這個月的目標：建立能讓 LLM 根據你的文件、而非僅依據訓練資料來回答問題的系統。

到月底，你應該能夠：匯入文件、將其嵌入並儲存、在查詢時檢索正確的區塊，並產生有根據、準確且可引用來源的答案。

RAG 是目前 AI 工程領域中最受歡迎的實用技能。幾乎所有真實的企業 AI 應用案例——客服機器人、內部知識庫、文件問答——都建立在它之上。

深入理解 RAG，而不只是複製教學，是區分優秀工程師與卓越工程師的關鍵。

1. 嵌入

在建立 RAG 系統之前，你需要了解嵌入到底是什麼——因為它是建構一切的基礎。

文字嵌入是將一段文字投射到高維向量空間中。

這段文字在該空間中的位置由一串長長的數字來表示。

關鍵在於，語義上相似的文字最終會在該空間中彼此靠近——這正是相似性搜尋得以實現的原理。

資源：

1. Stack Overflow 部落格：文字嵌入的直觀介紹 (免費)

連結： https://stackoverflow.blog/2023/11/09/an-intuitive-introduction-to-text-embeddings/

最佳初學者入門說明。由一位多年建構 NLP 產品的開發者撰寫，重點在於建立正確的直覺而非數學。

2. Google 機器學習速成課程：嵌入 (免費)

連結： https://developers.google.com/machine-learning/crash-course/embeddings

涵蓋了為什麼密集向量表示能解決 One-Hot 編碼無法解決的問題——特別是捕捉項目之間的語義關係。

3. HuggingFace：嵌入入門 (免費)

連結： https://huggingface.co/blog/getting-started-with-embeddings

動手實作指南。展示如何使用 sentence-transformers 函式庫產生嵌入、託管它們，並用它們對真實的 FAQ 資料集進行語義搜尋。

4. OpenAI 嵌入指南（官方文件，免費）

連結： https://platform.openai.com/docs/guides/embeddings

在程式碼中使用 OpenAI 的 text-embedding-3-small 和 text-embedding-3-large 模型的參考指南。

重點關注： 向量在概念上是什麼、為什麼相似的文字會產生相似的向量、餘弦相似度如何運作、不同嵌入模型（OpenAI、HuggingFace sentence-transformers）之間的差異，以及嵌入維度在實務上的意義。

練習： 取 20 句相關主題的句子，使用 OpenAI 或 sentence-transformers 嵌入它們，並撰寫一個簡單的最近鄰搜尋，返回與查詢最相似的 3 個句子。這本質上就是 RAG 核心的縮影。

2. 分塊

你的文件太大了，無法整體嵌入。分塊是在嵌入之前將文件分解成更小片段的過程。

你分塊文件的方式直接影響系統尋找相關資訊和提供準確答案的能力。即使是一個完美的檢索系統，如果在準備不良的資料上進行搜尋，也會失敗。

資源：

1. Weaviate：RAG 的分塊策略 (免費)

連結： https://weaviate.io/blog/chunking-strategies-for-rag

最實用的指南。涵蓋固定大小、遞迴和語義分塊，並清楚說明何時使用每種方法。

2. Unstructured：RAG 分塊最佳實踐 (免費)

連結： https://unstructured.io/blog/chunking-for-rag-best-practices

深入探討了區塊大小、重疊，以及嵌入模型的上下文窗口如何施加硬性限制。

一個好的實驗起點是使用約 250 個 Token（約 1,000 個字元）的區塊大小，並在連續區塊之間設置 10-20% 的重疊，以避免在邊界處遺失上下文。

3. LangChain 文字分割器文件（官方，免費）

連結： https://python.langchain.com/docs/concepts/text_splitters/

在程式碼中使用 RecursiveCharacterTextSplitter、MarkdownTextSplitter 和語義分割器的實用參考。

重點關注： 以帶重疊的固定大小分塊作為基準、針對結構化文件的遞迴分塊、用於更好邊界檢測的語義分塊，以及核心權衡：區塊太大會失去檢索精度；區塊太小會失去上下文。

初學者提示： 從 LangChain 的 RecursiveCharacterTextSplitter 開始，設定 chunk_size=500 和 chunk_overlap=50。這是對大多數文件最合理的預設值，能為你提供一個可供改進的工作基準。

3. 向量資料庫

一旦你有了嵌入，就需要一個地方來高效儲存和搜尋它們。這就是向量資料庫的用途。

正確的選擇取決於你的情況：使用 Chroma 進行快速的本地原型開發，使用 Pinecone 進行託管的即用型擴展，使用 Weaviate 獲得具有強大混合搜尋功能的開源靈活性，使用 Qdrant 進行複雜過濾和具成本效益的自託管，如果你已經在使用 PostgreSQL 並希望避免增加另一個系統，則使用 pgvector。

資源：

1. Chroma 官方文件 (免費)

連結： https://docs.trychroma.com/

Chroma 非常適合優先考慮開發速度和簡潔性的個人開發者和小型團隊，它在記憶體中或本地運行，無需管理基礎設施。

2. Pinecone 學習中心 (免費)

連結： https://www.pinecone.io/learn/

優秀的免費教學，涵蓋向量搜尋概念、混合搜尋和 RAG 流程。即使你不使用 Pinecone，這些也是很好的通用材料。

3. Qdrant 文件 (免費)

連結： https://qdrant.tech/documentation/

適用於具有進階過濾功能的生產環境的最佳開源選擇。速度非常快、靈活且可免費自託管。

4. pgvector（開源，免費）

連結： https://github.com/pgvector/pgvector

如果你正在建立已經使用 PostgreSQL 的項目，pgvector 可以直接將向量搜尋添加到你的現有資料庫中，無需新的基礎設施。

重點關注： 建立集合、插入帶有元數據的嵌入、透過 similarity 搭配 top_k 進行查詢，以及在查詢時按元數據過濾。

你不需要理解索引演算法（HNSW、IVF）——只要理解如何使用它們。

練習專案： 將任何公開文件（例如 Python 文件或維基百科文章轉儲）中的 50-100 頁索引到 Chroma 中，並附帶元數據（來源 URL、章節標題）。撰寫一個查詢函式，該函式能為任何問題檢索出 5 個最相關的區塊。

4. 元數據過濾

純粹的相似性搜尋對於真實應用來說是不夠的。元數據過濾允許你將檢索範圍限制在相關的子集中——按日期、來源、文件類型、使用者、類別或你與每個區塊一起儲存的任何其他屬性進行過濾。

資源：

1. Pinecone：元數據過濾指南 (免費)

連結： https://docs.pinecone.io/guides/data/filter-with-metadata

透過程式碼範例清楚說明如何在相似性搜尋之前或期間按元數據欄位過濾向量。

2. LlamaIndex：元數據過濾器指南（官方文件，免費）

連結： https://docs.llamaindex.ai/en/stable/module_guides/querying/node_postprocessors/node_postprocessors/

說明了如何在 LlamaIndex 流程中在查詢時應用過濾器。

重點關注： 在匯入時為每個區塊標記相關的元數據（來源檔名、頁碼、章節、日期、類別），並在查詢時使用這些欄位來過濾結果。這正是玩具 Demo 與生產系統之間的區別，在生產系統中，使用者可以詢問「只顯示 2025 年第四季度到 2026 年第一季度報告的結果」。

5. 重新排序

重新排序是一種技術，可以為任何關鍵字或向量搜尋系統的搜尋品質增加語義提升。

在第一階段檢索返回一個候選集之後，重新排序器會根據查詢的真正上下文相關性——而不僅僅是向量接近度——對這些結果進行重新評分。

這個兩階段模式是：嵌入和搜尋（快速，近似）→ 對 Top-K 結果重新排序（較慢，更準確）。其結果是檢索品質顯著提升，而延遲成本僅有適度增加。

資源：

1. Cohere 重新排序文件（官方，免費）

連結： https://docs.cohere.com/docs/reranking-with-cohere

最好的起點。涵蓋完整的重新排序工作流程，包括電子郵件和 JSON 文件等半結構化資料。只需添加一行程式碼即可整合到現有的檢索管道中。

2. LangChain：Cohere 重新排序器整合（官方文件，免費）

連結： https://python.langchain.com/docs/integrations/retrievers/cohere-reranker/

說明了如何使用 ContextualCompressionRetriever 將 Cohere 重新排序連接到 LangChain 檢索器中。

重點關注： 先檢索後重新排序的兩階段模式、雙編碼器（用於第一階段嵌入搜尋）和交叉編碼器（用於重新排序）之間的差異，以及對 Top-20 結果與 Top-5 結果進行重新排序在延遲/品質上的實際權衡。

6. 檢作品質問題

大多數 RAG 失敗並非模型失敗，而是檢索失敗。理解檢索可能出錯的方式對於除錯真實系統至關重要。

需要學習的常見問題：

• 語義漂移： 查詢嵌入與相關區塊的嵌入不匹配，即使資訊就在那裡。修正方法：嘗試查詢重寫或 HyDE（假設性文件嵌入）。
• 區塊邊界問題： 相關資訊被分割到兩個區塊中。修正方法：增加重疊或使用語義分塊。
• 遺失元數據上下文： 區塊在語義上與查詢相似，但屬於錯誤的文件、日期或使用者。修正方法：使用元數據過濾。
• Top-K 太小： 正確的區塊存在，但不在檢索到的 Top-5 結果中。修正方法：檢索時增加 Top-K 值，並在重新排序後減少。

資源：

1. LangChain：查詢轉換 (免費)

連結： https://python.langchain.com/docs/how_to/#query-analysis

涵蓋查詢重寫、後退提示和 HyDE。

2. Pinecone：改善檢作品質 (免費)

連結： https://www.pinecone.io/learn/retrieval-augmented-generation/#retrieval-quality

常見失敗模式的實用逐步解說與修正方法。

7. 減少幻覺

與普通的 LLM 相比，RAG 能大大減少幻覺，但它並不能完全消除幻覺。

透過在執行時為模型提供檢索到的事實，RAG 將其回應錨定在真實來源上，而不是僅依賴訓練資料，並且模型的輸出甚至可以引用這些來源，從而提高透明度和信任度。

但是，檢索失敗、不良區塊和相互矛盾的資訊仍然可能導致模型憑空捏造。

資源：

1. Zep：減少 LLM 幻覺——開發者指南 (免費)

連結： https://www.getzep.com/ai-agents/reducing-llm-hallucinations/

實用的開發者聚焦指南，涵蓋提示接地策略、用於事實任務的思維鏈，以及輸出驗證模式。

2. Voiceflow：減少 LLM 幻覺的 5 種方法 (免費)

連結： https://www.voiceflow.com/blog/prevent-llm-hallucinations

對綜合策略的良好概述：RAG + 思維鏈 + 防護欄共同作用，勝過任何單一方法。

重點關注： 提示模型僅根據提供的上下文回答（當答案不在其中時，說「我不知道」）、在呈現回應之前增加信心門檻，以及在責怪 LLM 之前始終驗證檢作品質。

8. 引用與接地

一個穩固的 RAG 系統不僅提供答案——它還會告訴你答案的來源。這對於使用者信任和除錯至關重要。

資源：

1. Anthropic：為 Claude 提供來源（文件，免費）

連結： https://docs.anthropic.com/en/docs/build-with-claude/citations

說明了如何提示 Claude 產生帶有來源參考的引用回應。

2. LangChain：帶來源的 RAG (免費)

連結： https://python.langchain.com/docs/how_to/qa_sources/

說明了如何在 LangChain RAG 管道中將來源文件與答案一起返回。

重點關注： 將區塊元數據（來源檔名、頁碼、URL）傳遞到你的提示上下文中，指示模型在其答案中引用來源，並在你的 UI 或 API 回應中顯示這些來源。

9. 你的 RAG 框架：LangChain 或 LlamaIndex

你不需要從頭開始建立 RAG 管道。有兩個框架主導這個領域，值得了解：

LlamaIndex 針對將搜尋和索引放在首位進行了最佳化——它將匯入、分塊、嵌入和查詢抽象成幾行程式碼，讓你能在一個下午建立一個可運作的原型。

當你的應用程式更像一個編排引擎時，LangChain 就大放異彩——它在多 Agent 工作流程、工具調用和條件鏈方面表現出色，這些在生成答案之前可能需要查詢多個 LLM 或外部 API。

在第三個月，從 LlamaIndex 開始學習 RAG。當你進入第四個月的 Agent 工作時，再轉向 LangChain。

資源：

1. LlamaIndex：RAG 簡介（官方文件，免費）

連結： https://developers.llamaindex.ai/python/framework/understanding/rag/

涵蓋 RAG 的五個關鍵階段：載入、索引、儲存、查詢和評估——以及 LlamaIndex 如何處理每個階段。

2. LlamaIndex 初學者教學（官方文件，免費）

連結： https://developers.llamaindex.ai/python/framework/getting_started/starter_example/

官方快速入門指南。用不到 30 行程式碼建立一個可運作的 RAG 系統。

3. LangChain：建立一個 RAG Agent（官方文件，免費）

連結： https://docs.langchain.com/oss/python/langchain/rag

展示如何使用 RAG Agent 在非結構化文字上建立一個問答應用程式，從一個 40 行的精簡版本到一個包含重新排序的完整檢索管道。

練習專案： 建立一個「與你的文件聊天」應用程式。匯入 10-20 個 PDF 或文字檔案（你自己的筆記、教科書章節、產品文件——任何內容）。建立一個 FastAPI 端點，接受一個問題，檢索 Top-5 最相關的區塊並進行重新排序，然後從 Claude 或 OpenAI 返回一個帶有引用的答案。這是一個實實在在的作品集項目。

第三個月里程碑

到這個月底，你應該能夠：

• 解釋什麼是嵌入，以及為什麼相似的文字會產生相似的向量
• 使用適當的策略智慧地對任何文件進行分塊
• 在向量資料庫中儲存和查詢嵌入，並進行元數據過濾
• 添加重新排序步驟來改善檢作品質
• 系統地除錯常見的檢索失敗
• 使用 LlamaIndex 或 LangChain 建立一個完整的端到端 RAG 管道，該管道能匯入文件、檢索相關區塊，並返回有根據、可引用的答案

⏩------------------------------------------------------------------------⏪

第四個月：Agent、工具、工作流程與評估

你這個月的目標：建立能夠自主執行一系列動作的 AI 系統、整合多步驟工作流程，並批判性地評估它們是否正常運作。

到月底，你應該能夠從頭開始建立一個真正的 Agent，理解何時不該使用 Agent，並衡量你所建立系統的效能。

這是 AI 工程變得真正複雜的地方。第四個月的技能是區分初級 AI 工程師與能夠獨立掌握整個 AI 功能的人員的關鍵。

1. Agent 循環

Agent 不是魔法，它是一個非常簡單的模式。

將 Agent 視為目標驅動的系統，它們不斷循環進行觀察、推理和行動。

這個循環使它們能夠處理超出簡單問答的任務，進入真正的自動化、工具使用和即時適應的領域。

「思考」發生在提示中，「分支」發生在 Agent 在可用工具之間進行選擇時，而「執行」則發生在我們呼叫外部函式時。其他一切都只是輔助機制。

一旦你內化了這一點，即使是最複雜的 Agent 框架也變得易於理解。

資源：

1. Anthropic：建立有效的 Agent（官方，免費）

連結： https://www.anthropic.com/research/building-effective-agents

關於生產環境中 Agent 的單一最佳文章。在撰寫任何 Agent 程式碼之前，請先閱讀此文。

2. OpenAI：建立 Agent 實用指南（官方 PDF，免費）

連結： https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

OpenAI 的補充指南，涵蓋生產環境中的 Agent 模式、防護欄和安全模式。

3. freeCodeCamp：開源 LLM Agent 手冊 (免費)

連結： https://www.freecodecamp.org/news/the-open-source-llm-agent-handbook/

一份全面的實用指南，涵蓋 Agent 循環、LangGraph、CrewAI、規劃、記憶和工具使用。適合快速上手。

4. LangChain Academy：LangGraph 簡介（免費課程）

連結： https://academy.langchain.com/courses/intro-to-langgraph

最廣泛使用的 Agent 編排框架 LangGraph 的官方免費課程。涵蓋狀態、記憶、人在迴路中等更多內容。

重點關注： 感知 → 規劃 → 行動 → 觀察的循環、Agent 循環如何終止、當工具呼叫在循環內失敗時會發生什麼，以及為什麼 Agent 本質上就是一個 while 循環，由 LLM 做出分支決策。

練習： 不使用任何框架，直接使用 OpenAI 或 Anthropic API，從頭開始建立一個 Agent。給它 3 個工具、一個目標和一個循環。這是真正理解框架抽象了什麼的最有價值的事情。

2. 工具選擇

編寫好的工具是成功的一半。工具及其參數的描述是 LLM 的使用手冊。如果手冊含糊不清，LLM 就會誤用該工具。要極度、無情地明確。

一個描述不佳的工具將被錯誤地調用、在錯誤的時間被調用，或者完全被忽略。一個描述良好的工具會表現得可預測，並能在廣泛的輸入中正確地被選中。

資源：

1. OpenAI：函式呼叫最佳實踐（官方文件，免費）

連結： https://platform.openai.com/docs/guides/function-calling/best-practices

關於編寫可靠運作之工具描述的權威指南，包含命名慣例和參數文件化模式。

2. Anthropic：工具使用最佳實踐（官方文件，免費）

連結： https://docs.anthropic.com/en/docs/build-with-claude/tool-use/implement-tool-use#best-practices-for-tool-definitions

Anthropic 的對應指南。特別注意關於何時讓模型選擇與強制使用特定工具的指導說明。

重點關注： 編寫一目了然的動詞作為工具名稱、編寫能解釋何時呼叫工具（而不僅僅是工具功能）的描述、保持參數最少且型別正確，以及設計以 LLM 為呼叫者的工具。

初學者提示： 問自己一個問題來測試每個工具描述：「如果除了這個 JSON schema 之外沒有任何文件，我能確切知道何時以及如何呼叫這個工具嗎？」如果不能，它就需要更多改進。

3. 狀態管理

在 LangGraph 中，狀態是一個流經圖表的共享記憶體物件。它儲存所有相關資訊——訊息、變數、中間結果和決策歷史——並在執行過程中自動管理。

理解狀態是建立能夠處理多輪任務、從失敗中恢復，並在組件之間乾淨地交接的 Agent 的關鍵。

資源：

1. LangGraph 官方文件：狀態管理 (免費)

連結： https://langchain-ai.github.io/langgraph/concepts/low_level/#state

最高參考文獻。涵蓋狀態模式、reducers，以及狀態如何流經節點和邊。

2. DataCamp：LangGraph Agents 教學（免費）

連結： https://www.datacamp.com/tutorial/langgraph-agents

透過實作程式碼涵蓋狀態、節點和邊的基本概念，逐步建立具有跨工作階段持續記憶體的具狀態 Agent。

3. Real Python：Python 中的 LangGraph（免費）

連結： https://realpython.com/langgraph-python/

一篇詳盡的教學，建立一個完整的具狀態 LangGraph Agent，並詳細說明狀態圖和條件式邊。

重點關注： 使用 TypedDict 定義狀態模式、reducers 如何合併並行更新、記憶體內狀態與持久化檢查點之間的差異，以及人機協作暫停如何透過在中途檢查和修改狀態來運作。

4. Agent 的重試與錯誤處理

Agent 的失敗方式與一般的 LLM 呼叫不同。中途中錯誤的工具呼叫可能會破壞狀態、導致無限迴圈，或默默產出錯誤答案。你需要針對所有這些情況制定明確的策略。

資源：

1. LangGraph：錯誤處理與重試（官方文件，免費）

連結： https://langchain-ai.github.io/langgraph/how-tos/autofill-tool-errors/

說明如何在 LangGraph 的工具節點層級新增自動錯誤處理和重試邏輯。

2. OpenAI 實用 Agent 指南：護欄章節（免費）

連結： https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

將護欄作為分層防禦策略，結合基於 LLM 的檢查、基於規則的過濾器（如正則表達式）和審核 API，在 Agent 循環的每個階段審查輸入和輸出。

重點關注： 最大迭代次數限制以防止無限迴圈、每個工具的指數退避重試、在工具執行層捕獲並記錄例外而不導致 Agent 崩潰，以及在何時向用戶顯示失敗訊息 vs 默默重試。

5. 何時不該使用 Agent

這是 AI 工程中最重要卻也最常被忽略的技能之一。Agent 令人興奮，但它們也緩慢、昂貴、不可預測且難以除錯。知道何時該選用更簡單的方案，是良好判斷力的表現。

Anthropic 建議找到最簡單的解決方案，只在必要時增加複雜度——這可能意味著根本不要建立 agent 系統。

Agent 系統以延遲和成本換取更好的任務表現，你應該仔細考量何時這種取捨是合理的。

決策框架是：

• 如果任務能在一個提示中，搭配適當的上下文解決，則使用單一 LLM 呼叫。
• 如果步驟是固定且可預測的，則使用工作流程。
• 只有在步驟數量確實無法預測且需要動態決策時，才使用 Agent。

資源：

1. Anthropic：建立有效 Agent，何時使用 Agent（官方，免費）

連結： https://www.anthropic.com/research/building-effective-agents

關於此問題最權威的答案，直接來自建立這些模型的團隊。

2. Simon Willison：設計 Agent 循環（免費）

連結： https://simonwillison.net/2025/Sep/30/designing-agentic-loops/

一位資深工程師對何時需要 Agent 複雜度以及如何思考 Agent 循環設計的實務見解。

必須牢記： 一個由 3 個固定 LLM 呼叫組成的鏈，永遠會比一個可能進行 3 次呼叫的 Agent 更快、更便宜且更容易除錯。將 Agent 保留給真正開放式任務。

6. 多步驟工作流程

在「單一提示」和「完整 Agent」之間，存在一個廣大且高效的中間地帶：工作流程。當任務可以清晰地分解為固定的子任務時，工作流程是理想的選擇——犧牲延遲來換取更高的準確性，因為每個單獨的 LLM 呼叫都變得更容易、更專注。

常見模式包括提示鏈（一個呼叫的輸出作為下一個的輸入）、路由（分類輸入並發送給專門的處理器）、並行化（同時執行多個呼叫並匯總結果），以及協調器-子Agent（一個 LLM 規劃，其他 LLM 執行）。

資源：

1. Anthropic：工作流程模式（官方，免費）

連結： https://www.anthropic.com/research/building-effective-agents#workflow-patterns

涵蓋所有主要模式，包含圖表和程式碼範例。並行化和協調章節特別有用。

2. LangGraph：多 Agent 網路（官方文件，免費）

連結： https://langchain-ai.github.io/langgraph/concepts/multi_agent/

說明如何將多個 Agent 連接成一個網路，包含監督者和移交模式。

練習專案： 建立一個 3 步驟的內容管線：

步驟 1 – 一個 LLM 從文章中提取關鍵事實。

步驟 2 – 另一個 LLM 呼叫使用這些事實，並行生成一篇推文、一篇 LinkedIn 貼文和一篇摘要。

步驟 3 – 一個最終的 LLM 呼叫為這三項內容評分以選出最佳者。

無需 Agent，純工作流程。

7. 評估測試框架

評估是你判斷 AI 系統是否真正有效的方式——不僅是你手動測試的範例，而是系統性地橫跨數百個輸入。

AI Agent 功能強大但部署複雜，因為其機率性、多步驟的行為引入了許多失敗點。

Agent 的不同部分——LLM、工具、檢索器和工作流程——各自需要自己的評估方法。

資源：

1. DeepEval（開源，免費）

連結： https://deepeval.com/docs/getting-started

一個受 pytest 啟發的開源 LLM 評估框架。編寫包含輸入和預期輸出的測試案例，使用超過 50 個內建指標（包括幻覺、答案相關性和事實一致性）來執行，並在版本之間捕捉回歸。

2. Promptfoo（開源，免費）

連結： https://github.com/promptfoo/promptfoo

一個用於測試和評估 LLM 應用的 CLI 和程式庫，具備自動化測試套件。支援跨多個模型的多個提示的並排比較、CI/CD 整合，以及針對安全漏洞的紅隊測試。

3. LangSmith（免費方案）

連結： https://smith.langchain.com/

針對 LangChain 和 LangGraph 應用的追蹤、除錯和評估。免費方案很大方，追蹤 UI 讓除錯 Agent 循環變得容易許多。

4. Ragas（開源，免費）

連結： https://docs.ragas.io/

專門針對 RAG 管線的評估框架。衡量忠實度、答案相關性、上下文精確度和上下文召回率。如果你從第三個月開始評估 RAG 系統，這是必備工具。

重點關注： 建立一個包含 20-50 個代表性輸入（附有預期輸出或評分標準）的金色測試集，編寫可確定性評分（字串比對、JSON schema 驗證）或使用 LLM-as-Judge 的評估函式，並在變更提示或切換模型時自動執行評估。

關鍵心態： 評估不是可選的潤飾。每一次你變更提示、切換模型或調整檢索設定而未執行評估，都是在賭博。那些交付可靠 AI 產品的工程師會持續執行評估。

8. 任務成功率指標

除了自動化評估之外，你還需要能告訴你 Agent 是否達成實際目標的指標。

資源：

1. Hamel Husain：你的 AI 產品需要評估（免費）

連結： https://hamel.dev/blog/posts/evals/

針對為實際生產 AI 系統建立評估管線所寫的最實用文章之一，作者曾大規模執行過。

2. OpenAI Evals 框架（開源，免費）

連結： https://github.com/openai/evals

OpenAI 自己的評估框架，內含大量社群貢獻的評估模式可供參考。

重點關注： 過程指標（Agent 是否呼叫了正確的工具？）與結果指標（任務是否成功？）之間的差異，在建立任何東西之前先定義明確的成功標準，以及使用 LLM-as-Judge 來評估難以精確比對的輸出（如長篇回答或多步驟推理軌跡）。

練習專案： 將你第三個月的 RAG 管線，建立一個適當的評估測試框架。從你的文件中建立 30 個問答對，透過你的管線執行，然後使用 DeepEval 為每個答案的相關性、忠實度和完整性評分。然後改變一個變數（區塊大小、模型、top-k），重新執行以查看是否改善。

第四個月里程碑

到這個月底，你應該能夠：

• 解釋什麼是 Agent 循環，並在沒有框架的情況下從頭實作一個。
• 編寫能夠正確且可靠地被選中的工具描述。
• 使用 LangGraph 或同等框架正確管理 Agent 狀態。
• 處理 Agent 循環內的錯誤，避免崩潰。
• 自信地判斷一個任務需要 Agent、工作流程還是單一提示。
• 建立能夠鏈接、路由和並行化 LLM 呼叫的多步驟工作流程。
• 編寫自動化評估，在變更提示或模型時捕捉回歸。
• 為你建立的任何 AI 系統定義和衡量任務成功率指標。

⏩------------------------------------------------------------------------⏪

第五個月：部署、產品思維與可靠性

這個月的目標：將你建立的一切提升到生產就緒。

到月底時，你應該能夠部署一個能處理真實用戶、真實流量和真實失敗，而不會在凌晨兩點崩潰的 AI 應用。

這是大多數 AI 工程師停滯不前的地方。他們可以建立一個很棒的展示，但無法交付一個能承受現實世界考驗的產品。

這些技能是公司真正願意付錢的：可靠性、安全性、成本控制，以及在事情必然出錯時讓系統持續運行的能力。

1. FastAPI 生產環境模式

你已經知道如何從第一個月建立一個 FastAPI 應用。現在你需要讓它能承受生產流量。

開發和生產環境的差異很殘酷。一個帶有 --reload 的單一 uvicorn 程序在開發時還行。在生產環境中，一旦真實流量到來，它就會變成瓶頸。

你真正需要的：多工作者 ASGI 配置、適當的錯誤處理中介軟體、健康檢查端點和 CORS 政策。

資源：

1. FastAPI 部署文件（官方，免費）

連結： https://fastapi.tiangolo.com/deployment/

官方指南，涵蓋 Uvicorn 工作者、Gunicorn 和 Docker 部署。在閱讀任何其他內容之前先從這裡開始。

2. FastAPI 生產部署指南（CYS 文件，免費）

連結： https://craftyourstartup.com/cys-docs/fastapi-production-deployment/

全面的生產模式：Gunicorn 配置、Nginx 反向代理、健康檢查、速率限制。包含你可以直接參考的真實配置檔。

3. FastAPI 生產最佳實踐（FastLaunchAPI，免費）

連結： https://fastlaunchapi.dev/blog/fastapi-best-practices-production-2026

涵蓋非同步資料庫連線池、Redis 快取、JWT 驗證和背景任務。這些是來自一個已被超過 100 位開發者使用的真實模板的生產環境驗證模式。

重點關注： 使用 Gunicorn 搭配 Uvicorn 工作者（而非純 Uvicorn）、設定健康檢查端點、新增 CORS 中介軟體、實作適當的非同步資料庫會話，以及對任何不需要阻塞回應的操作使用背景任務。

2. Docker

Docker 是你停止說「在我的機器上可以跑」並開始交付一致部署的方法。

如果你在建立 AI 應用，Docker 能解決依賴衝突、確保環境一致，並讓擴展變得直接。

你不需要成為 Docker 專家。你需要能夠將你的 FastAPI + LLM 應用容器化，並部署到任何地方。

資源：

1. Docker 官方入門指南（免費）

連結： https://docs.docker.com/get-started/

權威起點。涵蓋映像檔、容器、Dockerfile 和 Docker Compose。

2. freeCodeCamp：如何使用 Python 和 Docker 建立與部署多 Agent AI 系統（免費）

連結： https://www.freecodecamp.org/news/build-and-deploy-multi-agent-ai-with-python-and-docker/

實用的端到端教學，使用 Docker Compose 建立一個真正的多 Agent 管線。涵蓋關注點分離、cron 排程和安全考量。

3. DataCamp：使用 Docker 部署 LLM 應用（免費）

連結： https://www.datacamp.com/tutorial/deploy-llm-applications-using-docker

專門針對 LLM 應用與 RAG 管線的逐步指南。涵蓋 Dockerfile 建立、環境管理和部署。

4. LLM 應用的 Docker 容器化（ApXML，免費）

連結： https://apxml.com/courses/python-llm-workflows/chapter-10-deployment-operational-practices/containerization-docker-llm-apps

涵蓋基礎映像選擇、依賴管理、多階段建置，以及用於多服務 LLM 部署的 Docker Compose。

重點關注： 為 Python/FastAPI 應用編寫 Dockerfile、使用多階段建置來保持映像檔小巧、使用 Docker Compose 進行多服務設定（應用 + 資料庫 + Redis）、使用環境變數管理機密、以及使用 .dockerignore 避免洩漏敏感檔案。

練習專案： 將你第三個月的 RAG 應用容器化。建立一個 docker-compose.yml，用於執行你的 FastAPI 應用、一個向量資料庫（Chroma 或 Qdrant）和 Redis 作為快取。部署後，執行 docker compose up 就能啟動所有服務。

3. 背景任務與佇列

LLM 呼叫很慢。如果使用者要求你的應用處理一個文件，而你讓他們等待 30 秒的回應，他們會離開。

背景任務讓你立即接受請求，非同步處理，並在完成時通知使用者。

資源：

1. Celery 官方入門指南（免費）

連結： https://docs.celeryq.dev/en/stable/getting-started/introduction.html

標準的 Python 任務佇列。涵蓋基本設定、任務定義和工作管理。

2. FastAPI 背景任務文件（官方，免費）

連結： https://fastapi.tiangolo.com/tutorial/background-tasks/

內建的輕量級背景任務，適用於簡單的使用案例。對於快速發送即忘的任務使用這個，對於更重的任務使用 Celery。

重點關注： 理解何時使用 FastAPI 內建的 BackgroundTasks，以及何時使用像 Celery 這樣的完整任務佇列；設定 Redis 作為訊息代理；處理任務失敗和重試；以及將任務狀態回傳給使用者。

4. 認證與 API 金鑰安全

如果你的 AI 應用有 API，那麼它就需要認證。沒有認證，任何人都可以使用你的端點，燒光你的 LLM 額度，而你醒來時會看到一張 5,000 美元的帳單。

資源：

1. FastAPI 安全文件（官方，免費）

連結： https://fastapi.tiangolo.com/tutorial/security/

涵蓋 OAuth2、JWT 令牌、API 金鑰和基於依賴注入的認證模式。官方參考資料，建議完整閱讀教學。

2. OWASP API 安全十大風險（免費）

連結： https://owasp.org/API-Security/

權威的 API 安全風險列表。在發布任何東西之前，先了解認證失效、注入和大量賦值。

3. Auth0：API 認證最佳實踐（免費）

連結： https://auth0.com/docs/get-started/authentication-and-authorization

在 API 中實作認證和授權的實用指南。

重點關注： JWT 令牌用於用戶認證、API 金鑰管理用於服務間通訊、按用戶/金鑰進行速率限制、絕不將機密儲存在程式碼中（使用環境變數），以及理解認證（你是誰）和授權（你能做什麼）之間的區別。

5. 日誌記錄與可觀測性

在生產環境中，如果你看不到正在發生什麼，你就無法修復出了什麼問題。

LLM 應用有一個獨特的挑戰：模型可能回傳 200 狀態碼，但仍然產出無用或幻覺的答案。傳統監控無法捕捉到這一點。你需要針對 LLM 的可觀測性。

資源：

1. Langfuse（開源，免費方案）

連結： https://langfuse.com/docs/observability/overview

開源 LLM 可觀測性平台。追蹤每個請求：傳送的提示、收到的回應、令牌用量、延遲、工具呼叫。支援提示版本控制、評估和 LLM-as-Judge 評分。與 OpenAI、Anthropic、LangChain、LlamaIndex 整合。

2. LangSmith（免費方案）

連結： https://smith.langchain.com/

來自 LangChain 團隊。如果你正在使用 LangChain/LangGraph，設定只需一個環境變數。追蹤、除錯、監控儀表板和線上評估。免費方案對於開發和小規模生產來說很充裕。

3. Python Structlog（免費）

連結： https://www.structlog.org/

Python 的結構化日誌記錄。產出真正可搜尋和可解析的 JSON 日誌。遠比 print() 或基礎日誌記錄更適合生產應用。

重點關注： 追蹤每個 LLM 呼叫（輸入提示、輸出、令牌、延遲、成本）、使用 JSON 輸出的結構化日誌記錄、設定顯示請求量、錯誤率和每日成本的儀表板，以及當某些東西故障或成本飆升時發出警報。

6. 提示與版本管理

在生產環境中，你的提示就是程式碼。它們需要版本控制、測試和回滾能力。

在未追蹤變更的情況下於生產環境中修改提示，是你破壞東西卻無法找出原因的方法。

資源：

1. Langfuse 提示管理（免費）

連結： https://langfuse.com/docs/prompts

集中式提示版本控制，內建測試遊樂場。將你的提示版本控制與應用程式碼分開管理。在無需重新部署應用的情況下部署提示變更。

2. Anthropic 提示管理最佳實踐（免費）

連結： https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview

關於大規模組織、迭代和管理提示的最佳實踐。

重點關注： 將提示儲存在應用程式碼之外、為每個提示變更進行版本控制、在生產環境中進行 A/B 測試提示變體，以及當新提示表現較差時擁有一個回滾策略。

7. 成本監控與速率限制

LLM API 按令牌計費。如果沒有成本控制，流量高峰或提示中的錯誤可以在幾分鐘內燒掉數百美元。

資源：

1. OpenAI 用量儀表板（官方）

連結： https://platform.openai.com/usage

按模型、按日追蹤支出，並設定用量限制。

2. Anthropic 用量儀表板（官方）

連結： https://console.anthropic.com/ 同樣適用於 Claude API 用量。

3. Helicone（免費方案）

連結： https://www.helicone.ai/

基於代理的可觀測性工具，捕捉每個 LLM 呼叫並自動追蹤成本。設定只需一行程式碼：變更你的基礎 URL。

4. LiteLLM（開源，免費）

連結： https://github.com/BerriAI/litellm

超過 100 個 LLM 提供者的統一介面。包含預算管理、速率限制和跨提供者的支出追蹤。

重點關注： 設定每日/每月硬性支出限制、在你的 API 中實作每用戶速率限制、對簡單任務使用較便宜的模型（不要所有事情都用 GPT-4/Opus）、使用 Redis 快取重複的相同請求，以及監控每個請求的成本，以便及早發現昂貴的提示。

8. 快取

如果 20% 的使用者詢問類似的問題，你就在為同一個 LLM 呼叫支付 20 次費用。

快取是同時降低成本和延遲的最簡單方法。

資源：

1. Redis 官方文件（免費）

連結： https://redis.io/docs/

標準的記憶體內資料儲存。快速、簡單，且完美適用於 LLM 回應快取。

2. GPTCache（開源，免費）

連結： https://github.com/zilliztech/GPTCache

專門為 LLM 應用設計的語意快取。使用嵌入相似性來尋找語意相似（不僅是相同）查詢的快取回應。

重點關注： 對完全相同提示的精確比對快取、對相似查詢的語意快取、快取失效策略（基於 TTL 最簡單），以及衡量快取命中率以了解實際成本節省。

第五個月里程碑

到這個月底，你應該能夠：

• 使用正確的生產環境配置，在 Docker 中部署一個 FastAPI + LLM 應用。
• 使用背景任務和佇列處理長時間運行的任務。
• 透過認證、速率限制和 API 金鑰管理來保護你的 API。
• 使用 Langfuse 或 LangSmith 追蹤和除錯 LLM 呼叫。
• 管理提示，具備版本控制和回滾能力。
• 即時監控成本並設定支出限制。
• 快取 LLM 回應以降低延遲和成本。

⏩------------------------------------------------------------------------⏪

第六個月：專精並成為可聘用的專家

你所獲得的這些知識和技能可以應用於三個方向（當然，這只是我所看到的）。

你需要選擇其中一個並專注於實踐。

儘管上面提到的一切，最好也是通過純粹的實踐來學習。

方向 1：AI 產品工程師

如果你想要快速找到新創公司的工作，這是最佳選擇。

這是最常見的路徑。你建立真實使用者會互動的 AI 驅動產品。

你已經具備了第一到第五個月的大部分技能。現在在產品方面深入。

專注於：

• LLM 應用
• RAG
• Agent
• 部署
• 產品使用者體驗

這個月要學什麼：

1. 端到端產品建構

停止建構教學。建立人們可以使用的產品。

資源：

1. Vercel AI SDK（免費）

連結： https://sdk.vercel.ai/docs

建立具有串流支援的 AI 驅動 UI 的最快方法。React、Next.js 和 Vue 整合，內建串流 UI 元件。

2. Streamlit（免費）

連結： https://docs.streamlit.io/

用純 Python 建立資料應用和 AI 展示。適合內部工具和 MVP，不適合生產規模的 UI。

3. Gradio（免費）

連結： https://www.gradio.app/docsQuick 用最少的程式碼打造 ML/AI 介面。特別適合用來展示模型與建立原型。

本月重點： 打造 2–3 個完整的、可以展示的專案。例如「與你的文件對話」應用程式、AI 驅動的內部工具，或是能自動化真實工作流程的 Agent。把它們做出來、放到 GitHub 上、部署到某個大家能試用的地方。

2. AI 產品的使用者體驗

AI 產品之所以失敗，往往是因為使用者體驗沒有考慮到模型的限制。

資源：

1. Google：People + AI 指南（免費）

連結： https://pair.withgoogle.com/guidebook/

針對設計人機互動的最佳資源。內容涵蓋如何設定預期、處理錯誤以及建立信任。

2. Nielsen Norman Group：AI 使用者體驗指南（免費）

連結： https://www.nngroup.com/topic/artificial-intelligence/

以研究為基礎的 AI 介面設計指南。

本月重點： 如何處理串流時的載入狀態、模型出錯時要顯示什麼、如何讓使用者提供回饋，以及為 AI 輸出的「機率性」（有時就是會出錯）來設計體驗。

方向 2：應用型 ML / LLM 工程師

如果你想要更深入的技術角色，這個方向最適合你。

這個方向是為那些想超越 API 呼叫、理解底層運作原理的工程師準備的。

重點關注：

• 微調（Fine-tuning）
• 何時該微調 vs 何時該用提示工程
• 評估（Evaluation）
• 推理最佳化（Inference optimization）
• 開源模型
• 訓練管線（Training pipelines）

本月學習目標：

1. 何時該微調 vs 何時該用提示工程

應用型 ML 中最關鍵的決定：你需要改變模型，還是只需要改變與它對話的方式？

資源：

1. Google ML 速成課程：微調、蒸餾與提示工程（免費）

連結： https://developers.google.com/machine-learning/crash-course/llm/tuning

針對這三種方法以及各自適用時機，最清晰的解釋。

2. Codecademy：提示工程 vs 微調（免費）

連結： https://www.codecademy.com/article/prompt-engineering-vs-fine-tuning

提供實用的決策框架，並附上每種方法的明確使用案例。

3. IBM：RAG vs 微調 vs 提示工程（免費）

連結： https://www.ibm.com/think/topics/rag-vs-fine-tuning-vs-prompt-engineering

涵蓋完整的決策空間，包含何時該合併使用各種方法。

需要牢記的決策框架： 從提示工程開始（最便宜、最快）。如果模型需要存取特定資料，再加入 RAG。只有在提示工程加上 RAG 仍無法達到所需的品質、一致性或延遲時，才考慮微調。

2. 實務中的微調

當你真的需要微調時，以下是如何進行。

資源：

1. OpenAI 微調指南（官方、免費）

連結： https://platform.openai.com/docs/guides/fine-tuning

開始微調最簡單的方式。上傳 JSONL 資料集、執行一個任務、獲得一個自訂模型。即使你之後轉向使用開源模型，這個流程也很適合用來學習。

2. HuggingFace Transformers 微調教學（免費）

連結： https://huggingface.co/docs/transformers/training

處理開源模型的標準函式庫。涵蓋訓練、評估與模型儲存。

3. Unsloth（開源、免費）

連結： https://github.com/unslothai/unsloth

微調速度提升 2 倍，記憶體用量減少 80%。開箱即支援 LoRA 和 QLoRA。這是在消費級硬體上微調開源模型的最快途徑。

4. LLaMA-Factory（開源、免費）

連結： https://github.com/hiyouga/LLaMA-Factory

統一框架，支援微調 100 多種 LLM。包含網頁 UI，可進行無程式碼微調。支援 LoRA、QLoRA、全參數微調、RLHF 與 DPO。

本月重點： 準備訓練資料集（JSONL 格式）、理解 LoRA 和 QLoRA（參數高效微調）、在 OpenAI 或使用 HuggingFace 執行微調任務、評估微調後的模型與基礎模型的差異，以及判斷何時微調不符合成本效益。

3. 開源模型

並非所有事情都需要透過 OpenAI 或 Anthropic。開源模型給你完整的控制權、沒有 API 成本，而且能夠在本地端執行。

資源：

1. Ollama（免費）

連結： https://ollama.ai/

用一條指令在本地端執行開源 LLM。支援 Llama、Mistral、Gemma 以及數十種其他模型。這是實驗開源模型最快的方式。

2. HuggingFace Model Hub（免費）

連結： https://huggingface.co/models

最大的開源模型儲存庫。可以瀏覽、下載並部署適用於任何任務的模型。

3. vLLM（開源、免費）

連結： https://github.com/vllm-project/vllm

高吞吐量的 LLM 推理引擎。比單純的 HuggingFace 服務快 2–4 倍。這是生產環境中服務開源模型的標準配置。

本月重點： 使用 Ollama 在本地端執行模型進行測試、理解量化（Quantization：GGUF、GPTQ、AWQ）及其對部署的重要性、針對你的使用案例基準測試開源模型與 API 模型的差異，以及使用 vLLM 在生產環境中服務模型。

4. 推理最佳化

讓模型在生產環境中跑得更快、成本更低。

資源：

1. HuggingFace：最佳化 LLM 推理（免費）

連結： https://huggingface.co/docs/transformers/llm_optims

涵蓋 KV-cache 最佳化、量化以及批次處理策略。

2. NVIDIA TensorRT-LLM（免費）

連結： https://github.com/NVIDIA/TensorRT-LLM

在 NVIDIA GPU 上達到最大推理效能。大多數大規模生產環境的 LLM 服務都在使用它。

本月重點： 提升吞吐量的批次處理策略、降低記憶體與成本的量化、加速生成速度的 KV-cache 最佳化，以及為你的推理工作負載選擇合適的硬體。

方向 3：AI 自動化工程師

如果你想要立刻為企業打造解決方案，這個方向最適合你。

這個方向的重點在於使用 AI 自動化真實的商業工作流程。比較不專注於打造產品，而是解決營運上的問題。

重點關注：

• 工作流程編排（Workflow orchestration）
• 商業流程自動化
• 多工具系統
• CRM、文件、電子郵件、客服、營運使用案例

本月學習目標：

1. 工作流程編排

真正的商業自動化幾乎從來不是單一個 LLM 呼叫。它是橫跨多個系統的一系列行動。

資源：

1. n8n（開源、可自架免費）

連結： https://docs.n8n.io/

可視化的工作流程自動化，內建 AI 節點。能將 LLM 連接到超過 400 種整合服務（Slack、Gmail、Notion、CRM 等）。這是 AI 自動化中最好的無程式碼/低程式碼選項。

2. LangGraph：多 Agent 工作流程（免費）

連結： https://langchain-ai.github.io/langgraph/concepts/multi_agent/

以程式碼為優先的編排方式，用於複雜的多 Agent 系統。適用於 n8n 不足以應付、需要完整程式化控制的情況。

3. Temporal（開源、免費）

連結： https://docs.temporal.io/

用於長時間運行、容錯流程的持久化工作流程引擎。當你的自動化需要應對崩潰、重試和逾時情況時使用。

本月重點： 設計能夠優雅處理失敗的工作流程、將 AI 連接到真實的商業工具（電子郵件、CRM、資料庫、試算表）、建立包含人工審核步驟的流程，以及記錄每個自動化動作以利稽核軌跡。

2. 商業流程自動化

AI 自動化的獲利關鍵在於解決特定且昂貴的商業問題。

資源：

1. Zapier AI Actions（免費方案）

連結： https://zapier.com/ai

無需程式碼即可將 AI 連接到 6,000 多個應用程式。適合在打造客製化解決方案之前，先用來原型化自動化流程。

2. Make (Integromat)（免費方案）

連結： https://www.make.com/

可視化自動化平台，具備進階邏輯與 AI 整合。對於複雜的工作流程來說，比 Zapier 更強大。

本月重點： 找出投資報酬率最高的自動化目標（通常是重複性高、耗時且基於規則的任務）、建立能夠輔助人類而非取代人類的自動化流程，以及衡量實際節省的時間與金錢。

3. CRM、文件、電子郵件、客服自動化

最常見且最有價值的 AI 自動化使用案例。

資源：

1. OpenAI Cookbook：AI 驅動的電子郵件處理（免費）

連結： https://github.com/openai/openai-cookbook

使用 AI 進行電子郵件分類、路由和回覆的模式。

2. LangChain：文件處理管線（免費）

連結： https://python.langchain.com/docs/how_to/#document-loaders

從超過 80 個來源攝取和處理文件。

本月重點： 建立 AI 驅動的電子郵件分類與自動回覆系統、打造能夠萃取結構化資料的文件處理管線、建立使用 RAG 技術於知識庫的客服聊天機器人，以及將 AI 整合到現有的 CRM 工作流程中（HubSpot、Salesforce 等）。

方向 3 的練習專案： 建立一個端到端的潛在客戶資格審核系統。它應該要：

從某個來源（CSV、API 或表單）抓取或匯入潛在客戶

使用 LLM 研究每個潛在客戶（公司資訊、合適度評估）

根據你的理想客戶檔案（ICP）評分和排名潛在客戶

草擬個人化的開發信

將所有內容記錄到試算表或 CRM 中

這是一個真實的、可銷售的自動化解決方案，企業確實會為此付費。

⏩------------------------------------------------------------------------⏪

總結

經過這 6 個月，你可以期待什麼？

老實跟你說，沒有什麼一夜致富的神話。

這份路線圖不會讓你在 6 個月內變成資深 AI 工程師。

但它會讓你成為一個能夠建立、交付並部署真正 AI 系統來解決真實問題的人。

而現在，市場正在為這樣的能力買單。

對 AI 工程師的需求並沒有減緩。職缺數量年增 25%。

PwC 發現，需要 AI 技能的職位與相同但不需要 AI 技能的職位相比，薪資溢價高達 56%。

只有 1% 的公司被認為是「AI 成熟」的，這意味著 99% 的公司仍然需要幫助。美國勞工統計局預測，到 2034 年，相關職位將成長 26%。

這些不是誇大的數字。這些是基於分析的實際數字。

如果你在美國全職工作：

初級 AI 工程師 起薪為 $90,000–$130,000

中級（3–5 年經驗） 落在 $155,000–$200,000

高階職位 則為 $195,000–$350,000+

根據 Glassdoor（2026 年 3 月）的數據，平均薪資為 $184,757

中級薪資範圍的增長最快，年增 9.2%，因為企業迫切需要能夠在無需持續監督下交付生產級 AI 的人才。

如果你比較偏好自由接案：

AI Agent 開發 收費 $175–$300/小時

RAG 實作 收費 $150–$250/小時

LLM 整合 收費 $125–$200/小時

Reddit 上有一位開發者在兩週內為一家法律事務所建立了一個文件摘要工具，賺了 $8,000 美元。一位自由接案者以 $150/小時的費率每週工作 25 小時，年收入可達 $195,000 美元。

而如果你選擇走顧問路線，就像我上一篇文章提到的，你可以收費：

為企業設定 AI Agent：$300–$5,000

AI 內容管理：$500–$2,000/月

自動化客服：$1,000–$4,000

設定冷開發信系統：$500–$2,000

服務的範圍甚至更廣，但一旦你掌握了這份路線圖中的技能，你在 2026 年就已經是一位受歡迎的專家了。

這些都是真實的人做著真實工作所得到的真實數字。

現在，這是我真正希望你從這一切中帶走的東西：

從每個月中選擇一個專案，然後動手打造它。不是閱讀相關文章，不是觀看教學影片。而是建構它、打破它、修復它、部署它、將它放到 GitHub 上。能夠被僱用的工程師是那些展示他們「做了什麼」的人，而不是那些展示他們「學了什麼」的人。

開始分享你所學到的東西。在 X、LinkedIn 或任何平台上寫下來。教學是學習最快的方式，同時也能建立你的聲譽。我所見過最好的機會，都來自那些「被看見」的人，而不是那些投了 500 份履歷的人。

而且，請不要等到你覺得自己準備好了。你永遠不會覺得準備好了。「我正在學習」和「我正在建構」之間的差距，是大多數人永遠卡住的地方。

一旦你有了正在運作的專案，就開始申請工作、開始接案、開始提供服務。即使它們還不完美。市場不會獎勵完美。市場獎勵的是能夠「交付」的人。

如果你真的願意付出努力，6 個月的時間足以改變一切。

我真心相信，正在閱讀這篇文章的每個人都能做到。

只要持續建構，持續學習。

希望這對你有幫助，我的家人們 ❤️