Prompt-Engineering

Properties2
tags狀態/草稿
aliasesPrompt Engineering, 提示詞工程, 提示語設計, 提示语设计

閱讀時間約 16 分鐘

Prompt-Engineering

一句話定義

設計與優化給 LLM 的指令（prompt）以引導其生成期望輸出的實踐。

核心要點

  • 基本結構：提示語通常包含指令（Instruction）、上下文（Context）與期望（Expectation）。指令定義要做什麼，上下文補足背景，期望規範輸出形式與品質標準。
  • 三個實務問題（2026-05-13-Stanford-AI系統課程）：好的 prompt 至少要交代「給誰看」「產出格式」「重點是什麼」。例如「總結文章」太空泛；「將再生能源論文整理成 5 個重點，聚焦政策意涵，給政策制定者看」會讓模型更容易對齊受眾、長度與判準。
  • 使用前先分清任務姿勢（2026-07-30-閱讀前哨站-AI判斷力）：先問這次要的是「成果」還是「過程」，材料來自「內在」還是「外在」。成果型任務要盯交付格式、條件與事實；過程型任務要保留釐清、被挑戰與自我看見。這讓 prompt 設計不只追求更快產出，也能選擇讓 AI 成為 AI陪練。
  • 任務邊界意識：BCG 顧問實驗中的 Jagged Frontier 提醒，AI 不是所有任務都加分；若任務剛好在模型弱區，使用者又過度信任輸出，結果可能比不用 AI 更差。
  • Centaur / Cyborg 切換：重複性高、流程清楚的任務可用 Centaur 式委派；需要判斷、創意與來回校正的任務更適合 Cyborg 式高頻協作。
  • 提示類型：指令型、問答型、角色扮演型、創意型、分析型、多模態提示語。
  • 元素分類：資訊類元素決定要處理什麼內容；結構類元素決定輸出如何組織；控制類元素負責約束、驗證、迭代與品質管理。
  • 模型適配：對 推理模型，提示語應清楚表達目標、資料、約束與評估標準，避免過度拆解或角色扮演干擾模型推理；對通用模型，則常需要更明確的分步引導、示例與結構化輸出規範。
  • 迭代觀：不要期待一次提示就完美；從基礎提示開始，根據輸出缺陷逐步補充資料、約束與驗證要求。
  • 第一版策略「從無約束逐步加約束」（2026-05-02-Agent神文沒告訴你的事）：
    1. 不要把第一版寫成複雜說明書 —— 抄成熟項目的專業 prompt 兩秒翻車：效果沒更好、token 消耗爆炸
    2. 先寫沒有限制條件的版本 → 看模型怎麼做（建立 baseline 認知）
    3. 再不斷添加限制條件 —— 更格式化 / 哪部分多思考 / 提供例子
    4. 過關信號：只要 Agent 能 follow 指令、一步步往上加東西它能照做 → prompt 這關就過了
    • 典型反例：只想做視覺設計，原本一句「你是一個視覺設計師，給我一個方案」就快能用 → 把專業提示詞一股腦丟進去 → 開始拆步驟、規劃流程、一步步執行 → 更慢、不一定更好
  • Prompt 已經到頂仍做不好的判斷（2026-05-02-Agent神文沒告訴你的事 階段 3 觸發信號）：
    • 「很多時候它做不好不是系統提示詞寫得不夠好，而是這個任務本身需要的能力它根本就沒有」
    • 正確動作不是再改 prompt，是 加工具——例如要參考網上資料但拿不到 → 加搜索工具；要寫可用代碼但無法驗證 → 加驗證工具
    • 對位 Agent複雜度演化 階段 2 → 3 的觸發點。
  • 角色映射 × 領域：實務上先判斷任務需要哪一類協作者，再設計 prompt——本庫已累積兩個領域的角色清單：
  • CLI-agent 場景的三條負空間 prompt 原則（Claude-Code / 2026-04-30-Claude-Code完整教程）：駐留 agent 環境下，prompt 重心從「正向描述需求」延伸到「框住自由度」：
    1. Be specific：「build me an auth system」會產出過度設計的版本；「Build email/password auth using existing User model, store sessions in Redis with 24-hour expiry, add middleware that protects /api/protected」才有清晰目標。
    2. Tell what NOT to do：模型有偏好（例如 Claude 4.5 傾向過度設計、多檔案、不必要的抽象），要主動關閉：「Keep this simple. Don’t add abstractions I didn’t ask for. One file if possible.」
    3. Tell why（給原因）：「We need this to be fast because it runs on every request」改變模型的解法選擇；「This is a prototype we’ll throw away」改變權衡尺度。模型無法讀懂沒被講出來的限制條件。
  • Long-running agent 的 Goal-Prompt（2026-05-25-Gary-Chen-AI-Agent-27小時-Goal功能）：當 prompt 對象不是一次性回答，而是 /goal 類長任務 agent 時，指令要升級成 Goal-Prompt：outcome / verification / constraints / iteration policy / error handling。否則 agent 會自己定義 done，通常過早 wrap up 或做出使用者不認可的「完成」。
  • Plan mode 即「對話之外的 prompt 設計」：Claude-Code 的 Shift+Tab plan mode 把 prompt engineering 從「一句話寫好」推到「先讓 AI 產出實作計畫並等使用者確認，再進入修改」——本質上是在主對話前插入一輪 Prompt-Chaining 的 plan-then-execute 結構。
  • 創意產出迭代範式（散彈 → 收斂 → 變體）：
    1. 散彈：先要 N 個粗糙版本（不給太多方向，看 AI 默認思路）
    2. 收斂：給明確方向（風格 / 情緒 / 反差 / 連結點）再要 N 個
    3. 變體：選定一個版本後要求「優化 + N 種版本」做 A/B 對比
    • 來源：2026-04-30-Indie-Creative-035-AI行銷企劃 以實際 prompt-response 對話展示這個迭代範式；對位開發領域的「先給最小複現 → 拆解假設 → 逐一驗證」迭代範式，兩者都是 prompt engineering 的「迭代觀」在具體領域的展開。
  • 多輪上下文累積是迭代的前提：ChatGPT 等對話式產品保留同一段對話的歷史 prompt——好的 prompt 設計要把「歷史 prompt = 延伸 context」納入考量，後續追問可以省略已知狀態。
  • 可靠性：提示語設計不只追求生成品質，也要處理 AI-幻覺、偏見、倫理邊界與可驗證性。
  • 與 Context-Engineering 的關係：是 context engineering 的子集 / 起點。Context engineering 把焦點從單一 prompt 擴展到整個 context window 內所有元素的 curation（系統提示、記憶、工具回應、結構化輸出等）。
  • 三詞演化軸：Prompt → Context → Harness（2026-05-02-Harness-Engineering駕馭工程 李宏毅 整理）：當代 LLM 已經不只是一問一答，而是與環境多輪互動完成任務。三個詞重疊但各自關注的核心問題不同——
    • Prompt-Engineering：「該怎麼說」（一句話怎麼下，本頁主題）
    • Context-Engineering：「window 怎麼管」（整個 context window 內所有元素怎麼 curate）
    • Harness-Engineering：「多輪互動 + 工具 + feedback loop 整體怎麼跑」
    • 三層職責再分工：本頁繼續是 prompt 層的細節主述頁；harness 層的「Natural Language Harness」（如 2026-05-02-Harness-Engineering駕馭工程 中 李宏毅 用不到 80 字的工作原則就讓 Gemma 4 2B 從幻想變正常 agent）依然落在「該怎麼說」這軸，但放在 AGENTS.md / CLAUDE.md 等常駐配置檔中作為每次都進 prompt 的法律。
  • OpenAI 「AGENTS.md 是地圖、不是六法全書」原則（OpenAI 2025-02 Harness Engineering blog）：常駐配置檔不能塞滿——百科全書式的 AGENTS.md 表現極差，因為 context 全被吃掉；要告訴 agent「想知道什麼去哪裡找」，不是把所有規則塞進去。這是 prompt-engineering 在常駐配置層的關鍵紀律。
  • Prompt 與 Context 的精確區分（2026-05-02-AI-Agent-Context-Engineering系統化 李宏毅 整理）：
    • Context = AI Agent 經歷過的一切（含進到 LLM 的 P 部分 + 存在硬碟的 M 部分）
    • Prompt = Context 中真正進到 LLM 那一段（= P）
    • 上課 / 文獻常混用，但精確上 Prompt ⊊ Context——Prompt-Engineering 處理「P 怎麼寫」、Context-Engineering 處理「整個 (P, M) 怎麼演化」、Agent-Memory 處理「M 怎麼存 / 怎麼讀回 P」。
  • 「用 prompt engineering 來做 context engineering」（Agentic-Context-Engineering 流派的本質）：當把 context 演化函式 F 也交給 LLM 自己做時，工程量真正落在「怎麼寫教 LLM 整理 context 的 meta-prompt」——所以 ACE / Dynamic Cheatsheet / Recursive Language Model 等 paper 的核心都是 prompt engineering 的延伸應用。
  • 駐留 agent 場景的職責分工（Claude-Code 等 CLI-agent）：兩者在工具堆疊中各管一段，避免重疊：
    • Prompt-Engineering 負責「該說什麼」：CLAUDE.md 內容書寫、plan mode 指令、custom slash commands 模板、單次任務的指令 / 上下文 / 期望結構（含負空間三原則 Be specific / NOT to do / Why、散彈→收斂→變體迭代範式）。
    • Context-Engineering 負責「window 怎麼管」：session 容量監測（20-40% 起劣化）、外部記憶體跨 session 持續、scope 對話、複製貼上重置、果斷 /clear 等動作層做法。
    • 交界點：CLAUDE.md 是兩者共管——內容屬 prompt engineering（怎麼寫），載入時機與上下文成本屬 context engineering（什麼時候會被注入、佔多少 window）。

與其他概念的關係

  • 被 Context-Engineering 擴展為更全面的實踐。
  • 模型例子：DeepSeek 的 DeepSeek-R1 在新來源中被用作 推理模型 代表，顯示 prompt engineering 需要隨模型類型調整。
  • 可透過 Prompt-Chaining 把大型任務拆成連續步驟，並在中間加入檢查點與回饋。
  • 與 推理模型 共同決定任務品質：模型選型錯誤時，提示語只能部分補償；模型選型正確時，提示語負責把需求、資料與標準表達清楚。
  • 與 知識喚醒 關係密切：好的提示語可以用提問、類比、反常視角與情境回溯，喚醒人的隱性經驗。
  • 與 AI陪練：後者把 prompt engineering 往人機互動姿勢推進；提示語不只是讓 AI 代打產出，也可以設計成反問、反對、模擬與回饋，讓人保留判斷 reps。
  • 與 AI-幻覺 形成品質控制關係：提示語應要求模型區分事實與推測、提供來源、標示不確定性。
  • 在 AI輔助開發 中具體化為任務分類與角色指定：先確認是轉置、配置、翻譯、諮詢或除錯，再提供相應輸入與成功標準。
  • 在 AI輔助創意 中具體化為「散彈 → 收斂 → 變體」迭代範式：先試水溫，再給方向，最後做 A/B；驗證機制由人主觀判斷可用性而非外部測試。
  • 與 Goal-Prompt：後者是 prompt engineering 在 long-running agent 場景的任務規格格式，特別強調驗證、限制、迭代政策與停損。

相關來源

備註

反向連結