AI 快速原型實戰：BA/PM 用 AI 由需求到可點擊 Prototype 嘅 5 步工作流

2026-08-16 · BA × AI 實戰 · Eric Cheung

點解 BA/PM 要識快速原型

需求文件有一個天生嘅缺陷：文字好容易畀人誤讀。你寫「用戶可以申請假期」，stakeholders 腦入面出現嘅畫面可能完全唔同——有人諗到一個手機 App，有人諗到 Excel 表格，有人諗到 Email 畀 HR。20 頁 BRD 寫得再仔細，都阻唔到每個人各自解讀。原型就係為咗解決呢個問題：將抽象需求變成一個可以撳嘅畫面，所有人睇住同一樣嘢討論。

以前整原型係設計師嘅專利：要識 Figma、要識 UX 原則、要花幾日先出到一個似樣嘅版本。但 AI 改變咗呢個遊戲規則——而家你可以用文字需求，喺幾分鐘內生成一個可點擊嘅介面。BA/PM 唔需要成為設計師，但需要識得駕馭 AI，將需求變成原型，再喺開發之前同 stakeholders 驗證清楚。呢個正正係 AI-Augmented BA 嘅核心技能。

AI 快速原型 5 步工作流 — 由文字需求到可點擊 Prototype：AI 輔助嘅 5 步工作流

快速結論（TL;DR）

原型將抽象需求變成可以撳嘅畫面，令所有人睇住同一樣嘢討論——喺開發之前消滅理解誤差
5 步工作流：揀範圍 → AI 生成初稿 → 整可點擊原型 → 同 stakeholders 一齊行 → 迭代記錄
AI prompt 要分兩階段：先確認「畫面清單 + 用戶流程」嘅結構，先至深入畫面細節
測試時畀任務唔畀答案，留意 stakeholders 停低嘅位——嗰啲就係需求缺口
原型係需求嘅可執行版本：確認咗嘅決定要寫返入需求文件，兩者保持對齊

5 步工作流：由需求到可點擊 Prototype

AI 快速原型 5 步流程圖 — 5 步工作流總覽：揀範圍 → 生成初稿 → 整可點擊原型 → 一齊測試 → 迭代記錄

Step 1 — 揀啱原型目標同範圍

原型唔係為咗靚，而係為咗答一條問題。開始之前，先定義你今次想驗證啲咩假設——例如「用戶識得自己完成申請流程」或者「審批人睇得明下一個步驟係咩」。跟住畫低範圍：覆蓋邊啲角色、邊幾個流程步驟、明確唔做啲咩（登入、後台、error handling 全部可以留白）。範圍越細，原型越快，測試越有效。

驗證嘅核心問題：呢個流程用起嚟順唔順？用戶會唔會卡住？
目標用戶角色：邊個會用？佢哋有咩習慣同限制？
涵蓋嘅流程步驟：由邊一步開始、到邊一步完？
明確唔做嘅範圍：登入、權限、後台、異常處理——全部留白

Step 2 — 用 AI 由需求生成初稿

將需求整理成 AI 可以消化嘅 prompt：目標用戶、要做嘅任務、每個畫面嘅內容同操作。關鍵技巧係分兩階段——先叫 AI 出「畫面清單 + 用戶流程」，確認結構啱先至深入細節。結構錯咗嘅話，靚到識飛嘅畫面都係嘥氣。

我哋準備為「員工假期申請流程」設計一個可點擊原型。請幫我：
1. 列出原型需要嘅畫面清單（每個畫面一句講明目的）
2. 畫出用戶流程：由登入後到完成申請嘅每一步
3. 每個畫面列出：主要內容、操作按鈕、需要顯示嘅數據
4. 標出流程入面需要做決定嘅位（例如審批人選擇）
5. 輸出畫面描述，等我確認結構先至開始整

--- 貼上需求、目標用戶同 Step 1 嘅範圍 ---

Step 3 — 將 AI 輸出變成可點擊原型

有幾條路可以將 AI 嘅輸出變成真正可以撳嘅原型，揀邊條視乎受眾同時間：最快係叫 AI 直接生成 HTML/CSS，開瀏覽器就睇到；想靚啲可以用 v0、Bolt、Lovable 呢啲 AI 介面生成工具，幾分鐘出到 React 版本；如果團隊用 Figma，可以將 AI 生成嘅畫面描述餵入 Figma AI 做設計稿。同業務 stakeholders 演示，一個簡單 HTML 已經好夠——佢哋要嘅係「撳得到」，唔係「靚到 production 級」。

最快：叫 AI 生成 HTML/CSS，瀏覽器直接開——適合內部對齊同業務演示
最靚：v0 / Bolt / Lovable 生成 React 介面——適合要同開發團隊交接嘅原型
設計師協作：將 AI 畫面描述餵入 Figma AI 做設計稿——適合要落設計系統嘅專案
記住：原型嘅目標係驗證，唔係交付——夠用就好

Step 4 — 同 stakeholders 一齊行原型

原型嘅價值在於對話。唔好淨係將條 link 丟畀 stakeholders 叫佢哋「睇吓」，而係約佢哋坐低，一齊行一次流程。主持嘅技巧：唔好問「你覺得點樣？」——太開放，得嚟嘅答案多數係「幾好」。要畀任務：「你而家試吓申請一日假期。」然後觀察佢哋喺邊一步停低、邊度問問題、邊度撳錯。嗰啲位就係需求嘅缺口。

畀任務，唔畀答案：叫佢完成一個具體任務，睇佢自己做
問「點解」，唔問「係咪」：「點解你會撳呢度？」好過「呢度係咪有問題？」
記低停頓位：邊一步諗最耐，嗰度就係流程有樽頸
一人一套任務：stakeholders 各自做，先見到真正嘅分歧

Step 5 — 迭代同記錄決定

測試完之後，將發現分類：流程問題（步驟次序錯、搵唔到掣）、內容問題（字眼睇唔明、數據顯示唔啱）、範圍問題（發現全新需求）。叫 AI 幫你將 feedback 整理成「原型測試報告 + 修訂清單」，更新原型再行一輪。最後將確認咗嘅決定寫返入需求文件——原型就係需求嘅可執行版本，兩者要對得上。

以下係原型測試嘅觀察紀錄。請幫我：
1. 將 feedback 分類：流程問題 / 內容問題 / 範圍問題 / 設計偏好
2. 每項標明嚴重程度同建議修訂
3. 整理成一份「原型測試報告」連修訂清單
4. 標出需要同 stakeholders 再確認嘅開放問題

--- 貼上測試觀察紀錄 ---

3 個常見陷阱

陷阱一：原型整得太靚，stakeholders 以為係成品。靚到 production 級嘅原型會令人忘記「呢個仲係草稿」，開始執著於顏色同字型。喺原型加「草稿 / Draft」水印，一開始講明：呢個係驗證工具，唔係 final UI。
陷阱二：跳過測試直接開發。原型最大嘅價值係提早發現誤解——如果整完原型就直接交畀開發，唔同 stakeholders 行一次，你只係將寫需求嘅誤解原封不動搬咗入 code。
陷阱三：畀 AI 自由發揮，脫離需求。AI 好鍾意加嘢——多咗個步驟、多咗個畫面、加咗啲你冇要求嘅功能。每次迭代都要對返 Step 1 嘅範圍：AI 加咗嘅嘢，問一句「呢個係咪需求入面有？」

總結

快速原型係 BA/PM 嘅超能力：將需求由「大家各自解讀」變成「大家一齊睇住同一樣嘢」。AI 負責將需求變成畫面嘅速度，你負責範圍、驗證同決定。5 步工作流入面，最值錢嗰步永遠係 Step 4——同 stakeholders 坐低一齊行。下次開需求會議之前，試吓用 AI 整一個可以撳嘅原型，你會發現討論嘅質素完全唔同。