昨天開始從「程式」的角度重新看 Gemini 的 Response。

原本對人來說很正常的：

Emoji：🐢
Title：海龜
Content：……
Question：……
Answer：……

真的要交給程式處理時，才發現事情沒有想像中單純。

有時候有 ---，有時候沒有；有時候是全形冒號 ：，有時候又變成半形冒號 :。

如果每一種情況都自己寫程式判斷，好像會慢慢變成「Gemini Response 猜猜樂」。

所以今天決定來試試 Google AI Studio 裡一直還沒有使用的功能：

Structured Output

Structured Output 是什麼？

簡單來說，前幾天都是透過 Prompt 告訴 Gemini：

我希望你產生什麼內容。

但如果這些內容最後要交給程式使用，我還希望可以進一步定義：

你應該用什麼資料結構把結果交給我。

這就是今天想解決的問題。

在 Google AI Studio 的 Structured outputs 編輯介面中，我看到兩種設定方式：

• Visual Editor
• Code Editor

Visual Editor 可以直接新增 Property、設定資料型別

Code Editor 則可以直接看到或編輯背後的 Schema。

對第一次接觸 Schema 的人來說，Visual Editor 看起來直覺很多。

所以這次我先從 Visual Editor 開始。

先定義一張 Learning Card

還記得 Day 04 設計的第一版 Learning Card 嗎？

當時決定先保留五個最基本的欄位：

Emoji
Title
Content
Question
Answer

所以這次就在 Visual Editor 裡，把原本預設的 response 移除，重新加入五個 Property：

emoji       string
title       string
content     string
question    string
answer      string

並把這五個欄位設定為必要欄位。

這樣等於是在告訴 Gemini：

等一下回傳 Learning Card 時，我希望資料裡有這五個欄位，而且它們都是字串。

切換到 Code Editor 後，也可以看到剛才設定的內容其實會變成一份 Schema。

大致會像這樣：

{
  "type": "object",
  "properties": {
    "emoji": {
      "type": "string",
      "description": "適合這個學習主題的一個 Emoji"
    },
    "title": {
      "type": "string",
      "description": "學習卡標題"
    },
    "content": {
      "type": "string",
      "description": "適合學習對象理解的簡短介紹"
    },
    "question": {
      "type": "string",
      "description": "根據 Content 可以回答的簡單問題"
    },
    "answer": {
      "type": "string",
      "description": "Question 的簡短參考答案"
    }
  },
  "required": [
    "emoji",
    "title",
    "content",
    "question",
    "answer"
  ],
  "propertyOrdering": [
    "emoji",
    "title",
    "content",
    "question",
    "answer"
  ]
}

看到這裡，其實已經開始有點像「程式要的資料」了。

不過 Schema 裡每個設定到底代表什麼，今天先不挖太深。

先 Run 看看再說。

這次把 Prompt 變簡單了

這次我也刻意把 Prompt 簡化。

前幾天會在 Prompt 裡明確寫：

每張學習卡包含：
- Emoji
- Title
- Content
- Question
- Answer

但現在這些欄位已經定義在 Structured Output 裡了。

所以 Prompt 改成只描述「我要什麼內容」：

請製作一張適合 3～4 歲幼兒學習的「海龜學習卡」。

學習目標：
讓孩子認識海龜，並了解海龜一個簡單的特徵。

內容請使用繁體中文，
使用適合 3～4 歲幼兒理解的詞彙。

這次想測試的概念其實很簡單：

Prompt
↓
負責「要產生什麼內容」

Structured Output
↓
負責「資料要怎麼回傳」

設定完成後，Run！

Gemini 真的回傳 JSON 了

這次 Gemini 回傳的結果是：

{
  "emoji": "🐢",
  "title": "認識海龜",
  "content": "海龜住在美麗的大海裡。牠的背上背著一個又圓又硬的大殼，就像隨身帶著堅固的小房子一樣喔！",
  "question": "海龜背上背著什麼呢？",
  "answer": "硬硬的大殼。"
}

五個設定好的欄位都有出現：

emoji       ✅
title       ✅
content     ✅
question    ✅
answer      ✅

而且這次不需要再找：

---

也不用管 Gemini 今天到底想使用：

：

還是：

:

因為資料已經有自己的欄位名稱了。

Prompt 管內容，Schema 管結構

這次實驗後，我覺得 Structured Output 最好理解的方式就是：

Prompt 負責內容，Schema 負責結構。

例如這次 Prompt 告訴 Gemini：

3～4 歲幼兒
海龜
認識一個簡單特徵
繁體中文

而 Schema 告訴 Gemini：

emoji
title
content
question
answer

兩邊負責的事情開始被拆開。

這也比一直在 Prompt 裡要求：

請按照以下格式回答……

更接近接下來要把 AI 整合進應用程式的方式。

當然，Structured Output 解決的是「資料結構」的問題，不代表 AI 產生的內容就一定正確。

所以之前提過的：

AI Output = Draft

還是沒有改變。

Day 10 小結

今天第一次使用 Structured Output，至少這次實驗中，Gemini 成功按照設定的 Schema 回傳了 JSON。

從 Day 08 到今天，剛好形成一個很明顯的變化：

自然語言 Response
↓
人看得懂
↓
程式不一定好處理

Structured Output
↓
定義 Schema
↓
Gemini 回傳結構化資料

不過今天只是先把第一張 Learning Card 成功變成 JSON。

打開 Schema 之後，又冒出了新的問題：

properties 是什麼？

required 要怎麼決定？

description 要寫多詳細？

Learning Card 的 Schema 應該怎麼設計？

看來成功拿到 JSON 還只是第一步。

明天就來正式拆解這份 Learning Card Schema。

Day 11｜Learning Card Schema 怎麼設計？把 AI 回傳格式定義清楚