如果把生成式 AI 的發展濃縮成一個畫面，那大概是這樣：最初，人們像在敲一扇陌生的大門，試著用不同語氣、不同句型、不同順序，看看門後的模型會不會多開一點。

這條路，就是 Prompt Engineering 的路。

它起初看起來像技巧，後來變成顯學，再後來又被許多人宣告「已經過時」。但如果把時間線拉長、把賽道看寬，你會發現：Prompt Engineering 從來沒有真的消失，它只是從舞台中央退到系統深處，從「會寫 prompt 的人」變成「會設計人與模型介面的人」。

這篇文章想做的，不是給你一份提示詞大全，而是回答三個更根本的問題：

• Prompt Engineering 是怎麼來的？
• 它為什麼會在 2022 年之後爆紅？
• 到了 2025、2026 年，為什麼大家又開始說它不夠了，甚至要改叫 Context Engineering？

一、縱向分析：Prompt Engineering 不是從 ChatGPT 開始的

1. 在它有名字之前，人們早就在「提示」模型

如果只看大眾印象，Prompt Engineering 好像是 ChatGPT 之後才出現的新職業、新能力。但從技術史來看，它的根其實埋得更早。

在早期 NLP 時代，模型通常是「一個任務、一套模型、一個訓練流程」。你做情感分析，就訓練一個情感分析模型；你做翻譯，就訓練一個翻譯模型。那時候，研究者當然也會設計輸入格式，但「如何把任務包裝成一句話」還不是主角。因為模型本身不是通用介面，而是特定任務機器。

轉折來自 Transformer 時代。當模型規模開始變大，尤其是 GPT 系列、T5 一類工作出現後，研究圈逐漸意識到：很多下游任務，其實都能被改寫成文字到文字、填空、或自然語言指令的形式。也就是說，輸入不只是資料，它本身開始承擔「告訴模型要做什麼」的功能。

這是一個很重要的觀念變化。它把原本分散在「資料前處理」「模板設計」「few-shot 示例編排」裡的做法，慢慢推向一個新方向：模型能力不只來自參數，也來自你怎麼問它。

這時候的 Prompt Engineering 還不是大眾理解的「寫一句魔法咒語」，而更像是一種研究方法。研究者在問的問題是：如果不改模型權重，只改輸入形式，能不能把預訓練模型的潛力更好地調出來？

後來的事證明，答案是可以。

2. 2020：GPT-3 把 prompt 從配角變成主角

真正讓 Prompt Engineering 脫離學術邊角、成為主線敘事的，是 2020 年的 GPT-3。

GPT-3 的關鍵，不只是參數變成 1750 億，而是它把「few-shot learning」變成了一件可以被廣泛感知的事：你不一定要重新訓練模型，只要在輸入裡放幾個例子、講清楚格式，模型就可能學會這個任務。這是很強烈的範式轉移。以前你要改模型；現在你可以先改提示。

從決策邏輯看，這一點會成立，不只是因為模型夠大，也是因為產業條件成熟了。大模型的訓練成本已經高到不是一般團隊可以承受，API 服務模式又開始成形。這意味著，對多數開發者和企業而言，「不動模型，只調用模型」不是權宜之計，而是唯一可行路徑。Prompt 因而成了最便宜、最快速、最低門檻的控制層。

這裡埋下了 Prompt Engineering 爆紅的第一顆種子：當模型能力由訓練時轉移到推理時，控制權就從 ML 團隊的一部分，流向更廣泛的開發者、產品經理、內容工作者，甚至一般使用者。

但 2020 年的 Prompt Engineering 仍然有很強的實驗色彩。它還不像後來那麼制度化、商業化。更像是一批研究者與早期開發者共同摸索出來的「新手藝」：你要知道例子怎麼排、順序怎麼放、輸出格式怎麼限制、任務描述怎麼寫，才能把 GPT-3 的能力穩穩叫出來。

這種「模型很強，但不穩；能力很多，但難以穩定喚起」的狀態，恰恰是 Prompt Engineering 得以誕生的土壤。

3. 2021：Prompting 從技巧變成方法論

2021 年，Prompt Engineering 開始被系統化。幾篇關鍵研究把這個領域從「大家各自試」帶到「可以分類、可以比較、可以研究」。

這一年，prompt-based learning 的系統性綜述出現，學界開始把 prompting 看成一種新的學習範式，而不只是零散技巧。與此同時，AutoPrompt、LM-BFF、Prefix-Tuning、Prompt Tuning 這些方向，也讓「prompt」一詞出現分流：一部分是自然語言 prompt，另一部分是可學習的連續向量 prompt。前者比較接近今天大眾熟悉的提示詞；後者則往模型適配技術走。

這一年最值得注意的，不是某一個提示模板，而是這個問題意識終於被講清楚了： Prompt 不只是輸入文字，它是模型與任務之間的轉接器。

也因為如此，Prompt Engineering 開始呈現出兩條路。

第一條路是偏研究：怎麼讓 prompt 設計更穩定、更可自動化、更少依賴人工靈感。這條路催生了自動提示生成、提示選擇、提示優化等研究。

第二條路是偏產品：既然大模型可以用 prompt 做越來越多事，那是不是不需要為每件事都重訓一個模型？這條路把 prompt 從實驗室帶進了應用層，讓它逐漸成為 AI 產品的日常操作介面。

如果說 2020 年 GPT-3 讓大家看到「原來可以這樣做」，那麼 2021 年做的事，就是把這件事從驚奇變成框架。

4. 2022：思維鏈與 ChatGPT，Prompt Engineering 的雙重爆炸

2022 年是 Prompt Engineering 真正進入主流敘事的一年，而且是兩股力量同時推動。

一股力量來自研究突破。這一年，Chain-of-Thought（思維鏈）prompting 與 Zero-shot Chain-of-Thought 先後把整個領域往前推了一大步。它們最重要的貢獻不是告訴大家「一步一步想」很厲害，而是證明了：很多原本被認為是模型不會做的事情，其實只是沒有被適當引導。

這背後的決策邏輯很直白。研究者發現，模型在語言理解上已經很強，但在數學、多步驟推理、符號推演等「系統二」任務上，光靠擴大規模不夠。於是問題從「怎麼訓練更強模型」轉成「怎麼讓模型把已經有的能力以正確形式展開」。思維鏈就是這個時代的答案：不要只要答案，要模型展示中間步驟。

另一股力量則來自消費級產品的出圈：ChatGPT 在 2022 年底把 prompt 帶進大眾文化。

這個影響太大了。過去，prompt 是研究者或 API 開發者的工作材料；ChatGPT 之後，prompt 成了所有人都能直接操作的介面。你不需要懂梯度、不需要懂損失函數、不需要有 GPU。你只要打字，就能立刻感受到：同一個模型，問法不同，結果差很多。

於是 Prompt Engineering 在這一年突然有了兩個身份：

• 一個是技術身份：它是讓模型在複雜任務上表現更好的推理方法。
• 另一個是社會身份：它成了一種新型數位素養，甚至一度被包裝成新職業與新稀缺技能。

這也是為什麼 2022 到 2023 年初，網路上會出現大量「prompt 範本」「萬用提示詞」「角色扮演 prompt」「咒語式 prompt」內容。它反映的不是大家集體迷信，而是大模型第一次把「輸入形式本身會顯著改變能力表現」這件事，變成一般人可感知的經驗。

只是，這裡也種下了 Prompt Engineering 後來被反思的第一個原因：太多人把它理解成一種文字技巧，而不是系統設計問題。

5. 2023：從一句好 prompt，走向推理、行動與外部工具

如果說 2022 年是 Prompt Engineering 的民間爆紅期，那 2023 年就是它的工程化轉折期。

這一年最重要的變化，是人們開始意識到：單靠 prompt 很難把模型做成可靠產品。不是因為 prompt 沒用，而是因為任務變複雜了。你不再只是要它寫一篇文案，而是要它查資料、引用知識、呼叫工具、規劃步驟、跨多輪記住上下文，甚至執行任務。

在這個背景下，ReAct 和 Tree of Thoughts 這類方法特別重要。ReAct 把「推理」和「行動」交織起來，讓模型不只是想，還能去查、去做；Tree of Thoughts 則把單一路徑的思考，擴展成可探索、可回溯的多分支過程。兩者都反映出一個共同判斷： Prompt 不再只是讓模型回答得更漂亮，而是要支撐模型在複雜任務裡走得更遠。

同一年，RAG 逐漸成為企業導入生成式 AI 的主流方案之一。這也讓 Prompt Engineering 的角色開始變化。過去 prompt 的任務是「把問題說清楚」；到了 RAG 時代，它還要承擔「整合檢索到的上下文、限制回覆依據、安排輸出格式」的責任。

企業端之所以偏好這條路，原因很務實：比起重新訓練模型，RAG 更新更快、可追溯性更好，也更容易接上企業自己的知識庫。對多數組織來說，這比追求某個神奇 prompt 更接近可落地路線。

這一年另一個關鍵轉折，是「提示工程」開始長出「提示安全」這條支線。Prompt injection、jailbreak、間接提示注入等問題讓大家第一次真正看見：如果模型會把語言當指令，那麼語言就不只是介面，也是攻擊面。

這很關鍵，因為它把 Prompt Engineering 從效果優化問題，變成了可靠性與安全性問題。從此之後，好的 prompt 不再只是讓模型更聰明，也要讓系統更不容易被騙。

6. 2024：Prompt Engineering 成熟了，也開始遇到自己的天花板

到了 2024 年，Prompt Engineering 已經不是野路子了。OpenAI、Google、Anthropic 等公司都陸續把自己的提示設計原則、結構化輸出方法、角色層級、範例撰寫技巧、評估與版本管理方式，整理成官方文件。這件事本身就代表一個訊號：Prompt Engineering 不再只是社群口耳相傳的秘笈，而是一套可教學、可複製、可運維的實務。

但成熟，通常也意味著邊界開始清楚。這一年，大家越來越明白 Prompt Engineering 的優勢和缺點其實同樣明顯。

它的優勢是快。不用蒐資料、不用重訓、不用部署新模型，改一段提示就能立即驗證。 它的缺點也是快。因為太容易改，所以也太容易碎。模型版本一變、上下文一變、任務一變，原本有效的提示可能就失靈。OpenAI 官方開始強調要固定模型版本、建立 eval；Google 和 Anthropic 也都反覆提醒：提示設計是迭代過程，不是一次寫好永遠有效的指令。

這其實說明了一件事：Prompt Engineering 越成熟，就越不像文案，越像軟體工程。你需要版本管理、測試、監控、回歸驗證。真正困難的不再是「想出一個聰明 prompt」，而是「讓這組提示在產品裡持續穩定工作」。

同時，效率問題也浮上檯面。Prompt 越寫越長，成本越高；上下文越塞越多，效果未必越好。於是 prompt compression、自動 prompt optimization、長上下文管理等議題開始升溫。這代表 Prompt Engineering 進入了一個新階段：不是只追求有效，而是追求有效且可持續。

7. 2025 到 2026：Prompt Engineering 沒有死，它只是被重新放回系統裡

到了 2025 年，開發圈開始流行另一個詞：Context Engineering。

這個轉向不是否定 Prompt Engineering，而是補上它被過度簡化的部分。因為真正的生產級 LLM 應用，從來都不是只靠一句提示完成。它還需要對話記憶、檢索到的文件、工具說明、權限邊界、前一步結果、使用者狀態、結構化輸出要求、安全規則等等。換句話說，模型好不好用，往往不是取決於你最後打進去那一句話，而是取決於你在整個上下文視窗裡，放進了哪些東西、以什麼順序放、放多少、哪些該省略。

這就是「context engineering」被提出的原因。它試圖把 Prompt Engineering 從一種被誤解成「寫句子技巧」的東西，重新拉回系統工程脈絡。

這個轉向背後的邏輯非常清楚：

• 當模型本身越來越強，花拳繡腿式的 prompt hack 邊際效益會下降。
• 當應用從單輪問答走向多輪任務與 AI agent，真正的瓶頸會變成上下文組裝，而不是語氣修飾。
• 當安全風險升高，指令、資料、工具、權限之間的界線設計，比某句提示更重要。

但這裡有一個常見誤解需要拆掉： Context Engineering 並不是 Prompt Engineering 的競爭者，它更像 Prompt Engineering 的擴充版本。

如果說早期的 Prompt Engineering 關心的是「怎麼問」，那麼 2025 之後更成熟的問題其實是：「在這一輪任務裡，模型應該知道什麼、不應該知道什麼、先知道什麼、後知道什麼，以及知道之後可以做什麼。」

所以，Prompt Engineering 並沒有死。它只是失去了過度神話的位置，回到它真正應在的地方：成為整個 LLM 系統設計中的一個核心元件，而不是唯一元件。

二、橫向分析：Prompt Engineering 的「競品」其實不是 prompt，而是其他控制模型的方法

1. 先判斷競品場景：這其實是「場景 A：沒有單一直接競品」

如果研究對象是一家公司或產品，我們通常能拉出一串直接對手。但 Prompt Engineering 不是公司，也不是單一產品，它更像一種控制層方法、一種與模型互動的技術實踐。因此，嚴格來說，它沒有單一的直接競品。

它之所以「沒有直接競品」，不是因為它壟斷，而是因為它所在的位置太底層、太普遍。只要你在用大型語言模型，就幾乎一定會在某種程度上做 prompt 設計。問題不在「用不用」，而在「只靠它夠不夠」。

因此，與 Prompt Engineering 真正構成競爭關係的，不是另一種 prompt，而是其他達成相同目標的方法：也就是那些同樣想讓模型更準、更穩、更可控的路線。最有代表性的四條，是 Fine-tuning、RAG、Context Engineering，以及 Agent／Tool-use orchestration。

也就是說，Prompt Engineering 的橫向分析，應該看的是：當團隊想提升模型表現時，為什麼有時選 prompt、有時選檢索、有時選微調、有時乾脆做成工具鏈與代理架構？

2. Prompt Engineering vs Fine-tuning：一個改輸入，一個改模型

Fine-tuning 是最經典的替代方案之一。它和 Prompt Engineering 面對的是同一個問題：如何讓通用模型更像你要的樣子。但兩者下手位置完全不同。

Prompt Engineering 改的是輸入。 Fine-tuning 改的是權重。

這個差異決定了一切。

Prompt Engineering 最適合的場景，是需求變動快、試錯速度重要、資料不足、或還在探索 use case 的時候。它幾乎沒有前置成本，今天改、今天看結果。對新產品、POC、內容生成、內部原型來說，這種靈活性幾乎無可取代。

Fine-tuning 則適合另一種世界：任務穩定、資料足夠、風格明確、吞吐量大，而且你不想每次都把長篇規則塞回上下文。比如客服對話風格、固定格式抽取、特定領域文風、特定任務的高一致性輸出。這些場景靠 prompt 可以做到七八成，但要做到長期穩、平均成本可控、行為一致，微調往往更划算。

從使用者口碑來看，Prompt Engineering 常被稱讚「上手快、能立刻看到效果」，但也常被抱怨「很脆、很玄、難維護」。Fine-tuning 則剛好相反：它被認為更穩、更像正式系統，但需要資料治理、訓練管線、評估機制與持續維護，門檻高很多。

所以企業在兩者之間做選擇時，真正考慮的通常不是技術信仰，而是商業條件：

• 你現在是要快速找到答案，還是要把答案固化成長期資產？ 如果是前者，Prompt Engineering 幾乎總是第一步。 如果是後者，Fine-tuning 才有可能成為下一步。

換句話說，Fine-tuning 不是 Prompt Engineering 的淘汰者，而是它的後繼工法。很多成熟系統，往往也是先 prompt，後微調，而不是一開始就重訓。

3. Prompt Engineering vs RAG：一個負責表達意圖，一個負責補足知識

如果說 Fine-tuning 是從模型內部改變能力，那麼 RAG 代表的則是另一條路：不要把知識硬塞進模型裡，也不要假設模型本來就知道；需要時再把正確資訊拿來。

這對 Prompt Engineering 形成了很直接的替代效應。因為很多過去被認為要靠 prompt 解決的問題，後來都被證明其實是知識問題，不是表達問題。

舉例來說，一個客服機器人回答錯誤政策，不一定是因為 prompt 寫得不夠清楚，也可能只是因為模型根本不知道你公司的最新規則。這種情況下，再怎麼修 prompt 都是治標。RAG 的價值就在這裡：它把 prompt 的工作重新分工。Prompt 用來定義任務與格式；檢索系統用來供應事實。

從使用者與企業視角看，RAG 最大優勢有三個：可更新、可追溯、可接企業私有知識。這對金融、法務、醫療、客服、內部知識問答等場景特別重要。你不需要重訓模型，只要更新知識庫，就能讓回覆跟著變。

但 RAG 的痛點也很明確。它不只是把文件丟進向量資料庫而已。檢索策略、切塊方式、排序品質、上下文長度管理、回答引用約束，每一環都會影響結果。很多團隊一開始以為做了 RAG 就能自動提升正確率，後來才發現：檢索做不好，只是把錯誤從模型內部，搬到系統外部。

這也是 Prompt Engineering 在 RAG 時代沒有消失的原因。RAG 並沒有取代 prompt，而是把 prompt 從單獨作戰，變成與檢索共同作戰。真正好的 RAG 系統，幾乎一定也有精心設計的 prompt：它要告訴模型哪些內容是可依據來源、哪些規則必須遵守、回答要不要保守、格式要如何控制。

所以如果要一句話概括兩者差別，就是：

• Prompt Engineering 主要解決「你要模型做什麼」。
• RAG 主要解決「模型回答時根據什麼」。

在企業實務裡，RAG 對 Prompt Engineering 不是敵人，而是最常見的搭檔。

4. Prompt Engineering vs Context Engineering：這不是取代，而是升維

2025 年以後，最常被拿來和 Prompt Engineering 對照的，就是 Context Engineering。它之所以聲量變高，不是因為 prompt 突然失效，而是因為越來越多團隊做到了同一個結論：真正讓 LLM 應用成功的，不是 prompt 寫得多巧，而是上下文組裝得多準。

這裡的「context」不是單純多貼幾段文件，而是整個任務當下模型可見的一切：系統規則、使用者目標、前文記憶、工具說明、檢索片段、過往決策、限制條件、輸出 schema、安全邊界。Prompt 只是其中之一。

從技術路線看，Prompt Engineering 還是偏向單次互動最佳化；Context Engineering 更偏向多輪系統設計。 從產品形態看，前者像寫說明書；後者像安排整個工作台。 從使用者口碑看，前者容易上手但常常不穩；後者更接近真正可靠的產品能力，但系統複雜度明顯更高。

為什麼這條路在 2025 年後特別重要？因為 LLM 應用已經不只是聊天了。當你開始做 coding copilot、研究助手、企業流程代理、長文分析、多工具協作時，模型失敗的原因往往不在「你這句話不夠漂亮」，而在「你沒有把它該看到的東西放進去，或者放太多不該看的東西」。

也正因如此，Context Engineering 特別受到資深開發者與 agent builder 的青睞。它更像生產環境裡的真實工作描述。但它的代價是：你不能再期待靠幾句魔法咒語獲勝。你得面對記憶策略、上下文壓縮、權限控制、檢索品質、模型切換、評估與監控等一整套問題。

因此，Context Engineering 並不是 Prompt Engineering 的反對面，而是它在產品化世界中的自然外延。可以說：

• Prompt Engineering 是入門；
• Context Engineering 是進階。

前者教你如何對模型說話；後者教你如何替模型搭好說話的現場。

5. Prompt Engineering vs Agent／Tool Use：當模型不只回答，還要做事

還有一類「間接競品」更值得注意：Agent 與 Tool-use 架構。

當你希望模型不只是回答，而是能查資料、算數字、呼叫 API、操作系統、分解任務時，單靠 prompt 的邏輯就會不夠。於是，像 ReAct 這類方法興起，讓模型在推理與工具行動之間來回切換。再往後走，就形成各種 agent framework、structured output、function calling、workflow orchestration。

這些方法對 Prompt Engineering 的最大衝擊，在於它們改變了「好結果來自哪裡」的答案。早期大家覺得，好結果來自好 prompt。後來越來越多工程團隊發現，好結果其實來自「prompt + 工具 + 驗證 + 約束」。

例如：

• 一個需要精確計算的任務，你可以用 prompt 叫模型慢慢想，但更穩妥的做法通常是讓模型負責理解題意，再把計算交給計算器。
• 一個需要查法規的任務，也不該只靠 prompt 要模型「嚴謹一點」，而應該讓它去查知識庫。
• 一個需要發送郵件或執行流程的任務，更不應只靠 prompt 勸它小心，而是要透過工具權限與確認機制來保證。

從使用者體感看，這類系統的優點是「比較像真的在工作」，缺點則是「失敗模式更複雜」。它們可以比單純 prompt 更可靠，但同時也把安全風險、觀測難度、流程除錯難度一起放大。Prompt injection 在這個階段變得更危險，正是因為模型一旦能呼叫外部工具，語言錯誤就可能變成行動錯誤。

這也再次說明：Prompt Engineering 並沒有退出競爭，而是逐漸從前台主角，變成這些架構中的協調器之一。它還在，但不再單打獨鬥。

6. Prompt Engineering 今天的生態位：它仍然是入口，但不再是終點

如果把整個 LLM 應用版圖畫出來，Prompt Engineering 目前佔據的位置其實非常清楚：它是最便宜的控制層，也是幾乎所有團隊的第一步。這個位置很難被完全取代。因為不管你最後選 RAG、微調、agent 還是 context orchestration，你幾乎都會先從 prompt 開始試。它仍然是最好的探索工具、原型工具、對齊工具與教學工具。

但它不再是終點。當任務要求往上走，系統往往會沿著這條路徑演化：

1. 先靠 Prompt Engineering 驗證可行性；
2. 再用 RAG 補知識；
3. 再用工具與 workflow 提高可執行性；
4. 必要時再用 fine-tuning 固化穩定風格與行為；
5. 最後用 eval、安全機制與上下文管理把整套系統拉到可營運。

這就是 Prompt Engineering 目前最真實的生態位：

• 它不再是全部，但仍然是起點。
• 它不是獨占性優勢，卻是普遍必備能力。
• 它最擅長的，不是單獨決勝，而是作為整個 LLM 工程堆疊的前哨與協調層。

7. 趨勢判斷：Prompt Engineering 的機會與風險

如果只看社群風向，會很容易得到一個誇張結論：Prompt Engineering 已經過氣了。這種說法有一半對，一半不對。

對的地方是： 那種把 Prompt Engineering 想成「寫幾句神奇話術，就能駕馭模型」的版本，確實正在退潮。模型越來越強、工具越來越完整、自動優化越來越普及，單純靠 prompt trick 建立門檻會越來越難。

不對的地方是： Prompt Engineering 作為一種能力，反而變得更底層、更通用、更難被替代。因為只要人還需要把意圖、規則、格式、限制、上下文翻譯給模型，這門能力就不會消失。

未來幾年的機會大概會落在三個方向：

• 第一，多模態與跨工具場景。 文字 prompt 只是開始，圖像、文件、表格、語音、工具說明、操作流程都會變成新型 prompt 組件。
• 第二，企業級 PromptOps／LLMOps。 誰能把 prompt 納入版本管理、測試、監控、A/B 驗證與安全審查，誰才有能力把它從試玩變成生產力。
• 第三，領域化上下文設計。 未來真正值錢的不是會不會寫「你是一位專家」，而是你是否懂得把金融、法務、醫療、客服、研發等場景的知識、流程與風險，正確翻成模型可執行的上下文。

風險則同樣明顯：

• 第一，商品化。 越多模型原生支援結構化輸出、工具呼叫、長上下文與更強對齊，越多基礎 prompt 技巧會變成常識。
• 第二，自動化取代。 Prompt optimization、prompt templates、framework 預設、agent builder 工具，都會吃掉一部分手工提示設計的價值。
• 第三，安全與責任風險升高。 當 prompt 不只是文本，而是行動鏈的一部分，錯誤提示、被注入提示、模糊權限提示，都可能導致資料外洩或非預期操作。

因此，Prompt Engineering 未來最有前途的方向，不是更像文案，而是更像架構師。

三、橫縱交匯：Prompt Engineering 的真正故事，是它如何從「問問題」變成「設計介面」

回看這整段歷史，Prompt Engineering 最有意思的地方在於，它不是單純變強或變弱，而是不斷改變自己的角色。

最早，它是研究者對預訓練語言模型的一種試探。 到了 GPT-3，它變成能力介面。 到了思維鏈與 ChatGPT 時代，它變成全民顯學。 到了 RAG、ReAct、agent 和安全問題浮現之後，它又退回工程體系，成為系統設計的一環。 再到 2025、2026 年，Context Engineering 的興起，其實只是逼大家承認：Prompt Engineering 從來都不只是寫一句話，而是替模型安排工作現場。

這也正是它在橫向競爭裡的真實位置。它不像 Fine-tuning 那樣深改模型，也不像 RAG 那樣主打知識供應，不像 agent framework 那樣直接負責流程執行，更不像 security layer 那樣站在最後一道防線。它更像所有這些方法之間的翻譯層：把人的目標、制度的約束、資料的上下文、工具的規格，轉成模型能理解且願意遵循的形式。

所以，如果要對 Prompt Engineering 的未來做一個不誇張、但盡量準確的判斷，我會這樣說： 它不會消失，但會失去神話；它不再是單獨的明星技能，而會變成 LLM 時代的基礎工程素養。

未來真正有競爭力的人，不會只是會寫 prompt 的人，而是懂得何時該用 prompt、何時該上 RAG、何時該微調、何時該交給工具、何時該做權限與防護設計的人。也就是說，Prompt Engineering 的終點，不是成為咒語學，而是成為一種新的系統思維。

它最初讓人著迷的地方，是你只靠一句話就能撬動一個巨大模型。 而它最後真正有價值的地方，則是你終於知道： 一句話什麼時候夠，什麼時候根本不夠。

這，也許才是 Prompt Engineering 這門學問最成熟的時刻。

📚 資料來源

• Brown et al. (2020), Language Models are Few-Shot Learners: https://arxiv.org/abs/2005.14165
• Liu et al. (2021), Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing: https://arxiv.org/abs/2107.13586
• Gao, Fisch, Chen (2020/2021), Making Pre-trained Language Models Better Few-shot Learners: https://arxiv.org/abs/2012.15723
• Wei et al. (2022), Chain-of-Thought Prompting Elicits Reasoning in Large Language Models: https://arxiv.org/abs/2201.11903
• Kojima et al. (2022), Large Language Models are Zero-Shot Reasoners: https://arxiv.org/abs/2205.11916
• Zhang et al. (2022), Automatic Chain of Thought Prompting in Large Language Models: https://arxiv.org/abs/2210.03493
• Yao et al. (2022/2023), ReAct: Synergizing Reasoning and Acting in Language Models: https://arxiv.org/abs/2210.03629
• Yao et al. (2023), Tree of Thoughts: Deliberate Problem Solving with Large Language Models: https://arxiv.org/abs/2305.10601
• Schulhoff et al. (2024), The Prompt Report: A Systematic Survey of Prompting Techniques: https://arxiv.org/html/2406.06608v1
• Sahoo et al. (2024/2025), A Systematic Survey of Prompt Engineering in Large Language Models: Techniques and Applications: https://arxiv.org/abs/2402.07927
• OpenAI Developers, Prompt Engineering: https://developers.openai.com/api/docs/guides/prompt-engineering
• Google AI for Developers, Prompt Design Strategies: https://ai.google.dev/gemini-api/docs/prompting-strategies
• IBM, RAG vs. Fine-tuning vs. Prompt Engineering: https://www.ibm.com/think/topics/rag-vs-fine-tuning-vs-prompt-engineering
• Simon Willison, Prompt Injection 專題整理: https://simonwillison.net/series/prompt-injection/
• Yi et al. (2025), Benchmarking and Defending Against Indirect Prompt Injection Attacks on Large Language Models: https://arxiv.org/html/2312.14197v4
• Microsoft Security Response Center, How Microsoft Defends Against Indirect Prompt Injection Attacks: https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks
• Microsoft Security Docs, Defend Against Indirect Prompt Injection Attacks: https://github.com/MicrosoftDocs/security/blob/main/security-docs/zero-trust/sfi/defend-indirect-prompt-injection.md
• Stack Overflow, 2025 Developer Survey: https://survey.stackoverflow.co/2025/
• Stack Overflow Blog, Developers remain willing but reluctant to use AI: The 2025 Developer Survey results are here: https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/
• Kartik Mittal et al. (2024), Developer Challenges on Large Language Models: A Study of Stack Overflow and OpenAI Developer Forum Posts: https://arxiv.org/html/2411.10873v1
• GetZep Blog, What is Context Engineering, Anyway?: https://blog.getzep.com/what-is-context-engineering/