在昨天的文章中，我們建立了Prompt Engineering的核心心法——它不是聊天玄學，而是透過明確邊界與規則來「收斂模型輸出的機率分佈」

然而，在實際開發軟體或Agent系統時，我們不可能每次都手動複製貼上一大串文字到聊天介面。真實業務情境充滿動態變化：用戶名稱不同、查詢歷史不同、業務狀態不同

今天我們進入實戰篇：在工程架構中，我們該如何管理、動態組裝並有效應用這些提示詞？

一、從靜態文字到「動態模板（Prompt Templates）」

在程式碼中，最糟糕的做法就是直接在業務邏輯裡硬編碼（Hardcode）一大串字串
當提示詞越來越長、包含多個變數時，字串拼接（String Concatenation）會極難維護且容易出錯

現代Agent開發普遍採用**模板引擎（Template Engine）**的概念，將靜態邏輯（規則、角色）與動態數據（用戶輸入、外部資料）徹底分離

• 靜態核心（Static Base）：定義模型角色、思考框架與永恆不變的業務限制
• 動態插槽（Dynamic Slots）：預留佔位符（Placeholders），在執行階段（Runtime）動態注入外部上下文

二、實戰範例：動態提示詞模組化設計

以Python為例，我們可以使用結構化模板來管理提示詞：

# 1. 定義可重複使用的基礎模板
SYSTEM_TEMPLATE = """
你是系統的【{node_name}】節點，負責處理用戶的特定操作

# 系統當前狀態
- 用戶 ID: {user_id}
- 會員等級: {membership_tier}
- 當前時間: {current_time}

# 業務邊界規範
{constraints}

# 輸出要求
請以 JSON 格式輸出，結構包含 "status" 與 "next_action"
"""

# 2. 依據不同業務場景動態組裝
def build_node_prompt(node_name: str, user: dict, constraints: list) -> str:
    formatted_constraints = "\n".join([f"- {c}" for c in constraints])
    return SYSTEM_TEMPLATE.format(
        node_name=node_name,
        user_id=user.get("id"),
        membership_tier=user.get("tier"),
        current_time="2026-08-20",
        constraints=formatted_constraints
    )

# 3. 執行階段調用
user_profile = {"id": "USR-9527", "tier": "VIP"}
node_constraints = [
    "VIP 用戶無需收取退貨手續費",
    "若申請金額超過 10,000 元，觸發人工審核"
]

prompt = build_node_prompt("RefundProcessor", user_profile, node_constraints)

透過這種方式，Prompt 變成了標準的函數輸入與物件，能輕易在不同工作流節點間共用與抽換

三、工程化管理三原則：Prompt as Code

當團隊規模擴大、工作流涉及數十個Agent節點時，管理Prompt就如同管理程式碼，需要遵循以下三個工程實踐：

1. 外部化與解耦（Decoupling）

不要將大量 Prompt 寫死在核心業務檔中
建議抽離至獨立的 .yaml、.json 或 Markdown 檔案中管理：

# prompts/classifier.yaml
version: "1.2.0"
description: "客服意圖分流提示詞"
template: |
  你是一名分流助理。
  請將下列訊息分類至指定標籤：{categories}
  用戶訊息：{user_message}

這樣一來，調整提示詞時不需要直接改動程式核心邏輯

2. 版本控制（Version Control）

提示詞的微小改動都可能導致輸出格式改變，進而使下游解析邏輯崩潰
因此，Prompt 必須納入 Git 版本控制，每一次優化都應有對應的Commit Log與Diff記錄

3. 動態 Few-shot 檢索注入

在大規模系統中，預先寫死固定範例可能無法涵蓋所有情境
進階做法是利用向量資料庫動態檢索範例：

• 當用戶問「退貨」相關問題時，系統從範例庫檢索出2筆與「退貨」最相似的高品質範例動態拼入 Prompt
• 當用戶問「發票」問題時，動態抽換為「發票」的示範

這能大幅節省 Token，同時維持極高的針對性。

四、實戰總結：Prompt 在工作流中的角色

在完整的Agent系統中，Prompt Engineering的定位是：

小結與下集預告

掌握了Prompt Engineering與動態模板管理後，我們解決了「如何給模型下指令」的問題。

但在真實的工作流中，模型不可能只看一兩句指令——它需要看對話紀錄、讀取使用者的長篇文件、甚至調用外部檢索的參考資料
這時我們面臨的挑戰變成了：Context 視窗有限、Token 成本昂貴、過長的上下文會讓模型迷失方向（Lost in the Middle）

明天 【Day 4】甚麼是 Context Engineering，我們將從Prompt邁向更大的系統視角，探討現代Agent工程如何精準管理與調度模型所看見的「上下文」！