Figma 或 AI Prototype，正式 App 能沿用多少？先分清三種資產

先說結論：Figma 或 AI 做出的 Prototype 通常能沿用「要做什麼、畫面怎麼走、哪些流程值得先驗證」；但它不等於已具備能上架、能處理真實資料、能長期維護的 App。

要判斷可以沿用多少，不要先問「這個 Prototype 做完幾成」，而要先分清你手上的資產屬於哪一類：視覺稿、可點擊原型，還是可執行程式。三者能省下的工作不同，仍缺的風險也不同。

第一類：視覺稿，能留下介面規格

Figma 畫面、AI 生成的設計圖、使用流程圖與元件規則，最適合保留作為介面與討論規格。它們可以幫團隊確認：

• 哪些角色看得到哪些畫面。
• 使用者完成一件事要經過哪些步驟。
• 表單有哪些欄位、按鈕與狀態。
• 哪些畫面是第一版一定要做，哪些先延後。

但一張畫面不會自動定義資料從哪裡來、送出失敗時怎麼辦、誰能修改、資料如何保存，或後台由誰操作。視覺完成度高，仍可能只是產品討論的開始。

第二類：可點擊 Prototype，能先驗證流程

Figma 的 prototype 可以將畫面與互動連接起來，讓人點按、切換頁面或打開 overlay。這非常適合拿來測試：使用者是否看得懂流程、順序是否合理，以及某個按鈕到底該放在哪裡。

可點擊不等於已接上真實系統。Prototype 裡的「登入成功」「付款完成」或「預約已建立」，可能只是跳到下一個畫面；正式產品仍需確認帳號、資料、金流、通知、錯誤處理與權限邊界。

如果 AI 協助建立了互動，也應逐項核對 trigger、動作與目的。AI 可以加快建立基本流程，不會替你決定例外規則或證明每個連接都符合真正的業務流程。

第三類：可執行前端程式，可能留下部分工程資產

有些 Prototype 已經是能在瀏覽器或手機模擬器打開的前端程式。這比單純畫面多了一層可檢查的資產，但也不能直接等同正式 App。

要評估能否沿用，至少要確認：

1. 原始碼與設計素材的使用權是否清楚。
2. 專案是否能在可控制的環境建置與執行。
3. 套件、第三方服務與帳號是否可取得且可更新。
4. 畫面中的資料是否來自真正 API，還是寫死的假資料。
5. 登入、權限、例外與錯誤是否真的被處理。
6. 是否有基本測試、版本紀錄與可交接的部署方式。

上述任何一項尚未確認，都不代表程式不能用；只代表它還需要先調查，不能先把它算進已完成的正式功能。

手上已有 Figma、AI Prototype 或前端展示版，想先請團隊評估哪些能沿用，可以參考奧微軟體的APP 外包服務。

虛構教學例：一個預約服務 App 到底能沿用什麼？

假設你手上有一個「預約服務」Prototype：首頁、服務選擇、日期時間、確認頁與預約成功畫面都做得很完整。

先把資產分開：

正式需求不應只寫「照 Figma 做」。更好的寫法是：「使用者選擇可預約時段並送出後，系統建立一筆預約；同一時段已滿時，使用者不能再次送出，且要看見可理解的提示。」接著再標記時段容量、取消規則、通知方式及管理者權限哪些仍待確認。

這個例子是教學情境，不是客戶案例，也不代表每個預約 App 都需要相同功能。

產品化前要補的五個缺口

1. 真實資料與後端

畫面可以先用假資料，但正式版本要知道資料由誰建立、誰能修改、是否需要歷史紀錄，以及資料錯誤時如何更正。若需要後台、API 或資料庫，這些都應列入範圍，而不是等到畫面完成後才補。

2. 帳號與權限

「有登入」不等於權限已定義。要先區分個人帳號、企業帳號、管理者與客服等角色，並寫出每個角色可看、可改、可匯出的資料。越權或資料混用也應成為驗收情境。

3. 失敗與例外

Prototype 最容易只演成功流程。正式 App 至少要問：網路中斷、重複送出、付款失敗、資料過期、取消與客服介入時，使用者與管理者各看見什麼？

4. 上架與裝置

正式 App 需要測試目標裝置、版本更新、帳號控制權與商店資料。Apple 的審查指引要求送審版本完整、可用，並要求功能不能只是重新包裝網站；這也是為什麼「手機網頁能跑」不等於一定該做成 App 或能直接上架。

5. 維護責任

誰處理第三方服務續費、憑證更新、推播異常、系統故障與新增功能？這些事項不一定都要由同一個團隊負責，但應在上線前明確列出，而不是等服務中斷後才找人接手。

何時不必做 App？

若使用者只需要偶爾查詢資訊、操作主要發生在桌面、沒有安裝需求，也不需要裝置能力，先改善網站或既有流程可能更合適。

是否做 App 應回到使用者的核心任務，而不是因為已經有漂亮 Prototype 就必須往下開發。Apple 與 Android 的公開品質指引也都把可用的完整功能與使用者價值放在單純畫面之外。

找開發團隊前，帶著這份盤點表

第一次討論時，帶上以下資料就能讓評估更具體：

1. Figma／Prototype／原始碼的連結與可使用範圍。
2. 第一版的使用者角色與一條完整核心流程。
3. 哪些畫面、流程與資料已確認，哪些只是展示。
4. 現有 API、資料、帳號及第三方服務清單。
5. 一個正常情境與一個失敗或權限不足情境的驗收例子。

這些資料不會讓任何廠商在未確認範圍前就能保證固定價格或時程，但能讓雙方先判斷哪些資產可沿用、哪些要補，以及第一版真正需要完成什麼。

如果你已經有 Figma、AI Prototype 或前端展示版，可以帶著資產清單、核心流程與目前未知項，和奧微討論產品化範圍與後續開發條件。

資料來源與更新

• Figma Help Center，Prototype interactions 與 AI interactions，查核日期：2026-09-11。
• Apple Developer，App Review Guidelines，查核日期：2026-09-11。
• Android Developers，App quality，查核日期：2026-09-11。

本文由奧微軟體開發企業社製作，屬一般軟體外包與產品化教學；文中的預約服務 App 為虛構示例。