用 AI 開發手機 App：Flutter vs React Native AI 工作流

一句話說明

AI 可以加速手機 App 從原型到上架的每個階段，但 AI 生成的程式碼在安全性和效能上需要額外檢查，特別是 API Key 管理、本地資料儲存和網路通訊這三個環節。

AI 如何改變手機 App 開發

2024 年之前，手機 App 開發最花時間的環節是 UI 刻版——把設計稿變成實際的介面程式碼。一個簡單的表單頁面，手工刻可能需要 2-3 小時。2026 年，用 AI 描述你要的版面配置，通常 5 分鐘就能得到可以跑的 UI 程式碼。

除了 UI，AI 在以下環節也明顯加速了開發。

API 串接：描述你要呼叫的 API 格式和回傳資料結構，AI 可以產出完整的網路請求程式碼、錯誤處理和資料解析邏輯。

狀態管理：手機 App 的狀態管理（什麼時候要重新載入資料、暫存哪些資訊、頁面切換時如何傳遞資料）是常見的複雜度來源。AI 對主流的狀態管理模式（Provider、Riverpod、Redux、Zustand）都很熟悉。

測試程式碼：手動寫單元測試和 Widget 測試是很多開發者跳過的步驟。AI 可以根據你的程式碼自動產出測試案例，至少涵蓋基本的成功和失敗路徑。

文件和註解：AI 可以為你的函式和類別產出說明文件，減少團隊溝通成本。

但 AI 無法取代的部分包括：產品設計決策（這個功能該不該做）、使用者體驗的細微判斷（按鈕的位置和大小是不是「感覺對」）、和效能調校（為什麼這個頁面在低階手機上特別卡）。

Flutter vs React Native：AI 開發體驗比較

AI 對 React Native 的支援通常比 Flutter 好，原因是 JavaScript/TypeScript 在 AI 訓練資料中的比例遠高於 Dart。如果你是 Vibe Coding 新手，用 React Native 起步會比較順。

但 Flutter 的 Widget 系統結構化程度很高，AI 產出的 UI 程式碼在 Flutter 上的一致性通常比 React Native 好——React Native 的 CSS 樣式有時候 AI 會用不同的方式實作，結果可能在不同裝置上長得不一樣。

如果是原生開發（Swift/Kotlin），AI 的支援也不差，但跨平台框架讓你只需要維護一份程式碼，AI 輔助的效率更高。

AI 輔助開發的完整工作流

第一階段：設計和原型

用自然語言描述你的 App 功能、目標使用者和主要頁面。讓 AI 產出 App 的資訊架構（IA）和頁面流程圖。

Prompt 範例：

我要開發一個餐廳訂位 App（iOS + Android）。
功能：
- 使用者註冊/登入（Google, Apple 登入）
- 瀏覽附近餐廳（地圖+列表）
- 查看餐廳詳情和可訂時段
- 預約訂位
- 訂位紀錄

請列出所有需要的頁面，每個頁面的主要元素，以及頁面之間的跳轉邏輯。

AI 產出的架構通常涵蓋 80% 的需求，但你需要補充：是否需要離線功能、推播通知的觸發條件、多語言支援的範圍。

第二階段：UI 開發

拿到頁面架構後，逐頁讓 AI 產出 UI 程式碼。每次只做一個頁面，確認效果後再做下一個。一次丟太多頁面給 AI，產出的品質會下降。

這個階段最常見的問題是「AI 產出的畫面和我想的不一樣」。解決方式是用更具體的描述：「上方是搜尋列，下方是餐廳卡片列表，每張卡片有餐廳照片、名稱、評分、距離，卡片高度固定 120dp」比「做一個餐廳列表頁面」有效得多。

第三階段：業務邏輯和 API 串接

把後端 API 的文件（或至少是端點列表和回傳格式）給 AI，讓它產出網路請求的程式碼。這個階段的重點是錯誤處理——AI 產出的程式碼經常只處理「成功」的情況，對於網路逾時、伺服器錯誤、資料格式不對等情況可能完全沒處理。

第四階段：測試

讓 AI 為每個功能模組產出單元測試。但要注意：AI 產出的測試可能只測試「程式碼是否正確執行」（按照程式碼邏輯驗證），而沒有測試「業務邏輯是否正確」（按照產品需求驗證）。你需要自己補充邊界條件的測試。

第五階段：上架前檢查

這是 AI 輔助開發中最容易被忽略的階段。詳見下方的安全檢查清單。

AI 生成 App 的常見安全問題

API Key 直接寫在程式碼裡

這是 AI 生成的手機 App 程式碼中最普遍的安全問題。AI 為了讓範例能跑起來，經常把 API Key 直接寫在程式碼中。手機 App 跟 Web 後端不同——任何人都可以反編譯你的 App（APK 用 jadx、IPA 用 Hopper），看到寫在程式碼裡的字串。

正確做法：API Key 放在後端伺服器，App 透過你自己的後端 API 呼叫第三方服務，而不是 App 直接呼叫。如果一定要在 App 端放某些設定，用各平台的安全儲存機制（iOS Keychain、Android Keystore）。

本地資料儲存不安全

AI 經常用 SharedPreferences（Android）或 UserDefaults（iOS）存放敏感資料，像是登入 Token、使用者資料。這些儲存方式的資料是明文的，Root 過的 Android 手機或越獄的 iPhone 上可以直接讀取。

敏感資料應該用加密儲存：Flutter 用 flutter_secure_storage，React Native 用 react-native-keychain。

網路通訊沒有額外保護

AI 產出的 API 呼叫程式碼通常只用 HTTPS，沒有做 Certificate Pinning。Certificate Pinning 是讓 App 只信任特定的伺服器憑證，防止中間人攻擊（MITM）。沒有 Pinning 的話，攻擊者在同一個 Wi-Fi 網路下可以用 Proxy 工具（如 Burp Suite）攔截 App 的所有網路通訊。

輸入驗證不足

AI 產出的表單驗證通常只做格式檢查（Email 格式對不對、密碼長度夠不夠），但很少做安全驗證（防止 SQL Injection、XSS）。雖然大部分的安全驗證應該在後端做，但前端也應該有基本的輸入清理。

權限要求過多

AI 產出的 App 經常在一開始就要求所有權限（相機、位置、通知、儲存空間），而不是在實際需要的時候才要求。這不只是安全問題，也會影響使用者體驗和 App Store 審核。

上架前的安全檢查清單

一、搜尋專案中所有的字串常數，確認沒有 API Key、密碼、或其他密鑰直接寫在程式碼中。搜尋關鍵字：key、secret、password、token、api。

二、檢查本地資料儲存方式。任何 Token、密碼、個人資料是否用了加密儲存，而非明文儲存。

三、確認所有網路請求都使用 HTTPS。檢查有沒有 allowsArbitraryLoads（iOS）或 cleartextTrafficPermitted（Android）被設成 true。

四、檢查 App 要求的權限清單。每個權限是否都有對應的功能需求？有沒有可以移除的多餘權限？

五、做一次基本的滲透測試。在 Root/越獄裝置上跑你的 App，用 Proxy 工具看網路通訊，確認敏感資料有加密、API Key 不在 App 端。

六、確認第三方套件的安全性。AI 建議的套件可能已經停止維護、有已知漏洞、或功能過於龐大（只用到一個小功能但引入了整個套件的攻擊面）。

七、檢查錯誤訊息。App 在錯誤時有沒有顯示過多資訊（伺服器 IP、資料庫結構、堆疊追蹤）給使用者看？

安全與限制

AI 生成的手機 App 程式碼最大的安全風險不在於程式碼本身有漏洞，而在於開發者因為「AI 寫的應該沒問題」而跳過了安全檢查。

手機 App 和 Web 應用的安全模型不同。Web 應用的程式碼在你的伺服器上，使用者看不到。手機 App 是安裝在使用者的裝置上，程式碼和資料都在使用者的控制範圍內。這意味著任何寫在 App 裡的密鑰都可能被提取，任何本地儲存的資料都可能被讀取。

AI 對手機特有的安全概念（Keychain、Certificate Pinning、ProGuard 混淆、App Transport Security）的理解通常不如 Web 安全概念。你可能需要明確要求 AI 使用這些技術，而不是期待它自動考慮到。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題

延伸閱讀

• Vibe Coding 是什麼？
• AI 程式碼審查
• 手機上的 AI App 推薦