設計師能不能自己把第一版產品做出來？

前一天我把救災平台從模糊想法整理成比較具體的產品定義。到了 Day 20，我想回答一個實際的問題：定義做完之後，設計師能不能不靠工程師，自己把第一版 Prototype 生出來？

過去的流程是需求 → User Flow → Wireframe → UI → Prototype，再交給工程師，每一關都要重新溝通。很多問題其實要等資料真的流動起來、狀態真的改變之後才會浮現，光靠 Figma 靜態稿很難判斷一個功能到底成不成立。

這次我想測的是另一種 Agent-first 流程：讓 AI Agent 直接參與從產品定義、Plan、Prototype 到測試迭代的全過程，設計師負責持續給方向和判斷。

先讓 Agent 讀懂需求，畫面放到後面再說

我把整理好的產品需求丟給 Agent，第一步先讓它產出一份 Implementation Plan——把需求拆成頁面、元件、資料結構、互動邏輯，等這份 Plan 定案，才進入實際畫面。

這一步很考驗產品判斷力，因為 Agent 產出的 Plan 常常「看起來很完整、但理解錯了方向」。舉個例子：平台裡有一個「現場回報」功能，我心裡設定的是「越簡單越好，能填的資訊有限」，但 Agent 第一版直接把它變成一張標準表單——所有欄位都設成必填，還要求使用者手動輸入完整地址。

現實情況複雜得多。使用者可能正在移動、訊號很差、根本沒空慢慢打字，甚至說不出正確地名。一個「必填地址」的假設，在現場可能直接讓這個功能報廢。

較好的 Solution 可能是將這個欄位重新定義成一組依情境退場的機制：預設用裝置定位直接帶入座標，使用者不用打字就能完成回報；定位不準的時候，提供手動微調位置的方式，取代重新輸入地址；真的完全沒有訊號、定位失敗的情況，才退回到最陽春的文字描述，讓使用者用自己的話描述大概位置，事後再由其他人協助核對。整套邏輯的重點在於能自動就自動，自動不了才交給人手動處理。

所以審 Plan 的時候，我會盯著三件事：它有沒有理解使用情境、有沒有抓對核心任務、技術方案會不會反過來傷害體驗。Plan 的角色終究是拿來討論、拿來被挑戰的。

Prototype 跑起來之後，很多「合理設計」突然變得很怪

Plan 確認後進入 Prototype，我特別關注兩個畫面：一個處理「資訊怎麼快速進系統」，一個處理「大量資訊進來後，人怎麼快速判斷、行動」。

有意思的反差出現在一個小細節上：我原本設想「點一下地圖上的標記，只該跳出一個精簡摘要」，但 Agent 第一版直接把完整詳情——所有欄位、所有紀錄——全部塞進那個小小的彈出視窗，桌機手機都用同一套，完全沒意識到「摘要」跟「詳情」應該是兩層資訊、兩種呈現方式。

這種問題在靜態畫面裡完全看不出來，只有 Prototype 真的跑起來、真的去點的時候才會冒出來。

發現問題後我會用自然語言跟它溝通，比如：

「回報成功之後，要讓使用者知道這筆資訊現在的狀態，送出後應該要有明確的回饋。」

或者：

「列表要讓人一眼分辨出哪些還沒人處理、哪些正在進行、哪些已經有人接手，不能全部長得一樣重要。」

這種修法適合探索階段——先講清楚「要解決什麼問題」，讓 Agent 處理實作。但一旦問題縮小到很具體的技術細節（比如彈出視窗跳出來之後，背景元件居然還能被點到），直接改 code 反而更快。設計師要慢慢學會判斷什麼時候該講「產品的話」，什麼時候該講「工程的話」。

這裡我也刻意先跟 Agent 講清楚一件事：顏色、間距、字級這些視覺變數不要寫死在各個元件裡，統一用 design token 管理，元件本身則盡量照 design system 的規則長。原因很單純——探索階段的畫面一定會一直改，如果每個顏色都是散落在不同檔案裡的寫死數值，之後想調一次主色調或整體風格，等於要一個一個元件慢慢找。但如果一開始就讓 Agent 建一層 token（顏色、間距、圓角、陰影都對應到變數），之後不管是換一個主色、還是要做 light/dark 切換，理論上只要改 token 定義，畫面就能一次跟著變。這算是一個看起來多花時間、但長期回收很快的小投資。

Agent 最容易出錯的地方：它以為自己理解了

速度快，也會放大錯誤。

我告訴 Agent：「幫忙找出附近可以支援的人。」它很自然地把這句話翻成「按距離排序」。工程上完全合理，但產品上可能整個方向錯了——距離近但沒有交通工具的人，實際支援能力可能比不上距離遠一點、但有對的設備跟技能的人。

這種時候我會先問自己：「附近」這個詞我到底有沒有想清楚要包含哪些條件，比起急著改 Prompt，先把問題定義想清楚往往更有效。很多時候 Agent 做錯，問題出在我給的問題定義本身就不夠精確。

類似的落差也出現在一個「這筆資訊可信嗎」的小功能上。我原本的用意是要做一個群眾校驗機制，讓資訊的可信度能反過來影響它在系統裡的權重——但 Agent 一開始只把它當成單純的按讚數字。問題出在我一開始沒把「為什麼需要這個功能」講清楚。

Antigravity 最讓我意外的地方：看得到它在做什麼

跟以往用 AI 寫程式最大的不同，是 Antigravity 會即時預覽 Agent 正在操作的畫面——它現在點了哪個按鈕、切到了哪一頁、正在檢查哪個狀態，都會像有人在旁邊操作瀏覽器一樣同步顯示出來，過程整個攤在我眼前。

這件事情比想像中重要。當我看到它點開某個列表、切換某個篩選條件，卻遲遲沒有觸發我預期的畫面變化時，我馬上就知道問題出在哪一層，不用等它寫完一輪報告才回頭 debug。等於是把原本「Agent 自己默默做、做完再告訴你」的黑盒流程，變成一個可以隨時介入、隨時喊停的過程。

我也會直接讓它自己跑一輪 walkthrough：照著設定好的路徑操作 Prototype，檢查有沒有明顯斷點——按鈕點不動、跳轉跳錯、狀態沒更新。這很像正式找真人測試之前，先跑一次自動化的 smoke test。搭配即時預覽畫面，等於是在旁邊看著它「代替使用者」把整個流程走一遍，哪裡卡住一目了然。

問題抓出來，回去改一次，再跑一次。如果這個循環一天內可以跑好幾輪，就會變成一個很短的迴圈：

設計 → 實作 → 操作 → 發現問題 → 修改 → 再測試

對還在探索階段的產品來說，這個速度差很多。

Prototype 定型之後，交棒給專業工程團隊

當這一輪迭代跑到我覺得可以拿給真實使用者看的程度，我就把整個 codebase push 上 GitHub，再接 Vercel 產生一個可以直接分享的 demo link——不用另外架環境，也不用解釋怎麼跑起來，測試者點連結就能操作，回饋收得比想像中快很多。

這一步也順勢把角色交接的問題解決了。原本我這邊只是用 Agent 自己單線推進，但接下來要進入更嚴謹的開發，就需要交給專業的前後端工程師接手。我用 branch 做版本管理——把探索階段的實驗留在自己的分支，穩定下來、驗證過的部分才合併進主線，工程團隊接手時看到的是一條乾淨、有脈絡可循的紀錄。

Agent 幫忙做出來的東西，終究是拿來驗證方向用的。它的價值在於用最低成本把「這個功能到底成不成立」這件事先驗證掉，等方向確認了，再交給真正要對品質、效能、維護性負責的人接手，才是比較健康的分工方式。

AI 加速了實作，但難題還是留給人

這輪做完，我覺得 Agent 最大的價值，是把「從想法到可以操作」的成本壓得很低。以前設計師大部分時間花在整理規格、畫流程、等工程排期；現在這些時間可以挪去做問題定義、情境理解、測試迭代。

但也有些事情，AI 現在還是給不出答案。比如什麼樣的資訊該被標成高風險？資訊互相矛盾時，誰有權限修改？誤判造成資源用錯地方，系統該怎麼補救？這些問題背後牽涉的是產品策略、風險判斷、責任歸屬，需要人來做選擇。

Agent 讓設計師更快做出東西，也讓設計師更快撞上真正難的決策。當「把東西做出來」變得便宜，設計師該花時間的地方，就會往「什麼值得做、怎麼驗證、出錯誰負責」移動。

這也剛好帶到下一個問題：當這個平台本身也開始用 AI 做判斷，它到底能不能、該不該幫忙做決策？這會從 AI-assisted design，正式走進 AI-assisted decision making。