AI 工程師的 4 個月轉職指南
AI 工程是當今科技領域薪資最高、成長最快的工作之一。而進入這個領域的門檻，現在比以往任何時候都更低。
大多數指南都搞錯了方向。它們給你一堆理論，要你精通線性代數和神經網路數學，然後你在第二週就放棄了。
或者它們用 80 個連結淹沒你，沒有順序也沒有結論，讓你花更多時間決定要學什麼，而不是真正去學習。
我讀遍了熱門的路徑圖，測試了它們推薦的工具，然後打造了一個我會親手交給正在轉職、而且有正事要做的朋友的版本。
不需要數學學位。不需要四年計劃。
四個月的專注學習，每個技能一個明確的選擇，可以直接複製的提示詞，以及那些在不知不覺中扼殺大多數轉職嘗試的錯誤。
先說為什麼我認為現在時機正好，然後是完整的學習路徑。
為什麼這扇門是開著的（而且我可以證明）
你可能聽過 AI 會搶走工作。
但比較少人提到的是：AI 正在創造一個特定、高薪的職位類別，速度比市場上幾乎任何其他領域都快，而且傳統的門檻正在消失。
PwC 的 2026 年全球 AI 就業指標分析了橫跨六大洲超過十億個職缺廣告。有三個發現對任何考慮轉職的人來說都很重要。
首先，需要 AI 技能的工作成長速度約為整體市場的八倍。AI 技能職位成長了 69%，而整體就業市場只成長了 9%。
這不是四捨五入的誤差。這是一個正在與其他領域拉開差距的類別。
其次，薪資溢價是真實存在且持續上升的。擁有 AI 技能的勞工，相較於沒有這些技能的類似職位，享有 62% 的薪資溢價，高於前一年的 57%。
企業願意支付更多，而不是更少，來僱用真正能用這些工具進行建構的人。
第三，這一點改變了轉職者的遊戲規則：學位要求正在下降，而且下降最快的正是這些職位。
Pwc 發現，在 2019 到 2024 年間，需要學位的 AI 增強型工作比例從 66% 下降到 59%。
對於 AI 可以自動化部分工作的職位，這個比例下降得更明顯，從 53% 降到 44%。雇主在 AI 相關工作中，比在任何其他領域都更快地放棄學歷篩選。
還有一個數字值得深思。在美國，最受 AI 影響的入門級職位自 2019 年以來成長了 35%。
同期，其他入門級職位減少了 10%。AI 階梯的最底層正在變寬，而其他入門級市場正在萎縮。
現在來說說誠實的反面觀點，因為我不是來賣你一個夢想的。
PwC 也發現，受 AI 影響的入門級職位越來越要求過去只屬於資深人員的技能：判斷力、溝通能力、以及對結果負責而非只對任務負責的能力。
門檻並沒有全面降低。它移動了。重點不再是「你有沒有學歷」，而是「你能不能真正讓這個東西運作，並解釋它為什麼能運作」。
如果你是沒有工作經驗的應屆畢業生，這可能是壞消息。但如果你是從其他職業轉職過來的人，這是好消息，因為你已經擁有他們現在要求的東西。
你交付過成果。你應對過利害關係人。你在壓力下承擔過責任。
一個 22 歲的 CS 學位畢業生通常沒有這些經驗。如果你把你現有的判斷力，加上這份指南中的技術技能，你並不比那些應屆畢業生落後。
在雇主最在意的軸線上，你甚至領先他們。
這就是轉職者的優勢，幾乎沒有任何路徑圖會告訴你這件事。在接下來的四個月裡，把這個優勢放在你的口袋裡。這就是為什麼這個計劃對你來說是可行的。
快速談一下薪資，因為在投入四個月之前，你會想知道真實的數字。
我會在最後提供完整的數據和來源，但簡單來說：截至 2026 年中，Glassdoor 統計美國 AI 工程師的平均薪資約為 143,500 美元，典型範圍大約在 115,000 到 181,000 美元之間。
資深職位的薪資更高。負責招募生產級 AI 工作人才的獵頭表示，中階基礎薪資集中在 155,000 到 200,000 美元之間。
這些不是從誇大其詞的討論串中挖出來的誇大數字。它們是當前的真實數據，我會告訴你每個數字的來源。
AI 工程師實際上在做什麼（60 秒版本）
在開始計劃之前，讓我們先消除最大的恐懼來源，因為它比任何技術障礙都阻擋了更多人。
當大多數人聽到「AI 工程師」時，他們想像的是有人在實驗室裡從頭訓練一個巨大的模型，周圍環繞著 GPU 和他們永遠無法理解的數學。
那是另一份工作。它叫做研究科學家或 ML 研究員，這樣的人相對較少，而且通常確實需要高等學位。
那個成長速度比市場快八倍的 AI 工程師工作，完全是另一回事。
你是在現有模型的基礎上建構產品和功能。你拿 Claude、GPT 或一個開源模型，然後讓它在一個真實的應用程式中，執行一個特定且可靠的工作。
在實務上，這意味著你連接模型 API，設計提示詞和提供給模型的上下文，取得結構化資料，將模型連接到工具和資料庫，讓它檢索正確的資訊，處理所有可能出錯的情況，然後部署它，讓真實的人可以使用。
它介於軟體工程、產品工作和應用 AI 之間。你是個建構者，而不是研究員。
這裡有一個我常用的單行測試。如果你能讓一個 LLM 在應用程式內部可靠地執行特定工作，而且你了解足夠的知識來在它出錯時修復它，你就是一個 AI 工程師。就是這麼簡單。
這份指南中的所有內容，都是為了讓你達到這個目標。
你不需要知道 Transformer 的內部運作原理。你不需要微積分。你不需要能夠推導反向傳播。
你需要成為一個稱職的建構者，了解如何在現實世界中與這些模型協作。
這是一項可以學習的技能，而四個月的專注學習足以讓你達到能實際運用的程度。
在第 1 個月之前請先閱讀：扼殺轉職的 4 個錯誤
我刻意把這個放在路徑圖之前。
大多數指南把錯誤放在最後，但扼殺轉職的錯誤發生在第二週，而不是第三個月。如果你只記得這份指南中的一個章節，請記住這個。
我看過人們，包括早期的我自己，犯過每一個這些錯誤。這些都與智力無關。
它們關乎策略。修正策略，四個月的計劃才能真正奏效。
錯誤 1：從理論和數學開始。
你感到興奮，你想要做好這件事，所以你去找一個機器學習課程，從線性代數、梯度下降和神經網路背後的數學開始。
三週後，你看了很多課程，什麼也建構不出來，你覺得自己是個冒牌貨。於是你放棄了。
解決方法：跳過它。針對你目標的工作，你不需要推導數學。
你需要建構。
當你在真實專案中遇到它們時，你會學到實際需要的概念，而且因為它們與你建構的東西相關聯，你會記得特別牢。
先學理論是聰明人在這條路上失敗最常見的原因。不要從那裡開始。
錯誤 2：看教學影片而不是動手建構。
這個錯誤很狡猾，因為它感覺像是一種進步。你看了四個小時的 Python 課程，跟著點頭，覺得自己學到了東西。你沒有。
你看著別人學到了東西。當你打開一個空白檔案時，那些知識都不見了。
解決方法：30 分鐘法則。每花一個小時觀看或閱讀，至少要花 30 分鐘在不開教學影片的情況下動手建構。
自己輸入範例。把它們弄壞。修改它們。遇到錯誤並修復它們。錯誤才是學習的來源。
一個建構得很糟但持續四個月的人，每次都勝過一個完美觀看但持續四個月的人。
雇主可以在十秒內從你的 GitHub 看出差異。
錯誤 3：學習工具而不是學習技能。
你聽說 LangChain 是熱門工具，所以你深入學習 LangChain。
六個月後，這個領域已經變了，大家都在用別的東西，你的 LangChain 知識感覺白費了。於是你去追新的工具。
然後那個工具也變了。你總是落後，因為你優化錯了層級。
解決方法：學習工具底下的技能。撰寫能產生可靠輸出的提示詞這項技能，不會因為框架更新而過時。
從模型取得結構化資料的技能、評估你的系統是否真正運作的技能、或是決定一個任務需要 Agent 還是單次呼叫的技能——這些技能會跨越所有曾經存在和將要存在的工具。
把學習工具當作練習技能的方式，而不是最終目標。這份指南正是基於這個原因，圍繞著技能來組織。
錯誤 4：等到你覺得準備好了才公開建構。
你決定等你「準備好了」之後，才開始分享你的作品、申請職位或提供自由接案服務。
你永遠不會覺得準備好。「準備好」是一種在你開始之後才會出現的感覺，而不是之前。
與此同時，那些被錄取、接到客戶的人，是在他們覺得自己夠格之前的幾個月，就開始分享粗糙的作品了。
解決方法：從第 1 個月就開始公開建構。發布你做出來的小東西。寫下你學到的東西。
在你完成專案的當天就把它放到 GitHub 上，即使是那些很醜的專案。
「我正在學習」和「我正在被看見地建構」之間的差距，是大多數轉職者卡住一整年的地方。早點縮小這個差距。
沒有人會那麼仔細地看你的早期作品，讓它使你難堪，而且複利效應從你開始的那一天就啟動了。
在整個過程中，把這四個錯誤放在心上。
下面的路徑圖預設就是為了避免所有這些錯誤而設計的：技能優先、建構優先、工具無關、從第一天就公開。
第 1 個月：Python 和基礎建設
你這個月的目標：成為一個稱職的 Python 開發者，能夠呼叫 API、管理一個小型專案，並且不再需要 Google 基本語法。
不是專家。是稱職。
第 2 到第 4 個月的一切，都假設你能夠撰寫乾淨的 Python 程式碼並在終端機中工作。這是基礎，急著跳過它以後會讓你吃苦。
在你開始之前，有一件事需要內化：AI 工程首先是軟體工程。AI 的部分是建立在一個正常的軟體堆疊之上。
如果底層的堆疊不穩固，AI 的部分就永遠無法可靠。所以第 1 個月是要讓自己對基礎知識足夠熟悉，讓它們不再成為你的障礙。
我會為每個技能提供一個主要的選擇，並附上明確的理由。我刻意不給你每個主題五個選項。選擇是動力的敵人。
選擇我指出的那個，只有在它真的不適合你時才去尋找其他選項。
Python
Python 是整個領域的語言。在接下來的四個月裡，你接觸到的幾乎所有函式庫、API、教學和職位都是用 Python。你學會它，其他一切都會變得更容易。
我的選擇：CS50P，哈佛大學的 Python 程式設計入門。 免費、嚴謹，而且它強迫你實際解決問題，而不是看著別人解決問題。
習題集是全部的價值所在。它比一個輕鬆的 YouTube 課程要求更高，而這正是重點。
你想要那個會讓你稍微掙扎的版本，因為掙扎正是技能形成的地方。
你可以在 cs50.harvard.edu/python 找到它。
如果 CS50P 對一個完全的初學者來說太難了，YouTube 上的 freeCodeCamp Python 課程是一個比較溫和的入門點，但把它當作暖身，而不是主要課程。
一旦你不再害怕一個空白檔案，就回來上 CS50P。
實際上要專注的內容，大致順序是：變數和資料型別、迴圈和條件判斷、函式，然後是集合型別（列表、字典、集合、元組）。
然後是檔案處理以及讀寫 JSON，你會不斷地用它來處理 AI API。
然後是足夠的類別和物件導向基礎，讓你能在沒有恐慌的情況下閱讀別人的程式碼。
然後是使用 try 和 except 進行錯誤處理。
最後是虛擬環境和 pip，這樣你就可以安裝套件而不會搞壞你的系統。
不要試圖記住這些東西。理解到足以快速查閱的程度，然後透過動手建構讓它內化。
你第 1 個月的 Python 建構目標：一個能做點正事的小型命令列工具。
一個可以讀寫 JSON 檔案的支出追蹤器就是個好選擇。或者一個呼叫免費公開 API 並以乾淨格式印出結果的腳本。
大概 60 到 100 行你自己的程式碼。
它醜不醜不重要。重要的是你寫了它。
從第一天就用 AI 來學習
這裡是我會做而舊路徑圖不會做的事：從第一週開始就用 AI 來學習 AI。
你擁有史上最好的耐心導師，而且在免費方案上它完全免費。當你遇到一個你不懂的錯誤時，不要在論壇上花 40 分鐘。
把它貼到 Claude 或 ChatGPT，請它用白話解釋這個錯誤，並引導你走向解決方案，而不是直接給你答案。
這裡有一個我會在第一天就設定好的複製貼上提示詞。把它存起來。
這是這份指南中幾個值得加入書籤的產出物之一。
提示詞：你的 Python 學習夥伴
（框架：FAG 學習夥伴，由 AI Guides 提供）
1你的任務：在我作為轉職者學習寫程式的過程中，扮演我耐心的 Python 導師。23關於我的背景：4- 我正在學習 Python 以成為 AI 工程師。5- 我在寫程式方面是絕對的初學者，但在努力工作方面不是。6- 我透過動手做來學習效果最好，而不是被直接給予答案。78你該做的事：9- 當我貼上一個錯誤時，用白話解釋它的意思以及可能的原因。不要只是給我修正後的程式碼。10- 先用提示引導我走向解決方案。只有當我問第二次時，才顯示完整的解答。11- 當我分享我寫的程式碼時，告訴我一件做得好的事和一件可以改進的事。只限這兩點。12- 在我讓某個東西運作之後，問我一個簡短的問題，來確認我是否真的理解了。1314規則：15- 不要使用術語而不在旁邊附上一行的白話解釋。16- 假設我想要學習，而不只是通過。稍微慢一點沒關係。17- 如果我即將養成一個壞習慣，直接且溫和地告訴我。1819輸出風格：對話式、簡短、一次只講一個概念。
這個月每天使用它。它能將學習寫程式中令人沮喪的部分，轉變成一場對話，而不是一堵牆。
它也會讓你熟練於撰寫提示詞，這是第 2 個月的核心技能，而且你甚至在知道這件事之前就開始練習了。
有一個注意事項，這樣你才不會養成壞習慣：使用 AI 來理解和排除障礙，而不是讓它幫你寫全部的程式碼。
如果你讓它幫你寫程式碼而你只是在旁邊看，你就回到了錯誤 2。
讓它解釋。你來打字。
Git 和 GitHub
Git 是開發者儲存、版本控制和分享程式碼的方式。
GitHub 是你的作品公開存在的地方，並成為你的作品集。
你會不斷地使用這兩者，而對於轉職者來說，GitHub 是你最接近履歷的東西，直到你擁有真正的經歷。
我的選擇：GitHub Skills。 免費、互動式，而且由 GitHub 在 GitHub 內部建構，所以你透過使用工具來學習它。從那裡開始，而不是抽象地閱讀關於 Git 的知識。
你可以在 skills.github.com 找到它。
如果分支和合併模型讓你困惑——而且它一開始會讓每個人都困惑——Learn Git Branching 這個視覺化工具可以透過讓你看到分支的移動來幫助你理解。
要專注的內容： init、add、commit、push 和 pull 的核心循環。然後是分支和合併。
然後是 .gitignore 檔案的作用，以及為什麼你永遠不應該將機密或 API 金鑰提交到公開儲存庫——這在你開始使用付費 API 時會變得極其重要。
然後是如何撰寫一個基本的 README，因為你的 README 在你之後求職時會發揮真正的作用。
這個月要建立的習慣： 你接觸到的每個專案，即使只是一個 20 行的腳本，在你建立的當天就要放到 GitHub 儲存庫中。
這就是錯誤 4 的解決方案的實際應用。你從一開始就在安靜地公開建構。
到了第 4 個月，你會有一串作品足跡，而不是一個空白的個人檔案。
終端機
你會不斷地從命令列執行腳本、安裝套件和管理專案。
在終端機中動作緩慢或感到害怕，會拖累其他所有事情，而且這是一個很容易修正的問題。
我的選擇： 一個簡短的初學者終端機課程來涵蓋基礎知識，然後就直接用它。MIT 的「Missing Semester」教材如果你想深入的話會更詳細，但對於第 1 個月，你只需要導航和執行東西。
學習 cd、ls、pwd、mkdir 和 rm 來移動和管理檔案。
學習 cat 和 grep 來閱讀和搜尋。
學習如何從終端機執行 Python 腳本，以及如何設定環境變數——當你需要處理 API 金鑰時就會用到。
你不需要成為 shell 大師。你需要的是不再猶豫。
用終端機來做所有事情一個星期，即使是你通常會用滑鼠做的事情，就能讓你達到目標。
API、JSON 和 HTTP
這是通往第 2 個月的橋樑。
從你開始使用 LLM 建構的第一天起，你就會進行 API 呼叫，這意味著你需要在使用 OpenAI 或 Anthropic 的工具之前，了解 Web API 是如何運作的。
我的選擇： MDN Web Docs HTTP 概述 來了解概念，加上 Python requests 函式庫文件來學習如何在程式碼中實現。
MDN 解釋請求和回應如何運作的方式，比任何其他免費資源都更清晰。
然後 requests 會向你展示如何用幾行程式碼在 Python 中進行這些呼叫。
要專注的內容： 什麼是 GET 和 POST 請求，以及如何在 Python 中進行它們。
讀寫 JSON，這是每個 AI API 使用的格式。
HTTP 狀態碼以及常見狀態碼的意義，特別是 200 代表成功、401 代表 API 金鑰錯誤、429 代表速率限制、500 代表伺服器錯誤——因為你會不斷地看到這些。
什麼是 API 金鑰，以及基本的認證是如何運作的。
以及對 Python 中 async 和 await 做什麼的輕量介紹——當你之後開始串流模型的回應時會用到。
現在先不要深入學習 async。
只要知道它存在，以及它大致解決了什麼問題就好。
你的建構目標： 一個 Python 腳本，呼叫一個免費的公開 API——一個不需要金鑰的 API，像是 Open-Meteo 天氣 API——並將結果印成乾淨的格式化輸出。
這是你整個第 2 個月都會在做的事情的一個縮小版，只是還沒有 AI 的部分。
關於 SQL 的快速說明
你不需要成為一個資料專家，但你會經常需要查看和查詢資料，而基本的 SQL 可以不斷地解救你。
我的選擇是 SQLBolt，它是免費、互動式的，並且可以在大約 20 個簡短的瀏覽器內課程中教你 SQL 的核心。
你可以在 sqlbolt.com 找到它。
專注在 SELECT、WHERE、GROUP BY、JOIN 和 ORDER BY。
目前這樣就夠了。
當一個專案需要時，你可以再深入學習。
第 1 個月的里程碑
到這個月底，你應該能夠撰寫一個可以讀寫檔案、呼叫 API 並且處理自身錯誤而不會崩潰的 Python 程式。
你應該使用 Git 對那個程式碼進行版本控制，並讓它存在於 GitHub 儲存庫中。
你應該能夠在終端機中移動而不猶豫。你應該了解 HTTP 請求是什麼，並能夠在 Python 中進行一個。
而且你應該能夠執行一個基本的 SQL 查詢。
如果你能做到這些事情，你就有了基礎。
大多數放棄的人從來沒有走到這一步，而走到這一步確實是最困難的部分，因為它是最不令人興奮的。
從第 2 個月開始會變得更有趣，因為從這裡開始，你將使用 AI 來建構。
第 2 個月：使用 LLM API 進行建構
你這個月的目標： 使用模型 API 建構真實的 AI 驅動功能。
到月底為止，你應該能夠熟練地撰寫能產生可靠輸出的提示詞、從模型取得結構化資料、讓模型呼叫你自己的函式、管理對話、以及處理所有可能出錯的情況。
這是整個工作的核心。之後的一切都建立在這個基礎之上。
這個月是事情開始變得真實的月份。你停止設定，開始讓模型做事。
在這裡慢慢來。
在第 2 個月投入深度，比在這份指南中任何其他地方投入深度都更有價值。
真正有效的提示詞撰寫
提示詞撰寫不是有禮貌地向聊天機器人問問題。
它是撰寫指令的技能，這些指令能夠從一個本質上是機率性的系統中，產生一致且可靠的輸出。
作為一個 AI 工程師，你在這裡花費的時間會比你預期的更多，而精通這項技能是你這個月可以做的最有槓桿作用的事情。
我的選擇：Anthropic 的互動式提示詞工程教學，放在 GitHub 上。這是現存最實作導向的資源，分成章節，並包含你可以對著 Claude API 執行的真實練習。
你練習自己撰寫和修正提示詞，而不是閱讀關於它的知識——如果你還記得錯誤 2，這正是重點所在。
你可以在 anthropics/prompt-eng-interactive-tutorial 儲存庫中找到它。一旦你完成了這個教學，Anthropic 和 OpenAI 的官方提示詞工程文件就是你會回來查閱的參考資料。
要專注的內容： 系統訊息和使用者訊息之間的差異，以及為什麼這個差異很重要。
為什麼具體性每次都勝過禮貌性。
鏈式思考提示，你要求模型在回答之前逐步推理，這在任何涉及邏輯的事情上都能明顯改善結果。
在你的提示詞中使用範例，稱為少樣本提示，來向模型展示你想要的格式。
以及培養對微小的措辭變化如何導致巨大的輸出變化的感覺——這只能透過大量練習來獲得。
一個能快速教你這個技能的建構練習：選一個真實的任務，比如摘要一份文件或分類一個意見回饋，然後為它寫五個不同的提示詞。
全部執行。
並排比較輸出。你會立刻看到提示詞設計對可靠性的影響有多大，而這個教訓會比任何課程都更深刻地烙印在你腦中。
結構化輸出
在一個真實的應用程式中，你幾乎從來不會想要從模型那裡得到一段文字。
你想要的是你的程式碼可以解析、儲存和使用的結構化資料。結構化輸出透過強迫模型回傳符合你定義的 schema 的資料來解決這個問題。
這是區分一個展示用原型和一個真正能在軟體內部運作的東西的技能之一。
我的選擇： Python 的 Instructor 函式庫，並以 OpenAI 和 Anthropic 的官方結構化輸出文件作為後盾。
Instructor 是使用 Pydantic（一個用於定義資料形狀的 Python 函式庫）從任何主流模型中取得結構化資料的最乾淨方式。
它可以用同樣的程式碼跨供應商運作，並且當模型回傳格式錯誤的內容時會自動重試。
這非常接近許多在職工程師實際使用的東西，這使得它值得在真實專案中學習，而不是一個玩具版本。
要專注的內容： 定義一個描述你想要資料的 Pydantic 模型，將那個 schema 傳遞給 API，以及處理模型拒絕回傳或回傳意外內容的情況。
理解真正的結構化輸出（schema 被強制執行）和較寬鬆的 JSON 模式（不保證）之間的差異。
這裡是你的第二個值得加入書籤的產出物，一個即使在加入函式庫之前也能運作的可靠結構化提取提示詞模式。
提示詞：結構化資料提取
（框架：FAG 提取器，由 AI Guides 提供）
1你的任務：從我提供的文字中提取結構化資料，並以乾淨的 JSON 格式回傳。23操作方式：4- 仔細閱讀輸入的文字。5- 只提取下方「輸出」欄位中列出的欄位。6- 如果文字中缺少某個欄位，請使用 null。不要猜測或編造。7- 只回傳 JSON 物件。不要有任何解釋、Markdown 或前言。89規則：10- 每個值都必須能追溯到輸入文字中的某個來源。11- 日期使用 YYYY-MM-DD 格式。數字以數字型態呈現，而非字串。12- 如果文字內容模稜兩可，寧可回傳 null，也不要自信地給出錯誤答案。1314輸出：一個包含以下欄位的 JSON 物件：15{16 "field_one": 字串或 null,17 "field_two": 數字或 null,18 "field_three": 字串列表或空列表19}2021輸入文字：22[在此貼上文字]
這個測試失敗的備註，因為我答應過要給你誠實的版本：你第一次這樣做時，模型有時會把 JSON 包在 Markdown 程式碼區塊中，或者在前面加上一句友善的說明，然後你的解析器就會卡住。
這很正常。解決方法是在解析前先移除程式碼區塊，並在提示詞中明確要求只回傳 JSON 物件，而上面的範例模式已經做到了這點。
一旦你遇到過這個問題並處理好它，以後就永遠知道怎麼處理了。
你的建置目標：一個收據或發票解析器。
輸入像「發票 123，3 個小工具共 45.99 美元，3 月 30 日到期」這樣雜亂的原始文字，然後回傳一個包含發票號碼、金額、商品數量與到期日的乾淨結構化物件。
這是一個真正實用的小工具，也是一個很好的作品集項目。
工具呼叫
工具呼叫是將文字生成器轉變為能夠執行行動的關鍵：搜尋網路、查詢資料庫、呼叫你的 API、執行程式碼。
這是整份指南中最重要的技能之一，也是第三個月所有內容的基礎。
讓你能夠理解的心智模型：模型不會執行你的函式。
它會檢視對話內容，決定應該使用某個工具，然後回傳一個結構化的請求，指明要呼叫的函式名稱與引數。
你的程式碼負責執行該函式，並將結果交回給模型。模型是決策者，你的程式碼是執行者。
我的推薦：同時閱讀 OpenAI 的函式呼叫指南 和 Anthropic 的工具使用文件。
這兩個概念在兩者之間完全相同，語法略有差異，同時閱讀兩者能讓底層模式變得顯而易見。
然後實際操作一個可執行的筆記本範例，例如 OpenAI Cookbook 中的範例，這樣你就能看到完整的循環，而不是零散的片段。
你需要專注的重點：在 schema 中清楚地描述你的函式、解析模型的工具呼叫回應、執行函式並將結果回饋給模型，以及處理模型決定不需要使用工具的情況。
你的工具描述品質比初學者想像的更重要，這個主題在第三個月會再次強烈地出現。
你的建置目標：一個配備三個工具的小型助手，例如 get_weather、calculate 和 search_notes，其中 search_notes 只是在一個寫死的字典中搜尋。
將它們全部連接起來，觀察模型如何根據你的提問決定要呼叫哪一個。
當你親眼看到它自行選對工具的那一刻，這個概念就會永遠烙印在你腦中。
對話狀態與串流
這個月還有兩個較小但至關重要的技能需要掌握。
模型在呼叫之間沒有記憶。對話是你必須在每次請求時都發送完整訊息歷史紀錄來管理的。
理解這一點至關重要，而且幾乎每個人在一開始都會對此感到驚訝。
我的推薦是 OpenAI 和 Anthropic 的訊息文件。
專注於理解 messages 陣列的結構、為什麼你需要同時附加使用者的訊息和模型的回覆、當你超過上下文視窗時會發生什麼事，以及修剪舊訊息的基本策略。
建立一個簡單的多輪終端機聊天機器人，讓它能保留歷史紀錄並有重置指令。這個項目很小，但能完整地教會你這個概念。
串流是指逐字顯示模型正在生成的輸出，而不是讓使用者等待完整結果。
這能讓應用程式的速度感覺快上許多。
我的推薦是來自任一供應商的官方串流文件，以及 Simon Willison 關於串流底層運作方式的清晰解說。
專注於設定 stream 選項、迭代處理資料區塊，以及從片段中組合出完整的回應。
對於任何真人會使用的東西，串流幾乎永遠是正確的選擇。
沒有人想盯著轉圈圈圖示等上十秒鐘。
成本、失敗處理，以及一個安全概念
這是區分業餘專案與可以交付給使用者使用的產品的三個關鍵。
成本與 Token：模型按 token 計費，一個 token 大約等於 0.75 個英文單詞。
輸入和輸出的 token 價格不同。
學會在發送請求前估算成本、將供應商的定價頁面加入書籤，並內化一條能省下真金白銀的規則：不要為了簡單任務使用最大、最貴的模型。
一個較便宜的模型通常就足夠好了，而且規模化後的成本差異非常巨大。
失敗處理：API 會失敗。
可能會遇到速率限制、請求超時、模型回傳格式錯誤的輸出。
優雅地處理這些情況，是讓產品達到可上線狀態的關鍵。
學會捕捉速率限制錯誤，並在每次嘗試之間增加延遲時間來重試，這稱為指數退避。
Python 的 Tenacity 函式庫可以用一個裝飾器做到這一點。
學會在信任模型的輸出之前先驗證它，永遠不要讓意外的回應導致你的整個應用程式崩潰。
提示詞注入，簡要說明：這是 LLM 應用程式中最大的安全風險。
當不受信任的使用者輸入與你的指令混合在一起時，就可能發生這種情況，讓使用者能夠覆蓋或劫持你的系統行為。
你不需要在這個月就成為安全專家，但你需要在你發布任何東西之前知道它的存在。
OWASP 關於此主題的指南是權威參考資料。
核心防禦措施：不要信任未經驗證的模型輸出來自動執行重要操作，並給予你的工具完成工作所需的最小權限。
第二個月里程碑
到這個月底，你應該能夠為特定任務編寫出能產生可靠輸出的提示詞、使用 Pydantic 和 Instructor 從模型取得結構化的 JSON、設定工具呼叫讓模型能執行你的 Python 函式、即時串流回應、管理多輪對話歷史紀錄、在發送請求前估算 token 成本、處理 API 錯誤和錯誤輸出而不會崩潰，並能解釋什麼是提示詞注入。
這本身就是一套真實、有就業競爭力的技能組合。
許多在生產環境中的付費 AI 功能，做的正是這些，而且僅止於此。
但下個月，你將要建置那個真正能讓你獲得錄用的東西。
第三個月：RAG 與 Agent，讓你獲得錄用的技能
你這個月的目標：建立能讓模型從你的文件中回答問題的系統，而不僅僅依賴它們的訓練資料；以及建立能自主執行多個步驟的系統。
這兩個技能，檢索與 Agent，是目前 AI 工程領域中最受歡迎的實務能力。
幾乎所有真實世界的企業用例，從支援機器人到內部知識工具再到文件分析，都建立在它們之上。
我將許多路線圖分散在兩個月的內容濃縮成一個月，因為你不需要精通所有進階變化形式才能獲得錄用。
你需要建立一個紮實的檢索系統和一個紮實的 Agent，理解每個元件存在的原因，並能在它們出錯時進行除錯。
這就是門檻。讓我們來達成它。
RAG，先用白話文解釋
RAG 代表檢索增強生成。
剝去術語，它很簡單：你給模型一個可以查閱的「圖書館」，這樣它就不需要記住所有東西，並且能夠回答關於你特定文件的問題。
流程是：你取得你的文件，將它們分割成區塊，將每個區塊轉換成一串能捕捉其意義的數字，然後儲存起來。
當使用者提出問題時，你用同樣的方式將他們的問題轉換成數字，找到數字最接近的區塊，然後將這些區塊連同問題一起交給模型。
模型使用你提供的內容來回答。這就是 RAG。其他的一切都是優化。
讓我們逐步建立各個元件。
嵌入
嵌入是將一段文字轉換成一長串代表其意義的數字。
有用的特性：意義相似的文字最終會得到相似的數字，在數字空間中彼此靠近。
這種「接近性」使得基於意義的搜尋成為可能，而這正是 RAG 的引擎。
我的推薦，用於建立直覺：Stack Overflow 部落格上關於文字嵌入的直觀介紹，它專注於心智模型而非數學；當你準備好在程式碼中生成嵌入時，再閱讀 OpenAI 的嵌入指南。
專注於理解什麼是向量、為什麼相似的文字會產生相似的向量，以及大致上如何測量兩者之間的距離。
你不需要了解嵌入是如何產生的數學原理。你需要知道如何使用它們。
一個能完整教會你這個概念的小型建置：取 20 個相關主題的句子，將每個句子轉換成嵌入，然後寫一個小函式，給定一個新句子，從你的集合中回傳三個最相似的句子。
這就是縮小版的 RAG。一旦你建立了這個，完整版本就只是將同樣的想法規模化。
分塊
你的文件太大，無法整體嵌入，所以你在嵌入之前將它們分割成區塊。
你如何分塊直接決定了你的系統找到正確資訊的能力。
即使檢索設定完美，如果底層的區塊品質不佳，也會失敗。
我的推薦：從 LangChain 的 RecursiveCharacterTextSplitter 開始，區塊大小設定為約 500 個字元，重疊部分約為 50 個字元。
這個重疊很重要，因為它可以防止你在一個區塊結束和下一個區塊開始的邊界處失去意義。
這是一個合理的預設值，能給你一個可運作的基準。
你需要在腦中記住的核心權衡：區塊太大會失去精確度，區塊太小會失去上下文。
從預設值開始，然後根據你的檢索實際出錯的情況進行調整。
向量資料庫
一旦你有了嵌入，你需要一個地方來快速儲存和搜尋它們。這就是向量資料庫的功能。
我的學習推薦： Chroma。它在本地端執行，無需設定任何基礎設施，這正是你在學習時所需要的。
你現在還不需要託管在雲端的大規模服務，過早加入它只會給你更多需要設定和可能出錯的東西。
Chroma 讓你能專注於概念本身。
你可以在 docs.trychroma.com 找到它。
學習建立一個集合、插入帶有來源和章節等元數據的嵌入、透過相似度查詢來取得最匹配的結果，以及在查詢時根據元數據進行過濾。
你不需要了解底層的索引演算法。你需要使用它們。
當你最終需要生產規模時，如果你的應用程式已經使用 Postgres 資料庫，pgvector 是自然的下一步；而當你想讓別人來管理時，也有託管選項。
但那是第四個月或在職場上才需要關心的問題。現在，在本機使用 Chroma 就足夠了。
讓檢索真正變好
基本的相似度搜尋只能讓你做出一個展示用的原型。
一些改進能讓你的系統可靠地運作，而了解這些改進正是區分那些只是複製教學的人，與那些真正理解系統的人。
元數據過濾：在儲存每個區塊時，為它標記有用的資訊，例如來源檔案、日期、章節或類別。
然後在查詢時根據這些資訊進行過濾。這是區分玩具系統與一個能讓使用者問「只顯示第四季報告的結果」並確實得到結果的系統之間的差異。
重新排序：你的第一次搜尋快速但粗略。
一個重新排序器會取前幾個結果，並根據它們與問題的實際相關性重新評分，這能以很小的速度成本顯著提升品質。
模式是：快速檢索一個廣泛的集合，然後透過重新排序縮小到最好的幾個。Cohere 的重新排序文件是學習這個概念最清晰的地方，而且通常只需加入一行程式碼。
檢索除錯，因為大多數 RAG 失敗是檢索失敗，而不是模型失敗。
當你的系統給出錯誤答案時，問題通常不在模型。
是檢索交給了它錯誤的區塊。
學習常見的失敗模式：問題和相關區塊在數字空間中不匹配，即使資訊確實存在（可透過改寫查詢來解決）；相關資訊分散在兩個區塊中（可透過增加重疊來解決）；或者正確的區塊存在但沒有進入前幾名結果（可透過檢索更多結果，然後再重新排序來解決）。
當答案錯誤時，在責怪模型之前，先檢查檢索到了什麼。這一個習慣將為你省去巨大的挫折感。
grounded 回答與引用：一個好的 RAG 系統不僅回答問題，還會告訴你答案的來源，這能建立信任並讓除錯變得容易許多。
將每個區塊的來源資訊傳入你的提示詞，並指示模型引用它。
這是你的第三個成品，一個讓 RAG 系統保持誠實的 grounded 提示詞。
這是我最推薦你加入書籤的一個，因為它是區分一個會編造答案的系統和一個你可以信任的系統的關鍵。
提示詞：Grounded RAG 回答
（框架：FAG Grounding，由 AI Guides 提供）
1你的任務：僅使用提供的上下文來回答使用者的問題。23操作方式：4- 閱讀下方的上下文區塊。每個區塊都有一個來源標籤。5- 僅使用在上下文中找到的資訊來回答問題。6- 在每個陳述之後，引用其來源標籤，格式如 [來源：檔案名稱，第 3 頁]。7- 如果上下文中沒有包含答案，請準確地說：8 「我沒有在提供的文件中找到足夠的資訊來回答這個問題。」910規則：11- 絕不使用來自所提供上下文之外的知識。12- 絕不猜測。絕不憑空填補聽起來合理的內容。13- 如果上下文部分回答了問題，請回答該部分，並清楚說明缺少了什麼。1415上下文：16[在此貼上帶有來源標籤的檢索區塊]1718問題：19[使用者的問題在此]
那個「當你不知道時，準確地說出這句話」的指令發揮了巨大作用。這是減少檢索系統中幻覺最有效的方法，因為它給了模型一個被認可的方式來承認無知，而不是為了顯得有幫助而編造答案。
你的 RAG 建置
使用一個框架來整合這些元件，而不是從頭開始建立每一個部分。
對於你的第一個 RAG 系統，我的推薦是 LlamaIndex，它是以搜尋為優先來設計的，能讓你用少量的程式碼就建立起一個可運作的流程。
LangChain 是另一個主要的選擇，它在接下來要討論的多步驟 Agent 工作中表現更出色，所以你很快就會接觸到它。
你的建置目標，這是一個真正的作品集項目：一個「與你的文件聊天」的應用程式。
匯入 10 到 20 個 PDF 或文字檔（你自己的筆記或一組產品文件都很適合），建立一個能接受問題、檢索最相關的區塊（使用重新排序），並回傳附有引用的答案的系統。
為它加上一個簡單的介面。
這個專案會讓招募主管認真看待你，因為這正是現在許多公司付費請人建立的東西。
Agent
在這個月的中間，轉向 Agent。
Agent 聽起來像魔法，但一旦你看到它，就會發現它其實很簡單：它是一個循環，模型在其中反覆決定下一步、使用工具執行該步驟、查看結果，然後再次決定，直到任務完成。
心智模型：一個 Agent 就是一個 while 迴圈，由模型來做出分支決策。
思考發生在提示詞中。分支是模型選擇使用哪個工具。執行是你的程式碼執行該工具。
其他的一切都是管線。一旦你理解了這一點，即使是複雜的 Agent 框架也變得容易理解。
我的推薦，而且我會建議你在寫任何一行 Agent 程式碼之前先閱讀它：Anthropic 的「建立有效的 Agent」。
這是關於 Agent 如何在實務中運作最清晰的論述，來自於建立這些模型的團隊。
當你準備好要建置時，再搭配一個實作框架課程，例如 LangGraph 的介紹，這是最廣泛用於編排 Agent 的框架。
你需要專注的重點：感知、決策、行動、觀察的循環，以及它如何知道何時停止。
當工具呼叫在循環內失敗時會發生什麼事。如何編寫模型能夠實際使用的工具描述，因為描述模糊的工具會被錯誤呼叫或被忽略。
以及管理狀態，這是 Agent 在工作時流經的共享記憶體。
這個月最有價值的練習：完全不使用任何框架，僅直接使用模型 API，從頭開始建立一個小型 Agent。
給它三個工具、一個目標和一個循環。這會教你框架隱藏了什麼，並讓你之後接觸的任何框架都變得有意義。
在你接觸 LangGraph 之前，先做這個練習。
何時不該使用 Agent
這是該領域中最容易被忽略的技能之一，了解這一點標誌著你是一個有判斷力的人，而不是一個盲目追逐新潮事物的人。
Agent 很令人興奮，但它們也比更簡單的方法更慢、更昂貴、更不可預測、更難除錯。
選擇最簡單且有效的方法，是你知道自己在做什麼的標誌。
值得記住的決策框架：如果任務可以在一個提示詞中配合正確的上下文完成，就使用單一模型呼叫。
如果步驟是可預測的，就使用固定的工作流程，即你定義的一系列步驟。
只有在步驟數量真正不可預測，且需要模型動態決策時，才使用 Agent。
一個由三個固定呼叫組成的鏈，永遠比一個可能進行三次呼叫的 Agent 更快、更便宜、更容易除錯。將 Agent 保留給真正開放式的任務。
在單一呼叫和完整的 Agent 之間，存在一個廣大且富有成效的中間地帶：工作流程。
鏈式呼叫，一個呼叫的輸出餵給下一個。
路由，你對輸入進行分類並將其發送給專門的處理器。
平行化，你同時執行多個呼叫並組合結果。
大多數真實世界的問題最適合用工作流程而非 Agent 來解決，而 Anthropic 關於 Agent 的文章很好地涵蓋了這些模式。
評估，簡要但認真地
你需要知道你的系統是否真的有效，而不僅僅是在你手動測試的兩個範例上有效。
這就是評估的目的。建立一個包含 20 到 30 個代表性輸入的小型集合，並附上預期輸出或評分標準，然後每當你更改提示詞、更換模型或調整檢索時，就用你的系統對所有輸入進行測試。
像 DeepEval 這樣的通用工具，以及專門用於 RAG 的 Ragas，能讓這個過程易於管理。
比工具更重要的是心態：你在沒有執行評估的情況下所做的每一次提示詞更改或模型更換，都是一場賭博。
那些發布可靠 AI 產品的人會持續執行評估，而現在開始養成這個習慣，即使只是小規模地進行，也能讓你領先許多已經在該領域工作的人。
第三個月里程碑
到這個月底，你應該能夠解釋什麼是嵌入以及為什麼相似的文字會產生相似的向量、合理地分割文件、在向量資料庫中儲存和查詢嵌入並使用元數據過濾、加入重新排序以改善結果、除錯檢索失敗而不是責怪模型、建立一個完整的 RAG 流程來回傳 grounded 且有引用的答案、從頭開始實作一個 Agent 循環、正確判斷一個任務需要單一呼叫、工作流程還是 Agent，以及執行基本的評估來檢查你的工作。
這就是有就業競爭力的核心。
如果第一個月到第三個月都紮實，你就能建立公司正在招聘的系統。
第四個月是關於證明這一點並獲得報酬。
第四個月：發布、展示、獲得錄用
你這個月的目標：將你建立的一切變成真實可用的東西，然後將其轉化為一份工作或有償工作。
這是大多數人停滯不前的地方。
他們可以建立一個展示用的原型，但無法發布一個能經得起真實使用的產品，也無法將他們的技能轉化為收入。
這個月將解決這兩個問題。它包含的新概念較少，而更側重於執行，因為在這一點上，執行才是最重要的。
足夠讓你上線的部署知識
你不需要成為基礎設施專家。
你需要能夠將一個可運作的 AI 應用程式放到某個真實的人可以使用的地方，而且它不會崩潰或讓你破產。
最低限度的必要知識：學習足夠的 Docker 知識來打包你的應用程式，讓它在任何地方都能以相同方式執行，這解決了「在我機器上可以跑」的問題。
學習將該容器部署到某個地方。
並學習成本和可靠性的基礎知識，以防止一個小錯誤變成災難：在你的 API 帳戶上設定嚴格的支出限制、加入快取機制以避免為相同的請求支付兩次費用，以及加入速率限制以防止單一使用者耗盡你的預算。
Docker 的官方入門指南涵蓋了打包的部分。
針對 AI 特定的成本方面，核心做法是快取相同的請求、在夠用的情況下使用較便宜的模型，以及設定一個嚴格的每月支出上限，這樣一個失控的循環就不會讓你在一個晚上損失 500 美元。
你還需要基本的可觀測性，這是一個花俏的詞，意思是能夠看到你的應用程式在做什麼。
LLM 應用程式有一個特定的問題：模型可以回傳一個完全成功的回應，但同時也是無用或錯誤的，而一般的監控工具無法捕捉到這一點。
像 Langfuse 這樣的工具會追蹤每一次模型呼叫，向你顯示提示詞、回應、token 成本和延遲時間，這使得除錯和成本控制變得容易許多。
在一個專案上設定好這個工具，以便你理解這個模式。
不要在這一點上過度投資。
一個應用程式，正確部署，並配有成本控制和基本的追蹤，就能教你所需的一切，並給你一些真實可展示的東西。
部署的深度可以在工作中學習。
其他所有路線圖都跳過的部分：將專案轉化為工作。
你已經建立了三個真實的專案。現在讓它們為你效力，因為一個沒人看到的偉大專案對你的職業生涯毫無幫助。
你的作品集是三個已部署的專案，每個都附有一個能發揮實際作用的 README。
而這裡有一個幾乎沒有人會做的關鍵動作，它將讓你脫穎而出：在每個 README 中，加入一個關於哪裡出了問題以及你會如何做得不同的章節。
大多數作品集假裝一切都很順利，這讀起來要不是不誠實，就是膚淺。
一個寫著「這裡是我的第一個方法失敗的地方，這是我學到的教訓，這是我如何修正它的」的 README，正好傳達了雇主們說他們現在正在篩選的那種判斷力。
這就是引言中提到的轉職者優勢，現在變得清晰可見。
沒有人期望一個轉職者擁有完美的專案。他們會對一個能深刻理解自己作品、足以提出批評的人印象深刻。
像這樣組織每個 README：專案解決的問題、誰會使用它、你採用的方法及其原因、哪裡出了問題以及你學到了什麼，以及如何執行它。
五個章節。
這比大多數擁有電腦科學學位的人的作品集還要好。
履歷和個人資料的調整：你不需要假裝擁有多年經驗。
你需要一行清楚的敘述，說明你能做什麼。
像是「我建立生產級的 LLM 應用程式：RAG 系統、Agent 和 API 整合。這裡有三個我已經發布的專案。」
然後連結到這些專案。你現有的職業生涯是一項資產，而不是需要隱藏的東西。
「前 [你的領域] 專家，現為 AI 系統建置者」是一個比「初級開發者」更強而有力的故事，因為它帶來了純粹的初級開發者所缺乏的領域知識和判斷力。
如果你從金融業轉職，你了解 AI 能解決哪些金融問題。
如果你從醫療保健業轉職，道理相同。善用你的背景。
公開打造作為你的管道： 在整個月裡，持續發布你正在建構的內容和你學到的東西。
我看過最好的機會，都降臨在那些勇於曝光的人身上，而不是那些默默投了 500 份履歷的人。
把你的專案寫下來。分享你修正過的錯誤。複利效應是真實存在的，而且現在你已經有實際的作品可以分享，這比在第一個月時容易多了。
選擇一個方向
到了第四個月，你可以將你的技能導向任何符合你目標的方向。有三個方向，選一個深入鑽研，而不是分散精力。
AI 產品工程師路線，最適合想快速找到新創公司工作的人： 你打造的是能讓真實用戶使用的 AI 驅動產品。
你從第一個月到第三個月已經具備了大部分所需技能。
更深入地學習建構完整、精緻的應用程式，以及產品端的知識，也就是應用程式如何處理模型出錯的情況、如何顯示載入狀態、以及用戶如何提供回饋。
推出兩到三個人們真正可以試用的東西。
應用機器學習路線，最適合想要更深層技術職位的人： 超越 API 呼叫，進入微調（fine-tuning）的領域，了解何時該微調而非只是改善提示詞（prompt）、使用像 Ollama 這樣的工具在本地端執行開源模型，以及推論最佳化。
要記住的決策框架： 從提示詞工程開始，如果模型需要你的特定數據，再加入檢索增強生成（RAG），只有在提示詞工程和 RAG 都確實無法達到你所需的品質時，才進行微調。
微調往往太早被採用。
AI 自動化路線，最適合想立即從企業賺到錢的人： 專注於自動化真實的商業工作流程，將 AI 串聯到電子郵件、CRM、文件和試算表等工具中。
像是 n8n 這類工具適合視覺化工作流程，而 LangGraph 則適合需要大量程式碼的工作流程。
這裡有一個可以銷售的建構項目： 一個潛在客戶資格審核系統，它能匯入潛在客戶，使用模型來研究並為每個客戶評分，草擬個人化的外聯郵件，並記錄所有活動。
企業願意為此支付真金白銀。
第四個月的里程碑
到這個月底，你應該要有一個已部署的 AI 應用程式，並具備適當的成本控制機制、三個作品集專案（每個都附有誠實的 README 檔案）、一個清晰的一句話自我介紹來說明你建構的內容、一條公開可見的工作軌跡，以及一個你選擇要深入鑽研的方向。
到了那個時候，你就不再是「正在學習 AI 的人」。你是能夠交付 AI 系統的人，而這正是市場願意付費的對象。
誠實的一面
我一開始就告訴過你，我不會賣給你一個幻想，所以在談到薪資數字之前，先給你最直接的版本。
四個月的專注工作能讓你有能力勝任初階職位，或準備好接自由接案的工作。這並不能讓你成為資深工程師。
資深工程師來自於多年在真實限制下交付真實產品的經驗，沒有任何指南能壓縮這個過程。
四個月的時間能帶給你的，是建構、交付和部署能解決真實問題的 AI 系統的能力，這是一個真正有價值、也真正能被僱用的狀態。
這一切的前提是付出實際努力，大約每週 15 到 20 小時，真正動手建構，而不只是觀看。
如果你每週只能投入 7 小時，那麼這會是一條八個月的路徑，而這也完全沒問題。
時間線會拉長，但終點不會改變。讓人失敗的不是緩慢的步調，而是停滯不前。
在這裡，持續性每次都勝過強度。
而這一切都建立在「錯誤」章節中提到的一個行為上：動手建構，不要只是觀看。
每個月都有一個專案。去完成這些專案。一個在四個月內建構了四個粗糙專案的人，是能被僱用的。
一個看了四個月完美教學影片的人，則不會。這就是整個遊戲的關鍵。
關於薪資，附上來源
現在來談你真正想知道的數字，全部都是最新的且有來源，因為隨意宣稱薪資範圍會讓這些指南失去可信度。
截至 2026 年 6 月，Glassdoor 數據顯示美國 AI 工程師的平均薪資約為 143,500 美元，典型的範圍大約是第 25 百分位的 115,000 美元到第 75 百分位的 181,000 美元，而頂尖收入者據報導可達約 223,000 美元。
資深 AI 工程師的平均薪資約為 285,000 美元，典型範圍大約是 221,000 美元到 375,000 美元，這顯示了當你擁有真實經驗後，薪資會有多大的跳躍。
這些是 Glassdoor 根據提交的薪資數據得出的數字。
負責招募真正從事 AI 生產工作人才的獵頭表示，中階基礎薪資集中在 155,000 美元到 200,000 美元之間，這是基於已簽署的錄取通知書而非調查數據，這與 Glassdoor 的範圍相符，為你提供了第二個獨立的參考。
以及我開頭提到的 PwC 2026 年晴雨表所呈現的更廣泛市場背景： AI 技能相關職位的增長速度約為整體市場的八倍，AI 技能享有 62% 的薪資溢價，而學歷要求在這些職位中的下降速度最快。
這些不是來自於誇大其詞的貼文。它們來自於對超過十億個職位廣告的分析。
自由接案和顧問工作的收入差異太大，無法在不誤導你的情況下精確報價，所以我只會說： RAG 實作、Agent 建構和 LLM 整合的收費標準很高，一個擁有三個紮實部署專案和清晰自我介紹的轉職者，在他們獲得全職工作之前，就可以開始為這類工作收費了。
這些專案就是證明。把它們建構出來，賺錢的機會就會出現。
本週就開始
以下是我如果是你，今天實際上會做的事情。
選擇第一個月的那個 Python 專案，那個小小的命令列工具。打開一個程式碼編輯器。
開始做 CS50P 的第一個問題集。設定好學習夥伴提示詞，讓 AI 在你遇到困難的部分指導你。
建立一個 GitHub 儲存庫，並把你第一個很醜的檔案放進去。這就是整個第一週要做的事。
不要等到你覺得準備好了才開始，因為「準備好了」是在你開始之後才會出現的，而不是之前。
不要在你寫下一行程式碼之前，就把未來四個月的完美細節都規劃好，因為計畫已經在這裡了，而規劃本身只是一種讓你舒適地逃避開始的方式。
學習和建構之間的差距，是人們浪費一年時間的地方。本週就把它填補起來。
四個月的實際工作，真的能改變你的可能性。
這扇門比以往任何時候都更加敞開，學歷門檻正在降低，而市場為這些技能支付的報酬，幾乎比科技業中任何其他技能都高。
你已經有了這份指南。剩下的唯一變數就是，你是否要動手建構。
把這份指南儲存起來，每個月回來參考一次。我會隨著工具和數字的變化持續更新它。
追蹤 @free_ai_guides 以獲取最新資訊 ❤️
