Prompt 工程薪水靠系統才會漲

我拆 2026 prompt engineering 薪資指南，直接對照角色、技能、RAG、評估與可複製的職涯路線。

我盯 prompt engineering 這件事一陣子了，老實說，一開始我也覺得它很飄。今天大家在講「寫得好一點」，明天又變成「你要會 RAG、evals、Python、agents，最好還懂系統設計」。這不是職缺描述，這比較像一張一直被改的考卷。更煩的是，薪水也跟著亂跳：有些公司把它當獨立職能，有些直接塞進 ML、產品或內容團隊，然後假裝沒事。

我讀了 Affordable AI 的 2026 prompt engineering 薪資指南，想看它到底是在講真話，還是在重複那種「AI 很熱所以什麼都值錢」的老梗。結果我發現它的重點其實很直白：錢不再來自「會寫 prompt」，錢來自你能不能把 prompt 周邊那堆系統一起做起來。

先把話講死一點：如果你還把 prompt engineering 想成聊天框技巧，你大概已經慢半拍了。這份指南沒有假裝自己是嚴謹薪資調查，它比較像一份實戰型地圖，告訴你角色怎麼分、技能怎麼升、薪資怎麼往上走。我下面會照這個脈絡拆開講，順便把我自己看完後覺得最值得抄的部分整理出來。

我也先提醒一句，這份文章沒有提供完整方法論或樣本設計，所以它不是那種可以拿來當統計證據的東西。它比較像市場訊號：當你能碰 API、評估、RAG、automation，薪資帶就會換一個檔位。這才是我覺得有用的地方。

薪資數字不是重點，工作邊界才是

“The role has shifted from writing prompts to building and maintaining the systems that power them.”

這句話翻成白話就是：prompt engineering 已經不是純文字修修補補，它正在變成「帶 AI 的應用工程」。差很多。前者像是在調語氣，後者是在做系統。

指南一開始就把市場切成兩種：一種公司把 prompt engineering 當成明確職位；另一種公司把它塞進既有職能裡，然後希望大家都別追問薪資怎麼算。我看過這種戲碼太多次了。以前是 DevRel、growth engineer、solutions architect，現在只是輪到 AI 相關職稱在玩同一套。

所以我現在看這類職缺，第一個問題不是「叫什麼名字」，而是「你到底要我負責到哪裡」。如果你只是幫內容團隊調 prompt、看輸出、修句子，那通常還在比較低的薪資帶。可是一旦你開始接 API、寫測試、接 retrieval、做 failure handling，工作性質就變了，錢也會跟著變。

指南提到印度市場常見的基礎帶大概落在 ₹4 lakh 到 ₹10 lakh，平均約 ₹5 lakh 到 ₹6 lakh。這不是什麼神諭，但至少它說明一件事：只靠 prompt 本身，薪資天花板不高。真正的差別在你能不能把 prompt 變成可維護、可測試、可部署的東西。

• 只會調 prompt，通常還在入門或偏低階帶。
• Prompt 加 automation，才開始像中階技能。
• Prompt 加系統 ownership，才真的接近高薪區。

實操上，我會建議你先把問題改寫成：「我現在做的是 prompt writing，還是 prompt systems？」這句一改，很多薪資期待會自己校正。

新手拿的是潛力，不是魔法

指南給 freshers 的範圍是 ₹3 lakh 到 ₹5 lakh，junior roles 大概落在 ₹5 lakh 到 ₹10 lakh。聽起來不豪華，但其實很合理，因為公司在這個階段買的不是神技，而是可塑性：你能不能學得快、講得清楚、在模糊需求裡做出可重複的東西。

我一直覺得 entry-level 的 prompt work 被講得太玄了。真正有價值的不是「你很會跟 AI 講話」，而是你能不能把一個模糊需求整理成固定流程，然後把輸出差異說明白。這種人比會背一堆 prompt 技巧的人更值錢，因為前者能進工作流，後者通常只會在 demo 時發光。

我之前幫一個團隊做內部 assistant prototype，最後表現最穩的不是那個最會喊 AI 的人，而是能把 prompt 版本整理好、把輸出差異記下來、再說清楚為什麼某個指令順序會少掉 hallucination 的工程師。這種人不一定華麗，但很省時間。

指南提到基礎 prompting、ChatGPT 和 Claude 的熟悉度、以及對 LLM 基本原理的理解。我同意，但如果我是主管，我還會多看三件事：你會不會做紀錄、看不看得出失敗模式、能不能把實驗寫給非技術同事看懂。這些東西很土，但很值錢。

實操上，別再做那種「我整理了 100 個酷 prompt」的作品集了。那東西很像在展示收藏癖，不像在展示能力。你應該做的是一個小型測試框架、一個前後對照案例，或一個只解決單一痛點的小工具。

• 每個 prompt 流程都留版本紀錄。
• 每個任務準備 10 到 20 筆測試案例。
• 把失敗模式寫出來，不要只寫成功案例。

Python 一出現，薪資就開始像工程師

這份指南最有價值的地方，不是薪資表本身，而是它偷偷點出一條分水嶺：只要職缺開始要求 Python、API、evaluation、RAG 或 workflow automation，薪資就會往上跳。這個訊號很重要，因為它代表工作內容已經不是「改字」，而是「做系統」。

Python 一出現，你就不再只是調整指令，而是開始處理 model call 週邊的事情：抓 context、轉換輸入、驗證輸出、失敗重試、依規則路由請求。這些動作的價值比單純改 prompt 高很多，因為它們能擴展、能維護，也能交給別人接手。

指南把 1 到 3 年經驗的角色拉到 GenAI engineer、LLM engineer，技能列得很清楚：RAG pipelines、agentic workflows、Python scripting、system design。講白了，市場已經在告訴你：職稱可能還叫 prompt engineer，但工作內容已經往「帶 AI 的軟體工程」靠攏了。

我看過不少團隊把這件事做歪。先找一個人來「優化 prompts」，然後很自然地把 API、retrieval、eval script 全丟給他，最後整個職位變成輕量 AI engineer。公司如果夠成熟，薪資會跟著工作範圍調整；公司如果不成熟，你就會在同一張名片下做三種職務。

實操上，我建議你至少把 Python 練到能做這幾件事：呼叫模型 API、讀資料、跑測試、存結果。你不用立刻變成後端純血，但你一定要能從「在瀏覽器裡打 prompt」升級到「做可重現的 workflow」。

如果你要找練習入口，我會直接看 OpenAI API docs、Anthropic docs，再搭一個 workflow 工具像 n8n 或 Zapier。工具不是重點，重點是你得離開一次性 prompt 的習慣。

RAG 不是加分題，是基本功

指南把 Retrieval-Augmented Generation 當成薪資加速器，我完全同意。RAG 這件事一進來，prompt engineering 就不再可愛了，因為你開始處理的是 knowledge plumbing，不是文字美化。只要你能把模型回答綁回真實文件，價值就會立刻變得可說服。

白話一點就是：模型不需要靠猜。它可以先抓外部 context，再根據資料回答，還能保留來源。對企業內部知識、客服、法務、稽核這種場景來說，這不是錦上添花，這是能不能上線的差別。

我看過太多團隊卡在「答案不夠好」這種表面問題，拼命改 prompt，結果真正的病灶是 context 根本沒餵對。RAG 進來之後，問題會從「怎麼修句子」變成「怎麼把知識流接好」。這才是工程問題。

指南說 RAG 已經不是嚴肅角色的可選項，我認同。你如果能設計 retrieval pipeline、處理 chunking、管理 citation、測試模型到底有沒有用到檢索內容，你的薪資位置就會比只會 prompt wording 的人高一截。

實操上，我會要求自己做一個完整的小 RAG 專案：用公開文件集、vector store、簡單查詢介面，然後測 groundedness、citation quality、answer drift。這一個專案比看十篇 prompt hacks 文更有用。

• 拿真文件做，不要只用玩具例子。
• 量化 retrieval 有沒有真的改善答案。
• 故意拿掉正確 context，看系統會不會亂講。

評估能力才是公司真正買單的東西

我最想偷走指南的一句話，是它把 evaluation 擺到很前面。不是 prompt writing。是 evaluation。這很重要，因為公司不會為「感覺比較好」付錢，公司只會為「我知道它真的比較好」付錢。

白話講，能解釋為什麼 prompt 失敗的人，比只會把 prompt 改得更順的人值錢。你如果能建 test set、做 scoring rubric、抓 hallucination、比較不同版本的輸出，那你做的就是工程，不是玄學。

我參加過太多 AI review，最常聽到一句話就是「這次模型感覺更好」。這句話基本上等於紅燈。更好是跟誰比？在哪些 case？錯誤率多少？在什麼限制下？如果你答得出來，你就會變成那個大家在 demo 前會先找的人。

指南提到 groundedness check 和 rubric-based assessment，這方向是對的。我會再補一個原則：評估要無聊、要可重複。漂亮 dashboard 很爽，但很多時候，一份規則清楚的 spreadsheet 比酷炫介面更能抓出問題。

實操上，直接做一組 20 到 50 筆測試題，包含容易題、邊界題、髒題。每次改 prompt 或 pipeline，都重跑一次，並且固定看 correctness、completeness、groundedness。這樣你才知道自己是在進步，還是在自嗨。

如果你想找現成的術語和架構參考，可以看 LangChain 和 LlamaIndex。我不是說你一定要用它們，我是說它們至少能幫你跟面試官講同一種語言。

高薪通常是因為你扛整包，不是因為你會一招

指南把 senior range 拉到 ₹20 lakh 到 ₹40 lakh+，AI Architect / GenAI Lead 甚至到 ₹50 lakh 到 ₹1 crore+。數字看起來很猛，但邏輯其實很單純：位置越高，你負責的不是 prompt，負責的是整個系統的可靠性、成本、安全和部署。

到了這一層，你要回答的問題會很煩：這功能為什麼這麼貴？模型掛掉怎麼辦？誰審輸出？怎麼防止亂答？供應商改價怎麼處理？這些都不是 prompt 技巧題，而是產品、平台、營運一起來的題目。

所以我才說，這個職位越往上，越像產品與平台領導。薪資跳上去，不是因為你會更會寫字，而是因為你開始承擔 ownership。公司買的是責任，不是花招。

我也看過很多人卡在這裡，原因很簡單：他們一直待在 chat UI 的世界裡。如果你的心智模型還停在「輸入 prompt、拿到答案」，你就很難進入架構討論。你得開始理解 data flow、fallback、cost control、monitoring，不然你只是很貴的 prompt tester。

實操上，從現在開始用系統思維問自己：輸入從哪來、輸出怎麼檢查、log 留在哪裡、失敗怎麼處理、誰負責整個生命週期。你如果能把這條線畫出來，基本上就已經在往 senior 走了。

職稱只是表面，範圍才是本體

指南列的路徑是 AI content assistant、junior prompt engineer、GenAI engineer、LLM engineer、AI lead、GenAI architect。我覺得這順序不錯，但我更想把它翻成一句更實際的話：你不是在升職稱，你是在擴大工作範圍。

也就是說，你先處理語言，再處理 workflow，接著處理系統，最後處理 ownership。職稱會變，是因為你碰到的面積變大了。當你的工作影響更多使用者、更多資料、更多金錢、更多風險，薪資就應該跟著上去。

所以這份指南對薪資成長的建議其實很務實：做可量化專案、展示商業結果、把 evaluation 學深、往端到端應用靠。這些不是勵志文案，這些是讓你在招聘市場上變得可讀的行為。

我再補一條很現實的：你的作品集要像 production thinking，不要像作業。只有 prompt snippets 的 GitHub repo 很弱；有 test harness、retrieval layer、eval 結果、再加一份講 tradeoff 的 README，這就像真的在做工程。面試官一看就知道你不是只會玩。

實操上，我會建議你選一條路，然後讓它看起來很明確。如果你想留在內容附近，就專精 marketing 或 support 的 prompt systems；如果你想拉高薪資，就往 Python、API、retrieval、deployment 靠；如果你要走管理或 lead，就把 cost、safety、evaluation 學到能講清楚。

可抄的模板

# 2026 Prompt Engineering Career Plan

## 目標職位
我想要的角色：［Junior Prompt Engineer / GenAI Engineer / LLM Engineer / AI Lead］

## 薪資目標
我目前想對齊的薪資範圍：［填入你所在市場的區間］

## 要補的技能
- Structured prompting 與輸出格式控制
- Python：API 呼叫、資料處理、automation
- RAG 基礎：chunking、retrieval、citation
- Evaluation：測試集、rubric、groundedness
- 產業知識：［你的領域］

## 作品集專案
1. 一個 prompt 版本控制與測試筆記本
2. 一個用公開文件做的小型 RAG assistant
3. 一份 evaluation set 與 scoring rubric
4. 一個用 n8n、Make 或 Zapier 做的 workflow automation

## 面試時能拿得出手的證據
- 改版前後的輸出對照
- 我找到並修掉的 failure modes
- 量化改善：［accuracy / latency / cost / groundedness］
- 一個可看的 GitHub repo 或 demo 連結

## 四週執行表
### 第 1 週
- 學會一個 API 並完成一次 model call
- 寫 10 個測試 prompts

### 第 2 週
- 做一份簡單的 evaluation sheet
- 比較兩個 prompt 版本

### 第 3 週
- 接上一個文件來源做 retrieval
- 量 groundedness 和 citation quality

### 第 4 週
- 自動化一個可重複流程
- 寫一篇短 case study，交代結果與取捨

## 面試故事模板
我的最佳案例是：
- 問題：［原本卡在哪裡］
- 作法：［我改了什麼］
- 結果：［哪些指標變好］
- 取捨：［我放棄了什麼］

## 履歷一句話
Built and evaluated prompt-driven AI workflows using Python, APIs, and RAG to improve output quality and reduce manual effort.

上面這段是我把原始指南整理成比較能直接拿去用的版本。它是衍生整理，不是原文照抄；結構和文字是我重寫的。你可以先把方括號填掉，再把你自己的專案數字補進去，這樣才像真的。

原始來源在這裡：Affordable AI 的 2026 prompt engineering salary guide。我另外參考了 OpenAI、Anthropic、n8n、LlamaIndex 的官方文件，因為這份指南真正指向的不是 prompt 本身，而是 prompt 背後那整套系統。