目錄
關於提示詞框架、怎麼寫、有哪些技巧，相關文章幾乎每隔一段時間就會出現。隨著模型能力不斷進化，其中不少技巧可能逐漸失效或變得不再必要。
以下整理了 10 項在真實專案現場反覆驗證、持續調整後歸納出的提示詞技巧，依照設計思維、撰寫技術與迭代修正三個層次，系統性拆解提示詞如何在實務中真正發揮作用。
「想」好提示詞：設計心法
動手寫 Prompt 之前，先想清楚這個 Agent 被允許做到什麼程度。角色定位、任務邊界、資料來源與風險承擔方式，都應在這個階段被明確定義。若想得不夠清楚，後面寫得再細，也只是在放大不確定性。
1. 要有框架，但不要被框架綁死
不論採用 ICIO、CRISPE、RASCEF 或其他提示詞框架，本質上都在回答三個問題：這隻 AI Agent 是誰、要做什麼，以及要怎麼做。框架本身不是目的，而是確保 AI 能力能被有效限定的方式。
沒有框架的提示詞往往是即興拼湊，容易在角色、任務與執行方式之間出現空白或衝突。框架提供的是一種思考順序，協助設計者在動筆前釐清邊界與責任分工。真正重要的不是完全套用格式，而是內化「先定義角色與行為，再要求輸出」的設計邏輯。
## 定位
你是我的會議記錄整理助手，擅長把口語內容整理成可執行的結論。
## 目標
我會貼上一段會議逐字稿，請你整理成「決議、待辦、風險、後續追蹤」。
## 資料來源
- 你只能依據我提供的逐字稿內容，不要補外部資訊
- 若逐字稿內沒有提到的事項，不要自行推測
## 整理方式
- 先抓出會議結論與共識，再整理待辦事項
- 待辦必須包含負責人、期限；若缺漏請用「待補」標記
2. 長鏈任務拆解為多步驟
當任務涉及多層判斷、整理與產出時，應避免一次要求模型完成所有事情，而是將流程拆解為 Stage 1 / Stage 2 / Stage 3 等多個步驟。每個階段只負責單一明確目標，且輸出格式保持一致，能直接作為下一階段的輸入。
長鏈任務若一次交由模型處理，容易中途偏離目標且錯誤難以追蹤。分段設計能有效降低失控風險，讓每個階段的結果都可以獨立驗收或重跑，將問題隔離在單一環節中修正。
## 執行步驟
### Stage 1：讀取進貨單
請讀取進貨單資料，並輸出以下欄位：
| 料號 | 進貨量 |
### Stage 2：計算用量
請讀取產線記錄表，依料號彙總使用數量：
| 料號 | 用量 |
### Stage 3：產出庫存記錄表
以進貨量-用量計算庫存數量：
| 料號 | 進貨量 | 用量 | 庫存 |
3. 設計 HITL（人類介入）流程
在提示詞或 AI 工作流程中，建議主動設計人類介入（Human-in-the-Loop）的檢查點。於關鍵節點要求人工審核、確認或決策，而非讓模型從頭到尾自動完成。
AI 並非 100% 正確的工具，尤其在高風險任務中，若缺乏人類介入機制，錯誤往往會一路放大。透過 HITL 設計，可在關鍵節點建立可控性，讓責任歸屬與最終決策仍掌握在人類手中。
## Stage 1：初步分析
讀取銷售數據報表，產出：
1. 問題摘要
2. 關鍵假設
3. 初步建議
- 用戶確認：
- 問題定義是否正確
- 是否有遺漏的重要限制條件
- 確認完成才得以進入下一步驟
## Stage 2：完整產出
根據 Stage 1 輸出結果，產出完整分析與建議方案。
「寫」好提示詞：撰寫技術
寫提示詞的目的是把需求轉換為 AI 能反覆理解且一致執行的規格。透過結構化段落、明確的輸出格式、清楚的規則與範例，才能確保每次輸出具有一致性。
4. 使用 Markdown 格式
撰寫提示詞時，建議一律採用 Markdown 格式，透過標題、段落與清單將不同層級的指令清楚分段。Markdown 對人類直覺好讀，對 AI 則具備明確的結構化特性，有助於模型辨識指令層級與優先順序。這種同時對人與模型友善的特性，使 Markdown 早已成為 AI Agent 領域最通用的提示詞格式。
5. 將判斷規則結構化
當提示詞中需要處理分類、判斷或對應規則時，建議使用結構化表格或條列式說明，而非文字段落描述判斷邏輯。
以自然語言描述規則往往隱含模糊空間，在複雜條件下 LLM 容易因不同理解產生歧義。結構化表格讓每一列都是一條可被明確比對的規則：
### 打卡紀錄讀取邏輯
| 上午打卡紀錄 | 下午打卡紀錄 | 標記 |
|------------|-----------|------|
| 晚於 8:00 | | 遲到 |
| | 早於 17:00 | 早退 |
| 無資料 | 無資料 | 異常 |
6. 提供資料範例
定義好輸入與輸出規則後，再提供少量「正確範例」，直接示範資料應如何被處理。這種示範式設計特別適合資料拆解、單位轉換等場景：
## 單價欄位提取
### 規則
- 金額統一轉為 XXX,XXX元（每三位數加半形逗號）
- 空白、N/A、Null 視為缺失值
- 無法判斷的文字標記為「異常」
#### 範例
1. 輸入：$1,200 → 輸出：1,200元
2. 輸入：2300 → 輸出：2,300元
3. 輸入：待確認 → 輸出：異常
7. 明確指定輸出格式
應先定義清楚期望的輸出格式，而非僅描述「請分析」、「請整理」。先有結構再填內容，是提示詞設計中極為關鍵的一步。指定格式能讓輸出具備一致性與可驗收性，確保內容可被程式解析或直接進入工作流程。
8. 宣告可用資料與工具邊界
無論實際使用了 RAG、MCP、Function Call 或其他工具機制，都建議在提示詞開頭清楚宣告模型可使用的資料來源與工具範圍。
若未明確限制，模型面對資訊不足時往往會自行補齊看似合理的內容，形成幻覺。事前定義可用範圍能讓輸出具備可追溯性：
## 工具清單
- 向量資料庫：company_docs_v1
- MCP 工具：gmail_mcp
### 回答問題時
- 必須查詢向量資料庫再作回答
- 若查無相關資料，回覆「資料不足，無法回答」
- 不得使用外部知識或自行推測
### 寄送電子郵件時
- 一律使用 gmail_mcp
- 不需自行生成寄信流程或模擬結果
「改」好提示詞：迭代修正
再完整的提示詞也需要透過實際測試驗證。當輸出不符預期時，重點不在一次改到完美，而是建立測試、調整、再驗證的節奏。
9. 讓 Agent 設計走在可控的迭代循環中
寫出第一版 Prompt 後，不應直接投入正式使用，而是先進入小規模測試——選擇幾筆具代表性的範例資料，觀察輸出是否符合期待。若結果不理想，回到提示詞微調後重新測試，反覆進行直到行為穩定可預期。
基本迭代流程：定義需求 → 撰寫初版 → 測試資料驗證 → 微調 → 重複測試 → 確認後上線。
10. 讓模型幫你調整提示詞
當提示詞需要調整時，與其憑直覺手動修改，不如將現有 Prompt 直接交給模型，告知需求後請它重新設計並指出修改段落。
LLM 對語意結構與潛在衝突的敏感度，往往高於人類直覺。特別是多次迭代後，提示詞累積了大量隱含假設與例外規則，人類很容易忽略真正寫下的內容。讓模型進行檢視，能在測試階段就提前暴露不穩定來源。
請協助調整一份提示詞。請先完整讀完，再根據以下調整事項，
告訴我「哪些段落需要修改」以及「建議怎麼改」。
同時檢查整份提示詞是否存在邏輯不一致或容易產生歧義的地方。
調整事項：
- （調整事項 1）
- （調整事項 2）
目前使用的提示詞：
（貼上你的 prompt）