一個新功能，
從想法到上線的旅程

把想法帶來

旅程從一個想法開始。你不需要準備完整的文件——一段描述、一份 PRD 草稿、或一張畫面截圖都可以當起點。第一步是把這個 Storybook 專案下載到自己的電腦（git clone），接下來整趟旅程都在你自己的副本裡進行。

• PM有產品想法或 PRD 草稿 → 下載專案，直接開始這趟旅程（下一站）。
• 設計師你也可以自己發起原型——下載專案後走一樣的旅程。只有一張 UI 圖、想先知道「現成元件夠不夠」→ 走快速通道：用 Component Coverage Analyzer 上傳圖片，AI 會回報哪些能用現成的、缺什麼。

提醒：Figma 設計稿在這條旅程裡是「參考資料」，不是必要條件。沒有設計稿也能出發。

一起釐清：AI 問，你答

發起的人（設計師或 PM）在自己的專案副本裡啟動原型。AI 不會悶著頭猜，它會一次一題地問清楚，確定之後才動工。產品問題一定要 PM 回答——別人代答不了。

• PM準備好三類答案：使用者從哪裡進來（哪個頁面、哪個按鈕）？要做在哪幾個平台（iOS、Android，還是兩個都要）？怎麼樣算做對了（驗收條件）？

提醒：答不出來的問題可以先掛著，AI 會記成「待決事項」——但每一條之後都要有人回頭給答案。其中目標平台不能掛：答案會寫進說明書的 Target Surfaces，第 5 站接棒的 AI 靠它決定要動哪一個 App 專案、以及導覽要怎麼接。

背後的 AI 指令：/storybook-product-prototype

長出可以點的原型

AI 用現成元件組出一個真的可以點的原型，放在 Storybook 裡：頁面之間可以跳轉、有假資料撐場面。同時，給下一棒的說明書也自動長好了（需求、畫面規格、流程圖、資料格式、驗收清單）。

• 設計師看兩件事：用的元件對不對（AI 列出它用了哪些現成元件，你確認或否決）、長得對不對（顏色間距有沒有走鐘、按下去的反應對不對）。

提醒：原型用的是假資料，這是刻意的——先把「長什麼樣、怎麼流動」定下來，真資料是之後工程的事。

一起看 Demo，蓋章

團隊圍著 Storybook 把原型走一遍。這一站要做兩個決定，然後蓋章。

• PM方向對嗎？驗收條件都照顧到了嗎？掛著的待決事項清掉了嗎？
• 設計師原型裡臨時做的新元件，哪些值得收編進元件庫讓以後大家共用？（收編是常態，不是例外）

交棒

交棒交的不是口頭說明，而是那包蓋過章的說明書。裡面的資訊完整到接棒的人（Production 端的 RD 或 AI）不用來問你就能開工。

• PM把說明書所在位置交給接棒的人，一句話講清楚要做什麼。
• RD開工前先檢查兩件事：章蓋了沒？沒蓋章就退回，不開工。Target Surfaces 寫清楚了嗎（iOS、Android 各要不要做）？如果是讓 AI 接棒，要指定一位該平台的 App 工程師陪跑——AI 遇到要做決定的地方會停下來等人回答。

背後的 AI 指令：/native-product-implementation（iOS／Android）。它讀的就是這包說明書，在 App 專案裡組出 SwiftUI／Compose 的畫面與導覽。

做成真的產品，驗收

Production 端的 RD 或 AI 照著說明書，把原型翻譯成真正的 App 程式碼——長在 Xcode／Android 專案裡，用的是該平台原生的畫面與導覽。這一站分兩棒：第一棒把畫面與流程組好（先用假資料跑通），第二棒才把假資料換成真的。做完各跑一輪自動檢查，長得不像的地方會用畫面比對工具抓出來。

• PM拿著驗收清單逐項打勾。
• RD第一棒：組畫面、接流程、把每個狀態做出來，全程跑假資料，並留好可替換的接縫。第二棒：把假資料換成真的（接 API、登入、儲存），由說明書上記名的那個人或團隊接手——沒記名就要先問清楚是誰，不能沒人認領。所以「做完了」不等於「可以上線了」，中間還有這一棒。

提醒：看到成品跑著假資料，不是偷工減料——那是交接設計，真資料由工程接手才安全。

背後的 AI 指令：第二棒是 /production-data-integration，只動資料、不動畫面。