我用 Google Vibe Coding 製作了一款 Android 應用程式

閱讀本文需 13 分鐘

快是真的快，粗糙也是真的粗糙

原文標題：我無法相信 Google 的快速編碼方式如何製作了我的第一個 Android 應用
原文作者：Sean Hollister，the Verge
編譯：Peggy，BlockBeats

編者按：Google AI Studio 正在將 AI 編程帶入一個更直觀的階段：用戶不再只是讓模型「寫代碼」，而是可以直接用自然語言生成一款 Android 應用，並在幾分鐘內安裝到真實手機上。從瀏覽器輸入提示詞，到 Gemini 自動生成代碼、設計界面、修復 Bug，再到應用出現在設備端，軟體開發的門檻正在被進一步壓低。

The Verge 作者 Sean Hollister 近日體驗了 Google AI Studio 的「prompt to phone」能力。他在一個下午內做出了三款應用，包括一款文字冒險遊戲、一個卡路里計算器和一款類馬里奧小遊戲，幾乎不需要親自寫代碼，部分 Bug 也能通過繼續對話快速修復。這種體驗顯示，AI 編程工具正在從開發環境走向更接近普通用戶的消費端場景。

這也是「個人軟體革命」最具想像力的地方。過去，普通用戶只能等待開發者做出通用產品；現在，他們或許可以根據自己的具體需求，臨時生成一個健身追踪器、卡路里計算器，甚至一款簡單遊戲。對 Google 來說，這不只是一次 AI 編程能力展示，也可能是 Gemini 進入手機端、開發者生態和訂閱收入的新入口。

但這次體驗同樣說明，AI 生成應用距離真正成熟仍有明顯差距。它可以快速做出「能跑」的程序，卻未必能做出可靠、準確、好用的產品：遊戲敘事粗糙、機制單薄，卡路里數據會出現嚴重誤判，類馬里奧小遊戲甚至會反覆崩潰。更複雜的問題，還包括版權邊界、數據來源、產品判斷和長期維護能力。

真正值得關注的，不是 AI 是否已經能替代開發者，而是軟體生產的起點正在發生變化。Google 已經證明，普通人用提示詞做出手機應用正在成為現實；但從「生成一個應用」到「做出一個好應用」，中間仍然需要人類的專業經驗、審美判斷和持續迭代。AI 可以大幅提前開發速度，但軟體質量的最後一公里，暫時還交不出去。

error

Gemini 正在嘗試自動完成我的應用創意。圖片來源：Google

我並不想要那種每一關都完全不同的隨機生成關卡——我想要的是一款經典文字冒險遊戲，玩家探索的是一個經過設計、有真實地圖結構的場景。不過，回合制戰鬥倒是可以接受。也許，這款遊戲還可以讓 AI 幫我自動生成地圖？

隨後，Gemini 又建議遊戲裡應該有「隱藏在房間中的秘密」、「令人滿足的成長系統」等更多設定。大多數時候，我只是順著它的思路點了點頭。

在我讓它正式開始寫代碼之前，最終的提示詞是這樣的：

圖片來源：Google

接下來，它就正式開始一路狂奔。我的同事 Jake 指出，和 Claude Code 不同，Gemini 不會先制定計劃，再詢問你是否要繼續執行。它會自動向前推進——當然，如果你願意，也可以隨時查看它寫出的代碼。

一分鐘後，它已經為我生成了五套設計原型：

20 分鐘後，我按下了「Install」按鈕，把這款遊戲傳輸到一台 Pixel 9 手機上。

不出所料，文案寫得很糟糕。遊戲裡也完全看不到惡魔的影子。整個地下城只有 11 個房間，而且玩家只要一路狂按攻擊按鈕，就能直接「通關」。認真玩的話，一分鐘之內就能打完。至少現在可以了——在此之前，Gemini 還幫我修復了兩個足以讓遊戲無法繼續的嚴重 Bug。

下面是 MOOD 的實際效果：

我並沒有太意外地發現，Gemini 所承諾的「引人入勝的敘事、帶有分支對話選項和多個結局」，最終只在遊戲最後濃縮成了一個簡單分支：我可以通過攻擊、與其融合，或者輸入一個後門密碼，來擊敗「Core Orator」——一個不知為何能把互聯網憤怒情緒轉化為企業利潤的 AI。

此外，遊戲還會主動把所有原本承諾的「秘密」直接暴露給玩家：它把這些內容都做成了發光按鈕，玩家甚至不需要輸入任何文字。當你遇到一個發光的寶箱時，遊戲會極其賣力地提醒你，它其實是一個 Mimic——也就是《龍與地下城》中那種偽裝成寶箱的經典怪物。

它不僅明確警告你「自行承擔檢查寶箱的風險」，甚至直接把它標注成敵人，並且不讓我離開，因為系統提示：「一個敵對的『Clickbait Mimic』正在擋路！」

說到這裡，MOOD 甚至會在你需要的時候，直接把用於解鎖隱藏結局的後門密碼告訴你。

不過，Bug 修復的過程倒是可以做到出奇順滑，前提是這個 Bug 是 Gemini 能夠正確識別的問題。當我告訴它，遊戲在與「The Whistleblower」對話時會卡住，因為結束對話的按鈕不見了，它立刻生成了一個新版本的應用。我按下「Install」，手機上的應用自動重啟，而我重新進入遊戲後，發現自己正停留在剛才離開的地方——只是這一次，我需要的按鈕已經出現了。

我的另外幾款應用，可能還需要更多打磨。那個卡路里計數器判斷某種食物熱量的最佳方式，竟然是去調用付費版 Gemini API，而我並沒有付費版 Gemini API 密鑰。當我要求它改為從其他數據庫中搜索相關信息時，我又發現，它對多種食物熱量的估算都嚴重偏低。

不過，當我告訴 Gemini，一杯 16 盎司的珍珠奶茶不可能只有 190 卡路里時，它似乎確實在自己的代碼中發現了那個低級錯誤。它此前認為，「milk」已經足以匹配「boba milk tea」，更糟糕的是，它還選擇了低熱量的 1% 低脂牛奶作為估算依據。Gemini 壯稱，現在它會進行更可靠的匹配。

但即便如此，我那份 3 盎司的台灣鹽酥雞剛剛被它算成了 140 卡路里，而我相當確定，真實熱量至少應該是這個數字的兩倍。所以，這款應用顯然還需要繼續修。

最後，也是最不重要的一點，我覺得自己有必要測試一下：Google 是否仍然允許用戶製作那些糟糕的任天堂山寨遊戲，就像我的同事 Jay Peters 今年早些時候用 Project Genie 做過的那樣；又或者，Google 已經吸取了教訓。

帶著深深的羞愧，我向大家展示——《Super Peach Rescue》：