狀態管理是什麼，跟「畫面看起來會動」有什麼不同？
很多人以為只要畫面上有動畫、有轉場效果，就代表這個原型是「互動的」，但這其實是兩件不同的事。單純的視覺轉場（例如點擊按鈕後畫面淡出淡入）只是預先錄好的表演，不管使用者做了什麼，播放的都是同一段動畫。狀態管理談的是更底層的東西：介面要「記得」使用者到目前為止做了什麼，並且根據這個記憶決定接下來要顯示什麼。
舉例來說，一個購物車圖示上顯示的數字，必須隨著使用者加入或移除商品即時更新，這個數字背後就是一個被追蹤的狀態；一個多步驟表單，使用者填到第三步時瀏覽器重新整理，如果前兩步的資料還在，代表狀態有被妥善保存。沒有狀態管理的原型，本質上只是一系列固定畫面的投影片，看起來像產品，但沒辦法真的被「操作」。
為什麼原型需要狀態管理，直接做一系列靜態畫面不行嗎？
靜態畫面（低擬真原型）當然有它的用途，速度快、成本低，適合驗證「這個流程的步驟順序合不合理」這種比較粗略的問題。但當團隊需要驗證更細緻的問題時，例如「使用者會不會搞不清楚哪個按鈕已經被點過」「表單填錯時的錯誤提示夠不夠明顯」，這些答案取決於介面在使用者操作當下的即時反應，靜態畫面完全模擬不出來。
更實際的理由是可信度：拿一份沒有真實狀態、每次點擊都導向同一張固定圖片的原型去讓利害關係人或使用者測試，很容易被一眼看穿「這是假的」，測試者的行為也會因此變得不自然（知道是假的就不會認真操作）。有真正狀態管理的原型，能讓使用者忘記自己在測試一個原型，得到的回饋才更貼近真實使用情境。這也是為什麼 2026 年多款 AI 原型工具開始把「能不能串接真正的後端邏輯」當作區分成熟度的關鍵指標，而不只是比誰的畫面比較好看。
在 AI 生成的原型裡，狀態管理實際上是怎麼被實作出來的？
傳統前端工程裡，狀態管理通常需要工程師手動決定：這個資料要放在單一元件的區域狀態，還是要放在整個應用程式共用的全域狀態，並選用對應的框架工具來管理。AI 設計工具要做到「有意義的互動」，等於是要在生成畫面的同時，也一併生成背後這套狀態邏輯——例如按下「加入購物車」的按鈕，要真的去更新某個被追蹤的購物車數量，而不只是播放一個按鈕按下去的動畫效果。
更進一步的做法是接上真正的後端服務。以 Figma Make 為例，這款工具與 Supabase 整合後，使用者只需要用自然語言描述「我要讓使用者可以登入、儲存資料」，工具就會自動判斷需要後端支援，把原本的假資料換成真正的 Postgres 資料庫，把原本沒有作用的登入按鈕換成真正能運作的帳號系統。這代表狀態不再只是「這個畫面暫時記得使用者點了什麼」的前端假象，而是真正被儲存、重新整理頁面後依然存在的資料。
如果我不是工程師，判斷一個 AI 原型有沒有做好狀態管理，該實際測試哪些行為？
最簡單的測試方法是「破壞它」：填一半的表單然後切換到另一個分頁再切回來，資料還在不在；把清單排序改了之後重新整理頁面，順序有沒有還原成原本的樣子；用兩個瀏覽器分頁同時操作，其中一邊的變動另一邊看不看得到。這些操作平常沒人會刻意去測，但正是這些邊角案例，會直接暴露這個原型是真的有狀態、還是只是外表看起來會動的固定畫面。
如果你是要用原型去做使用者測試或跟客戶簡報，先自己花五分鐘做這些破壞性測試，能避免在正式場合當場出包——例如客戶當著你的面重新整理頁面，結果剛剛填的表單資料整個消失，這種狀況比原型畫面不夠精美更容易讓人對整個提案失去信心。
Figma Make 在整合 Supabase 之後，使用者只要用自然語言提示「加入使用者登入功能」，工具就會自動觸發後端建立流程，把原本的假資料模擬替換成真正的 Postgres 資料庫，並提供帳號密碼或社群登入等真實驗證機制，讓一個原本只是點擊會換頁的原型，變成使用者真的可以註冊帳號、資料真的會被保存下來的可運作雛型，不需要工程師另外手動接資料庫。
優點是能讓利害關係人與使用者在測試階段就得到接近真實產品的操作體驗，及早發現流程上的問題；缺點是實作真正的狀態管理（尤其是接上真實後端）通常比純視覺原型耗費更多時間與運算資源，如果只是要驗證流程順序或初步視覺方向，可能沒有必要一開始就投入這個成本。