前言

前兩天我們把 Context 與 Role 這兩塊地基打穩了。今天要處理的是 CO-STAR 裡最直接影響「格式穩不穩定」的一項——Response(回應格式)。

這是整套範本設計裡,最容易「看到成效」的一個環節:同樣的內容,規則寫得好不好,產出的格式一致性可以差到天差地遠。今天要談的核心工具,是 Markdown 和 JSON 這兩種結構化語言,以及它們分別適合用在什麼情境。

一、為什麼「結構化輸出」是穩定性的關鍵最後一哩路

回顧 Day 2 談的穩定性來源,我們提過「指令模糊」是不穩定的第一個來源。而在所有規則類型裡,格式規則是最容易被「模糊帶過」的一種——因為人在腦中對格式的想像很清楚,但寫成文字時卻常常偷懶,只寫「請用清楚的格式」這種空話。

結構化輸出要解決的問題很直接:不要用形容詞描述格式,而是直接給 AI 一個「範本骨架」讓它照著填。 這跟 Day 10 要談的「給範例」邏輯類似,但今天談的是更基礎的一層——連範例都還沒給之前,先確保「容器的形狀」是固定的。

二、Markdown:適合「給人看」的結構化格式

Markdown 的強項,是它同時滿足了「結構清楚」和「人類直接閱讀友善」這兩個需求(這也是我們一開始介紹 Markdown 時談過的特性)。你在 System Prompt 裡規定 Response 格式時,可以直接給出章節骨架,例如:

請依照以下 Markdown 結構輸出,不得增減章節,不得改變章節順序:

# 資安週報 - {日期區間}

## 一、事件摘要
(以條列式列出本週所有事件,格式:[時間] 事件類型 - 簡述)

## 二、處理狀況
(說明已結案與處理中事件的數量與比例)

## 三、待辦事項
(僅列出尚未結案的高風險事件)

這種寫法的好處是:你不是在「描述」格式要求,而是直接把格式「畫」給 AI 看,它只需要照著骨架把內容填進去,不需要自己「猜」章節該怎麼分。這也直接對應 Day 3 談的「骨架」概念——這裡的骨架不只是 prompt 結構的骨架,也是輸出內容本身的骨架。

三、JSON:適合「給程式讀」的結構化格式

如果你的最終目標,不只是產出一份人看的報告,而是這份輸出之後還要被程式進一步處理(例如自動推送到 Slack、寫入資料庫、或做後續統計),Markdown 就不夠用了——因為 Markdown 本質上是給人讀的排版語言,程式要從裡面「精確」抓出某個數字或某個欄位,相對麻煩。

這時候 JSON 就派上用場。JSON 是一種用「鍵值對」表示資料的格式,程式可以非常精確地讀取指定欄位,不會有歧義。例如:

{
  "報告期間": "2026/08/24 - 2026/08/28",
  "事件摘要": [
    {"時間": "08/25", "類型": "異常登入", "簡述": "偵測到境外 IP 嘗試登入"}
  ],
  "未結案高風險事件數": 2,
  "本週結案率": "87%"
}

這種格式,特別適合對應到 Day 25-27 要談的「工作流整合」——當你之後要把 AI 產出的內容,自動串接到 Python 腳本、Slack 訊息、或其他系統時,JSON 讓後續程式處理變得精確又省事,不需要用複雜的文字解析去「猜」Markdown 裡的內容代表什麼意思。

四、該選 Markdown 還是 JSON?一個簡單的判斷原則

不用糾結「哪個比較好」,而是回到一個問題:這份輸出,下一步是要給人看,還是要給程式讀?

第三種情況其實是比較進階、也比較穩健的做法——讓 AI 負責「判斷內容」,把內容整理成精確的 JSON;排版這種機械性工作,交給程式去做,而不是每次都要求 AI 同時兼顧內容判斷和排版精美度。 這個概念會在 Day 25 之後,我們談自動化串接時,再更深入展開。

五、規則寫死到什麼程度才夠?

一個常見的疑問是:格式規則要寫多細?這裡有個實用的判斷標準——問自己「如果拿掉這句話,AI 有沒有可能做出不符合我期待的選擇?」

例如「請用條列式呈現事件」這句話,可能還不夠精確,因為 AI 可能用 -、也可能用 1. 2. 3. 數字編號,兩者都算「條列式」。如果你的公司習慣統一用 -,就該明講:「事件清單一律使用 - 作為條列符號,不使用數字編號。」

規則寫得越明確,AI 能自由發揮、也就是能「猜錯」的空間就越小——這正是 Day 2 反覆強調的穩定性,在格式這個環節具體的實踐方式。

六、今天的行動練習

拿出你手上的範本草稿,檢查目前的 Response 格式規則:是用形容詞描述(例如「請用清楚的格式」),還是直接給出結構骨架?如果是前者,試著把它改寫成一份具體的 Markdown 骨架,或視你未來是否需要串接自動化,額外設計一份 JSON 版本的輸出規則。

小結

今天的核心觀念是:格式規則不該用「描述」的,而該用「展示」的。 直接把骨架畫給 AI 看,遠比用形容詞說明來得穩定可靠。而 Markdown 與 JSON 這兩種工具,分別對應了「給人看」與「給程式讀」兩種不同的下游需求——搞清楚你的輸出接下來要去哪裡,就能決定該選哪一種。

下一篇,我們要離開格式這個「硬」的層面,回到內容本身「軟」的一面——怎麼透過 Tone & Style 的控制,讓 AI 寫出來的報告不再有濃濃的「AI 味」。