規格寫再多，AI 還是做偏？試試先做 Prototype

大家應該對 AI 輔助開發都各有一套心得吧。如果碰到新專案要開發，我自己試過的方法，不外乎就是先寫文件，定義有哪些功能、權限矩陣、畫 Mermaid 時序圖…等等，接著讓 AI 開始實作，但做出來常常跟想像的差很多。靜態畫面的 prototype，類似先畫 wireframe 的概念，我也試過，但是對互動操作型的產品，就沒那麼適合。

最近嘗試了不同的做法：「先做可操作、但不串後端的 prototype」，有資料、有互動、可以操作 user flow，但是不串真正的後端、正式資料庫，而是先用 IndexedDB 存資料在瀏覽器中。

我發現它解決了兩個我很常遇到的問題：

• 一口氣把所有規格從頭開始定義到最細節，其實不太符合人類的思考模式；比較自然的做法，是先有大架構，看到實際畫面、操作幾次之後，再逐步發現原本沒想到的細節與例外情境。
• 前端開發如果只靠文件定義，就要讓 AI 做出符合預期的樣子，只能說很吃規格撰寫的功力。

這個做法的好處是：

• 在進行 prototype 開發的過程，透過整個視覺畫面，可以讓開發者把流程想清楚、定義得更完整，人畢竟是視覺的動物，有了畫面，再往下進行，會比光看文字容易很多。
• 可以更方便的拿來跟團隊、使用者進行討論，使用者也可以實際操作看看流程順不順。
• 最重要的一點，這整個 prototype 就是一份用 code 寫成的文件，裡面定義了操作方式、定義邊界、定義各種細節，跟文字規格相比，需求描述的精確度瞬間提升好幾倍。

這次是在做一個活動管理平台時，嘗試使用這套方法。平台功能大致是大家想得到的那些：活動建立、使用者報名、現場報到、問卷填寫、統計。

這類系統有個很適合拿來驗證這套方法的特性：同一套系統中同時有活動主辦方、報名者、現場工作人員等不同角色，每個角色看到的頁面、資料與操作都不一樣。因此 prototype 如果能直接切換角色，就能很快驗證不同使用情境是否合理。

那這個 prototype 是怎麼進行的呢？我會先從產品裡最核心的功能開始，往下推導出：

• 初步的 layout，例如：Nav Bar、Left Menu、Tab Bar 等頁面骨架
• 頁面路徑的大致架構
• 有哪些角色，跟大致的權限劃分

這幾件事其實是綁在一起的，頁面路徑跟 layout 有關聯，角色、權限，又會影響頁面路徑，所以這幾樣我會擺在一起考慮。等這些差不多確定之後，再往下定義「資料模型 (data model)」。

在回答 AI 800 個問題之後，可以得到一份初步的資料模型規劃，我通常會讓 AI 畫出 Mermaid ER Diagram，來視覺化理解，接著實作成 IndexedDB schema。

AI 產生 schema 之後，我會先看：有哪些 entity，以及重要欄位的 type。看 entity 可以掌握產品裡有哪些核心對象；type 則很適合拿來判斷 AI 是不是對需求有語意上的誤解。

舉例來說，需求中定義了兩種報到驗證方式： 掃 QR code 報到，或是工作人員搜尋報名者電話，手動幫忙進行報到。

而 AI 產生的報到方式的資料格式：

export type CheckInMethod =
  | "QR_CODE"
  | "STAFF_SEARCH"
  | "MANUAL";

一看就會知道，其中「MANUAL」完全是文字上造成的誤解，工作人員搜尋的方式其實就是「手動」的方式。type 的定義，可以很清楚地反映出 AI 如何解讀需求規格。

前面花了一點篇幅講資料模型 和 schema，但拉回整體流程來看，這一階段真正要先確定的，其實就是幾個專案地基：頁面路徑、角色與權限、資料模型。這些先有一個大致穩定的版本之後，就可以開始進行畫面的開發，我會先挑最核心的 user flow 開始實作。

但做到這裡很快就會發現，光有畫面還不夠，少了對應的資料和狀態，還是無法真正驗證畫面和流程。這時候我會準備一組 seed data，也就是事先定義好的測試資料，需要時直接載入 prototype。當然，透過畫面操作，建立臨時的假資料當然也可以，但如果需要反覆驗證，每次都要手動建立，會比較花時間。而且開發中，常會需要重建資料庫、修改 schema，也可以做一個「重置」的功能，每次都載入這份 seed data，回到初始狀態。

使用 seed data 還有一個好處是，可以直接把「特殊狀態」變成「規格」的一部分，譬如，直接產生一筆「報名已額滿」活動的 seed data，就可以很明確地驗證，各個相關頁面在額滿狀態下應該怎麼顯示。

另外，由於這個平台有不同角色的使用者，我也會在 seed data 裡建立多個角色，並加上一個「切換身份」功能，選中的身份可以存在 localStorage，這樣就能夠快速從不同視角操作整個 prototype。

核心的 user flow 做得差不多之後，接下來就可以開始把周邊的功能一個個疊加上去。我自己大致會重複這樣的流程：

確認功能需求 → 視需要調整資料模型 → 補上對應的 seed data → 實作頁面路徑 → 實作畫面與互動 → 實際操作驗證

有時候做到一半才會發現原本的資料模型不適用，有時候做出來，實際操作後，才發現原本設想的流程本身就有問題。這時就再往回修改。這也是做 prototype 的目的，「從實作中定義規格」。

因為 prototype 的目標是驗證會影響產品核心功能的設計，所以我不會把所有功能都完整做上去，像是：

• 登入
• 頁面路徑權限控管
• 上傳圖片
• 寄發 email
• 排程背景任務
• 三方服務，如：金流、LINE…等

把重點放在會影響核心流程的驗證即可。

軟體開發的彈性、可能性實在太大了，要靠文字規格窮舉所有情況實在太困難，透過一個可操作的 prototype，把流程、邊界定好，就能進一步縮小 AI 自由解讀需求的空間，開發也就比較不容易走偏。以上是我的一點經驗分享，希望對大家有幫助囉。