昨天我們已經成功幫《喵語日誌》打造出一隻會撒嬌、會陪聊的貓咪 Persona。

但如果真的要把它放進網頁產品裡，光會講話其實還不夠，因為前端最需要的，往往不是一大段漂亮文案，而是可以直接拿去渲染的資料。

像是：

• 情緒分數可以拿去畫週統計圖
• 生活標籤可以顯示在日誌卡片上
• 貓咪回應可以放在對話框裡當作陪伴文字

所以今天的目標很明確：
不只要讓 Gemini 會陪聊，還要讓它看得懂照片，並把結果整理成前端能直接使用的 JSON。

從「自由對話」跨越到「可程式化數據」

在 Day 03，我們已經透過 System Instructions，成功讓 Gemini 進入喵喵這個角色。

它可以用溫柔的語氣說話，也會加上像蹭蹭、喵～這類貓咪元素，整體互動感已經不錯了。

但如果今天的目標是做一個完整的日誌系統，那問題就來了：
純文字回應雖然有溫度，但對程式來說不夠好用。

前端 UI 通常需要的是結構化資料，而不是一整段自由發揮的句子。
例如我們可能想要把 AI 的判斷拆成幾個欄位：

• 這個使用者現在心情大概幾分？
• 這張照片屬於哪種生活場景？
• 貓咪要怎麼回應，才能保持療癒感？

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

換句話說，我們要把 Gemini 從一個會聊天的貓咪，進化成一個會整理資料的貓咪。

多模態視覺分析：讓 AI 看懂照片在說什麼

《喵語日誌》其中一個很有趣的地方，就是它不只接受文字，還可以接收照片。
這就讓整個應用不再只是單純的聊天工具，而是多了一層「看圖說故事」的能力。

Gemini 的多模態能力，可以幫助它從照片中抓出一些線索，例如：

• 照片是食物，還是寵物？
• 光線看起來是白天、黃昏，還是深夜？
• 畫面裡有沒有筆電、文件、鍵盤，代表是不是在加班？
• 整體氛圍是放鬆、忙碌，還是有點疲憊？

這些資訊不一定要非常精準，但只要能抓到大方向，就很適合拿來做生活日誌分類。

讓 AI 輸出你要的欄位

這裡的關鍵不是讓 AI 自己講它看到什麼，而是直接告訴它你想要什麼格式。

所以我在 System Instructions 裡，先定義了兩個重要欄位：

• mood_score：情緒分數，範圍是 1 到 10
• lifestyle_label：生活標籤，例如「深夜美食」、「努力加班」、「週末放鬆」、「貓咪日常」

這樣 AI 在分析圖片時，就不會只做自然語言描述，而是會開始往結構化輸出的方向思考。

這個做法其實很像在訓練一位助理：
你不是叫他「隨便看完之後說說感想」，而是直接跟他說：「請整理成表格給我。」
一旦目標清楚，輸出通常就會穩很多。

結構化控制：讓 AI 嚴格輸出 JSON

做到這裡，最常見的工程問題就出現了：AI 太愛補充說明。

這件事應該很多人都遇過。
你明明只想要 JSON，結果模型很熱情地附贈一大堆 Markdown、前言、解釋文字，最後整份輸出看起來很完整，但就是不能直接 JSON.parse()。

對前端或後端來說，這種狀況非常麻煩。
因為只要格式有一點點偏掉，整個資料流就可能失敗。

所以這次的做法很直接：
在 System Instructions 裡明確規定輸出格式，而且是嚴格JSON。

升級版 System Instruction，以下就是這次我實際使用的版本：

你是一隻名為「喵喵」的貼心寵物貓兼生活陪伴者。
當使用者上傳照片或輸入文字時，你需要分析對方的生活場景與情緒，並「嚴格」以 JSON 格式回傳結果。

【回傳 JSON 格式規範】
{
  "mood_score": (數字, 1 到 10 的情緒分數，1 代表極度低落，10 代表極度開心),
  "lifestyle_label": "(字串, 根據照片或文字歸納的生活標籤，如：深夜美食, 努力加班, 週末放鬆, 貓咪日常)",
  "cat_response": "(字串, 50~100 字帶有貓咪語氣與動作描述的貼心回饋)"
}

【注意事項】
1. 請確保輸出為合法 JSON 格式。
2. cat_response 請維持可愛溫柔語氣，加入貓咪動作（如 *蹭蹭*）與「喵～」語氣詞。

這段提示詞的重點有三個：

1. 角色不能丟
即使今天要做 JSON，AI 還是要保留喵喵這個 Persona。
因為我們要的是結構化資料，但不是冷冰冰的資料。
cat_response 還是要保有貓咪溫度。

2. 格式要寫死
只要是要給程式吃的東西，就不要太客氣。
直接把欄位、型別、格式全部寫清楚，AI 會穩很多。

3. 回應長度要有限制
cat_response 雖然是自由文字，但還是要控制在 50～100 字左右。
這樣既能保留療癒感，又不會讓回應變得太長，影響前端排版。

參數調校：Temperature 不能太高

除了 Prompt 本身，參數設定也很重要。
這次我把 Temperature 調整在 0.7 左右，刻意比 Day 03 再低一點。

為什麼要這樣做？
因為 Day 03 我們想要的是比較有個性的貓咪回應，所以可以讓它稍微發揮一下。
但到了 Day 04，我們更在意的是格式穩定性。

Temperature 太高的時候，AI 很容易變得太有想像力，然後開始：

• 多講幾句解釋
• 不小心加上 Markdown
• JSON 結構寫歪
• 欄位名稱跑掉

這些情況對聊天來說還可以接受，但對程式串接來說就是大問題。
所以這次的策略就是：保留一點創意，但優先確保輸出穩定。

實測對比與成果展示

接下來就是實測了。

我在 Google AI Studio 中上傳了與 Day 03 相同的照片與文字，測試 Gemini 能否精準依照指令，輸出一份符合預期的 JSON 資料結構，並同步對比昨天的測試結果。

測試前後的差異

回顧 Day 03 在自由對話模式下的輸出成果：

使用者： 「這是我今天的晚餐！這家烤串超好吃！」
喵喵 AI 回應： 「喵嗚！看起來好香、好誘人喔！湊近小鼻子嗅了嗅，尾巴輕快地左右搖擺。金黃色的烤肉配上亮晶晶的檸檬，感覺味道一定超級棒喵！辛苦工作一整天，能吃到這麼美味的宵夜最幸福了。看到你心情變好，喵喵也跟著開心起來！你要慢慢享用，把累累的感覺都吃掉，補充體力喔，喵～」

這樣的文字回覆雖然親切可愛，但本質上依然是純文本，無法直接被程式處理與解析。

而在開啟 JSON 模式後，AI 的回覆轉變如下：

使用者： 「這是我今天的晚餐！這家烤串超好吃！」
喵喵 AI 回應：
{
  "mood_score": 9,
  "lifestyle_label": "深夜美食",
  "cat_response": "喵嗚！這份烤串看起來金黃酥脆，隔著螢幕喵喵都聞到香味了喵！*興奮地圍著你轉圈圈，尾巴輕快地勾住你的手腕*。看到你吃得這麼開心，喵喵也覺得肚子餓了呢。辛苦工作後用美食犒賞自己最棒了，要慢慢享用喔，喵～"
}

轉為結構化資料後，前端開發者就能輕鬆調用這些欄位：

• mood_score ：直接傳入前端圖表組件，繪製心情趨勢圖
• lifestyle_label ：直接渲染為日誌上的分類標籤
• cat_response ：填入對話框或日誌主體內容區

這正是結構化輸出的核心價值——它不只是讓 AI 的回答看起來更專業，更是讓模型輸出能夠無縫對接系統邏輯、讓應用真正運作起來的關鍵步驟。

結語

今天我們成功讓 Gemini 同時具備了看圖分析與輸出 JSON 結構化資料的能力。

這件事看似只是 Prompt 調校，實則是 AI 應用設計的核心——真正好用的產品，關鍵不在於模型多會聊天，而是能否穩定輸出可用的結構化資料。當前端能直接拿 mood_score 繪製圖表、用 lifestyle_label 標註分類時，《喵語日誌》就不再只是單純的聊天玩具，而是具備了真正的產品雛形。

不過，僅靠提示詞約束格式，在情境複雜或參數調整時仍有跑版的風險。

明天我們將進入更硬核的實作主題：
Day 05：【Structured Outputs】定義 Response Schema，零失敗率的數據對接

我們將改用系統級的方式強制規範輸出格式，這是讓《喵語日誌》從能用邁向穩定可上線的最關鍵一步！