約束式提示詞指的是在提示詞中，明確指定輸出的形式限制，例如要求 AI 生成 JSON、Markdown 表格，或遵循特定的資料綱要 (Schema)。這種控制除了可以讓輸出結果美觀易讀，也直接影響了後續的資料處理、系統整合與自動化流程

這篇文章除了會跟大家介紹約束式提示詞外，還會介紹可以怎麼將它應用在 RAG 或自動化系統上，也會分享該怎麼設計約束式提示詞以符合你的需求

為什麼需要嚴格限制輸出格式？

如果能穩定輸出符合特定的 JSON 綱要或 Markdown 結構，程式或自動化流程就能直接讀取並處理，無需再進行耗時且容易出錯的手動清理，對於資料管線、自動報表生成或 API 介接都是助益良多。

而且在團隊協作中，不同成員、不同時間點使用的提示詞，往往會產生風格迥異的輸出，讓後續整合變得困難許多，所以我們透過格式約束，保證每次輸出的結構都很穩定，可以大幅降低維護成本。

此外大家可能會發現，如果我們輸出的格式很模糊，或是讓 AI 完全自由發揮，那 AI 常常會加入額外的說明文字或是把順序打亂，那明確的格式約束可以有效減少這類非預期的錯誤，而且無論是前端渲染、資料庫儲存還是回傳 API，後續的資料流程都要依賴這些穩定的資料格式，當我們可以預測 AI 輸出的格式後，我們後續的設計就可以相對簡潔安全，減少因格式變動而產生的例外處理。

JSON 與 Markdown 的適用場景

如果你的輸出需要進一步被機器解析、寫入資料庫、接入 API 或進行自動化處理，那麼選 JSON 就對了。JSON 格式結構嚴謹，容易被驗證，也能跟兼容現有的系統和工具。對於需要長期維護與迭代的場景，JSON 格式能大幅降低人工清理資料的成本

Markdown 則更適合以人為主要的閱讀對象。例如團隊文件、簡報素材、知識庫內容 ... 等等，使用 Markdown 表格或標題層級能讓結果更直觀，也方便直接貼到 Notion、Confluence 或 GitHub README 等平台。缺點是結構不夠嚴格，不利於後續做程式化處理

在某些混合場景中，還會出現雙格式輸出的需求，例如同時輸出 JSON (供程式處理) 與 Markdown (給人閱讀)。這時候我們可以在 Prompt 裡明確要求 AI 先輸出 JSON，接著再用該 JSON 生成 Markdown 表格。這樣的串接方式能同時滿足機器可讀與人類可讀兩種需求

不過要特別注意的是，雖然在處理結構化資料任務時，使用 JSON 是最佳解。但 JSON 格式可能會增加 Token 的消耗，並有括號、引號等語法錯誤的風險。

設計高品質約束式 Prompt 的小技巧

以下是一些實作中容易被忽略，卻非常有用的小技巧：

明確定義 Schema 與欄位屬性

我們除了請 AI 輸出 JSON 格式外，更要明確定義每個 Key 的名稱、資料型別，並標示哪些欄位是必要的，哪些是可選的

提供完整的範例輸出 (Few-shot)

在提示詞中給予一個包含假資料的完整輸出範例，AI 就會傾向模仿這個結構，並大幅降低格式錯誤的機率。

加入錯誤檢查與修正指令

我們可以要求 AI 在生成內容前先自我驗證

定義輸出順序與結構層級

即使是 JSON 或表格，也應盡可能指定欄位的順序或層級關係，避免 AI 自由調整，導致每次輸出結果的結構不一致

請將以下提供的使用者資料，轉換為一個結構化的 JSON 物件。
請嚴格依照以下指定的順序與層級結構輸出，不要增加、減少或調換任何欄位的位置。

{
  "user_id": string,           // 1. 使用者 ID (必填，固定放在最前面)
  "username": string,          // 2. 使用者名稱
  "is_active": boolean,        // 3. 帳號是否啟用
  "profile": {                 // 4. 個人資料 (必須為巢狀物件)
    "display_name": string,  // 4a. 顯示名稱 (profile 物件中的第一個欄位)
    "bio": string,           // 4b. 個人簡介 (可選)
    "avatar_url": string     // 4c. 頭像 URL (可選)
  },
  "last_login": {              // 5. 最後登入資訊 (巢狀物件)
    "timestamp": string,     // 5a. 時間戳 (ISO 8601 格式)
    "ip_address": string     // 5b. IP 位址
  },
  "tags": [string]             // 6. 用戶標籤 (陣列，固定放在最後面)
}

權衡 Token 消耗與格式複雜度

前面有提到，JSON 格式相對會消耗比較多的 Token。在需要大量呼叫 API 的應用中，必須衡量格式的嚴謹性與成本效益。通常，格式越嚴格，巢狀結構就越深，好處是控制力更強，但 Token 消耗也隨之高，甚至模型出錯的機率也可能隨之增加，需要稍微注意

使用範例

用於資料分析報表的 JSON 輸出

請幫我分析最近一季產品銷售數據，並輸出一個包含三個產品的 JSON 陣列。

每個物件的 Schema 必須如下：
{
  "product_name": string,
  "region": string,
  "sales_q1": number,
  "sales_q2": number,
  "growth_percentage": number
}

請依據以下資訊生成內容：

- A 產品, 亞洲區, Q1: 12000, Q2: 15000
- B 產品, 歐洲區, Q1: 8000, Q2: 7500
- C 產品, 美洲區, Q1: 10000, Q2: 13500

growth_percentage 欄位請計算 Q2 相對於 Q1 的成長率，並四捨五入到小數點後一位。

使用 GPT-5 輸出的結果：

整合使用者回饋的 Markdown 表格

請將以下用戶回饋的重點，整理成一個 Markdown 表格。

表格需包含以下欄位：回饋項目, 提及頻率, 正面評論比例 (%), 負面評論比例 (%)。

原始資料：
- 關於 UI 設計的評論共 50 則，其中 40 則是正面的。
- 關於功能穩定性的評論共 80 則，其中 60 則是正面的。
- 關於客戶服務速度的評論共 30 則，其中 15 則是正面的。

請確保比例數值計算正確，並顯示百分比符號。

使用 GPT-5 輸出的結果：

因為 GPT-5 的回答太好笑了 XD，所以我再多用一個 Gemini 2.5 Pro 模型來測試輸出：

小結

要讓格式控制變成一個真正有效力的工具，可以把它設計成流程的一部分，例如：

• 對於需要作為資料輸入的任務 (如 RAG 系統、報表、自動化流程)，一定要事先定義好格式 schema 並進行測試
• 建立格式範本與驗證步驟，並把他們作為標準的操作流程
• 在團隊中統一格式風格與約束規範，讓不同成員的 Prompt 輸出可互換

約束式提示詞的價值不僅僅是讓輸出看起來整齊，還有可以讓 AI 的回覆融入我們的工作流中，我們將格式控制當作設計流程的一環後，就可以把它變成一個知識處理的工具，而非單純聊天的對象，我想這就是約束式提示詞在專案應用中的吸引力吧