Alliance — F&B Entertainment Alliance Platform

Developer Brief（技術概念與 MVP 開發規劃書）

文件版本：v1.0 ｜ 日期：2026-08-05 對象：投資人 / 合夥人 ｜ 階段：MVP Phase 1 公司：Global Wisdom Hub（globalwisdomhub.com） 技術路線：Cross-platform（Flutter / React Native）｜ 預算幣別：USD

---

⚠️ 關於本文件的驗證狀態（請先閱讀）

本 Brief 為產品與技術概念規劃，屬投資決策階段文件。文中所有：

• 開發預算數字
• 開發時程
• 第三方服務費用

皆為基於一般業界行情的估算（Estimate / Assumption），尚未取得正式廠商報價或簽約。標示為 [Assumption] 的項目，須於進入實作前透過實際報價、技術 PoC 驗證後才可作為承諾依據。

---

目錄

1. Executive Summary（投資摘要）
2. Product Concept — 三方生態圈
3. System Architecture（系統架構）
4. User Flow（核心使用流程）
5. UI/UX 提案（兩案 + Mockup + 建議）
6. Database 設計（高階）
7. API 清單（Google Map / YouTube / Payment / AI）
8. MVP 範圍與階段規劃
9. MVP 開發預算估算（USD）
10. Risks / Assumptions / Next Steps

---

1. Executive Summary（投資摘要）

Alliance 不是一個優惠券 App，而是一個「餐飲娛樂聯盟平台」。

我們把真實現場拍攝的餐飲、酒類（Sake / Whisky / Wine）、娛樂內容，結合 Google Map 地圖探索、會員積分、尋寶遊戲（Treasure Map） 與商戶管理系統，串連消費者、F&B 商戶、娛樂場所與品牌，打造新世代餐飲娛樂生態圈。

與一般優惠 App 的關鍵差異

投資亮點

• 內容護城河：真實影片內容難以被競品快速複製，且與 YouTube / 自有網站形成流量閉環。
• 三方飛輪：消費者探索 → 商戶內容曝光 → 更多商戶加盟 → 更豐富探索，形成網路效應。
• 遊戲化黏性：尋寶任務把「消費」轉為「闖關」，提升消費頻率與品牌探索。
• AI 為輔非主體：AI 僅用於後台推薦、行銷輔助與數據分析，降低技術風險與合規疑慮，內容真實性是賣點。
• 分階段控風險：Phase 1 先驗證消費者 App + 商戶後台 + Alliance 管理平台三大骨幹，避免一次重投入。

MVP 目標（Phase 1 Definition of Done）

在單一城市（示範：London）落地一個可運作的最小生態閉環：消費者能探索地圖 → 看真實影片 → 走尋寶任務 → 集點兌換；商戶能自助上架內容與活動；Alliance 總部能審核商戶、管理內容、看數據。

---

2. Product Concept — 三方生態圈

Alliance 平台由三個使用者角色與三個產品介面構成，透過內容、積分與數據互相驅動。

                    ┌─────────────────────────────────┐
                    │       ALLIANCE PLATFORM          │
                    └─────────────────────────────────┘
                                   │
        ┌──────────────────────────┼──────────────────────────┐
        ▼                          ▼                          ▼
┌───────────────┐         ┌───────────────┐         ┌───────────────┐
│  Consumer App │         │Merchant Portal│         │ Admin Dashboard│
│   消費者 App   │         │  商戶後台      │         │ Alliance 總部   │
├───────────────┤         ├───────────────┤         ├───────────────┤
│ 地圖探索        │         │ 上架店鋪/影片   │         │ 商戶審核/管理    │
│ 真實影片        │         │ 活動/優惠管理   │         │ 內容統一管理     │
│ 尋寶任務        │         │ 會員/回饋查看   │         │ 數據分析 (AI輔助)│
│ 積分/獎勵       │         │               │         │               │
└───────┬───────┘         └───────┬───────┘         └───────┬───────┘
        │                         │                         │
        └───────── 消費/內容/積分/數據 形成三方飛輪 ──────────┘

價值閉環： - 消費者 得到探索樂趣、真實資訊、會員回饋。 - 商戶 得到低成本內容曝光、活動導客、會員數據。 - Alliance 得到平台交易數據、招商能力、品牌合作籌碼。

Website ↔ App 整合：官網（globalwisdomhub.com）負責招商、品牌合作、投資資訊、活動報名並導流下載 App；App 負責消費者體驗與會員服務，並反向連回官網品牌頁。

---

3. System Architecture（系統架構）

高階架構（MVP 階段，AI 為輔助模組）：

┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ Consumer App │   │Merchant Portal│   │Admin Dashboard│
│ Flutter / RN │   │   Web (SPA)  │   │   Web (SPA)  │
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘
       │                  │                  │
       └──────────────────┼──────────────────┘
                          ▼
              ┌───────────────────────┐
              │   API Gateway / BFF   │   REST / GraphQL
              │   Auth (JWT / OAuth)  │
              └───────────┬───────────┘
                          ▼
    ┌─────────────────────────────────────────────┐
    │            Backend Services                  │
    │  Merchant · Content · Membership · Quest ·   │
    │  Points · Event · Booking · Analytics        │
    └───────┬───────────────────────────┬─────────┘
            ▼                           ▼
   ┌────────────────┐          ┌──────────────────┐
   │  PostgreSQL    │          │  Object Storage   │
   │  (核心資料)     │          │  (圖片/縮圖/QR)    │
   └────────────────┘          └──────────────────┘
            │
            ▼
   ┌──────────────────────────────────────────────┐
   │  第三方整合 External Integrations              │
   │  Google Maps · YouTube Data API · Payment ·  │
   │  Push Notification · (AI: Recommend/Analytics)│
   └──────────────────────────────────────────────┘

架構原則 - 模組邊界清楚：每個 service 單一職責，可獨立測試與演進（Membership、Points、Quest、Content 分離）。 - 內容儲存分層：影片初期外掛 YouTube（零儲存成本、快速上線）；圖片/縮圖/QR 存 Object Storage。未來再建自有 Video CMS。 - AI 為旁掛模組：推薦與分析以獨立服務接後台數據，不進入核心交易路徑，降低耦合與風險。

[Assumption] 具體技術選型（PostgreSQL / GraphQL vs REST / 雲端供應商）待技術負責人於 PoC 階段定案。

---

4. User Flow（核心使用流程）

4.1 消費者主流程（Consumer）

下載 App (由官網/QR導流)
   → 註冊/登入 (手機/Email/社群)
   → 地圖首頁：GPS 定位 → 看附近 Alliance 商戶
   → 點商戶 → 看介紹/影片/活動/評價 → 預約 或 導航到店
   → 到店掃 QR Code → 獲得積分 / 推進尋寶任務
   → 完成尋寶路線站點 → 解鎖 徽章 / 積分 / 免費體驗
   → 積分兌換獎勵 → 回訪

4.2 商戶流程（Merchant）

Alliance 審核通過 → 取得商戶帳號
   → 登入 Merchant Portal
   → 上架：店鋪資料 / 圖片 / 影片(YouTube連結) / Menu
   → 建立活動 (例: Friday Whisky Tasting：日期/時間/價格/名額/會員優惠)
   → 發放/檢視積分與回饋 → 查看會員消費數據與活動成效

4.3 Alliance 總部流程（Admin）

收到商戶加盟申請 → 審核資料 → 開通帳號
   → 統一管理內容 (影片/文章/活動/推廣)
   → 管理品牌頁 → 監看平台數據
   → AI 輔助分析 (熱門品類/高消費區域/高轉換活動) → 行銷決策

---

5. UI/UX 提案（兩案 + Mockup + 建議）

完整可點擊 mockup 請開啟 alliance-mockups.html（可 A/B 切換、點擊手機放大、鍵盤操作）。每案 7 個畫面，以下為兩張總覽截圖。

本產品有兩個核心賣點：①地圖探索 × 尋寶遊戲化、②真實現場影片內容。兩個提案各自以其中一個賣點作為 App 的主入口範式，讓決策者直觀比較兩種產品性格。

提案 A — Explorer-First（地圖探索主導）

核心概念：開場即沉浸式 Google Map，周邊 Alliance 商戶與尋寶路線疊在地圖上；「探索地圖、走任務」是主導航。體感像 Google Maps × Pokémon Go。

七畫面：① 地圖探索首頁（Pin + 尋寶路線 + 底部商戶清單）→ ② 商戶詳情頁 → ③ 尋寶任務路線（5 站進度 / 掃 QR 解鎖）→ ④ 積分 / 獎勵錢包 → ⑤ Onboarding / 登入（定位授權）→ ⑥ 搜尋 / 品類篩選 → ⑦ 掃碼打卡成功（積分 +50 · 情緒高點）。

提案 B — Story-First（真實影片主導）

核心概念：開場即全螢幕垂直影片 Feed，滑動觀看餐廳、Chef、品飲活動的真實現場內容；「看內容、被種草」是主導航。體感像 TikTok / Reels × 美食探索。

七畫面：① 真實影片 Feed 首頁（互動 + 「看店」CTA）→ ② 商戶頁（影片牆前置）→ ③ 尋寶任務（第二層，從影片延伸）→ ④ 個人檔案 / 積分 → ⑤ Onboarding / 興趣選擇（種子化影片牆）→ ⑥ 影片播放 / 留言社群 → ⑦ 從影片到現場 · 打卡成功（內容→到訪轉化）。

我的建議

建議採「A 為主結構、融合 B 的影片 Feed 作為第二 Tab」。

理由： 1. 尋寶遊戲化（A）是本產品最難被複製的差異點，也是提升消費頻率的核心機制，適合作為主導航與品牌記憶點。 2. 真實影片（B）是內容護城河，但影片產能需時間累積；把它放在強勢的第二 Tab（影片），既保留內容沉浸體驗，又不讓 MVP 初期「內容不足」拖累首屏。 3. 兩者共用同一套底部導航與品牌系統（見 mockup：A 的 tab 為「探索/影片/任務/我的」；B 為「影片/地圖/任務/我的」），意味著未來可用資料驅動 A/B 測試決定預設首屏，工程上不需重做。

若投資/營運策略更偏「內容媒體」路線，則採 B 為主；此決策建議在 MVP 上線後以留存與轉換數據驗證，而非提前鎖定。[Needs validation]

商戶後台與 Alliance 管理平台 UI（Backend）

上述兩案是消費者 App。另外兩個角色介面為 Web/桌面後台，在 alliance-mockups.html 頂部切換到 Merchant 後台 與 Admin 平台 分頁即可檢視（消費者 App 與後台已合併於同一檔）。設計刻意採乾淨淺色數據介面，與消費者 App 的沉浸深色區隔 —— B2B 工具以清晰、可讀、可操作為先。

Merchant Portal（商戶後台） — 商戶自助經營，含 KPI 總覽、到訪趨勢、內容/活動管理與新增活動表單：

Alliance HQ Admin Dashboard（總管理平台） — 總部審核商戶、統一管理內容、數據儀表板（AI 輔助）。圖表採已驗證的 CVD 色盲安全配色 + 圖例二次編碼：

三個角色（Consumer / Merchant / Admin）共用同一套品牌系統（Alliance 標誌、Fraunces 標題、琥珀主色），但依使用情境分化：消費者端沉浸深色重體驗，後台端淺色重數據與操作效率。

---

6. Database 設計（高階）

MVP 核心資料表與關聯（高階，不下到欄位型別；細節於實作階段定案）：

users ────< user_points_ledger >──── points_rules
  │                                        
  │──< memberships (tier, badges)          
  │──< quest_progress >──── quest_steps >──── quests
  │──< bookings >──── events                
  │──< reward_redemptions >──── rewards     
  │                                         
merchants ──< merchant_media (photo/video_url)
  │        ──< events (date/time/price/quota/member_offer)
  │        ──< rewards
  │        ──< qr_codes (check-in)
  │        └─ 位置欄位 (lat/lng) → 供地圖查詢
  │
content (video/article/promotion) ── 關聯 merchants / quests

核心實體說明

積分採 Ledger（流水帳）設計：所有加減點皆記錄，餘額由帳可推導，確保可追溯、可對帳，避免直接改餘額造成爭議。

---

7. API 清單（第三方整合）

內建 API（自建後端）：Auth、Merchant、Content、Membership、Points、Quest、Event/Booking、Analytics 等 service 對三個前端提供 REST/GraphQL 介面。

所有第三方費用與 quota 需在 PoC 階段以實際 key 測試確認，再據以估算營運成本。[Needs runtime validation]

---

8. 交付範圍分層：Baseline MVP / Options / Phase 1.5

交付範圍的權威定義見 PRD §5。本 Brief 僅摘要，不另創一套需求。核心原則：第一版只固定承諾「完整核心迴圈」，Options 另計，Phase 1.5 延後。 Reviewer 應能在 2 分鐘內分清三層。

8.1 Baseline MVP（固定承諾 · 完整核心迴圈）

探索 → 到訪 → 集點 → 兌換 ＋ 商戶/總部最小可運營：

• Consumer：Login、探索（地圖或影片，擇一主入口、另一為次 tab）、商戶頁、YouTube 影片內嵌、QR/GPS check-in、積分 ledger、獎勵兌換、單一預設尋寶路線、Onboarding、搜尋/品類篩選
• Merchant（最小驗證流程）：登入、上架店鋪/圖片/影片連結、送審
• Admin（最小營運/稽核）：商戶審核（approve/reject）、內容上/下架、基本營運指標、稽核 log

8.2 Options（獨立估價/排期 · 不含在 Baseline 固定價與時程）

• O1 完整 Quest Builder / 複合任務
• O2 Event / booking 完整流程 —— mockup 中「預約 / Reserve」為 concept preview，非已承諾功能
• O3 進階 dashboard / 報表
• O4 Push campaign

8.3 Phase 1.5（後續版本）

• 金流收款、AI 個人化推薦、進階 push automation、進階會員分級 / loyalty automation
• （更後：自有 Video CMS、多城市 / 多語系）

8.4 合規前提（見 PRD §8.5 Governance）

第一版上線受合規 release gates 約束，涵蓋：18+ eligibility、酒精行銷、age assurance、媒體權利、UGC moderation、隱私 lawful basis、定位資料、資料保存、帳號刪除、第三方處理者、法域（decision G1–G11）。未取得 Legal／客戶書面確認前，對應功能顯示 open risk，不視為已合規。 完整決策表、owner、due date 與 release gate 見 PRD §8.5（本 Brief 不自行下法律結論）。

---

9. MVP 開發預算估算（USD）

⚠️ 以下為 [Assumption] 業界行情估算，非正式報價。 實際金額依團隊所在地、外包 vs 自建、設計精細度與第三方費用差異可達 1.5–2 倍。建議以此表向 2–3 家開發商詢價後定案。

9.1 建議交付模式：平行團隊 × AI 輔助 × 先驗證市場

投資人應看「日曆週數與驗證里程碑」，不是把不同職能的工作量順序相加。 以下時程對齊 §8 交付分層；Baseline MVP 為固定承諾範圍，Options（O1–O4）不納入 Pilot／Baseline 固定時程，Phase 1.5 另階段估價。所有週數均為 [Assumption]，須在 Week 0–2 完成團隊排程與技術 PoC 後轉為正式 delivery plan。

建議核心團隊：6–8 人並行交付

AI 輔助使用邊界：用於 UI／API scaffolding、測試案例與 fixtures、文件同步、靜態分析、重複性 refactor 與 regression triage；Auth、積分 ledger、QR/GPS 防濫用、隱私／法遵、安全與 production release 必須由人員 review 並通過自動測試。AI 是 throughput accelerator，不是刪除 QA／Tech Lead 的理由。

估算依據採保守解讀：GitHub 的受控 coding task 曾觀察到 AI 輔助組完成速度提升，但該結果不等於整體專案同比縮時；DORA 2025 亦指出 AI 可提高 throughput，但若缺少自動測試與快速 feedback loop，delivery stability 可能下降。因此本計畫只把 AI 效益放在可驗證、可 review 的工作，不直接套用單一 productivity 百分比。

9.2 MVP 日曆時程與市場驗證 Gate [Assumption]

投資人摘要：在決策與素材準時到位的前提下，目標是 10–12 週推出可驗證市場的 Pilot MVP，而非等待所有 production hardening 完成才接觸市場；完整 launch-ready Baseline 預估 14–18 週。這是多職能平行執行的日曆時程，不是把各職能工作順序累加的長期專案。

時程成立前提：Week 0–2 鎖定 Baseline、6–8 人核心團隊可同時到位、種子商戶／內容／測試帳號已準備、第三方 API 權限可用、G1–G11 的 blocking decision 能依 gate 完成。任一前提未成立，時程須重新 forecast，不應以加班或跳過 QA 補足。

9.3 分階段投資預算（USD）[Assumption]

預算以交付成果與投資 Gate呈現，不以投入工時單位推算：

Options（§8.2）另計，不阻塞 12 週市場驗證：

Options 若增加專責人力可與 hardening 部分平行，但預算、integration risk 與 QA scope 會同步增加；不得把所有 Option 塞回 Baseline 卻維持原時程。

投資規劃建議級距：Baseline MVP（§8.1） 一次性開發估 USD $90K – $180K（採混合團隊、含設計與 QA），另備 15–20% 風險緩衝。此區間只含 Baseline；Options（§8.2 O1–O4）與 Phase 1.5 需獨立估價與排期，不含於此。

Phase 1.5（§8.3）：金流、AI 個人化、進階 push automation、會員分級 —— 另階段估價，本輪不列入。

9.4 每月營運成本（上線後）[Assumption]

⚠️ 上述營運數字必須以實際 API key 壓測與真實用量驗證後才可作為財務模型輸入。[Needs runtime validation]

---

10. Risks / Assumptions / Next Steps

10.1 主要風險與緩解

10.2 關鍵假設（需驗證）

• [Assumption] 所有預算 / 時程 / 第三方費用為業界行情估算，未取得正式報價。
• [Assumption] 技術選型（Flutter vs RN、DB、雲端）待技術負責人 PoC 定案。
• [Needs validation] UI/UX 主案（A vs B）建議由 MVP 上線後留存/轉換數據驗證。
• [Needs runtime validation] Maps / YouTube / Payment quota 與費用須以實際 key 測試確認。
• [Needs validation] 合規決策 G1–G11（PRD §8.5）尚待 Legal / 客戶書面確認；owner 命名（Client/Product/Legal/Engineering）與 due date 為本輪假設。

10.3 Next Steps（下一步）

1. 確認 UI/UX 主方向（建議 A 為主 + 影片 Tab）→ 收斂為完整 UI Kit。
2. 技術 PoC：Maps 用量成本、YouTube 內嵌、尋寶任務引擎可行性。
3. 向 2–3 個 6–8 人交付團隊詢價，要求分別承諾 Gate A–D 的人力配置、10–12 週 Pilot、14–18 週 launch-ready Baseline、驗收證據與排除項目，取得正式報價取代本文件估算。
4. 簽約種子商戶（單一城市），準備首批真實影片內容。
5. Week 0–2 完成 MVP DoD、技術 PoC、G1–G11 gate 與 pilot KPI，通過 Gate A 後進入平行開發。

---

附件

• alliance-mockups.html — 完整全平台 Mockup（單一檔），頂部切換 4 分頁：消費者提案 A / B（各 7 畫面）、Merchant 後台（2 畫面）、Admin 平台（2 畫面）。可點擊放大、鍵盤操作、reduced-motion
• mockup-proposal-a.png / mockup-proposal-b.png — 消費者 App 提案 A / B 總覽
• mockup-merchant.png / mockup-admin.png — 商戶後台 / Alliance 管理平台總覽

---

Global Wisdom Hub · turnkey business solutions · F&B consultancy · sake & whisky education · bridging Asia and Europe.

Alliance — F&B Entertainment Alliance Platform

Product Requirements Document (PRD)

格式：PRD（依 github/awesome-copilot@prd 概念）｜ 對象：Product / Engineering / Design 團隊 版本：v0.1（Draft）｜ 日期：2026-08-06 ｜ Owner：Global Wisdom Hub 狀態：Discovery 完成、待技術 PoC 驗證 相關文件：Alliance-App-Developer-Brief.md（投資人版）、alliance-mockups.html（UI/UX 提案 A/B，各 7 畫面）

⚠️ 驗證聲明：本 PRD 中所有預算、時程、第三方 quota/費用、效能數字為 [Assumption]，須經技術 PoC 與實際報價驗證後方可作為承諾。標 [Needs runtime validation] 者需以實際 runtime output 佐證。

---

0. Discovery Summary（探索階段結論）

PRD 慣例：先問清楚「核心問題 / 成功指標 / 限制」，再進入需求。

---

1. Executive Summary

Alliance 讓消費者透過真實現場影片、Google Map 地圖探索、尋寶任務與會員積分，發現並到訪聯盟商戶；商戶自助經營內容與活動；Alliance 總部審核商戶、統一管理內容並取得數據。MVP Phase 1 在單一城市交付消費者 App + 商戶後台 + Alliance 管理平台的最小生態閉環。AI 僅用於後台推薦、行銷輔助與數據分析。

---

2. Goals & Success Metrics（目標與可量化成功指標）

PRD 慣例：禁用「快 / 直覺 / 好用」等模糊詞，全部量化。以下為 MVP 上線後 90 天目標。[Assumption]（目標值待與 stakeholder 校準）

反指標（Guardrail）：尋寶任務不得將「掃碼打卡」誤發積分率 > 0.5%；推薦不得推送已停業商戶。

---

3. User Personas（使用者角色）

---

4. User Stories & Acceptance Criteria（使用者故事與驗收準則）

PRD 核心：As a <persona>, I want <goal>, so that <value> + Given/When/Then 驗收準則。

Epic A — 地圖探索與商戶（Consumer）

US-A1　As Jordan, I want 打開 App 就看到附近 Alliance 商戶在地圖上, so that 我能立刻知道周邊有什麼。 - AC1 Given 已授權定位，When 進入探索首頁，Then 於 ≤ 2s 內在地圖顯示 GPS 位置與 ≤ 800m 內的 Alliance 商戶 Pin。 - AC2 Given 定位被拒，When 進入首頁，Then 顯示「開啟定位」空狀態並提供手動選城市。 - AC3 Given 附近無商戶，When 載入完成，Then 顯示 empty state 並建議擴大範圍或推薦路線。

US-A2　As Alex, I want 點商戶查看完整資訊與訂位, so that 我能決定是否前往。 - AC1 商戶頁須含：介紹、地址、營業時間、活動、相片、≥1 支影片、評價、預約連結。 - AC2 When 點「預約」，Then 進入預約確認頁，複述名額/時間/價格，並提供「免費取消」說明。（緩解高風險動作）

Epic B — 真實影片內容（Consumer）

US-B1　As Mei, I want 觀看商戶的真實現場影片, so that 我能感受真實體驗再決定到訪。 - AC1 影片以 YouTube Player 內嵌播放，起播 ≤ 3s [Needs runtime validation]。 - AC2 影片頁提供「看店 / 這家店」CTA 直達商戶頁。 - AC3 Given 商戶尚無影片，Then 顯示 content empty state（不得顯示空白）。

Epic C — 尋寶任務與積分（Consumer）

US-C1　As Jordan, I want 沿尋寶路線探索並解鎖獎勵, so that 探索像玩遊戲。 - AC1 路線顯示 N 站、每站狀態（done/current/locked）、分站獎勵（積分/徽章/體驗）。 - AC2 When 於商戶處掃正確 QR（且 GPS 距離 ≤ 100m），Then 記錄 check-in、發放對應積分、推進任務並顯示打卡成功頁。 - AC3 Given QR 與定位不符，Then 拒絕打卡並提示錯誤原因（防呆）。

US-C2　As Alex, I want 用積分兌換獎勵, so that 消費有回饋。 - AC1 積分採 ledger 流水帳，每筆加減可追溯；餘額 = 帳目推導。 - AC2 When 兌換，Then 檢核餘額足夠、扣點、產生兌換憑證；不足時 CTA 顯示差額。

Epic D — 商戶後台（Merchant Portal）

US-D1　As 商戶 Owner, I want 自助上架店鋪/影片/活動, so that 我能低成本曝光。 - AC1 可新增：店鋪資料、圖片、影片連結、Menu、活動（日期/時間/價格/名額/會員優惠）。 - AC2 上架內容須經 Admin 審核狀態機（draft → pending → published）。

US-D2　As 商戶 Owner, I want 查看會員與活動成效, so that 我能優化經營。 - AC1 可查看：到訪/消費紀錄、積分發放、獎勵使用、單一活動報名與轉換。

Epic E — Alliance 管理平台（Admin）

US-E1　As Admin, I want 審核商戶與內容, so that 平台品質可控。 - AC1 商戶申請可審核（approve/reject + 理由）；內容可上/下架。

US-E2　As Admin, I want 看跨店數據儀表板, so that 支援營運決策。 - AC1 Dashboard 顯示：活躍用戶、熱門品類、高消費區域、活動轉換率（見 §10 AI）。

---

5. Delivery Scope — Baseline MVP / Options / Phase 1.5（交付範圍分層）

本節為交付範圍的權威來源（source of truth）。 Reviewer 應能在 2 分鐘內回答：第一版一定交付什麼（Baseline）、哪些另計（Options）、哪些延後（Phase 1.5）。Options 不納入 Baseline 的固定估價與時程。

5.1 Baseline MVP（固定承諾 · 完整核心迴圈）

第一版必交付的最小完整迴圈：探索 → 到訪 → 集點 → 兌換，加上商戶與總部的最小可運營能力。

5.2 Options（獨立估價與排期 · 不納入 Baseline 承諾）

以下為 concept preview / 加購項，需獨立估價與時程，不計入 Baseline 固定價與 timeline：

Baseline 的尋寶任務僅為「單一預設路線 + 站點進度 + 分站獎勵」最小版；完整 Quest Builder（O1）另計。

5.3 Phase 1.5（明確後續版本）

• Payment（金流收款）
• AI personalization / recommendation
• Advanced push automation
• 進階會員分級 / loyalty automation

5.4 Integration dependencies & fallback

Maps / YouTube / QR / GPS 的實際行為與配額須經 PoC 驗證；本 PRD 不承諾未驗證行為。[Needs runtime validation]

功能對應畫面見 alliance-mockups.html（消費者提案 A/B 各 7 畫面、Merchant/Admin 各 2 畫面）。mockup 中屬 Options 的入口（如預約、完整任務編輯）為 concept preview。

---

6. UI/UX Requirements（設計需求）

提供兩個方向提案，須擇一或融合後定案（見 mockup）：

• 提案 A — Explorer-First（地圖主導）：首屏地圖 + 尋寶路線疊層；適合 Alex/Jordan 的目標導向與探索。
• 提案 B — Story-First（影片主導）：首屏垂直影片 Feed；適合 Mei 的內容種草。
• 建議：A 為主結構 + B 影片作為第二 Tab，共用同一設計系統，上線後以 G1–G3 數據 A/B 決定預設首屏。[Needs validation]

設計驗收：每個核心畫面須交付 default / loading / empty / error 四狀態（mockup 已含 onboarding 與打卡成功高點畫面）。

---

7. Technical Architecture（技術架構，摘要）

跨平台 App（Flutter/RN）＋ Web 後台（Merchant/Admin）＋ API Gateway/BFF（Auth JWT/OAuth）＋ 後端服務（Merchant/Content/Membership/Quest/Points/Event/Booking/Analytics）＋ PostgreSQL ＋ Object Storage ＋ 第三方（Maps/YouTube/Payment/Push/AI）。完整架構圖見 Developer Brief §3。

[Assumption] 技術選型待 PoC 定案。

---

8. Non-Functional Requirements（非功能需求，量化）

全部量化，不用模糊詞。[Needs runtime validation]（須壓測驗證）

---

8.5 Governance, Compliance & Release Gates（治理 · 合規 · 發布關卡）

本節為合規決策的 source of truth。 所有項目在取得 Legal / 客戶書面確認前，一律標 Needs validation / Unverified，不得寫成已合規。同一 decision ID 於 §13 Risks、§14 Open Questions、§15 DoD 交叉引用，避免資訊漂移。 Owner 命名為本輪 [Assumption]（待客戶確認）：Client（客戶/品牌方）、Product、Legal、Engineering。

8.5.1 Governance Decisions（治理決策表）

8.5.2 Release gates 定義

• Design sign-off gate：G1、G11 未決不得定案設計範圍。
• Development start gate：Baseline scope（§5.1）+ G1/G11 需先確認。
• Content go-live gate：G2、G4、G5 未決不得開放內容/UGC/影片上架。
• Production release gate：G3、G6–G10 未取得 Legal/客戶書面確認前，顯示 open risk，不標 Completed。

[Assumption] Due date 待客戶排定；本輪不代客戶決定日期，僅標 [TBD] 並指派 owner。

---

9. Dependencies & Integrations（依賴與整合）

---

10. AI System Requirements（AI 需求 + 評估策略）

awesome-copilot PRD 特色章節：AI 需附評估策略，非只描述功能。AI 為輔助、非核心路徑。

AI 護欄：不得推薦已停業/未審核商戶；生成文案須標示 AI 輔助並經商戶確認後發布。

---

11. Data Requirements（資料需求，高階）

核心實體：users、memberships、merchants、merchant_media、events、bookings、quests/quest_steps/quest_progress、qr_codes、points_rules/user_points_ledger、rewards/reward_redemptions、content。關聯見 Developer Brief §6。積分採 ledger 設計以確保可追溯。

---

12. Out of Scope（Baseline MVP 明確不做）

交付分層的權威定義見 §5。以下為 Baseline MVP 明確不承諾者；Options（§5.2）與 Phase 1.5（§5.3）另計/延後。

• 自有 Video CMS（初期用 YouTube）→ P2
• 完整金流收款 → Phase 1.5（Baseline「預約」僅 concept preview，見 O2）
• 進階 AI 自動投放 / 個人化行銷 → Phase 1.5
• 完整 Quest Builder / Event booking 完整流程 / 進階報表 / push campaign → Options（§5.2）
• 多城市 / 多語系大規模擴張 → P2
• 商戶自助結算與複雜分潤 → P2

---

13. Phased Rollout & Risks（分階段上線與風險）

Risk × Governance 交叉引用：合規未決（§8.5 G1–G11）為 Baseline 的 release-gate 風險；未取得 Legal/客戶確認前，對應 gate 顯示 open risk（見 §8.5.2）。

預算 [Assumption]：Baseline MVP 一次性 USD $90K–$180K + 15–20% 緩衝；營運 $250–$1,200/月。Options 另計、不含於此區間。詳見 Developer Brief §9。

---

14. Open Questions（待決問題）

每個 Needs validation / Unverified 項目均已於 §8.5 指派 owner；Due date 待客戶排定（[TBD]）。

---

15. Acceptance / Definition of Done（MVP 完成定義）

Baseline MVP（§5.1）視為完成，當：

1. §5.1 B1–B7 全部達成，且 §4 對應 US 的 AC 通過（含 empty/error 狀態）。
2. §8 非功能門檻經壓測達標 [Needs runtime validation]；文字/UI/focus 通過 WCAG 2.2 AA contrast。
3. 單城市 ≥ 20 商戶、每商戶 ≥ 2 則內容上架。
4. 三個介面（Consumer/Merchant/Admin）端到端可運作並通過 UAT。
5. 合規/治理 acceptance（§8.5）：G1（18+）、G2（酒精行銷）、G4/G5（媒體權利/UGC）、G6（隱私 lawful basis）、G7（定位）、G8/G9（保存/刪除）之 acceptance criteria 均取得 Legal / 客戶書面確認；未取得者對應 release gate 顯示 open risk，該 gate 不標 Completed。
6. Options（§5.2）不列入 Baseline DoD；如客戶採購，各自有獨立 DoD。

DoD 與 §8.5 release gates、§13 Risks、§14 Open Questions 引用同一 decision ID（G1–G11），確保四處一致、無資訊漂移。

---

Global Wisdom Hub · F&B Entertainment Alliance Platform — PRD Draft v0.2（P1 scope 分層 + governance gates）