（2026年2月5日 更新）關於提示詞框架、提示詞怎麼寫、提示詞技巧，相關文章幾乎每隔一段時間就會出現一次。隨著模型能力不斷進化，其中不少技巧隨著時間可能逐漸失效，或變得沒那麼必要。
EgentHub 作為 AI 企業導入的專家，我們在真實專案現場反覆驗證、實際使用、並持續調整後，整理了10項提示詞技巧與各位讀者分享，❗❗也限時贈送 8 大場景Agent體驗與企業級提示詞，錯過可惜❗❗有別於一般提示詞的分享文章，我們依照設計思維、撰寫技術與迭代修正三個層次：
- 「想」好提示詞：提示詞設計的心法
- 「寫」好提示詞：提示詞撰寫的技術
- 「改」好提示詞：提示詞修改的技巧
EgentHub限時活動：8大企業場景Agent與企業級Prompt免費送
「想」好提示詞
怎麼設計提示詞的整體架構？
動手寫Prompt之前，先想清楚這個 Agent 被允許做到什麼程度。角色定位、任務邊界、資料來源與風險承擔方式，都應在這個階段被明確定義，若想得不夠清楚，後面寫得再細，也只是在放大不確定性。
1.要有框架，但不要被框架綁死
- 說明：在設計提示詞或 Agent 時，不論採用的是 ICIO、CRISPE、RASCEF，或其他命名各異的提示詞框架，本質上都在回答三個問題：這隻AI Agent 是誰、要做什麼，以及要怎麼做。框架本身並不是目的，而是一種確保AI能力能被有效限定。
- 原因：沒有框架的提示詞，往往是即興拼湊而成，容易在角色、任務與執行方式之間出現空白或衝突。框架提供的是一種思考順序，協助設計者在動筆前先釐清邊界與責任分工。雖然不同框架的名稱與切分方式各不相同，但設計邏輯大致相同；真正重要的不是完全套用格式，而是內化這種先定義角色與行為，再要求輸出的設計邏輯。
- 範例(會議記錄助手)
## 定位
你是我的會議記錄整理助手，擅長把口語內容整理成可執行的結論。
## 目標
我會貼上一段會議逐字稿，請你整理成「決議、待辦、風險、後續追蹤」。
## 資料來源
- 你只能依據我提供的逐字稿內容，不要補外部資訊
- 若逐字稿內沒有提到的事項，不要自行推測
## 整理方式
- 先抓出會議結論與共識，再整理待辦事項
- 待辦必須包含負責人、期限；若缺漏請用「待補」標記
- 將模糊語句改寫為可執行描述，但不得改變原意
## 輸出
請用以下 Markdown 結構輸出：
```
### 決議
- ...
### 待辦
| 事項 | 負責人 | 期限 | 備註 |
|------|--------|------|------|
| | | | |
### 風險與未決問題
- ...
### 下次會議建議確認
- ...
```
### 提醒
- 若逐字稿內容矛盾，請列出矛盾點並標註「需澄清」
- 若資訊不足以填表，請保留欄位並以「待補」填入，不要捏造
2.長鏈任務拆解為多步驟
- 說明：當任務涉及多層判斷、整理與產出時，應避免一次要求模型完成所有事情，而是將流程拆解為 Stage 1／Stage 2／Stage 3 等多個步驟。每個階段只負責單一明確目標，且輸出格式需保持一致，能直接作為下一階段的輸入，而不需要額外轉換。
- 原因：長鏈任務若一次交由模型處理，容易在中途偏離目標，且錯誤難以追蹤。分段設計能有效降低失控風險，讓每個階段的結果都可以獨立驗收或重跑，將問題隔離在單一環節中修正，也更容易針對特定階段優化效能與成本。
- 範例（資料比對與計算）
## 執行步驟
### Stage 1：讀取進貨單
請讀取進貨單資料，並輸出以下欄位：
| 料號 | 進貨量 |
|------|--------|
### Stage 2：計算用量
請讀取產線記錄表，
依料號彙各時間區段的總使用數量，
並維持以下欄位結構：
| 料號 | 用量 |
|------|-----|
# Stage 3：產出庫存記錄表
請在不更動欄位名稱的前提下，
以 進貨量-用量 計算庫存數量，
並以 Markdown 表格輸出最終結果：
| 料號 | 進貨量 | 用量 | 庫存 |
|------|--------|------|------|
3.設計 HITL流程
- 說明：在提示詞或 AI 工作流程中，建議主動設計人類介入（HITL）的檢查點，於關鍵節點要求人工審核、確認或決策，而非讓模型從頭到尾自動完成所有步驟。這些檢查點無固定形式，可以是部分資料的抽查、格式檢驗、是否可進入下一階段，或是否需要人工修正後再繼續等。
- 原因：AI 並非 100％ 正確的萬能工具，尤其在高風險或高影響任務中，若缺乏人類介入機制，錯誤往往會被一路放大並流入正式流程。透過 HITL 設計，可在關鍵節點建立可控性，讓責任歸屬、合規審查與最終決策仍掌握在人類手中。人機協作仍是目前AI最可被信任與擴展的工作模式。
- 範例（銷售分析報告）
# 執行步驟
## Stage 1：初步分析
讀取銷售數據報表，從每個月的銷售數據分析趨勢並產出潛在問題
初步產出：
1.問題摘要
2.關鍵假設
3.初步建議。
- 用戶確認：
- 問題定義是否正確
- 是否有遺漏的重要限制條件
- 確認完成才得以進入下一步驟
## Stage 2：完整產出
根據 Stage 1輸出結果，產出完整分析與建議方案。
「寫」好提示詞
怎麼把腦中的需求轉成可被穩定執行的結構？
寫提示詞的目的是把需求轉換為 AI 能反覆理解且一致執行的規格。透過結構化段落、明確的輸出格式、清楚的規則與範例，設計者才能確保每一次輸出具有一致性，而不是每次看似合理卻難以重複使用。
4.使用 Markdown 格式
- 說明：撰寫提示詞時，建議一律採用 Markdown 格式，透過標題、段落與清單，將不同層級的指令清楚分段，而不是以單一長段文字描述所有需求。這能讓提示詞本身具備可閱讀、可掃描的結構。
- 原因：Markdown 對一般使用者而言是一種直覺、好學且低學習門檻的格式，多數寫作者與工程師都已熟悉其語法，能快速理解與修改提示詞內容；而對 AI 來說，Markdown 則具備明確的結構化特性，有助於模型辨識指令層級、優先順序與角色分工。這種同時對人類與模型友善的特性，使 Markdown 早已成為 AI Agent 領域中最通用的提示詞格式。
延伸閱讀:科技報橘《Markdown 如何征服世界，成為 AI 世界共通語言？》
- 範例（撰寫一篇科技產品介紹文章）
# 任務目標
請協助撰寫一篇科技產品介紹文章，受眾為一般3C讀者。
## 寫作風格
- 語氣專業但不艱澀
- 避免行銷式用語
- 每段落為完整論述
## 必須包含
- 產業背景說明
- 技術影響分析
- 未來趨勢觀察
## 禁止事項
- 不使用條列式堆疊短句
- 不直接翻譯英文原文
5.將判斷規則結構化
- 說明：當提示詞中需要處理分類、判斷或對應規則時，建議使用結構化表格或是條列式說明來呈現條件與結果，而不是以文字段落的方式描述判斷邏輯。將規則轉換為表格後，每一列即是一條可被明確比對的規則，能有效避免語意重疊或理解偏差。
- 原因：以自然語言描述規則，往往隱含模糊空間，在複雜的條件下，LLM容易因不同理解下產生歧義。使用條列式說明或是結構化表格呈現判斷規則時，AI更能穩定執行。
- 範例(打卡紀錄表分析)
### 打卡紀錄讀取邏輯
| 上午打卡紀錄 | 下午打卡紀錄 | 標記 |
|------------|-----------|------|
| 晚於 8:00 | | 遲到 |
| | 早於 17:00 | 早退 |
| 無資料 | 無資料 | 異常 |
6.提供資料範例
- 說明：在定義好輸入與輸出的規則後，再提供少量「正確範例」，直接示範資料應該如何被理解與處理。這些範例可以是最終結果，也可以刻意呈現中間處理後的樣貌，讓模型清楚知道哪些轉換邏輯才是期望行為。
- 原因：當任務涉及格式轉換、資料清洗或隱含規則判斷時，即使定義了判斷方式、格式，仍有機會出現意料之外的錯誤，因此輔以實際範例，等於把處理邏輯具體化，讓模型不必猜測意圖。這種示範式設計特別適合資料拆解、單位轉換等場景，能有效提升一致性，並降低錯誤被放大的風險。
- 範例（金額欄位資料清洗）
## 單價欄位提取
### 規則
- 金額統一轉為以下格式
- XXX,XXX元 (每三位數加上半形逗號)
- 空白、N/A、Null 視為缺失值
- 無法判斷的文字標記為 「異常」
#### 範例
1.
輸入：$1,200
輸出：1,200元
2.
輸入：2300
輸出：2,300元
3.
輸入：待確認
輸出：異常
7.明確指定輸出格式
- 說明：在提示詞中，應先定義清楚期望的輸出格式，例如固定的表格欄位、段落結構，或可直接使用的文字排版，而不是僅描述「請分析」、「請整理」這類開放式要求。先有結構，再填內容，是提示詞設計中極為關鍵的一步。
- 原因：當輸出格式未被明確規範，模型會以「看起來合理」為目標自由發揮，導致每次回傳結果形式都不相同，難以比對、解析或後續使用。指定格式能讓輸出結果具備一致性與可驗收性，確保內容可以被程式解析、流程串接或直接進入工作流程。對人類來說，明確的結構也有助於降低理解與檢查成本。
- 範例（產品錯誤分析報告）
## 輸出格式
請依照以下表格格式回傳結果，不要加入額外說明文字：
```
《XXX 錯誤回報分析》
時間：XXXX 年 XX 月 XX 日
錯誤回報數：X 筆
| 欄位 | 說明 |
|------|------|
| 問題摘要 | 以一句話描述核心問題 |
| 關鍵原因 | 條列 2–3 個主要原因 |
| 影響層面 | 對使用者或系統的影響 |
| 建議行動 | 可執行的下一步建議 |
```
8.宣告可用資料與工具邊界
- 說明：在 Agent 或提示詞設計中，無論實際使用了 RAG、MCP、Function Call，或其他工具機制，都建議在一開始就清楚宣告「模型可以使用的資料來源與工具範圍」，並明確說明特定情境下應使用哪一種工具或資料，避免LLM誤用或省略。
- 原因：若未明確限制資料與工具來源，模型在面對資訊不足時，往往會自行補齊看似合理的內容，形成難以追溯的幻覺。透過事前定義可用範圍，能讓輸出結果具備可追溯性與可稽核性。同時，當資料不足時，也能自然銜接到固定回報格式或 HITL 流程，而不是默默產出錯誤答案。
- 範例（知識問答與MCP串接）
## 工具清單
本任務中，你能使用以下資料與工具：
- 向量資料庫：company_docs_v1
- MCP工具：gmail_mcp
###回答使用者問題時
- **必須查詢**向量資料庫再作回答
- 若查無相關資料，請明確回覆「資料不足，無法回答」
- 不得使用外部知識或自行推測
###當任務涉及寄送電子郵件時：
- 請一律使用 gmail_mcp
- 不需自行生成寄信流程或模擬結果
「改」好提示詞
怎麼讓提示詞更貼近我的需要？
再完整的提示詞，也需要透過實際測試才能驗證是否可靠，當輸出不符預期時，重點不在一次改到完美，而是建立測試、調整、再驗證的節奏，逐步校正行為。讓模型參與提示詞修正，能加速這個過程，但前提是整個迭代仍由人類掌握方向與節奏。
9.讓 Agent 設計走在可控的迭代循環中
- 說明：任何提示詞或 Agent 的設計，幾乎都是從一個具體需求開始。寫出第一版 prompt 之後，不應直接投入正式使用，而是先進入小規模測試階段，選擇幾筆具有代表性的範例資料，觀察輸出是否真的符合原本的期待。若結果不理想，就回到提示詞本身進行微調，再重新測試，如此反覆，直到行為穩定可預期。
- 原因：若缺乏明確的測試與回饋循環，每一次修改都可能引入新的不確定性。透過「撰寫 → 測試 → 調整 → 再測試」的迭代節奏，設計者能清楚知道是哪一次改動帶來行為變化，避免在正式上線後才發現Agent不夠穩定，造成損失。
- 範例（Agent 設計的基本迭代流程）
1. 定義需求與任務邊界
2. 撰寫初版 prompt
3. 使用少量測試資料驗證輸出行為
4. 若結果不符預期，微調 prompt
5. 重複測試直到輸出穩定
6. 確認後才正式上線使用
10.讓模型幫你調整提示詞
- 說明：當Agent的提示詞需要調整時，與其憑直覺自行手動修改，不如將現有 prompt 直接交給模型，告知你目前的需求，請他重新設計與告知修改段落，並確保不會造成與其他段落的邏輯互斥。
- 原因：LLM 對語意結構與潛在衝突的敏感度，往往高於人類直覺。特別是在多次迭代後，提示詞通常已累積大量隱含假設與例外規則，人類很容易「以為自己記得」，卻忽略真正寫下來的是什麼。讓模型進行提示詞檢視，能在測試階段就提前暴露不穩定來源，避免錯誤一路被帶進正式上線環境。
- 範例（與AI對話的提示詞修改模板）
請協助調整一份提示詞，以下是我目前的版本以及我想修改的幾個重點。
請你先完整讀完這份提示詞，
再根據我列出的調整事項，告訴我「哪些段落需要修改」，以及「建議怎麼改」。
在提出修改建議的同時，
也請順便檢查整份提示詞是否存在邏輯不一致、規則衝突或容易產生歧義的地方。
以下是我想調整的事項：
- （調整事項 1）
- （調整事項 2）
- （調整事項 3）
這是目前使用的提示詞：
（貼上你的 prompt）
如果你的企業正在思考導入AI，建立專屬於自己公司 AI Agents，EgentHub 作為專業的AI Agent服務商，除了擁有企業級AI Agent管理平台，也有一套完整的AI Agentf企業導入計畫，讓企業從需要顧問陪跑到員工 AI 賦能，形成自己的AI企業文化。
EgentHub限時活動：8大企業場景Agent與企業級Prompt免費送
