從對話到代理：自主 AI 代理的進階提示工程

我們對軟體系統的第一個預設，是它的行為完全可以預期。決定論系統保證：給定相同輸入，永遠得到相同結果，邊界清晰、可控性高。

進入大型語言模型的世界後，這種確定性不再成立。系統的輸出建立在機率分布之上，相同的輸入可能產生不同的結果。提示（prompt）是我們與這些模型互動的主要介面——設計良好的提示，是通往廣博知識與自動化代理系統的捷徑；設計不良，換來的就是充滿幻覺的輸出。

核心原則：清晰、簡潔、動作動詞、指令優於約束

建立高階代理系統的第一步，是掌握基本的溝通法則。語言模型本質上是模式識別機，當指令含有含糊的字眼時，它會在龐大的神經網路中啟動錯誤的權重。

第一，指令必須清晰、具體、簡潔，並使用強烈的動作動詞。 與其要求「思考一下這篇文章的重點」，不如下達「分析、分類、提取或總結」這類精確的指令。精確的動詞能縮小模型的預測範圍。這裡的「思考」與後文思想鏈的「思考」不同——前者是模糊的動作指令，後者是有結構的推理技巧，兩者不能混為一談：

第二，指令優於約束。 指示模型該做什麼，比指示它不該做什麼更有效。這與人類認知機制相似：當被要求「不要去想一頭粉紅色的大象」時，大腦在處理否定指令之前，必須先提取「粉紅色大象」的特徵，反而形成鮮明的印象。AI 處理負面約束時也有類似機制——設定過多「不要做什麼」時，模型會把注意力集中在要避免的事物上。以正向框架給出明確的執行路徑，效率更高。

第三，實驗與迭代。 提示工程是迭代過程，而不是一次到位的寫作。從草稿開始，測試輸出，分析缺點，再修正提示。模型版本更新、temperature 與 top-p 等設定、甚至措辭的細微變化，都會改變結果。記錄每一次嘗試與對應的輸出，是持續提升品質的關鍵。

基礎技巧：零樣本、單樣本與少樣本提示

基礎技巧的三個層次，差異在於提供給模型的範例數量。

少樣本提示的效能很大程度取決於範例的品質與多樣性。範例必須準確、能代表任務，並涵蓋模型可能遇到的變化或邊緣情況——單一錯誤就足以讓模型混亂。

分類任務必須打亂類別順序

少樣本分類任務有一個反直覺的細節：必須混合不同類別的範例順序。若要教模型分辨正面與負面評論，先給三個正面例子、再給三個負面例子，聽起來邏輯清晰，但模型是模式識別機——當範例永遠是三個正面、三個負面時，它會把「前三個必須是 A、後三個必須是 B」這個順序本身當成一種需要學習的隱藏規則。

打亂順序，是強迫模型忽略排列的規律，將運算資源集中在文字內容本身的特徵上。否則模型如同背誦題號順序的學生，換個題型即失效。以電影評論分類為例：

評論：「表演非常出色，故事也很吸引人。」 → 正面
評論：「視覺效果令人驚嘆，但對話很弱。」 → 負面
評論：「還可以，沒有什麼特別的。」       → 中立
評論：「我發現情節令人困惑，人物也不討人喜歡。」 → 負面

隨機交錯正面、中性、負面的範例，模型才能學到真正的分類特徵。

長上下文的活用

現代模型如 Gemini 具備超長上下文處理能力，使少樣本可以擴展為幾十甚至幾百個隨機打亂的範例，讓模型吸收極度複雜的分類邊界，大幅降低過度擬合特定順序的風險。

建構提示：系統提示、角色提示與分隔符

使用者的輸入充滿不可預測性，甚至可能含有惡意指令。要確保模型不把使用者輸入當成最高指導原則，就必須應對提示注入（prompt injection）攻擊——透過將指令結構化來達成。

系統提示設定語言模型的整體上下文與目的，定義預期的行為：

你是個樂於助人且無害的人工智慧助理。
以禮貌和資訊豐富的方式回答所有問題。

角色提示把特定角色指派給模型，引導它反映該角色的知識、語氣與溝通方式：

擔任經驗豐富的旅遊部落客。
寫一篇關於羅馬最好的隱藏寶石的簡短而引人入勝的段落。

分隔符是最基礎的結構化工具。以三個反引號（```）、XML 標籤或破折號，將系統指令、上下文背景與使用者輸入明確隔離：

<instruction>總結以下文章，聚焦作者提出的主要論點。</instruction>
<article>
[在此插入文章全文]
</article>

分隔符的實質作用是建立指令與資料之間的邊界。缺乏此邊界時，模型可能混淆指令與輸入的歸屬，無視已設定的規則，轉而執行使用者注入的指令。

系統提示的自動最佳化

系統提示也可以自動最佳化。Vertex AI Prompt Optimizer 這類工具，會依使用者定義的指標與目標資料，系統性地迭代改善提示，確保給定任務能獲得最佳效能。這與後文的自動提示工程（APE）與元方法屬於同一脈絡。

上下文工程：讓模型掌握動態環境

靜態的系統提示與分隔符只是起點。上下文工程（contextual engineering）在每次任務執行時動態注入相關資訊——上一輪對話、檢索到的文件、工具回傳的結果、目前的操作環境——讓模型的回答有所依據。

其核心論點是：模型輸出的品質，取決於提供的上下文豐富度，而非模型架構本身。因此它的工作重點從「優化提問的措辭」，轉移到「建立完整的作戰畫面（operational picture）」。這代表了從傳統提示工程的一大演進：不再只盯著眼前這一句使用者查詢，而是把多重層次的資訊納入考量。

上下文的來源可分成三層：

以寫一封回覆主管的電子郵件為例。未做上下文工程時，模型只能憑一句簡短的指令猜測語調與內容；做完之後，模型會整合三種來源——行事曆上的空檔時間（工具輸出）、與收件人的職場關係（隱含資料）、上次會議的筆記（檢索文件）——才能產出具體、個人化、真正可用的回覆。

隱含資料的引入同時帶來隱私與倫理課題。在企業、醫療、金融等領域，上下文工程必須搭配嚴謹的治理機制，否則動態注入的使用者資料可能被誤用。這正是「工程」二字的重量——建置在執行期擷取與轉換資料的管線，並建立回饋迴圈持續改善上下文品質。上下文工程正是把無狀態的聊天機器人，轉化為能感知情境的代理系統的關鍵方法。

結構化輸出：解析並驗證

要讓模型融入自動化工作流程，必須要求它輸出特定格式（例如 JSON），再以 zod 或 Pydantic 這類函式庫驗證。核心概念是解析並驗證（parse, don’t validate）。

要求語言模型輸出結構化格式有其必要。在代理系統中，可能同時有多個 AI 模組互相協作——模型與模型之間透過結構化資料溝通。若模組 A 交給模組 B 的是格式不固定的文字，模組 B 的程式邏輯無法可靠解析，整個工作流程就會中斷。

此外，語言模型天生可能產生幻覺——漏掉逗號、把數字寫成字串。zod 在此承擔驗證職責：不只確認輸出是 JSON，還會對照定義的嚴謹綱要。若規定年齡必須是整數而模型給出文字，zod 會拒絕該輸出，並可將錯誤訊息回傳給模型要求重寫：

import { z } from 'zod'

// 定義期望的結構：解析並驗證一體成形
const UserSchema = z.object({
  name: z.string().describe('使用者的全名'),
  email: z.email().describe('使用者的電子郵件地址'),
  dateOfBirth: z.date().optional().describe('使用者的出生日期'),
  interests: z.array(z.string()).describe('使用者興趣清單'),
})
type User = z.infer<typeof UserSchema>

// 假設這是 LLM 回傳的 JSON
const llmOutputJson = `{
  "name": "Alice",
  "email": "alice.w@example.com",
  "dateOfBirth": "1995-07-21",
  "interests": ["NLP", "Python", "Gardening"]
}`

try {
  // zod 解析 JSON，同時根據 schema 驗證資料
  const user: User = UserSchema.parse(JSON.parse(llmOutputJson))
  console.log(user.name) // Alice
  console.log(user.dateOfBirth) // Date 物件（zod 已把字串轉成日期）
} catch (e) {
  // 若 JSON 格式錯誤或資料型別不符，zod 拋出驗證錯誤
  console.error('LLM 回傳的 JSON 無法通過驗證', e)
}

強制輸出結構化資料，是把大型語言模型從不可預測的散文產生器，轉變為確定性資料處理器的關鍵。這是從玩具級應用走向工業級應用的分水嶺。若輸出格式是 XML，在前述 zod 的 TypeScript 生態下，可先用 fast-xml-parser 把 XML 轉成 JSON，再交給 zod 驗證；若後端是 Python，則用 xmltodict 轉成字典，再以 Pydantic 的欄位別名把冗長的 XML 結構對應到物件的欄位。

推理技巧：思想鏈、思想樹與自洽性

面對複雜的數學或邏輯推演，模型常常未產生中間過程就直接給出答案，而答案通常是錯的。必須強迫它產生推理步驟。

思想鏈（Chain-of-Thought, CoT）

思想鏈是將推理步驟顯式化的技巧——在提示中加上「讓我們一步一步思考」。語言模型本質上是逐 token 預測下一個 token，無法先默默思考再輸出，只能邊生成邊推理。直接要求答案時，它只能憑機率猜測。

加入「一步一步思考」後，模型被迫先產生中間推理步驟。這些推理 token 會立刻成為新的上下文，從機率上引導後續生成，使最終答案 token 的機率集中在正確結果上。推理過程等於為模型自己建立逐步推進的依據：

提示：一列火車以每小時 60 英里的速度行駛 240 英里，
這趟旅程需要多久？讓我們一步一步思考。

解確定性數學題時，應將模型的 temperature 設定為零，使每一步都選擇機率最高的路徑，排除隨機發散。最佳實務是將最終答案放在推理步驟之後，因為推理的產生會影響後續 token 的預測。

CoT 有兩種變體：

後退提示（Step-back Prompting）

後退提示先要求模型考慮與任務相關的一般原則，再將此較廣闊的答案作為解決原始問題的上下文：

提示 1（後退一步）：「一部優秀偵探小說的關鍵因素是什麼？」
提示 2（原始任務 + 後退上下文）：利用上述關鍵因素，為一部以小鎮為背景的新懸疑小說寫一個簡短的情節摘要。

此作法讓模型先啟動相關的背景知識與更廣泛的推理策略，產出較準確的答案，減少受表面元素的干擾。

思想樹（Tree-of-Thought, ToT）

當線性推理陷入死路時，需要更高階的技巧。思想樹允許模型同時展開多條推理分支，評估未來幾步，發現走錯時可以回溯。其計算需求較高，但適合需要探索、回溯或在得出解答前評估多種可能性的複雜問題。

以經典的填字謎題為例：目標是用一加一減填入算式「○ ＋ ○ － ○ ＝ 5」，數字只能選 3、4、6。思想鏈只能沿著單一路徑前進，走錯了就整題重來；思想樹則在同一輪展開多條分支——先假設第一個 ○ 是 3，試試 (3 ＋ 4 － 6)，失敗後不是回到起點，而是切換到另一條仍在計算中的分支，假設第一個 ○ 是 6，推出 (6 ＋ 3 － 4) 成立：

             ○ ＋ ○ － ○ ＝ 5
                     │
      ┌──────────────┼──────────────┐
     ○=3            ○=4            ○=6
      │              │              │
  3＋4－6=1 ✗     4＋6－3=7 ✗     6＋3－4=5 ✓

走錯的分支被捨棄，正確的分支繼續往下，模型從錯誤中恢復，不需要重頭推理。

自洽性（Self-Consistency）

自洽性是建立於思想鏈之上的進階技巧，目的是利用模型的機率特性提高推理的可靠性。單一思想鏈可能走偏，但若多次推理的多數結果收斂到同一答案，正確的機率便大幅提升。它由三個步驟組成：

1. 產生多樣化的推理路徑：以較高的 temperature，將相同的提示多次送給模型，鼓勵它探索不同的推理方法
2. 提取答案：從每條推理路徑中取出最終答案
3. 多數決：統計各答案出現的次數，選出最一致的結果作為最終答案

模型運行 1（高溫）：「所有鳥都能飛」是真的，因為多數鳥會飛
模型運行 2（高溫）：提到企鵝與鴕鳥，結論為假
模型運行 3（高溫）：多數鳥類會飛、少數例外，結論為真
自洽性結果：多數決 → 真

自洽性的代價是：同一問題需要多次運行模型，運算與 API 成本隨次數線性上升。對簡單的摘要任務，此成本不符比例；但若代理需要規劃涉及數百萬美元的跨國供應鏈排程，或進行複雜的醫療資料交叉比對，決策風險極大、容錯率為零，以額外的運算成本換取確定性的準確度，是合理的投資。任務的決策風險，決定了此類成本的合理性。

動作與互動：工具使用與 ReAct

若模型只能在文字介面內運作，就無法與外部環境互動。工具使用（tool use）與 ReAct 是賦予代理實際行動能力的機制。

工具使用／函式呼叫

現代語言模型常針對函式呼叫進行微調。模型解讀可用工具的描述（用途與參數），收到請求後決定是否需要使用工具、識別適當工具，並格式化呼叫所需的參數。注意：模型本身不執行工具——它產生結構化輸出（通常為 JSON），由代理系統執行工具，再把結果回傳給模型整合進互動：

使用者：倫敦現在的天氣怎麼樣？
模型輸出（函式呼叫）：
{
  "tool_name": "get_current_weather",
  "arguments": { "city": "London" }
}

ReAct：Reason and Act

ReAct（推理與行動）將思想鏈推理與工具使用交錯。它模擬人類解決問題的方式——透過推理、行動收集更多資訊或朝目標前進。以做菜的流程為例：嚐湯後覺得味道不夠，這是思考；打開櫃子取鹽，這是行動；發現鹽罐空了，這是觀察。基於觀察，改以醬油代替，又展開新的思考與行動。此即標準的 ReAct 迴圈：

思考 ──> 行動 ──> 觀察 ──> 思考 ──> 行動 ──> 觀察 ──> ... ──> 最終答案

實際軌跡如下：

思考：使用者問兩個資訊：法國的首都及其人口。
     我可以使用搜尋工具來查找。
行動：Search({"query": "法國首都"})
觀察：巴黎
思考：首都是巴黎。現在我需要找巴黎的人口。
行動：Search({"query": "巴黎當前人口"})
觀察：2023 年巴黎人口估計約 210 萬人。
思考：兩個資訊都找到了，可以回答使用者。
最終答案：法國首都為巴黎，2023 年人口約 210 萬人。

防止無限迴圈：Final Answer 觸發條件

ReAct 迴圈中，模型持續思考、搜尋、觀察，必須有機制阻止它無止境地執行工具、耗盡運算預算。原始資料僅描述迴圈以輸出最終答案收尾，沒有明確的觸發機制；實務上關鍵是在提示中設立嚴格的狀態切換規則：定義明確的最終答案（Final Answer）觸發條件，每次獲得觀察結果後，模型都必須核對「手上的資訊是否足以回答使用者的原始問題」。一旦邏輯條件滿足，模型強制跳出搜尋迴圈，切換到輸出最終答案的模式。這是代理具備任務完成度判斷能力的關鍵——模型必須對任務狀態有一定程度的自我評估。

進階技術：提示的自動化與自我進化

隨著代理系統愈來愈複雜，包含各種 API 呼叫、JSON 驗證與思想鏈，人工調整提示詞開始不符合成本效益。當人為語言的直覺達到極限，必須引入自動化。

自動提示工程（APE）

自動提示工程（APE）利用語言模型本身來產生、評估並完善提示。整體概念是建立一個「元模型」，接受任務描述並產生多個候選提示，再依給定輸入集的輸出品質（可能以 BLEU、ROUGE 或人工評估）篩選出效果最佳的提示。

DSPy：把提示當程式

DSPy 框架把提示視為可編譯的程式模組。在 DSPy 中，不需手寫冗長的提示詞，只需提供兩個元件：

系統利用一個較小的語言模型自動重寫提示詞，餵給主模型測試，再根據目標函式反覆評分，找出產生最高準確率的提示組合——相當於以自動化方式執行大規模的 A/B 測試。此過程同時優化兩個面向：

• 少樣本範例最佳化：程式化地從黃金集中抽樣不同組合的範例進行測試
• 指令提示最佳化：以 LLM 作為元模型，迭代地改寫提示的措辭、語氣與結構

迭代提示／細化

迭代提示是最樸素但有效的方法：從簡單、基本的提示開始，根據模型的初始回應逐步修正，直到輸出符合期望。這與 APE 的自動化流程不同，屬於人類驅動的迭代設計循環：

嘗試 1：「為新型咖啡機編寫產品說明。」（結果太籠統）
嘗試 2：「為新型咖啡機編寫產品說明，強調速度與易於清潔。」（更好，但缺乏細節）
嘗試 3：「為 SpeedClean Coffee Pro 撰寫產品說明，強調 2 分鐘內
         沖泡一壺的能力與自清潔週期，鎖定忙碌的專業人士。」（接近期望）

提供反面例子

「指令優於約束」的原則通常成立，但有些情境下反面例子有幫助，只是要謹慎使用。反面例子展示模型不該產生的輸出，用來澄清界線、防止特定類型的錯誤回應：

產生巴黎熱門旅遊景點的清單。不包括艾菲爾鐵塔。

反面例子（不該做的事）：
  輸入：列出巴黎的熱門地標。
  輸出：艾菲爾鐵塔、羅浮宮、巴黎聖母院。

使用類比

類比把任務連結到熟悉的事物，幫助模型理解期望的輸出或流程，特別適合創造性任務或解釋複雜角色：

充當「資料廚師」。把食材（資料點）做成一份
「總結菜」（報告），為商業受眾強調主要風味（趨勢）。

因子認知／分解

對於非常複雜的任務，把總體目標分解成較小、較易管理的子任務，分別提示模型執行，再組合子任務的結果。每一步可以獨立驗證與除錯：

提示 1：「為一篇關於 AI 對就業市場影響的論文產生詳細的大綱。」
提示 2：「根據此大綱撰寫引言：[插入大綱]。」
提示 3：「根據此大綱撰寫『對白領工作的影響』一節。」
提示 N：「結合各部分並撰寫結論。」

元方法：用 LLM 改善 LLM 的指令

元方法（meta-method）是將現有提示交給另一個大型語言模型，讓它擔任提示工程顧問，協助找出邏輯盲點與潛在歧義。我們可以提供現有的提示、希望達成的任務，以及目前輸出的範例（含不符合期望的原因），請 LLM 分析並提出改進建議。這代表一種 AI 輔助的自我改善機制——利用模型對語言與模式的理解來優化提示，形成正向增強迴圈：

優化提示範例：
分析以下語言模型提示，並提出改進方法，
以一致地從新聞文章中提取主要主題與關鍵實體
（人物、組織、地點）。目前提示有時會遺漏實體
或把主要主題搞錯。

現有提示：「總結本文的要點並列出重要的名稱和地點。」

檢索增強生成（RAG）

檢索增強生成（RAG）在模型回答前，先從外部資料庫檢索最新文件，動態加入提示的上下文。與其把所有知識塞進提示詞，RAG 讓代理系統保持在最新的資訊狀態，不受訓練資料時點的限制，同時緩解幻覺問題：

使用者查詢：「最新版的 Python 函式庫 X 有哪些新功能？」
系統操作：在文件資料庫搜尋「Python 函式庫 X 最新功能」
提示 LLM：「根據以下文件片段：[插入檢索到的文字]，解釋最新版的 Python 函式庫 X 的新功能。」

角色模式（使用者角色）

前面提到的角色提示把角色指派給模型；角色模式則反過來，描述輸出的目標受眾，讓模型依受眾調整語言、複雜度與語氣：

你正在解釋量子物理，目標受眾是沒有相關知識的高中生。
用簡單的方式解釋，並使用他們可能理解的類比。
解釋量子物理：[插入說明請求]

使用 Google Gems

Google Gems 是 Gemini 內建的可設定功能，每個 Gem 都是核心模型的特化實例，為特定可重複任務量身訂做。建立 Gem 時提供一組明確指令，定義目的、回應方式與知識領域；底層模型會在整個對話過程遵守這些預先定義的指令。例如：

• 一個只解讀特定程式庫的程式碼解釋器
• 一個產生無臆測摘要的資料分析器
• 一個遵循特定風格指南的翻譯者

如此使用者不必在每次新查詢時重建上下文，減少對話冗餘，讓產出穩定符合初始要求，從通用互動轉變為特化的預設 AI 功能。

提示特定任務

程式碼提示

語言模型可產生、解釋、翻譯或除錯程式碼，程式碼提示有多種用例：

有效的程式碼提示需要提供足夠的上下文，指定語言與版本，並明確功能或問題。

多模式提示

當代模型正走向多模式，能跨文字、圖像、音訊、視訊處理與產生資訊。多模式提示組合多種輸入格式指導模型，例如提供圖表圖像並要求解釋圖中描述的流程（圖像輸入＋文字提示），或提供圖像並要求產生描述性標題。

對 UI/UX 的影響

進階提示工程對使用者體驗的影響，體現在三個層面。

第一個層面：提供可觀測的確定性。 傳統介面與 LLM 介面的最大差異，是輸出的不確定性。代理系統在思考、推理、呼叫工具時，若介面僅顯示空白等待畫面，使用者會感到焦慮並失去掌控感。介面應將代理的運作過程視覺化——顯示目前的推理階段、呼叫了什麼工具、取得了什麼結果：

┌────────────────────────────────────────────────┐
│ 研究助理                        ReAct 代理      │
├────────────────────────────────────────────────┤
│ 思考中：釐清使用者的問題需求                   │
│    ├─ 已呼叫工具  get_current_weather          │
│    ├─ 觀察結果   倫敦，18°C，多雲              │
│    └─ 推理進度   ████████░░  80%               │
│                                                  │
│ 最終答案：倫敦目前 18°C，多雲，建議攜帶外套。    │
│ [展開推理軌跡]  [暫停交由人工]  [重新提問]     │
└────────────────────────────────────────────────┘

第二個層面：推理軌跡必須可追溯。 CoT 讓模型的推理過程可被檢視，對除錯與建立信任至關重要。介面應允許使用者展開檢視思考步驟，理解結論的來源。此原則與評估與監測的精神一致，可參考這裡-打造自我品管的 AI 承包商：評估與監測。

第三個層面：驗證失敗要清楚呈現。 當 zod 拒絕格式錯誤的輸出、或代理偵測到資訊不足以回答時，不能讓使用者面對抽象的錯誤訊息。介面應說明「AI 嘗試輸出某種格式但失敗了，已要求重寫」，或「資訊不足，需要更多資料」。

前後端技術怎麼實作

對應上述 UI/UX 需求，前後端的職責分工如下。

後端：將提示管線建置為可觀測的服務

• 以 zod（或其他 schema 驗證工具）在每個代理邊界驗證 LLM 輸出，阻擋幻覺產生的非法格式
• 以分隔符與範本引擎（如 Handlebars 或字串模板）將系統提示、使用者輸入與上下文明確隔離，降低提示注入風險
• 將 CoT、自洽性等技巧設計為可調整參數：temperature、numGenerations、maxTokens、chainOfThought: boolean
• 記錄每次呼叫的推理軌跡（thinking、action、observation、final answer）供前端展開檢視

前端 <──(WebSocket 事件串流)── 提示管線
                                ├─ 上下文組裝（分隔符隔離）
                                ├─ 模型呼叫（CoT / temperature）
                                ├─ zod 驗證 → 失敗則要求重寫
                                └─ 推理軌跡記錄 → 狀態持久化

前端：將推理過程視覺化

• 以階段指示器呈現代理生命週期：思考中、呼叫工具、觀察結果、產生答案
• 以可展開的軌跡樹呈現 CoT 與 ReAct 的每個步驟，失敗的分支標示原因
• zod 驗證失敗時，顯示「已請 AI 重新產生」的提示，而非原始錯誤
• 在執行高運算技巧（自洽性、思想樹）時，顯示預估成本與進度，說明等待的必要性

最佳實踐：把提示當工程資產管理

提示工程是可以透過實務精進的技能。把下列實踐內化成習慣，就能顯著提升代理系統的品質：

總結

提示已不是單純的提問，而是一門嚴謹的工程學科。從零樣本的基礎指令出發，透過打亂順序避免模式偏見；以 zod 將不可預測的散文結構化為精確的資料；以上下文工程為代理建立動態的作戰畫面；以思想鏈強迫模型進行深度推理；以 ReAct 賦予代理與現實世界互動的能力；最後以 DSPy 與元方法實現提示的自動化與自我進化。這一切的演進，都是為了在機率性生成的環境中建立確定性的自動化系統。

將此與更大的脈絡連結：AI 已能透過 DSPy 與元方法，比人類工程師更有效率地測試、評分並優化自己的提示詞，甚至自行推演並定義最佳的推理路徑。當撰寫完美提示這項技能被 AI 徹底掌握時，我們在 AI 系統中的真正價值，將從下達具體指令，轉變為定義終極的目標與意義。這正是提示工程未來最值得投入的方向——不是繼續追求更精準的措辭，而是學會清楚表達「要達成什麼」，讓 AI 自行接手「怎麼達成」。當提示最佳化不再需要人工介入時，真正重要的，是我們如何定義系統所要追求的目標。

參考資料

• Agentic Design Patterns - Appendix A: Advanced Prompting Techniques
• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
• Tree of Thoughts: Deliberate Problem Solving with Large Language Models
• Self-Consistency Improves Chain of Thought Reasoning in Language Models
• ReAct: Synergizing Reasoning and Acting in Language Models
• Large Language Models as Optimizers
• DSPy
• zod