結構化輸出:讓 AI 交出可直接匯入的表格與 JSON

場景:三十份評語,合併時對不上欄

一位中五數學老師用 AI 為全班的專題做初評,每次貼一份,提示是:

請評這份專題,並用表格列出優點與改進建議。

三十次之後她想把結果合併成一個試算表,才發現問題:有些輸出是兩欄(優點、建議),有些變成三欄(多了「分數」),有些把建議寫成項目符號而不是表格儲存格,還有五份在表格前面加了一段「以下是我的評估」。內容大致都對,但合併要用兩個小時人手對齊。

同一件事,把欄位寫死:

角色:你是中五數學科的專題評閱助理。
任務:評閱下方專題,並輸出單一表格。
輸出格式:Markdown 表格,欄位依序為——學生代號、探究問題清晰度(1-5)、數據處理(1-5)、結論合理性(1-5)、最大優點(一句)、首要改進建議(一句)、需教師核實(是/否)。
限制:只輸出表格,前後不得有任何說明文字;不得增減或重新排列欄位;每格不多於 30 字;分數必須是 1 至 5 的整數。不得重寫學生的專題內容。任何你無法從專題判斷的項目,分數留空並把「需教師核實」填「是」。

第二次的三十份輸出,複製貼上到試算表,零手工。

原理

模型每次生成都是重新決定一次「怎樣呈現比較好」。你沒有給格式,它就按內容即興發揮——這在寫文章時是優點,在要合併資料時是災難。結構化輸出的本質,是把「呈現方式」由模型的自由變成你的規格。

可以這樣理解:你請三十位同事各交一份觀課紀錄。如果你只說「寫一份紀錄」,你會收到三十種格式;如果你派一張印好欄位的表格,你收到的是三十份可以直接統計的資料。表格的價值不在於美觀,在於它讓第三十一步變得可能。

還有一點常被忽略:固定欄位同時是一種防呆設計。 當你規定必須有「需教師核實」一欄,模型在不確定的時候就有地方可以誠實交代,而不是為了把表格填滿而編一個數字出來——這與 引用式提示 裡「授權它說找不到」是同一個道理。

JSON 則是給機器看的版本。它比表格嚴格:欄位名稱、資料型別、允許值都要事先講清楚。好消息是主流供應商現在都提供結構化輸出功能,由 API 層保證回應符合你給的結構,而不是靠提示碰運氣。學校自行開發整合時,這是必用的功能;只用聊天介面的教師,則靠提示加示例已足夠應付大部分情況。

模板一:Markdown 表格(給人看)

角色:你是[科目]科教師的批量整理助理。
任務:把下方[學生回應 / 觀課紀錄 / 問卷答案]整理成一張表。
輸出格式:單一 Markdown 表格,欄位依序為——項目編號、原文摘要(不多於 20 字)、類別、嚴重程度(高/中/低)、建議跟進、需教師核實(是/否)。
限制:只輸出表格,前後不得有任何說明文字或標題;不得增減、改名或重新排列欄位;「類別」只可使用以下值之一:概念理解、計算技巧、審題、表達、其他。無法判斷的項目,「類別」填「其他」並把「需教師核實」填「是」,不要猜測。不得改寫原文內容,摘要必須忠於原句。
資料:
[貼上內容]

模板二:嚴格 JSON(給系統看)

角色:你是輸出 JSON 的評卷服務,不與人對話。
任務:按下方評分準則評閱學生作答,輸出一個 JSON 物件。
輸出格式:只輸出一個 JSON 物件,結構如下,欄位名稱與大小寫必須完全一致:
{
  "student_ref": "字串,教師提供的代號",
  "criteria": [
    { "name": "字串", "score": 整數 1-5, "evidence": "字串,引自學生作答的一句", "comment": "字串,不多於 40 字" }
  ],
  "total": 整數,
  "needs_teacher_review": true 或 false,
  "review_reason": "字串,若 needs_teacher_review 為 false 則填 \"none\""
}
限制:只輸出 JSON,前後不得有任何文字、標題或說明;不得使用註解;不得新增或省略欄位,無值時填約定的空值而不是刪去欄位。score 必須是 1 至 5 的整數,不得使用小數或文字。evidence 必須是學生原文的一句,不得改寫或翻譯。凡評分依據不足以判斷,needs_teacher_review 填 true 並在 review_reason 說明原因。不得重寫學生的作答。
評分準則:[貼上準則]
學生作答:[貼上作答]

模板三:同一份資料要表格也要 JSON

先要 JSON,再由 JSON 生成表格,兩邊才不會對不上。

角色:你是資料格式轉換助理。
任務:把下方 JSON 轉成教師會議用的 Markdown 表格,不得改動任何數值。
輸出格式:單一 Markdown 表格,每個 criteria 項目一行,欄位依序為——評分項目、分數、關鍵佐證、評語、需教師覆核。表格下方另加一行合計。
限制:只輸出表格;所有數值必須與 JSON 完全相同,不得四捨五入、換算或補充;JSON 中沒有的資料一律留空,不得推算。needs_teacher_review 為 true 的行,在「需教師覆核」欄填「是」並保留 review_reason 的內容。
JSON:
[貼上 JSON]

怎樣處理模型在 JSON 前後加的多餘文字

即使寫了「只輸出 JSON」,仍然有機會收到一段開場白。由易到難三個做法:

1. 給一個完整的輸出示例。 示例比描述有效得多,尤其是把示例寫成一整段 JSON 而不是逐欄說明。
2. 明文列出禁止項。 「不得加入開場白、結語、標題、說明、Markdown 程式碼圍欄以外的內容」——逐項寫出來,比一句「只輸出 JSON」可靠。
3. 改用供應商的結構化輸出功能。 OpenAI 與 Google 都提供以 schema 約束回應的模式,由 API 保證格式。學校若要把 AI 輸出接進校務系統,這一層不能省,因為提示層永遠有失敗率。

常見錯誤

1. 只寫「用表格呈現」。 欄位每次不同,合併時全部要人手對齊。修正:欄位名稱與次序逐一列明,並禁止增減。
2. 沒有規定允許值。 「類別」欄第一次寫「概念不清」,第二次寫「概念理解問題」,統計時變成兩類。修正:把允許值列成封閉清單,並規定無法歸類時使用固定的「其他」。
3. 缺值時直接刪掉欄位。 JSON 少一個欄位,下游程式就會出錯。修正:明文規定無值時填約定的空值字串或 null,結構必須保持完整。
4. 沒有核實欄,模型為了填滿而編造。 這是結構化輸出最反直覺的風險:格式越整齊,錯誤越不容易被看出來。修正:一定要有「需教師核實」欄位,並在限制行說明甚麼情況要填「是」。

進階變化

• **科學科實驗數據整理:**加入單位欄與「數值來自學生記錄 / 由 AI 推算」欄,後者必須明確標示,否則推算值會被當成實測值。
• **中國語文的錯別字統計:**輸出表格欄位改為——原句、錯字、正確寫法、錯誤類型(形近/音近/其他)、出現次數。整個中三級的資料合併後,科組可以看出本年度要集中處理哪幾類。
• **常識科問卷整理:**把開放式答案歸類時,先讓 AI 用一次輸出提出十個類別,教師刪改後定為封閉清單,再用模板一批量處理。先定類別再分類,結果穩定得多。
• **通識與公民及社會發展的資料比對:**表格加一欄「立場」,允許值限定為支持、反對、中立、無法判斷,並規定無法判斷時不得猜測。
• **SEN 學生的觀察紀錄:**欄位改為可觀察行為、出現情境、支援措施、成效(改善/不變/惡化/未能判斷)。留意紀錄中不要放入姓名,用代號處理,理由見 校務文書與家長溝通提示。

小結與下一步

結構化輸出是把 AI 由「幫我寫一段」升級為「幫我處理三十份」的那一步。規格寫得越死,合併與統計就越輕鬆;而一個誠實的核實欄,是整齊格式底下唯一能防止錯誤被掩蓋的設計。

同樣的欄位規格用在圖片、手寫功課與語音輸入上,見下一課 多模態提示;把這些定好的規格保存成科組資產,見 建立科組提示模板庫。