昨天我們聊到了現代AI開發的典範轉移——從訓練、微調，演進到了如今以「工作流」為核心的時代

既然要談工作流，整個Agent系統與LLM互動的最前端輸入，就是 Prompt（提示詞）

很多人剛接觸大型語言模型（LLM）時，會覺得Prompt Engineering（提示工程）不過就是「把中文講清楚一點」、「多加幾句禮貌的話」，但在軟體工程與 Agent 系統中，Prompt Engineering 的定位遠不止於此

那到底什麼是Prompt Engineering？

一、Prompt Engineering 的本質：為不確定性建立「約束邊界」

LLM 本質上是一個機率預測器（Token Predictor）——它根據你給予的上文（Context），預測下一個最可能出現的詞

如果你給予的輸入模糊、自由度過高，模型的輸出就會呈現發散的機率分佈，這在創意寫作時是優點，但在系統中卻是災難：

• 輸出格式忽開忽閉（有時給JSON，有時附帶閒聊）
• 容易產生幻覺(或是自圓其說、創造不存在的規則)
• 無法穩定觸發特定邏輯分支
  

Prompt Engineering 的本質：
不是「寫出好文章」，而是透過精準的結構、規則與約束，壓縮模型的機率分佈，讓非確定性（Non-deterministic）的大語言模型在特定任務下產生高度穩定、符合預期的輸出

二、核心技術矩陣：常見的 Prompt 技術有哪些？

在構建工作流時，有幾種經典的 Prompt Engineering 技巧最常被組合使用：

1. Role & Persona Prompting（角色與視角設定）

賦予模型特定的身份與背景，限制其語氣與領域知識範圍。

• 普通寫法：

  「請幫我檢查這段Code有沒有Bug」

• Engineering 寫法：

  你是一名專精於Python與分散式架構的資深後端工程師 (告知LLM角色定位)
  請以嚴格的Code Review視角審查以下程式碼，專注於：

  1. 潛在的Race Condition
  2. 記憶體洩漏風險
  3. 異常處理是否完整

2. Few-Shot Prompting（少樣本學習）

不只給予規則，直接在 Prompt 中提供 1~3 個「輸入 ➔ 輸出」的標準範例
可以做為需要固定輸出格式或特定分類任務的參考，加強LLM知道應該以甚麼格式或方式完成任務

範例：

• 用戶輸入: "為什麼我這個月被多扣了50元？" ➔ 分類: 帳務
• 用戶輸入: "App一直跳出500錯誤代碼" ➔ 分類: 技術支援
• 用戶輸入: "請問你們週末有營業嗎？" ➔ 分類: 諮詢
• 輸入："您好，想請問商品可以換顏色嗎？"
  輸出：{"intent": "EXCHANGE_INQUIRY", "order_id": null, "sentiment": "NEUTRAL"}

3. Chain-of-Thought (CoT，思維鏈)

對於需要多步驟推理解析的問題，強迫模型在輸出最終答案前「一步步思考（Think step by step）」

LLM 依靠前文推導後文，如果直接要求它給出最終答案，計算資源（Token）不足以支撐內部推理；讓它輸出推理步驟，能大幅降低邏輯錯誤率

三、工程化視角：一個合格的System Prompt該具備什麼？

在開發Agent工作流時，我們通常不會寫一段散文式的Prompt，而是採用 模組化區塊（Block-based） 來設計：

[區塊 1] 角色定義 (Role & Goal)

你是訂單處理工作流中的「意圖解析節點」，負責將用戶自然語言轉化為標準結構

[區塊 2] 上下文與邊界 (Context & Constraints)

• 你只能處理與「退貨、換貨、查訂單」相關的請求
• 若用戶詢問與業務無關的問題，一律回傳特定錯誤代碼
• 嚴格禁止自行捏造訂單編號或用戶資訊

[區塊 3] 輸出規範 (Output Format)

請直接輸出符合標準格式的 JSON 字串，不要包含任何多餘的解釋文字：

{
"intent": "RETURN | EXCHANGE | TRACK",
"order_id": "string or null",
"reason": "string or null"
}

[區塊 4] 範例示範 (Few-shot Examples)

用戶輸入: "我的衣服尺寸太小了，想要換大一號，訂單編號是 #A1234"
解析輸出:
{
"intent": "EXCHANGE",
"order_id": "A1234",
"reason": "尺寸太小想換大一號"
}

四、常見誤區：容易踩的陷阱，千千萬萬要避開!

1. 過度客氣與贅詞：
   寫「請你幫幫我、麻煩你了」只會佔用Context Window的Token，對模型執行任務沒有任何實質幫助，因此別怕不禮貌的詢問會導致LLM們找你報仇
   
2. 否定句陷阱（Negative Constraints）：
   告訴模型「不要做什麼」，往往不如明確告訴它「遇到此情況時請做什麼」
   例如：「不要回覆太長」➔「請在 3 句話、50 字以內回覆完畢」
3. 把Prompt當無敵：
   如果一項任務需要即時數據、精密運算或極高嚴謹度，單靠Prompt是不夠的，這正是後續需要 Tool Calling、RAG 與 Harness 介入的原因

小結與下集預告

Prompt Engineering是現代Agent的「控制面板」，它是最便宜、最快速調整模型行為的手段

理解了基本概念後，在真實的軟體系統中，我們不可能手動在UI裡貼Prompt
明天 【Day 3】怎麼應用Prompt Engineering，我們將進入實戰，探討如何在程式碼架構中動態組裝提示詞、管理模板（Template），以及如何將提示詞模組化嵌入到自動化工作流中！