7.1 提示工程的基礎與進階#

從「指令」到「Agent」#

本書第一篇建立了傳統軟體工程的骨幹。從本章起，我們進入本書的差異化核心——AI 工程。而一切的起點，是理解如何與大語言模型（LLM）互動。

早期的人們發現：LLM 的能力，很大程度取決於你「怎麼問」。同樣一個模型，問法不同，回答品質天差地別。這催生了 提示工程（Prompt Engineering）——研究「如何設計指令（Prompt）來引導 LLM 產生高品質輸出」的技術。

本章的主軸，是一個重要的演進：

從多少「提示工程」，進化到更根本的「上下文工程（Context Engineering）」——因為決定 LLM 能力上限的，不只是「指令怎麼寫」，更是「模型看到的上下文是什麼」。

先掌握把一個 Prompt 寫「好」的基礎。好的 Prompt 通常包含三個層次：

給模型設定角色，能引導它的輸出風格與專業程度。

你是一位資深軟體架構師，專精於分散式系統。
請為我評估下面的架構設計，並指出其中的風險。

為什麼有效：角色設定「激活」模型在訓練資料中對應的模式——「架構師」會喚起架構師的口吻與知識，而「初學者」則喚起教學式的口吻。

任務要具體、明確、可執行。模糊的「幫我分析一下」遠不如「列出這個架構的 3 個可擴展性風險，並各給 1 個改進建議」。

格式能讓輸出可預期、好解析。指定標題、列表、JSON、或表格。

請用 JSON 格式回覆：{ "risks": [...], "suggestions": [...] }

在基礎之上，有幾個能顯著提升效果的進階技巧：

不要只「描述要做什麼」，而是給一兩個「示範」的輸入-輸出例子，讓模型模仿。

請將以下中文句子翻譯成英文，並附上簡短的確信度分數。

範例：
輸入：這個方案很有前景
輸出：This plan is very promising. (確信度: 0.95)

輸入：刪庫跑路
輸出：

Few-Shot 特別適合「難以用規則描述、但一看例子就懂」的任務。

要求模型「一步步推理再給答案」，能顯著提升需要多步驟邏輯的任務準確率。

小明昨天用了 200 元，今天又用了 300 元，他原本有 1000 元。
請一步步推導，他現在剩多少？

CoT 讓模型把「隱藏的推理步驟」具體化，減少跳步錯答。這在需要數值、邏輯、推理的任務上效果明顯。

對同一問題讓模型多次推理，然後投票取最常見的答案。透過「多次獨立思考 + 多數決」，降低單次推理的隨機錯誤。

讓模型「輸出推理與行動」的結構，是通向 Agent 的橋樑（見 8.4 節 ReAct）。它讓模型不只是「答」，而是「邊想邊做」。

提示工程很有效，但它有一個根本瓶頸：它只調整「指令」，而指令只是模型所見上下文的一小部分。一個更深的事實是——

模型的知識與能力是被「凍結」在參數裡的（在訓練時就被決定了）；Prompt 無法治療「模型不知道的事」。

具體的極限案例： - 模型的知識截止：你問它「今天的新聞」，模型不知道——因為它的知識停在訓練時 - 模型不知道你的私有事實：你的專案規格、你的程式庫、你的業務規則——模型參數裡根本沒有 - 模型看不見你的檔案：要讓它「看懂你的程式碼」，你得把程式碼「放進它眼前」

這些限制，都不是「把 Prompt 寫得更好」能解決的，而是要把更多的資訊「塞進上下文」——這正是上下文工程要解決的（7.2 節）。

一句話：提示工程教我們「怎麼用好指令」；而我們的眼光，很快要放到更浩瀚的「怎麼讓模型看到它該看的一切」——上下文工程。

在 Agent 與程式設計的場景（附錄 B 的 OpenCode 等），提示工程有了新的延伸：

「寫給 AI 的說明書」：像 4.4 節的 AGENTS.md（附錄 B.3），是「長期有效」的提示——告訴 AI「你是誰、在這個專案該怎麼做、規範是什麼」
可重用提示：把常用的優秀 Prompt 整理成可重用的「技能/指令」，避免每次重寫
與工具結合：提示不只描述任務，還描述「可用哪些工具、該如何用」（8 章）
約束與防禦：提示中要避免指令被使用者輸入干擾（13.1 節的提示注入）