昨天我把 LearningCard 的資料格式交給 Gemini，請它幫我建立第一版 React UI。

原本只是想看看：

如果不自己從零刻 Component，Gemini 能做到什麼程度？

結果 Gemini 不只產生 React + TypeScript 程式碼，還自己加入 Tailwind CSS、卡片切換、查看答案等互動。

到這裡其實已經很像一個可以使用的 Prototype 了。

照一般的開發流程，接下來大概就是：

建立 React 專案
↓
安裝 Dependency
↓
把 Gemini 產生的 Code 放進去
↓
調整環境
↓
npm run dev
↓
開始 Debug

但昨天準備結束實驗時，我在 Gemini 回覆旁邊看到了一個選項：

Make this an app

既然今天都已經在測試「AI 到底可以幫前端做到哪裡」，那乾脆繼續讓它做下去看看。

從 React Code 直接 Make this an app

這次我沒有重新寫 Prompt，也沒有修改昨天 Gemini 產生的程式碼。

直接從原本的回覆選單選擇：

Make this an app

接著 Gemini 開始建立應用程式。

這次使用的模型一樣是：

Gemini 3.8 Flash

完成後，Action history 顯示這次執行花了：

Ran for 115s

也就是大約兩分鐘。

但真正讓我注意到的不是時間，而是下面這段紀錄：

Installed 2 packages
Edited 12 files
Built

原本我只是給它一個 LearningCardApp.tsx 的需求，結果按下 Make this an app 之後，它已經開始自己建立完整的專案結構。

Gemini 到底建立了哪些東西？

從 Action history 可以看到，它總共修改了 12 個檔案：

metadata.json
index.html

src/types.ts
src/utils/audio.ts
src/data/learningCards.ts

src/components/Celebration.tsx
src/components/ParentModal.tsx
src/components/ThemeSelector.tsx
src/components/QuizMode.tsx

src/LearningCardApp.tsx
src/App.tsx
src/index.css

看到這裡，我第一個反應其實是：

等一下，我昨天不是只有要一個 Learning Card UI 嗎？（笑）

因為 Gemini 已經不只是把昨天的程式碼放進一個 React 專案。

它甚至開始自己拆檔案。

例如 Type 被獨立放到：

src/types.ts

學習卡資料則放到：

src/data/learningCards.ts

語音相關功能也出現了：

src/utils/audio.ts

甚至還多出了：

Celebration.tsx
ParentModal.tsx
ThemeSelector.tsx
QuizMode.tsx

身為前端工程師，看到這裡已經忍不住開始 Code Review 了（笑）。

原本只是一張 Learning Card，結果變成一個 Learning App

更有趣的是實際 Preview。

昨天 Gemini 第一次產生的版本還很單純：

Learning Card
├── Emoji
├── Title
├── Content
├── Question
├── Answer
├── 上一張
└── 下一張

但 Make this an app 之後，畫面明顯變得更完整。

除了原本的學習卡之外，現在還出現：

Learning App
├── Learning Card
├── Theme Selector
├── 查看答案
├── 上一張 / 下一張
├── 語音朗讀
├── 星星獎勵
├── 探索卡模式
├── 大挑戰模式
├── 親子小撇步
└── 多種學習主題

甚至海洋動物也不再只有原本的幾張。

Preview 顯示：

🐳 海洋探險 1 / 7

除了藍鯨、章魚、海龜、小丑魚之外，內容也繼續被擴充。

這時候我才發現：

Gemini 並不是單純把昨天的 Code「跑起來」，而是又根據它對這個產品的理解，把 App 繼續往下做了。

連「語音朗讀」都自己加進來了

其中一個我完全沒有要求的功能，就是語音。

畫面上直接出現：

自動朗讀

而從 Action history 也可以看到：

src/utils/audio.ts

Gemini 在建立 App 時，已經把語音相關邏輯獨立出來。

另外還加入了「唸給我聽」之類的互動，讓學習卡除了文字和 Emoji 之外，也多了一種操作方式。

這些都不是我原本 Prompt 裡面的需求。

我的 Prompt 從頭到尾其實只要求：

Emoji
標題
學習內容
問題
答案

結果 AI 自己開始補功能了。

還多了一個「大挑戰」

除了原本瀏覽學習卡的方式，Gemini 還自己加入兩種模式。

一個是原本比較接近 Learning Card 的：

探索卡

另一個則是：

大挑戰

從產生的檔案也可以看到：

src/components/QuizMode.tsx

也就是說，原本的：

看看卡片
↓
回答問題
↓
查看答案

又被 Gemini 延伸成另一種 Quiz 互動。

甚至還加入星星獎勵與答對時的效果，對應到：

src/components/Celebration.tsx

做到這裡，我原本的 MVP 已經開始默默膨脹了。

AI 也會自己 Scope Creep？

如果回頭看我最初定義的智慧學習卡，其實核心非常簡單：

Learning Card
├── emoji
├── title
├── content
├── question
└── answer

但經過 Make this an app 之後，已經變成：

Learning App
├── Learning Card
├── Navigation
├── Answer Interaction
├── Speech
├── Reward System
├── Challenge Mode
├── Multiple Topics
└── Parent Tips

這個結果當然很有趣，而且拿來做 Prototype 也很方便。

但同時也出現一個前端開發很熟悉的問題：

Scope Creep。

只是以前可能是 PM、客戶或開發到一半的自己一直加需求。

現在連 AI 都會幫忙加（笑）。

AI 覺得合理，不代表產品真的需要

這也是今天實驗之後，我覺得比「115 秒建立 App」更值得記錄的地方。

Gemini 很擅長根據上下文補完需求。

例如看到：

3～4 歲幼兒
+
Learning Card

它就開始推導：

是不是需要語音？
是不是需要比較大的按鈕？
是不是可以加入獎勵？
是不是可以做 Quiz？
是不是還可以換主題？

這些想法不一定不好。

問題是：

「看起來合理」和「這次 MVP 真的需要」是兩件不同的事情。

如果今天只是快速做 Prototype，我可能會覺得這些功能很方便。

但如果真的進入產品開發，就還是得一個一個問：

這個功能真的需要嗎？
誰會使用？
解決什麼問題？
要不要現在做？
維護成本是多少？

AI 可以幫忙提出答案，但最後還是需要人決定範圍。

前端工程師的工作，好像真的有點不一樣了

Day 14 的時候，我已經感覺到工作流程開始改變。

以前比較像：

需求
↓
自己設計 Component
↓
自己寫 JSX
↓
自己寫 CSS
↓
自己處理 State
↓
慢慢完成第一版

到了今天甚至變成：

需求
↓
Gemini 產生 React Code
↓
Make this an app
↓
安裝套件
↓
建立檔案
↓
拆 Component
↓
Build
↓
直接看到 Prototype

至少在這次實驗裡，我幾乎還沒有開始正式刻畫面，就已經有一個可以操作的 App 了。

但這不代表前端工程師只剩下按按鈕。

因為接下來反而出現另一批問題：

哪些功能要留？
哪些功能要刪？
資料結構合理嗎？
Component 要怎麼拆？
AI 自己產生的內容能不能使用？
真正的 API 要怎麼接？
錯誤狀態怎麼處理？

所以我現在比較傾向把 AI 當成一個可以非常快速產生 First Draft / Prototype 的工具。

以前花很多時間從 0 做到 1。

現在 AI 可以幫忙把 0 到 1 壓縮很多。

但從 1 繼續走到真正能維護、能整合、符合需求的產品，還是有很多工程工作。

不過現在還有一個很大的問題

畫面看起來已經很完整。

可以切換卡片、查看答案、播放語音，甚至還有不同模式。

但如果回到我們前幾天做的東西，就會發現：

這些資料其實還不是我們真正的資料。

Day 12，我們已經讓 Gemini 使用 Structured Output 回傳：

{
  "cards": [
    {
      "emoji": "🐢",
      "title": "認識海龜",
      "content": "...",
      "question": "...",
      "answer": "..."
    }
  ]
}

Day 13 又把它對應成：

type LearningCardResponse = {
  cards: LearningCard[];
};

但今天 Make this an app 產生的 Learning Card，仍然是 Gemini 在建立 App 時自己補上的範例內容。

也就是目前比較像：

AI Generated Content
        ×
AI Generated UI
        ↓
Prototype App

而我們真正想做的是：

使用者輸入學習需求
↓
Gemini
↓
Structured Output
↓
LearningCardResponse
↓
React UI

UI 已經有了。

資料格式也有了。

接下來，終於可以把前面幾天做的東西接在一起。

今天的小結

原本我以為 Make this an app 只是把昨天 Gemini 產生的 React Code 直接執行起來。

實際測試後才發現，它做的事情比我預期更多。

這次 Gemini 3.8 Flash 執行約 115 秒，Action history 顯示安裝了 2 個套件、修改 12 個檔案，最後完成 Build。

而且它不只是建立專案，還自行拆分 Type、Data、Utils 和 Components，甚至繼續加入語音、Quiz、星星獎勵、多主題與親子功能。

這次實驗讓我看到 AI 產生 Prototype 的速度確實很快。

但也讓我看到另一面：

AI 很會補需求，但它幫忙補上的需求，不代表全部都應該留下來。

所以到了這一步，我的工作反而從：

「我要怎麼把第一版 UI 寫出來？」

慢慢變成：

「AI 已經幫我做了一版，那我要留下什麼？」

這大概也是這幾天實驗下來，我感受到最明顯的開發流程改變。

明天預告

Day 16｜UI 有了，但資料還是假的：把 Learning Card JSON 接進 React

Day 12，我們已經有 Structured Output。

Day 13，我們建立了 LearningCard Type。

Day 14，Gemini 幫忙產生第一版 React UI。

Day 15，又透過 Make this an app 把它變成可以操作的 Prototype。

接下來終於要把這幾條線接在一起：

Structured Output
↓
LearningCardResponse
↓
LearningCard[]
↓
React UI

明天先不急著串 Gemini API。

先把 Day 12 真正產生的五張 Learning Card JSON 放進 React，看看能不能把目前 AI 自己產生的 Mock Data 換掉。

UI 有了，下一步就是讓它開始吃我們自己的資料。