隨著生成式 AI 的應用日益普及，我們從最初學習如何寫出精準提示詞的「提示工程（Prompt Engineering）」，邁向了一個更宏觀、更具系統性的新階段——「上下文工程（Context Engineering）」。這個由前 Tesla AI 總監 Andrej Karpathy 提出的概念，正在重新定義人類與 AI 的互動模式。
從 Shopify CEO 到 LangChain 創辦人，各大科技領袖也都開始強調「上下文工程」的重要性。當軟體開發進入「Vibe Coding（氛圍開發）」時代，企業與個人該如何應對？
以下 Q 為《數位時代》創新長黃亮崢提問，A 為 AWS 社群英雄蔣鐙緯（Ernest）的回答，他將深入拆解上下文工程的核心架構「TPMR」，並探討如何透過建立領域知識與優化工作流，讓 AI 真正成為能解決問題的「新同事」。
Q1：上下文工程是什麼？它與提示工程有何不同？
A：過去一兩年，大家剛接觸 ChatGPT 時，關注焦點在於「提示工程」，也就是研究用什麼關鍵字、什麼咒語能讓 AI 給出正確答案。但隨著模型能力提升，我們發現單純的提示詞已不足以應對複雜任務，這時就需要「上下文工程」。
我們可以把這過程想像成電影導演在鋪陳故事。電影開場時，導演通常不會直接讓主角說話，而是先用遠景帶出城市（例如紐約），中景帶入辦公大樓，近景聚焦在辦公桌，最後主角才登場。這就是「上下文」——在溝通開始前，先建立完整的背景情境。
同樣地，與 AI 協作時，我們不能只丟出問題，而必須像導演一樣鋪陳：交代現在的產業背景、我是誰、遇到什麼特定問題。透過上下文工程，以系統性的方式把意圖（Intention）、背景知識與限制條件完整交代給 AI，從而讓它能像一個理解狀況的人類一樣進行溝通，而不僅僅是一個接收指令的機器。
Q2：TPMR 框架的核心要素有哪些？它如何實踐上下文工程？
A：首先，我建議大家從「人類跟人類溝通」的認知架構來思考這件事。我們可以將溝通拆解為三個步驟： 第一步是「認識」 ，知道有某件事存在； 第二步是「知道」 ，理解其中的內容； 第三步才是「溝通」 。在上下文工程中，我們就是要把這個傳遞訊息的過程結構化。
為了將這些抽象概念具體落實，我將其拆解為四個核心元素，簡稱為 TPMR（Tool, Prompt, Memory, Retrieval）。如果用比較非工程、生活化的方式來舉例，我們可以這樣理解：
1. 提示詞（Prompt）： 首先要向 AI 講清楚你的意圖。
2. 領域知識（Memory）： 你需要告訴 AI 你所在的領域，是化學、半導體還是生物？領域知識又可分為兩類：
• 長期記憶：例如在生物學中，「界門綱目科屬種」的分類定義是不會變的知識，AI 可能已經內建了。
• 短期記憶：指最近要處理的特定資訊。例如我現在要研究某個特定的蛋白質，或者這是一份關於近期登革熱趨勢的 CSV 檔案。這些是 AI 本來不知道，需要我們「餵」給它的短期資訊。
3. 工具（Tool）： 當 AI 自身能力不足時，我們要請它「出動」工具。例如，我想知道該蛋白質在最近研討會上有沒有新的研究發表？這時就可以請 AI 使用瀏覽器（Browser）這個工具，代替我們去網路上搜尋、整理資訊。
4. 檢索（Retrieval）： 除了外部搜尋，如果我們實驗室內部就有歷年的研究數據，這些是非公開的資料。這時我們就可以動用 RAG（檢索增強生成）技術，把內部的結構化或非結構化資料拉進來給 AI 參考。
所以，一個完整的上下文工程就是： 我有明確的意圖，結合了領域知識，請 AI 運用搜尋工具去網路上找新資料，同時透過檢索調閱內部的實驗數據 。當這四個環節（TPMR）連在一起，就能讓通用模型瞬間變成具備產業知識的專家，這就是上下文工程的全貌。
Q3. 上下文工程如何改變我們與 AI 的互動模式？
A：以前有個流行語叫「寶寶心裡苦，但寶寶不說」，如果你不說，別人怎麼知道你苦在哪？現在的 AI 其實也有類似的感覺。雖然 AI 模型可能讀遍了全世界圖書館的書，知識淵博，但它看不懂你當下的問題是什麼。
舉個常見的例子：很多人會直接丟一個 CSV 檔給 AI，裡面有 10 個欄位、100 行資料，然後只下一句指令：「請幫我分析這個資料。」這時候 AI 其實很困惑，它不知道這些數據是問卷調查還是感測器測量？不知道你的分析目的是要看趨勢還是找異常？結果它只能「亂猜」，給你一個很普通的回答。
以公司剛入職的新進員工來比喻，不管這位新同事有多聰明、學歷多高，在他剛入職的前幾週，我們一定需要花時間帶他入職培訓：告訴他公司的資料放在哪個系統、SOP 是什麼、這個專案的目標為何。AI 也是一樣，它需要你提供上下文。
我們團隊的作法是，平時就會準備好一些 Markdown 格式的文件，例如「公司簡介」、「專案目標」、「目前遇到的困難」。當我們要請 AI 分析某個 CSV 檔時， 我們不會只丟檔案，而是會把公司簡介、專案目標連同檔案都餵給它，問它：「這些資料跟我們要解決的問題有無關聯？」這時候 AI 的回答就會精準非常多，因為它有了想像的依據，而不是瞎猜 。
如果你懶得提供這些上下文，你就只能依賴「Multishot（多重嘗試）」，也就是讓 AI 猜個五次、十次，看能不能矇對一次。這就像兩個人聊天，如果你只說「我是工程師」，對方很難接話，最後只能尬聊；但如果你能像國文老師教的那樣，練習用「完整語句」描述——包含主詞、動詞、受詞，加上場景、甚至指定語氣（要激進還是溫柔），AI 給你的回答就能一次到位。
這也是為什麼我們前面提到的 TPMR 框架這麼重要，它就像一張檢查清單，強迫我們把這些結構化的資訊都準備好。當你把這些該講的都講了，AI 就能從「猜測者」變成「高效執行者」，幫你省下大量的溝通試錯時間。
Q4：「黃金圈理論」可以應用在 AI 協作上，這如何改變我們的工作方式？
編按：黃金圈理論（Golden Circle）由英國作家與領導力講者賽門·西奈克（Simon Sinek）提出，是一個由內而外思考與溝通的框架，透過「Why－How－What」三層同心圓，強調先釐清「為什麼而做」，再談「怎麼做」與「做什麼」。
A：在「軟體 1.0」的手工業時代，我們被「格式」框住了，花了大量時間在學 What（例如 Excel 的函數、PPT 的排版）。但在 AI 時代，我們進入了「軟體 3.0」，透過自然語言就能驅動程式。這時候，我們應該回到最核心的 Why——「我的意圖是什麼？」。
舉例來說，過去我們丟一個 CSV 檔給 AI，只說「幫我分析」，這就像把資料丟給工讀生卻不給指示，AI 只能亂猜。但在上下文工程的思維下，我們要告訴 AI 你的意圖：我是電商老闆，想找出滯銷品原因；提供 How（方法/知識）：這是銷售數據，請依照某種行銷邏輯分析；最後才得到 What（結果）。
人類應該專注於定義清晰的「意圖」與「邏輯」，剩下的執行細節則交給 AI。這讓人類有機會從繁瑣的格式操作中解放，專注於解決問題的本質。
Q5：企業若想導入「黃金圈理論」這套思維打造內部的 AI Agent，最大的挑戰與準備是什麼？
A：企業導入 AI Agent（AI 代理）往往被誤視為純粹的技術議題，但根據我的觀察，成功的轉型必須遵循特定的層級順序： 首重文化與人才，其次是組織架構，最後才是技術導入 。
若以賽門的黃金圈理論審視，許多企業失敗的原因在於直接從最外圈的「What」（技術規格）切入。這種「先定規格」的做法往往會導致系統缺乏彈性，一旦技術更迭，核心價值的調整便會受到僵化架構的限制（被卡死）。
所以企業要開始思考導入上下文工程時，我認為以下兩塊準備工作缺一不可，同時需避免落入以下兩個情況。
DOS：
1. 建立專業領域的知識庫：
企業必須將內部的專業知識、技術參數進行數位化與結構化整理。
2. 梳理工作流程：
明確定義每一個部門內部及跨部門協作的標準作業程式（SOP）。
DON'TS：
1. 將責任全歸屬給 IT 部門：
過去在推動知識管理或數位轉型的經驗已證實，單靠 IT 部門無法強行推動跨部門的業務整合。成功的關鍵在於「去中心化」的參與——各部門必須主動承擔起定義知識與流程的責任。
各部門應主動將隱性知識顯性化，如：「這個部門的專業知識及工作流程是什麼？」並依此繪製具體的作業流程圖。企業應建立一種共識：初期的目標不在於完美，而在於建立「起點」。即便初版流程有瑕疵，只要有了基礎文本，AI 就能協助我們進行修正與優化。這正是 AI 時代的核心精神：透過每一次的嘗試與對話都會帶來學習與成長，然後再回到公司組織裡繼續應用，這就是最棒的迭代。
2. 將 AI 當作工具：
企業需要進行根本性的思維轉變，不應僅將 AI 視為單一工具，而應將其視為一支協作的「新同事軍團」。
那些願意投入資源、容許員工與 AI 進行大量實驗與互動的組織，其學習曲線與進化速度將遠超躊躇不前的競爭者。當企業不再糾結於 AI 是否能一步到位，而是專注於如何透過它加速內部的知識迭代，這才是導入「上下文工程」最核心的價值所在。
Q6：面對「軟體將被重寫」、「Vibe Coding」等趨勢，您對工作者與開發者有什麼建議？
A：面對 AI 帶來的變革，焦慮是正常的，但我鼓勵大家轉個念頭：「唯一不變的，就是變。」
未來的競爭力將建立在三個維度上：
1. 跨領域學習： 不要只懂單一技術。比如，雖然我是一名工程師，但我也需要懂業務邏輯、使用者體驗、行銷甚至心理學。因此，AI 幫你處理掉 80% 的瑣碎工作的情況下，多出來的時間應該用來探索陌生領域。
2. 系統性拆解思維： 就像我們把複雜的「上下文工程」拆解成 TPMR 一樣，學習將大問題拆解成小模組，再用 AI 各個擊破。
3. 大量實驗： 不要怕 AI 做錯，把它當成工具進行多重嘗試。同一個 CSV 檔，試著用五種不同的 Prompt 去跑，觀察結果。
未來的軟體開發與工作，將不再是單純的寫程式碼，而是「產品與技術的整合」。透過不斷的學習、拆解與實驗，我們就能駕馭 AI，打出屬於自己的漂亮組合拳。
（延伸閱讀｜數位關鍵字206｜從提示工程到上下文工程！學會TPMR框架重塑AI互動模式）
（本文初稿為 AI 編撰）
