範圍鎖定 · 文件 MVP-範圍定義 · 產生於 2026-09-22 15:45
MVP 範圍定義
決策狀態：已凍結 · 凍結日：2026-09-21 · 最近一次調整：2026-09-21（使用者要求提前納入三項 P1）· 下次可變更時點：MVP 上線後第一次回顧
這版 MVP 只回答一個問題： 使用者在 30 秒內，能不能把一則社群貼文變成地圖上一個「有來源、有評價、排得進行程」的圖釘。
只要這條路走得通、資料存得住、後台查得到，MVP 就算成立；其餘一律延後。以下範圍已凍結，任何新增需求走第 6 節的變更控制，不臨時插隊。
1. 目標與成功指標
| 指標 | 目標值 | 量測方式 | 目前實測 |
|---|
| 核心流程走得通 | 端到端不中斷 | 正式環境手動走一次 + 自動化測試 | 已驗證（見驗收清單） |
| 解析成功率（有效連結） | ≥ 95% | parse_jobs.status='ok' 佔比 | 測試情境 100%（有效連結） |
| 解析耗時 | < 3000 ms | parse_jobs.elapsed_ms | 1 ms（規則引擎） |
| 資料落地 | 重啟後不遺失 | 重啟服務後查詢同一筆 | 已驗證 |
| 後台可追蹤 | 事件／日誌可查 | /admin 資料表瀏覽 | 已驗證 |
2. 納入範圍
P0 — 沒有它 MVP 不成立
| 編號 | 功能 | 對應規格 | 取捨理由 |
|---|
| P0-1 | 社群連結匯入：貼上 URL + 貼文文字，解析出店名／地區／標籤／推薦語 | FR-1.1、FR-1.2 | 這是整個產品的入口，最小可行的替代方案（不依赖原生分享面板） |
| P0-2 | 解析結果確認與修正：可改店名／地區／地址，或從候選清單挑選 | FR-1.2 | 解析一定會有誤，人工確認是準確率的最便宜保險 |
| P0-3 | 共享地圖與圖釘：建立地圖、群組成員、圖釘落點與列表 | FR-2.1 | 私人／親友圈的容器，是「信任」的前提 |
| P0-4 | 圖釘雙重狀態：想去 / 已去過切換 | FR-2.2 | 一句狀態切換就撐起「庫存 → 踩點」的核心循環 |
| P0-5 | 親友實測評價：星等 + 文字，僅群組可見 | FR-2.3 | 產品最重要的差異化（打破業配不透明） |
| P0-6 | 清單瀏覽與搜尋：依狀態篩選、關鍵字搜尋 | FR-2.1 | 沒有列表，地圖滿了就找不到東西 |
| P0-7 | 庫存轉行程：勾選 2–5 個地點，依距離最近鄰排序並估移動時間 | FR-4.1、FR-4.2 | 把「收藏」變成「真的會去」，是價值主張的收尾 |
P1 — 有它體驗才完整（本版已實作）
| 編號 | 功能 | 取捨理由 |
|---|
| P1-1 | 解析錯誤態與手動新增 | 解析失敗不能讓流程斷掉，必須有出口 |
| P1-2 | 區域雷達（只顯示尚未去過的點） | 低成本、高感知的「附近有什麼」場景 |
| P1-3 | 夜間模式 | 沿用既有設計稿，成本極低 |
| P1-4 | 管理後台：資料表瀏覽、事件稽核、系統日誌、指標 | 沒有後台就無法驗收「資料可追蹤」，也無法維運 |
| P1-5 | 健康檢查與就緒探針、結構化日誌、安全標頭、寫入限流 | 上線監控與防護的最低門檻 |
| P1-6 | 使用者資料匯出（JSON） | 資料可攜，降低信任門檻，成本極低 |
| P1-7 | LLM 解析引擎（可插拔，設 MAPSYNC_LLM_KEY 即啟用，不需改程式） | 使用者要求提前納入：規則引擎已可跑通流程，但真實貼文的語意變化大，LLM 是準確率的直接解 |
| P1-8 | Google Places 打點補強（可插拔，含座標投影） | 使用者要求提前納入：補上 place_id、精準經緯度、地址、營業時間；失敗只略過不阻塞 |
| P1-9 | PWA 與 Android Web Share Target | 使用者要求提前納入：用 PWA 換取「從 IG 分享面板直接丟進來」，不用等原生 App |
3. 排除範圍（本版明確不做）
用「不做」換「做得完」，是本版最重要的取捨。
| 排除項目 | 為什麼現在不做 | 排程 |
|---|
| 原生 App 外壳（Flutter／React Native 雙平台） | 需要 Xcode／Android Studio、商店審核與兩套原生壳；核心價值不需要它才能驗證。分享面板已改以 PWA 的 Web Share Target 補上 | 驗證留存後再評估 |
| iOS 原生分享面板 | iOS 的 Web Share Target 支援度有限，需原生 App | 與原生外壳一併評估 |
| Supabase／Firebase 即時同步 | 多一個外部相依與費用；MVP 先用單一 SQLite，群組同步以輪詢／重整達成 | 需要在多人同時編輯的即時感時再導入 |
| KOL 專屬地圖外鏈與一鍵匯入 | 屬於成長引擎，需要公開頁與權限模型 | Phase 2 |
| Klook／KKday／Inline 導購 | 涉及實際金流與分潤合約，須使用者再次確認 | 商用階段，先與平台談妥再開發 |
| 付費訂閱、廣告 | 商業模式尚未驗證 | 不排程 |
| 多語系、國際化 | 目標使用者以繁體中文為主 | 不排程 |
| 端到端加密、法務合規認證 | 需要正式法律審查 | 商用前處理 |
4. 關鍵技術取捨
Flutter / React Native 原生 App
行動優先 Web App（PWA）
代價：吃不到 iOS 原生分享面板。
換到：一個網址就能上線、驗收、給人試用。
Google Places API 取座標與營業時間
內建地標辭典 + 區域推估 + 人工校正
代價：覆蓋率有限。
換到：零成本、零授權風險，且錯誤有出口。
LLM（Gemini／GPT）提煉店名與標籤
規則引擎 heuristic-v1，LLM 為可插拔升級
代價：對沒見過的文案理解力較弱。
換到：1 ms 回應、零費用、結果可預期可測試。
Supabase / Firebase Realtime
單一 SQLite（WAL 模式）
代價：無即時推播。
換到：單檔可備份、可搬移，維運複雜度趨近於零。
以上取捨只影響「怎麼做」，不影響第 2 節任何一條 P0 的完成標準。
每一項取捨都留了升級介面：解析引擎走 server/parser.js、地標走 server/gazetteer.js、資料層走 server/db.js，換掉任一層都不動其他模組。
5. 範圍凍結與變更控制
凍結原則：只有「P0 走不通」或「阻斷級缺陷」可以打破凍結；新想法一律進下一版待辦，不得插隊。
變更流程：提出 → 說明它擋住哪一條驗收標準 → 記錄在里程碑看板的「變更紀錄」 → 由範圍擁有者決定是否換出等量的既有項目。
等價交換：要加一件事，就要拿掉一件同等工作量的事，維持總量不變。
6. 驗收對應表
| MVP 範圍 | 驗收標準 | 證據位置 |
|---|
| P0-1～P0-3 | 核心流程在正式環境完整走通 | 驗收清單 §B、§G |
| P0-4～P0-5 | 圖釘狀態與評價正確寫入且可追蹤 | 驗收清單 §D、§F |
| P0-6～P0-7 | 行程可生成並依距離排序 | 驗收清單 §E |
| P1-1 | 解析錯誤態有明確出口 | 驗收清單 §C |
| P1-4～P1-5 | 後台可查、可追蹤、有日誌 | 驗收清單 §F、上線檢查清單 §7 |
| P1-7～P1-9 | LLM 解析、Places 打點、分享面板皆可切換且可降級 | 驗收清單 §8、整合測試 21 項 |
驗收判準一律以「在本機／正式環境實際操作一次」為準，不以程式碼看起來正確為準。