咻揪趣 MVP · v0.19.0
解法評估 · 文件 五項缺口解法評估 · 產生於 2026-09-22 15:45

五項規格缺口的解法評估

版本：v0.15.0 · 評估日：2026-09-21 · 對應《擴充清單與缺口盤點》§1

一句話結論： 五項都不是「技術做不到」，差別在成本、風險與有沒有更聰明的替代做法。三項純本機就能補完（真實定位、評價附照片、多選取代框選）、一項有零成本替代（路線改用估算＋導航深連結）、一項建議不要硬做而是改流程並修正規格措辭（伺服器抓取社群貼文）。

1. FR-3.1 區域雷達沒有真實定位

方案
成本 / 風險 / 可取性
A. 瀏覽器 Geolocation API ＋ 半徑過濾 建議採用
0 元、標準 API。需使用者授權，且**必須 HTTPS**（或 localhost）。可完全在本機做完並驗證。
B. 手動選擇區域
0 元，作為 A 的降級路徑：不給定位時，讓使用者自己選「中山站／大稻埕」。
C. IP 定位
不建議：都市區誤差常達數公里，「附近 1 公里」會變成笑話。

配套措施（比功能本身更重要）

  • 只在使用者按「雷達」時才請求定位，不背景追蹤；文案寫明「僅在你開啟時取得現在位置，不會記錄移動軌跡」。
  • 授權被拒 → 自動退回方案 B（手動選區域），不要留下「按了沒反應」的死路。
  • 座標只用於當次篩選，**不寫入資料庫**。

    • 本機可驗證 ✅（localhost 視為安全來源，可直接測授權與半徑過濾）

    2. FR-4.2 移動時間只是直線估算

    方案
    成本 / 風險 / 可取性
    A. Google Directions API
    最準，但需金鑰與計費（每次查詢都算錢），且行程一改就要重算。
    B. OSRM／OpenRouteService 公開服務
    免費，但公開 demo 有流量限制與服務條款風險，不適合正式環境。
    C. 估算 ＋ 一鍵外部導航 建議採用
    0 元：直線距離乘上繞路係數（約 1.3–1.4），再依交通方式調整時速；行程卡下方加「用 Google Maps 開啟這條路線」深連結。深連結不需要任何金鑰，使用者按下去就是真實導航與真實時間。

    配套措施

  • 時間一律標示「**估算**」，不寫成「預計 12 分鐘抵達」——避免使用者以為是導航。
  • 深連結一次帶完整路線：https://www.google.com/maps/dir/?api=1&origin=…&destination=…&waypoints=…&travelmode=driving，使用者按了直接進 Google Maps 導航。
  • 交通方式（步行／單車／開車／大眾運輸）先用下拉選單影響時速，之後若要精準再接 Directions API。

    • 本機可驗證 ✅ —— 已於 v0.15.0 實作並驗證（13 項測試全過）：

  • 加入繞路係數（步行 1.35／單車 1.30／開車 1.35／大眾運輸 1.45），不再低估距離。
  • 行程頁可選交通方式，時間估算隨之變化（實測同一組點：步行明顯多於開車）。
  • 行程卡新增「用 Google Maps 開啟這條路線」，深連結帶 origin／destination／waypoints／travelmode，**不需任何金鑰**。
  • 畫面明確標示「時間為估算」，真實路線交給 Google Maps。

    • 3. FR-1.3 伺服器沒有真的抓取社群貼文內容

    方案
    成本 / 風險 / 可取性
    A. 官方 API（Meta oEmbed／Graph API）
    需通過 app review，且**公開貼文的 caption 常拿不到**（平台刻意限制）。對 IG 尤其不友善。
    B. 第三方抓取服務（Apify 等）
    付費、且屬灰色地帶，可能違反平台條款；一旦平台改版就整條斷掉。
    C. 不硬爬，改優化流程 ＋ 修正規格措辭 建議採用
    關鍵洞察：Android 的分享面板本來就會把貼文文字一起帶進來（我們的 PWA share_target 已接收 text 參數），所以對 Android 使用者來說「附上文字」根本不是額外步驟，是分享的預設行為。真正缺的是文案引導。

    配套措施

  • 分享進來的文案改成：「已收到你的分享——若文字太少，解析會不準，可再貼上貼文說明」。
  • iOS／桌機使用者改為引導「複製貼文文字 → 貼上」，並在按鈕旁說明為什麼（取得品質）。
  • 把規格書的 FR-1.3 從「系統自動抓取」改寫為「取得來源歸屬與使用者提供的文字」——誠實對齊，才不會永遠躺在「做不到」清單裡。

    • 3.1 你提的方向：分享後直接接 Google Maps 店家資訊

    方向對，但要先分清兩件常被混在一起的事：

    問題
    Google Places 能不能解決
    「已知店名，要補齊地址／營業時間／座標／place_id」
    可以，而且已經做好了。server/places.js 只要設 MAPSYNC_PLACES_KEY 就會自動補進圖釘（含 place_id 與精準座標）。
    「不知道這則貼文在講哪家店」
    不能。Places 是按名稱／關鍵字查地點，不是「讀懂一則 IG 貼文」。沒有店名就沒有查詢字串，接再多 API 也查不到。

    務實做法是三段式，前兩段已實作：

    1
    有文字 → 提煉店名 → Places 補齊
    設定 Places 金鑰即啟用，解析後自動補地址、營業時間、place_id 與精準座標。
    2
    沒文字 → 「用 Google Maps 找這家店」深連結
    v0.15.0 已加入：解析失敗或需確認時，一键開 Google Maps 搜尋（帶入貼文文字或來源）。使用者找到店後把店名貼回，再走第 1 段補齊。零爬取、零成本。
    3
    顯示層 → 圖釘卡「在 Google Maps 開啟」
    v0.15.0 已加入：有 place_id 就用官方 deep link（query_place_id），沒有就用店名＋地區。
    一條不能踩的線（法務，不是技術）

    Google Maps Platform 的 Places 資料有儲存與顯示限制：受限制的欄位不能在脫離 Google 地圖的情況下無限期保存在自己的資料庫。實務上常見的合規做法是——

  • 長期只保存 place_id，其餘欄位需要時重新查詢（遵守快取期限）。
  • 顯示來源標示，並提供「在 Google Maps 開啟」連結。
  • 若要「大量、自動、永久」把 Google 店家資料變成自己的圖資，那不是工程問題而是**商業授權問題**：要洽 Google Maps Platform 的正式條款，或改用 OpenStreetMap／Foursquare／HERE 等其他圖資。

    • 我們目前的設計（只長期存 place_id、座標由內建辭典推估、顯示時附 Google 連結）已經落在安全區；但不要為了「資料看起來很滿」而把 Places 回傳的欄位全量落地。

    4. FR-2.3 評價不能附照片

    方案說明
    <b>把照片改成可掛在評價上</b> <span class="rich-badge ok">建議採用</span>既有 <code>pin_photos</code> 表加一個可為空的 <code>note_id</code>（遷移 v4）；上傳端點收 <code>noteId</code>；評價卡顯示縮圖。成本低、無外部依賴。

    配套措施：同一張照片不重複存兩份（圖釘照片 <code>note_id</code> 為空）；上傳時一併做浮水印？不需要——但要順便在此時補上 EXIF 去除（避免住宿位置外洩）。

    本機可驗證 ✅

    5. FR-4.1 只能勾選，不能框選

    方案說明
    A. 地圖拖曳框選行動裝置上「拖曳選取」與「平移地圖」衝突，需長按觸發，學習成本高、也難測試。
    <b>B. 清單多選 ＋ 依區域／標籤一鍵全選</b> <span class="rich-badge ok">建議先做</span>例如「中山站全選」「宵夜標籤全選」，再手動微調。<b>滿足 80% 的真實需求，成本只有 A 的三分之一</b>。

    配套措施：行程頁顯示「已選 3 個，共 12 個」，並支援「只選還沒去過的」這類條件式全選——這比框選更符合實際規劃行為。

    本機可驗證 ✅

    跨五項的通用配套：誠實標示

  • 估算的移動時間標「估算」；真實導航交給外部連結。
  • 定位標「僅在你開啟雷達時取得、不記錄軌跡」。
  • 解析結果標「來源：你提供的文字」與來源帳號。
  • 規格書與實作對齊：把做不到的措辭改寫（FR-1.3），或明列為「下一階段」。否則「說了做不到」的清單會一直重複出現。

    • 建議執行順序

    1
    真實定位（FR-3.1）
    半天內可完成並驗證；直接把主打場景做成立，投報率最高。
    2
    評價附照片＋EXIF 去除（FR-2.3）
    半天；同時補掉一個隱私風險。
    3
    路線估算＋一鍵導航深連結（FR-4.2）
    半天；零成本換到「可用的真實導航」。
    4
    條件式全選取代框選（FR-4.1）
    半天；比框選更貼近實際規劃行為。
    5
    分享文案與規格措辭修正（FR-1.3）
    極短，但是唯一誠實的解法——不要為了清單好看去做不合規的抓取。