2026 提示工程不敗心法：從 LLM 基礎對話到 Agent 上下文管理

type

status

date

slug

summary

一、提示工程的原理：說話的紀律

為什麼有些提示技巧從 2023 年活到了 2026 年，換了好幾代模型都還管用？

1. 把話講清楚，是工作的基本要求

Google 的指南裡有一個類比讓我印象很深：把 AI 想成一位才華橫溢但剛到職的新員工。他很聰明，但他對你的規範和工作流程一無所知。你的指令越精確，他的產出越好。Anthropic 的文件幾乎用了同樣的說法。

我覺得這個類比好用在它的反面：如果你的指令連一個新進員工都聽不懂，AI 一定也聽不懂。

但這件事跟 AI 的關係沒有大家想得那麼大。語言之所以拿來溝通，本來就是為了資訊的傳達。如果你自己也不知道你要什麼，不管是 AI 還是員工，都猜不出你的需求。所以那些一直有效的提示技巧之所以歷久不衰，是因為它們本質上是基本的說話技巧與傳達秩序：在最小的文字量裡，塞入最高的指令與資訊密度。

白話說就是：把話講清楚。

2. 三個歷久不衰的基礎技巧

這三個技巧在所有官方文件裡都反覆出現，原因很樸素：它們在本質上幫助你把抽象的期待轉化成具體的指令。

少樣本提示（Few-shot Prompting）：範例比描述更精準

你用言語解釋一件事，對方有時候還是會理解錯。但你拿一份成品給他看，說「就照這個感覺做」，誤差立刻縮小。帶新人的時候你本來就會這樣做，跟 AI 溝通也一樣。Anthropic 的建議是確保範例具備兩個特性：

相關性：緊密模擬實際場景

多樣性：包含邊緣情況，避免 AI 只從範例中習得表面模式

角色設定（Role Prompting）：校準溝通參數

當你跟不同專業背景的人說話，你會自動調整用詞的深度和角度。跟工程師講產品你會聊架構，跟行銷講同一個產品你會聊賣點。角色設定做的就是這件事：你在對話開頭指派一個角色，比如「資深技術架構師」或「十年經驗的產品經理」，等於在快速校準一組溝通參數，讓 AI 知道該用什麼深度和你對話。

明確化期望：格式、長度、重點方向

你跟人協作的時候，「隨便做就好」通常會得到一份你不想要的東西。但你說「用三個段落，每段不超過兩句，聚焦在原因而不是事件經過」，對方交回來的東西就會精準很多。這個道理也適用於可重用的模板設計，比如把常用的指令做成帶有變數的模板，像是「將以下 {{來源語言}} 程式碼翻譯為 {{目標語言}}」，讓每次下指令都不用從零開始。

你會發現，這三個技巧的共同點是：它們全都是你跟人類協作時本來就會做的事。只是搬到 AI 上面，被冠上了專有名詞。

白話來說就是把話講清楚。

3. 你可能在犯的錯：防禦性寫作

「把話講清楚」有一個常見的陷阱。

我自己就踩過。我的 Gemini 個人設定裡，曾經堆了一大段這樣的指令：「不准使用省略號」「禁止一方面另一方面這種廢話」「不要在回應中使用技術術語」。我當時覺得很完整，把所有讓我不爽的 AI 行為都列了禁令。

但後來我對照了 Anthropic 和 Google 的指南，發現它們都提到同一個原則：告訴模型「要做什麼」，而不是「不要做什麼」。

原因很簡單。當你花大量篇幅描述你不要的東西，你其實在用寶貴的上下文空間（模型能一次讀取的資訊量是有限的）畫一張負面清單，模型需要先理解所有禁區，再從剩下的空間裡推導出你真正想要的回應。但如果你直接描述你期望的輸出狀態，模型的路徑就清楚多了。

防禦性寫作 ❌	正向描述 ✅
不要在回應中使用技術術語	用十歲小孩能理解的語言解釋
不准使用省略號	使用完整的句號結尾
禁止列點超過五項	用三到五個重點摘要核心論述

後者不只省了心力，而且給了模型一個明確的錨點，而不是一片模糊的禁區。

我把這種習慣叫做「防禦性寫作」：先想到 AI 過去讓你不爽的行為，然後瘋狂列禁令。這在 2023、2024 年那個模型還比較容易「兩面討好」的時代有它的道理，但到了 2026 年，模型進步了，這些高壓否定指令反而在浪費你最珍貴的資源。

關於這個資源到底是什麼，我們第三段會深入聊。

4. 退後一步問：你確定你知道自己要什麼？

還有一個我覺得被嚴重低估的技巧，Google 的白皮書裡有特別提到，叫做後退提示（Step-back Prompting）

邏輯很簡單：在讓 AI 解決具體問題之前，先退一步，讓它處理一個跟具體任務相關的一般性問題。把這個一般問題的答案拿到之後，再跟具體任務合併成新的提示。這個「退一步」讓 AI 在動手之前，先啟動了相關的背景知識跟推理過程。

但我覺得這個技巧真正厲害的地方，不在於 AI 端，而在於你自己。

但我覺得這個技巧真正厲害的地方，不在於 AI 端，而在於你自己。我自己在用的一個變體是這樣的：與其直接叫 AI「寫一份好的行銷文件」，我會先問它「2026 年一份好的行銷文件長什麼樣子？去查一下最新的趨勢和規範。」結果常常讓我驚訝，因為我的認知已經過期了。我以為我知道「好的行銷文件」該長怎樣，但我的標準還停在兩年前。

這就暴露了一個大家不太願意面對的問題：你以為你知道自己要什麼，但你的知識可能已經過期了。退後一步不只是一個提示技巧，它是一個提醒，提醒你在下指令之前，先確認自己的認知是不是最新的。

而這個「先退一步」的邏輯，其實正是接下來 Agent 思維的入口。

二、從指揮到委派：Agent 時代的認知翻轉

你已經很習慣跟 AI 一來一回了，但為什麼在用 Agent 的時候，這套反而變成了阻力？

1. 2023 到 2025 年的使用習慣，變成了你的包袱

先講一個你可能沒意識到的問題。

從 ChatGPT 爆紅到現在，大部分人的 AI 使用經驗被一種特定的互動模式塑形了：你說一句，AI 回一句，你再修正，它再調整。一來一回。這兩年的對話經驗，訓練出了一種很強的操作直覺：把「怎麼做」一步一步拆解清楚，告訴 AI 要怎樣、不能怎樣。

在 LLM 時代，這個直覺完全正確。因為傳統的 LLM 沒有自我驗證的能力。它生成完一段文字之後，不會回頭檢查自己寫得對不對、邏輯通不通。它必須靠你一來一回地糾正。所以你才養成了逐步指揮的習慣。

而且那個時代的模型確實會突然跟你說「我只是一個語言模型，無法完成你的要求」，讓你覺得它不可靠，需要把每一步都拴緊。

但 Agent 不一樣。

2. Agent 跟 LLM 的核心差異：閉環

先把工具使用的部分放到一邊（能連接 Gmail、Google Drive 這些外部服務是 Agent 的能力，但不是本質差異）。Agent 跟 LLM 最根本的不同，是它能自我驗證並且閉環。

吳恩達在演講裡用了一個我覺得極好的類比：

非 Agentic 的工作流，就像叫一個人寫作文但不准按退格鍵，必須從第一個字一鼓作氣寫到最後一個字。而 Agentic 的工作流是：先列大綱，搜尋資料，寫初稿，自我審閱，修改，再迭代。

LLM 就是那個不准按退格鍵的寫作者。Agent 則有反思（Reflection）的能力，它可以審閱自己的輸出，發現問題，自己修改，不需要你在旁邊一句一句盯。而且因為模型生成 Token 的速度遠快於人類閱讀，這種反覆迭代在幾秒鐘內就能跑完好幾輪。

這意味著你不需要時時刻刻都盯緊每一個步驟。

3. 直升機主管的陷阱

這裡有一個心理門檻。

使用 Agent 的時候，你的工作從「逐步指揮」變成「委派任務然後等待」。吳恩達在演講裡特別強調了這一點：你需要學會把任務交給 AI Agent，然後耐心等幾分鐘甚至幾小時。

這聽起來很簡單，做起來卻很難。因為你過去兩年的經驗告訴你：不盯緊它，它就會亂來。

我覺得這跟職場上的管理困境一模一樣。如果一個主管不相信員工是聰明的、可靠的、有辦法自主學習的，他就會忍不住一直盯著對方的過錯，試圖糾正和打斷每一步。交辦工作五分鐘就問進度，這種直升機主管帶不出獨立思考的員工。

Agent 也是同樣的道理。如果你把怎麼做一步步拆好餵給它，你其實是在限制它的推演路徑。它可能有更好的方式達到你要的結果，但你沒有給它空間去嘗試。

所以使用 Agent 的認知翻轉是這樣的：你要從給 how（步驟指令）轉向給 what 和 why（目標與原因）。

具體來說：

ㅤ	LLM 時代的指令	Agent 時代的指令
你給的東西	步驟（How）	目標與原因（What & Why）
指令範例	先分析這兩個產品的功能差異，然後找三個競爭對手的定價資料，最後做一張比較表格	比較這兩個產品的功能與定價，找出主要競爭對手，製作一份摘要表格讓我能在會議上做決策
你控制的	每一步的路徑	目標、範圍、品質標準

差別在哪？前者是你在規劃每一步，Agent 只是照做。後者是你給了目標（評估定價策略）、背景（為什麼需要這個）和素材（兩份產品文件），然後讓 Agent 自己決定用什麼方式達成。

它可能會先讀完你的文件，發現你沒提到的弱點，然後主動去搜尋你沒想到的競爭對手，最後給出一個你自己未必會走的分析路徑。

這就是委派。你的工作不再是設計每一步的路徑，而是把目的地講清楚，然後相信它有能力找到路。

三、上下文工程：放手之後，你的新戰場

如果提示工程（Prompt Engineering）關注的是「怎麼說」，那上下文工程（Context Engineering）關注的是什麼？

1. 你的工作重心，已經悄悄轉移了

Andrej Karpathy（OpenAI 創始成員）提出了一個觀點：真正的高手早就跳過了 Prompt Engineering，直接玩 Context Engineering。

他的定義是這樣的：上下文（Context）是模型在生成回應時所看到的全部 token 集合。這包括你的系統提示詞、對話歷史、工具定義、外部餵入的資料，全部加在一起。提示工程管的是你這一句話怎麼措辭，上下文工程管的是你在模型的工作記憶裡放了什麼。

提示工程像是你在會議上的一句發言，上下文工程像是你在會議前準備的整份議程、背景資料、與會者名單。一句話講得再好，如果議程是亂的、資料是錯的，會議還是開不好。

而上下文工程最大最大的前提，其實不是技術問題。是你必須先知道自己要什麼。

如果你不知道自己的目的，你就沒辦法判斷哪些資訊該放進上下文、哪些該拿掉。你的旅行如果沒有目的地，你永遠無法抵達。不是 GPS 壞了，是你根本沒有輸入地址。

這就是為什麼上下文工程的瓶頸不在技術端，而在使用者的後設認知：你得先對自己釐清「我到底要解決什麼問題」，才有辦法組裝出正確的上下文。

2. 三個你今天就能做的上下文管理

聽起來很抽象？其實你可能每天都在做上下文管理，只是不知道它叫這個名字。

① 設計你的系統提示詞（個人設定）

你在 Claude 的個人設定、Gemini 的 Gems、ChatGPT 的 Custom Instructions 裡寫的那段話，本質上就是在幫每一次對話預先填充上下文。它對應的是 Karpathy 框架裡「指令（Instructions）」這個類別，也就是你在每次對話開始前就塞進去的常駐指令。

寫得好，你每次開對話的起點就高。寫得差，你等於在浪費模型最珍貴的注意力。

這裡呼應前面講的防禦性寫作：如果你的個人設定裡堆滿了「不准這樣」「禁止那樣」，模型在每次回應時都要先消化一長串禁令，真正重要的指令反而可能被淹沒。正向描述你期望的輸出狀態，比列舉所有你不想看到的行為，來得更省 token 也更有效。

Anthropic 的指南裡還提到了一個進階思路：系統提示、脈絡提示和角色提示三者應該協同運作。

系統提示：定義大圖景（你希望 AI 扮演什麼角色、遵循什麼規範）

脈絡提示：提供當前任務的具體背景

角色提示：調整專業深度和語氣

把這三層分清楚，你的個人設定就不會變成一鍋大雜燴。

同樣重要的是告訴 AI 你給指令的原因。比如「不要使用省略號」跟「你的回應會由文字轉語音引擎朗讀，所以不要使用省略號，因為 TTS 引擎不知道該怎麼發音」，後者給了脈絡，AI 就能從這個解釋推導出更多你沒有明確說的規則（比如它可能會自動避免其他 TTS 難以處理的符號）。Anthropic 和 Google 的指南都強調了這一點：AI 足夠聰明，可以從解釋中進行泛化。

② 一個視窗一個任務：隔離你的上下文

這是最簡單也最被忽略的操作。一個對話視窗只執行一個任務。如果你有另一個問題，開另一個對話視窗解決，再把需要的資料複製過來。

為什麼？因為當你在同一個視窗裡混雜多個不同的任務，模型的上下文裡就充斥著大量跟當前任務無關的資訊。這些無關資訊會搶奪模型的注意力，壓過真正重要的指令。這種情況稱為 Context Distraction（上下文分心）。

在 Claude 這種平台上這一點特別重要，因為它的上下文視窗雖然大，但模型對資訊的注意力分配不是均勻的。無關的雜訊越多，核心指令被正確執行的機率越低。

③ 主動摘要交接：壓縮你的上下文

當你跟 AI 的對話到了一定長度，你會發現它開始「忘記」前面說過的事，或者回應的品質明顯下降。這不是 AI 變笨了。研究顯示，隨著上下文視窗裡的 token 數量增加，模型準確回憶資訊的能力會下降。Karpathy 把這個現象叫做 Context Rot（上下文腐化）。

我的做法是：在對話到了一個段落的時候，主動要求 AI 寫一份目前的工作進度與摘要，然後把這份摘要貼到一個新的對話視窗裡，從那裡繼續。

這個操作同時做了兩件事：

壓縮上下文：把冗長的對話歷史濃縮成精華

淨化上下文：把中間的嘗試錯誤、無效的分支全部丟掉，讓新對話從一個乾淨的起點開始

3. 四種上下文壞掉的樣子

當你開始意識到上下文管理的重要性，你會需要知道它壞掉的時候長什麼樣子。LangChain 的部落格文章 歸納了四種失效模式：

失效模式	一句話定義	類比
Context Poisoning（上下文污染）	AI 前面產生的錯誤資訊留在上下文裡，後續推理全基於錯誤前提	報告第一頁數字就錯了，後面每一頁的分析都跟著歪
Context Distraction（上下文分心）	上下文塞了太多無關資訊，重要指令被淹沒	開會時桌上攤了三十份不同專案的文件，沒人找得到今天該討論的那份
Context Confusion（上下文混亂）	過多細節和冗餘資訊，模型無法判斷哪些才是關鍵	資訊之間未必矛盾，純粹是太多、太雜
Context Clash（上下文衝突）	上下文裡存在互相矛盾的資訊	你前面說了一個定價標準，後面又貼了不同版本的定價表

回到最前面的那個觀點：Agent 的失敗，往往出在上下文工程，跟模型本身的能力無關。給錯、給太多、給太少、或是給了互相矛盾的資訊。修正 AI 行為的時候，先檢查上下文裡放了什麼，而不是先去調整你的措辭。

結語

提示工程的演化，就是從「怎麼跟機器說話」走向「怎麼提供機器正確的脈絡」。

說話的紀律：把話講清楚、舉例讓對方理解、確認自己的認知是最新的。這些基本功永遠不會過期，因為它們是溝通的底線，跟 AI 無關，跟人性有關。

放手的勇氣：承認對方可能比你想得更聰明，給目標而不是給步驟，讓 Agent 用它的方式跑到終點。這需要你克服過去兩年養成的控制直覺。

管理你餵給它的世界：你的系統提示詞、你的對話視窗、你的摘要交接，全部都是在塑造 AI 工作時看到的脈絡。這個脈絡的品質，決定了 AI 輸出的天花板。

而這三層的底下，有一個共通的前提：你必須先知道自己要什麼。

說話的紀律讓你的指令清晰，委派的勇氣讓 Agent 發揮潛力，上下文的管理讓整個系統不會在半路崩塌。而這一切的起點，需要你腦袋裡的想法足夠清楚。

參考資料

Google Prompt Engineering 白皮書

Perplexity at Work

Build with Claude Prompting best practices

YouTubeWhat's next for AI agentic workflows ft. Andrew Ng of AI Fund

What's next for AI agentic workflows ft. Andrew Ng of AI Fund

Andrew Ng, founder of DeepLearning.AI and AI Fund, speaks at Sequoia Capital's AI Ascent about what's next for AI agentic workflows and their potential to significantly propel AI advancements—perhaps even surpassing the impact of the forthcoming generation of foundational models. #AI #AIAscent #Sequoia #Startup #Founder #entrepreneur

AnthropicAIEffective context engineering for AI agents

Effective context engineering for AI agents

Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

LangChain BlogContext Engineering

Context Engineering

TL;DR Agents need context to perform tasks. Context engineering is the art and science of filling the context window with just the right information at each step of an agent’s trajectory. In this post, we break down some common strategies — write, select, compress, and isolate — for context engineering