系列：30 天用 Google AI 打造臺灣防災速報 App（Day 17/30）

後端上線了，接著要有畫面。防災資訊很依賴呈現方式：嚴重程度要一眼看得出來，緊急時不能讓人找不到按鈕。

今天用 Google Stitch 產生設計稿。Stitch 是 Google 實驗室推出的介面設計工具，用文字描述想要的畫面，它會產生設計圖，以及對應的 HTML 程式碼（HTML 是描述網頁內容與版面的標記語言）。以下是 8 月 25 日第一次使用的過程，以及產出內容裡要人工再檢查的地方。

給 Stitch 的描述

描述的重點放在資訊的層級與版面配置：首頁分三區、嚴重程度用顏色區分、底部固定一個問答按鈕、四種語言可以切換、字要大。

原本想用中文描述，但中文經過剪貼簿貼進 Stitch 後變成亂碼，所以改用英文。當時使用的自動化工具，無法把文字輸入 Stitch 的內嵌頁面，所以描述由我本人手動貼上。

描述原本是用 macOS 終端機的一行指令放進剪貼簿：printf 輸出描述文字，pbcopy 把它寫進剪貼簿，pbpaste、wc -c、head -c 120 再讀回剪貼簿，確認內容長度與開頭。最後貼進 Stitch 的，卻是這整行指令本身。以下是 Stitch 專案裡保存的原文：

$ printf 'A disaster alert mobile app (Android/iOS) for Taiwan. Home screen has
three zones: a critical alert banner at the top (only appears for critical-level
alerts, red background with white text); a scrollable list of active alert cards
in the middle, each card has a colored left-edge bar by severity (red/orange/blue)
and shows a category icon, title, affected counties, and last-updated time; a fixed
bottom button "Disaster Q&A" that opens a chat interface. Include a language
switcher (Traditional Chinese, English, Japanese, Korean). Clean and bright style,
high contrast, large fonts, senior-friendly.' | pbcopy && pbpaste | wc -c && pbpaste | head -c 120

（為了閱讀方便加了換行，原文是一行。）

描述前後多了指令，Stitch 仍照引號裡的描述產生畫面。

第一張畫面

描述裡要求的都有做到：

• 頂部的重大警報橫幅，紅底白字，中英雙語。
• 警報卡片左側有依嚴重程度分色的色條，卡片上有分類圖示、標題、影響縣市、更新時間。
• 右下角固定一個「災害問答」按鈕。
• 右上角的語言選單列出繁體中文、英文、日文、韓文（設計稿裡只是選單，沒有切換功能）。

描述裡沒寫、它自己加的：

• 底部導覽列，分成「警報資訊、防災地圖、物資通報、緊急協助」四個分頁。
• 畫面產生後，它反問要不要調整顏色的強度或字的粗細。

一次加一件事，做到 22 張

之後每次只追加一個需求，例如「加上地圖」「加上警報分類的篩選」「顯示只看地震的地圖」。這次後續產生的畫面，大致沿用了先前的顏色、字型和版面。

8 月下旬分兩次匯出，第一次 19 張，第二次補上 3 張，合計 22 張，另外附一份設計規格檔 DESIGN.md：

DESIGN.md 是 Stitch 整理出的設計規格：每個顏色的用途（主色、次要色、背景、文字）、字型與字級。它把這套設計命名為「Zenith Alert」。App 後來使用的英文字型 Plus Jakarta Sans，就是這份規格裡的標題字型。

要人工檢查的地方

1. 沒有來源的統計數字。 其中一次追加需求，是請它做「歷史地震紀錄」畫面，要有震央分布、規模趨勢和統計摘要。描述裡沒有提供任何資料，它仍然填上了看起來很具體的數字：

統計卡寫著總計 1,245 起、規模 5 以上 342 起、6 以上 48 起、7 以上 5 起，標題寫「近 30 年」，沒有寫地理範圍。我用美國地質調查所（USGS）的地震目錄查了一組對照：東經 119 到 123 度、北緯 21 到 26 度，查詢期間 1996 年 1 月 1 日到 2026 年 9 月 15 日，規模 4.5 以上共 2,011 筆，再依規模門檻計數：

Stitch 的數字有的偏少、有的偏多，和這組查詢結果都不相同，也沒有交代來源和範圍。畫面上的地圖小圖還寫著「1900–2023」和總計 14,250 起，同一個畫面裡，數字與年份彼此不一致。

這些數字在設計稿裡只是佔位，但看起來如同真實統計。沒有對照的話，很容易被當成事實留到正式版。這個 App 的歷史地震畫面，後來改用 USGS 的實際資料畫（Day 24）。

2. 圖示名稱變成文字。 同一張圖的底部導覽列，出現了 notifications_active、map、inventory_2、contact_emergency 這些英文字，左上角也有 emergency。這些是 Material Symbols 圖示字型的圖示名稱。HTML 裡有載入這個圖示字型，但同一個元素又套用了一般文字的字型設定，後者蓋掉了圖示字型，圖示名稱就以一般文字顯示，還和旁邊的中文擠在一起。頂部的標題也超出了紅色的導覽列。

只確認檔案存在、沒有實際看畫面，就會漏掉這類問題。回頭查 HTML，可以找到字型設定互相覆蓋的原因。

3. 匯出的圖要逐張打開。 8 月 29 日第二次匯出的壓縮檔裡有 22 個 screen.png，其中 6 個不是圖片，內容只有一行錯誤訊息 <FIFE Image failed to fetch>（圖片沒有從 Stitch 的伺服器取回），副檔名仍然是 .png。這 6 張在十幾分鐘前的第一次匯出裡是正常的，解壓縮時被第二次的檔案蓋掉了。檔案數量是對的，打開才知道圖片無法使用。9 月 26 日重新匯出，這 6 張才補齊。

設計稿之後

Stitch 產生的 HTML 程式碼不能直接放進 Flutter（Google 的跨平台 App 開發框架，用一套程式碼建置 Android、iOS 與網頁版），但版面、元件的排列、顏色的用途，都可以當成寫 App 時的對照。從設計稿到 App，還要接上真實資料、處理四種語言、在不同尺寸的手機上測試。

今日小結

• Stitch 用一段英文描述產生了首頁，要求的項目都有做到，還自己加了底部導覽列。
• 之後每次只追加一個需求，兩次匯出合計 22 張畫面，另附一份設計規格檔。
• 要人工檢查的三件事：沒有來源的統計數字、變成文字的圖示名稱、匯出後無法使用的圖片。
• 歷史地震畫面的數字，和 USGS 的查詢結果都不相同。

明天 Day 18：用 Flutter 建立跨平台 App，先在 Android 模擬器上執行。