AI Studio 把提示詞變成原生 Android

我拆 Google AI Studio 怎麼把提示詞變成原生 Android App，順手整理成可直接套用的 prompt 模板。

我用一堆 app builder 之後，最煩的不是它們不能生，而是生出來的東西常常很會裝。你一講需求，它就點頭；你一改方向，它也說好；但等你真的拿去手機上跑，UI 卡、狀態亂、權限多到像在做間諜軟體。我對這種 vibe coding 已經有點膩了，因為它最擅長的是第一分鐘，最不擅長的是第十分鐘。

所以我看到 The Verge 的 Jay Peters 這篇，第一反應不是「哇好強」，而是先看 Google 到底把門收多窄。Google AI Studio 這次不是叫你亂生，它是把範圍縮到原生 Android、預覽、裝機、再往 Play 規則靠。這種收斂我反而比較信，因為它承認一件事：能生 app，不等於能生可用的 app。

我真正有感的是流程變了。你在瀏覽器裡下 prompt，直接看 Android emulator，接著裝到連線裝置，最後才談測試者和上架。這不是魔法，但這是工作流。對我這種老是在補洞的人來說，這比「模型很聰明」有用太多。

這篇的觸發點是 Jay Peters 在 The Verge 的報導，原始內容提到的是 Google I/O 2026 的 AI Studio 更新。文章沒有提供公開的 star、bookmark 或觀看數，所以我不亂掰。重點是它把 Google AI Studio、原生 Android app、以及 Play 審核的邊界講得很清楚。

Google 不是在賣你一個萬能 app 生成器

“This initial release” is focused on “personal utility” apps like habit trackers and study quizzes, “hardware-enabled experiences” like apps that use your phone’s camera or GPS, and “AI-powered experiences” that rely on Gemini’s API.

翻譯一下就是：Google 先把可用場景圈起來，不讓大家幻想這東西能直接取代完整 Android 開發。這個限制我覺得很重要，因為太多工具一開始都愛講「什麼都能做」，最後變成什麼都做不好。這次 Google 反而很老實：你要做的是個人工具、硬體感知 app、或 Gemini 輔助 app，先從這幾種開始。

我自己很吃這套。因為「個人用途」代表單一使用者、單一任務、單一成功條件，這正是 prompt-first 最不容易翻車的地方。你叫模型做一個習慣追蹤器，它大概還能守住；你叫它做一個有多角色、多權限、多同步的產品，它就開始亂發明架構，然後把你拖下水。

實操上，我會把這個限制當成選題篩子。先問自己：這個 app 能不能用一句話說完？能不能只服務一個人？能不能先不碰複雜後端？如果答案都偏是，那才值得丟進 AI Studio。反過來，如果你一開始就在想社群、交易、訂閱、協作，那我勸你先手寫骨架，不要拿 prompt 去賭。

• 適合：習慣追蹤、單人筆記、測驗卡、拍照輔助、定位打卡。
• 不適合：社群、商城、即時協作、複雜權限、重度離線同步。

真正有用的是 emulator 到真機這條路

Google 說你可以先在內建的 Android emulator 預覽，再把 app 裝到連線的 Android 裝置上。這看起來很普通，但我覺得這才是這次最不像玩具的地方。很多 AI 工具都愛在網頁裡秀一個漂亮預覽，然後假裝那就是產品；真的丟到手機上，按鈕太小、鍵盤蓋住輸入框、狀態切換失控，整個就開始露餡。

我以前踩過這種坑：browser preview 看起來像樣，真機一跑就知道是幻覺。Android 特別不客氣，因為它不是只有螢幕，還有相機、GPS、權限、背景切換、生命週期。你如果只在瀏覽器看畫面，等於只驗證了半套。

所以這條流程的價值不是「更炫」，而是「更接近真的」。你可以先在 emulator 內把版面、導航、基本流程調好，再切到真機確認硬體行為。這樣做雖然還是要修，但至少你修的是 app，不是在修幻覺。

實操寫法很簡單：emulator 用來看結構，真機用來看現實。只要 app 牽涉到 camera、GPS、麥克風、通知或輸入法，我就會早早上真機，不會拖到最後才驚訝模型忘了手機會被來電打斷。

• emulator 適合：版面、導覽、表單、初版互動。
• 真機適合：相機、定位、權限、輸入延遲、背景/前景切換。

Google 故意把範圍縮小，這不是缺點

The Verge 的描述很直白，Google 其實是在暗示這些 app 比較適合「有限的體驗」。我不會把這解讀成保守，我會解讀成 Google 終於知道：如果不先縮 scope，AI Studio 很快就會變成一台亂噴 code 的機器，大家拿去做 demo 很爽，拿去做產品就開始痛苦。

我自己做 AI 輔助開發時，最怕的也是 scope 太大。模型最喜歡吃具體題目：追蹤水量、做單字測驗、把照片轉成筆記、記錄現場觀察、根據位置打卡。這些它都還算能處理。可是一旦你說「我要一個完整生產力平台」，它就開始自作主張，把本來簡單的事做得像企業系統。

這件事的翻譯就是：Google 給你的是起跑線，不是全自動代工廠。這其實很合理，因為大多數開發者也不需要全自動代工廠。他們需要的是快速驗證一個小想法，先做出能測的東西，再決定值不值得繼續投資。

我會建議你這樣用：先把 app 需求寫成一個動詞開頭的句子。像「記錄我每天喝水」可以，「管理我的人生」不行。前者是工具，後者是災難。

Play 規則還在，這點我反而放心

Google spokesperson Mia Carter 跟 The Verge 說得很明白：Google Play 的品質標準沒有要鬆，審核也不會因為 AI Studio 就變成隨便過。這句話很重要，因為很多 AI 生成工具最愛讓人誤會「做出來」等於「能上架」。不是。你只是拿到一份初稿，後面還是得自己收拾。

Google 也說 AI Studio 是在降低高品質 Android app 的入門門檻，但 app 還是要符合 Play 的品質與審核要求。這種說法我接受，因為如果上架門檻也一起鬆掉，商店很快就會被垃圾灌爆，最後大家都受害。

我做過幾次產品就知道，容易生成和能公開發布根本是兩件事。前者是速度，後者是責任。Google 保留審核，代表 AI Studio 可以幫你生第一版，但不能替你洗白一個爛 app。

實操上，我會把生成結果當成新來的 junior developer 初稿。能用嗎？可能。能直接交嗎？不行。你還是要檢查 permissions、隱私說明、無障礙、崩潰處理、空狀態和錯誤狀態。尤其如果你想進 Play，先假設這份 code 有問題，再一條條驗證。

• 對照實際功能檢查 permissions。
• 看生成文案有沒有亂寫資料收集與隱私聲明。
• 確認離線、被中斷、切到背景時不會直接炸掉。

Gemini 不是主角，但它是 Google 想推的方向

Google 還說這個初版支援依賴 Gemini API 的 AI-powered experiences。這當然不是巧合。它不是只給你一張白紙，而是在把你往 Google 自家的 AI 堆疊推。很 Google，很正常，也很現實。

白話一點說，這平台最適合的不是「整個 app 都是 AI」，而是「app 裡有一個明確的 AI 任務」。像摘要、分類、出題、協助、轉換使用者輸入，這些都還算合理。模型在這裡是加速器，不是產品總監。

我自己的經驗也一樣。AI-backed app 最好做的方式，是讓模型只負責一個 bounded interaction：丟照片、丟筆記、丟語音、丟短 prompt，然後回傳一個有用的結果。你一旦叫它負責整個流程，產品判斷也交給它，事情就會開始飄。

實操寫法：把 AI 功能設計成 app 裡的一步，不要讓它變成整個 app。你最好能在未來把 Gemini 換成別的模型而不重寫整個產品。做得到，代表你設計得比較健康；做不到，通常代表你把模型和產品黏死了。

Google 其實是在拉快 Android 的整條管線

The Verge 還提到 Google 同步推出 Android app 的 1.0 命令列工具、Gemini 查詢裡的 app recommendations，還有 Play Shorts feed。這些看起來像散裝消息，但我覺得它們指向同一件事：Google 想把 app 的產生、發現、分發，串成一條比較短的路。

這對開發者有意思的地方是，AI Studio 如果真的能接上 Android 生態，它就不是單純的玩具。你可以在瀏覽器裡做原型，在 emulator 看結果，在真機驗證，再往 Play 的流程走。這樣一來，從想法到可用成品的距離會短很多。

但我也不想把話講太滿。這種工具最怕的就是讓人誤會「流程變短」等於「規則消失」。沒有，規則還在，只是你前面的雜事少一點。這點我很買單，因為我本來也不想花時間在重複的樣板活上。

實操上，我會把 AI Studio 當前門，不當整棟樓。原始碼還是放自己的 repo，測試還是自己寫，發版檢查還是自己做。等 generated app 開始有點像樣，再把它拉回正常 Android workflow 裡處理。

可抄的模板

# AI Studio 原生 Android app prompt 模板

Build a native Android app called [APP_NAME].

Goal:
- Help one user do one job quickly.
- Keep the first version small and easy to test.

Core use case:
- [ONE_SENTENCE_DESCRIPTION]

Primary screens:
1. [SCREEN_1]
2. [SCREEN_2]
3. [SCREEN_3]

Data the app needs:
- [FIELD_1]
- [FIELD_2]
- [FIELD_3]

Hardware features needed:
- [camera / GPS / microphone / none]

AI features needed:
- [summarize / classify / generate / quiz / none]

Constraints:
- Make it a native Android app.
- Optimize for a personal utility use case.
- Keep permissions minimal.
- Use clear, simple UI.
- Handle empty states, loading states, and error states.
- Make it usable on a real phone, not just in a preview.
- Make sure it can be previewed in an Android emulator first.
- Make sure it can be installed on a connected Android device.
- Keep the app realistic for Play review after manual cleanup.

Definition of done:
- I can open the app on an emulator.
- I can install it on a connected Android device.
- The main workflow works end to end.
- The app does not ask for unnecessary permissions.
- The app would be reasonable to submit for Play review after manual cleanup.

Prompt to generate:
"Build this app as a native Android app with the screens, data fields, and constraints above. Start with the smallest useful version and keep the UI simple."

這段就是我會真的拿去丟的版本。它把 scope 壓小、把裝置驗證寫進去、也提醒你不要把 preview 當終點。對我來說，這才是 AI Studio 真正有價值的地方：不是幫你做夢，是幫你把第一版做得比較不丟臉。

來源致謝：主要拆解來自 The Verge 的原文，以及 Google AI Studio、Android 開發文件、Google Play Console 的公開資訊。我寫的是延伸解讀和可直接套用的 prompt 模板，不是原文轉貼。