Google Antigravity 展示 Android 開發流程：從 Stitch 設計到實機執行
Google 官方展示 Antigravity 使用 Stitch MCP 和 Android CLI 外掛，把設計轉為原生介面、驗證模擬器並送到實機。解析展示能說明的流程能力。
Google Antigravity 的新展示把 Android 開發流程接了起來。AI 從設計取得資訊，建立原生介面，在模擬器驗證，再把最後版本跑到真實手機上，讓「生成程式」與「能在裝置使用」有了更清楚的連線。
2026 年 10 月 6 日，Google Antigravity 官方帳號發布影片，說明它使用 Stitch MCP 與 Android CLI plugin 完成這些步驟。這是一段官方流程展示，適合觀察工具如何協作，完整應用的品質仍需要用自己的需求驗收。
設計如何進入 Android 開發流程
Stitch 在這段展示中提供設計，MCP 則是讓 AI 接上外部工具的協定。代理透過這條連線取得設計內容，再轉成 Jetpack Compose 元件，也就是 Android 用來建立原生畫面的介面工具。
這對已有設計稿的開發工作有幫助，因為版面需求可以直接成為實作參考。使用者仍應交代哪些內容必須保留，例如文字、操作順序與重要狀態，避免代理只照外觀建立一個看起來相似的畫面。
模擬器和真實手機各自提供什麼證據
模擬器是在電腦上模擬 Android 裝置的環境，方便快速檢查畫面與操作。實機則能確認程式確實安裝並在手機執行，兩者驗證的範圍不同。
官方展示把這兩步都放進流程，讓成果多了執行證據。但能在一臺手機啟動，不能自動代表所有螢幕尺寸、網路狀態與權限情境都通過。若要交付使用者，還要依應用功能列出實際需要檢查的狀況。
Android 指令外掛讓代理能繼續執行
CLI 是透過文字指令操作工具的介面，plugin 是安裝到工作環境的外掛。展示使用 Android CLI 外掛，把建置、驗證與裝置執行接到代理的工作中。
這讓 AI 有機會看到實作後的結果，再根據結果繼續修正。對小型團隊，價值在於縮短設計和第一次可執行版本之間的等待。但建立應用所需的資料來源、登入與功能規則，仍要有明確需求。
我會如何驗收這種開發方式
先選一個範圍清楚的畫面，要求代理保留內容與互動邏輯，再檢查畫面、輸入、返回與錯誤提示。這樣可以知道它是否理解設計背後的用途，而不只是產生視覺成果。
我看好這種把工具連結起來的方向，尤其是能讓代理從執行結果獲得反饋。若實作之後的修正仍需要大量人工，省下的初稿時間就應和後續整理成本一起計算。
從一句需求開始，先整理畫面背後的工作
Android 展示看起來像是從一句描述走到手機，但實際需求通常包含不止外觀。使用者要完成什麼、需要輸入哪些資料，以及按鈕之後發生什麼，都會影響程式應如何建立。
例如一個行程清單畫面，除了卡片排版，還要知道新增、修改和刪除的規則。若只有視覺稿，代理可能完成一個漂亮畫面，卻沒有完整互動。這是應用構想，不是官方影片所展示功能的逐項清單。
因此，我會先用文字寫出主要操作順序，再交給設計與開發工具。即使只是原型，也應說明哪些內容使用測試資料，哪些部分未連線真實服務，避免把可點選畫面當成正式應用。
Antigravity 的展示說明工具鏈能接起來，使用者則要提供鏈條處理的目標。需求越清楚，生成結果越容易驗收，也越容易知道後續修改應落在哪一步。
Stitch 設計需要轉成原生元件的意思
設計稿說明畫面應如何排列，Jetpack Compose 元件則是讓 Android 真正呈現和操作介面的程式結構。從設計到程式，不只是複製顏色與位置，也要把文字、狀態與互動變成可執行內容。
若某個卡片在資料較長時需要換行，原生實作就應處理不同長度。若有載入中或空白狀態，也要決定怎麼顯示。設計中沒有寫清楚的情境，不能指望代理每次都猜中產品需求。
使用 MCP 取得設計，讓代理有較直接的參考來源，但仍要檢查它取得的是哪個版本。設計修訂後，程式是否同步更新，會影響最後成果是否一致。工具連線本身不會替團隊決定哪份設計才是正式版本。
我會把關鍵文字、主要操作和不可省略的狀態列成簡短清單。這樣檢查時能逐項對照，不必只靠「看起來很像」判定設計已經正確落地。
原型與正式功能要在畫面中分清楚
AI 生成的第一版常適合展示流程，但展示可能使用固定資料。若清單內容每次相同，或按鈕只改變畫面，不代表已經完成資料儲存與後端連線。原型有用，但需要清楚界定用途。
以登入畫面為例，可以先製作版面與錯誤提示，讓團隊討論流程。真正的帳號驗證、狀態儲存與資料管理，則需要相應服務與規則，不能由一個漂亮的登入按鈕推論已經完成。
驗收時可以分成「展示是否清楚」與「功能是否真的執行」。前者看文字、順序和畫面，後者看輸入、資料改變與結果。兩種條件都應明確，才不會在交付時才發現大家理解不同。
本文把官方影片當成工具協作的證據，沒有將它延伸成任意應用都已可自動上線。從原型往正式產品走，仍需要需求、資料與實際使用情境的補充。
模擬器適合快速檢查，不必代替所有裝置
模擬器讓開發者在電腦上觀察 Android 畫面，適合確認基本排列和操作。修改後可以較快再次執行，讓代理看見結果，這是縮短開發迴圈的實用方向。
不過，實際手機的尺寸、效能與使用環境不同。某個畫面在模擬器正常，並不自動保證在每臺裝置都一樣。若產品會給不同使用者，應依主要裝置與功能安排測試範圍。
文字輸入也值得另外看。鍵盤出現後會改變可見區域，較長文字可能讓按鈕被擠出畫面，使用者放大字型也可能影響佈局。這些是可納入驗收的情境，並非本文已測試官方範例的結果。
我會先用模擬器確認清楚的基本流程，再用實機看實際操作感受。兩者互相補充，沒有必要把其中一個成功畫面當成全部品質的證明。
真實手機上的執行，應檢查人實際怎麼用
把程式跑到手機，是從程式碼走向使用的關鍵一步。它證明有可安裝、可啟動的版本，但使用者還需要確認手指點選、閱讀與返回是否自然，不只是看畫面已經出現。
可以按照主要任務完整操作一次，再加入取消、返回和重複操作。若某步需要網路，也應觀察沒有連線時的回覆。應用不能只在最順利的一條路徑上成立。
若涉及裝置權限，應確認請求時機和說明。使用者第一次看到權限要求，應知道它和功能有什麼關係。這是一般產品驗收方向，不能由官方影片推論特定權限流程已經完成。
AI 能幫助建立與修正程式，人的實際操作仍提供不同證據。讓團隊成員按自己理解使用一次，通常能發現開發者因熟悉流程而沒注意的地方。
代理取得執行回饋後，要能指出改了什麼
工具鏈的優點之一，是代理可以看到建置或執行結果，再繼續工作。但反覆修改應有清楚目的，否則程式越改越多，團隊卻不知道哪一項變化解決了問題。
可以要求每次修改說明觸發原因、影響範圍與檢查結果。例如為了修正某段文字超出畫面，就應指出調整了哪個元件，並再看相應畫面。這樣比較容易判斷是否只是改出另一個外觀。
當錯誤與環境有關，也應把它和程式邏輯分開。缺少開發資源、裝置未連線或版本不符合條件，都可能讓工作停住。代理需要能清楚描述目前位置，讓人知道下一步怎麼接手。
我會把可理解的修改紀錄看成重要成果。即使 AI 很快產生第一版，後續維護仍需要知道程式為何如此設計，否則節省的時間可能在交接時重新付出。
小型團隊可以先用一個畫面建立固定流程
匯入時不必先做整個應用，可以選一個需求穩定的畫面，固定設計稿、測試資料與驗收條件。讓代理完成設計轉譯、建置、模擬器與實機步驟，再看哪一段最需要人工協助。
如果畫面品質足夠，下一輪可以加入一項互動。若核心文字或狀態經常遺漏，則應先修正需求描述與檢查方法。逐步增加範圍，能讓問題保持可理解，也比較容易看到工具真正省下的部分。
完成流程後，團隊可以把有效指引整理成自己的工作規則。必要檔案、命名方式與檢查順序都能保留，讓後續任務不必每次從頭説明，但不應把某個範例的偶然條件當成通用規則。
我看好這類開發方式，原因是它讓設計與執行更靠近。但匯入是否成功，應看同一套方法能否重複完成不同需求，而不是只看一支順利示範。
最後交付要包含能接續工作的材料
對團隊而言，手機上能執行只是交付的一部分。還需要知道程式位置、使用條件、目前支援範圍與已知限制，才能讓下一位開發者繼續修改，而不是只拿到一段展示影片。
可以要求代理整理設計來源、主要元件與檢查結果，並指出哪些資料仍是測試內容。這些材料不需要很長，卻能讓交接者知道完成程度，也能避免原型被誤當成正式功能。
重要決定也應保留理由，例如某個操作為什麼需要確認、某段資料為何只能檢視。若只留下程式碼，後續修改可能把產品規則改變，卻不知道它原本服務什麼需求。
Antigravity 的展示提供了從想法到裝置的新方向。真正能帶進團隊的，是清楚需求、連續執行與可接手成果這三件事一起成立，讓 AI 產出的應用不只跑得起來，也容易繼續維護。
設計來源也應保留可追溯版本
Google 的設計轉程式教學提供 Stitch 與 Antigravity 連線的背景，新的 Android 影片則展示不同工具繼續接到裝置。閱讀時應區分教學與這次展示，不能把較早檔案中的每個步驟都當成新功能。
實際專案可以記錄設計版本、主要畫面與輸出時間，讓修改能夠回到相同依據。設計變化後再請代理同步，也應檢查它有沒有保留原本功能，而不是只換外觀。
這類記錄不需要複雜系統，清楚檔案與命名就能幫助開始。對團隊而言，可追溯來源會讓工具協作更容易接手，也讓每次修改有比較基礎。
Antigravity Android 展示常見問題
影片證明所有 Android 應用都能自動完成嗎？
它展示了指定流程與工具配合，不能推導成所有應用都能無人完成。需求越複雜，越需要清楚的功能條件與驗收方式。
Jetpack Compose 是生成模型嗎？
它是 Android 原生介面開發工具。展示中的 AI 代理用它建立畫面，並不是用它產生一般圖片或影片。
結語：從畫面生成走到可執行的應用
Antigravity 的展示讓設計、原生實作與裝置驗證有了連續流程。值得追蹤的，是這套方式在真實專案中能否保持需求一致，並把修正與驗收成本一起降下來。
延伸閱讀：Mobile Next MCP 是什麼？用 Claude、Codex 自動操作 iOS 與 Android 的安裝、功能與風險
