產品企劃建議書 · Product Proposal

衣途 YìTú — Pack what the sky tells you.

一款以「即時天氣 × AI 穿搭決策」為核心的旅遊 APP。輸入目的地與日期,系統自動抓取旅程當下的天氣預報,由 AI 直接告訴你每天穿什麼、帶什麼,並串接行程規劃與在地專家建議。

定位天氣驅動的旅遊穿搭決策助手 核心引擎實時天氣 API + AI 建議層 變現主軸訂閱 + 穿搭聯盟導購
01 · 市場洞察

旅行前最瑣碎、最焦慮的一件事:
到底要帶什麼衣服?

查天氣、換算溫度、想像當地早晚溫差、再對照行李空間與行程性質——這個決策過程分散在好幾個 App 之間,沒有任何工具替使用者「整合判斷並給出結論」。

痛點 01

資訊分散

天氣 App 報數字、穿搭靈感在 IG、行程在筆記本,三者從不對話,使用者得自己腦補拼湊。

痛點 02

預報≠決策

「明天 18°C 有雨」對多數人不等於「該帶什麼」。中間缺的是把資料翻譯成行動的判斷層。

痛點 03

場合錯配

同樣 22°C,海島跳島、都市逛街、高山健行該穿的完全不同——天氣只是變數之一。

02 · 產品定位

不只是天氣,是替你「做完決定」

市面上的旅遊 App 多在解決「去哪裡、住哪裡、怎麼排」。衣途切入一個尚未被佔據的縫隙:旅程期間的「身上裝備決策」。

One-line Positioning

「告訴我你哪天去哪裡,我告訴你每天穿什麼、行李怎麼打包。」

使用者要的不是更多數據,而是一個能整合天氣、行程性質、個人風格與行李限制,直接輸出穿搭與打包清單的決策夥伴。這正是 AI 最擅長、傳統工具做不到的事。

03 · 核心功能

四個模組,一條主線

所有功能都圍繞「天氣 → 穿搭決策」這條主軸展開,由淺到深、由免費到付費。

核心引擎 · 必裝亮點

① 天氣驅動 AI 穿搭

輸入目的地 + 旅遊日期區間,系統自動串接實時天氣 API,抓出該地該時段的逐日/逐時預報(溫度、體感、降雨、風、紫外線),由 AI 生成每日穿搭建議整趟行李打包清單,並標註「早晚溫差需洋蔥式」「需備雨具」等提醒。

差異化加值

② 風格化建議

建檔個人風格(休閒/商務/韓系/戶外機能)、性別、體質怕冷怕熱、行李大小。AI 把這些變數一併納入,讓建議從「正確」進化到「像你會穿的」。

黏著度

③ 行程整合

串接地圖/景點 API,依行程性質(跳島、登山、市區、宴會)調整穿搭邏輯——同樣溫度、不同活動,給不同答案。可一鍵生成或匯入每日行程。

內容信任感

④ 在地專家建議

合作在地嚮導/旅遊 KOL 提供目的地的穿著文化、季節限定提醒(如寺廟需遮肩、雪地防滑)。建立內容權威,也是 B2B 與 KOL 分潤的入口。

04 · 使用者旅程

從輸入到打包,五步搞定

1

輸入

目的地 + 日期區間

2

抓取

實時天氣預報串接

3

判斷

AI 融合天氣×風格×行程

4

輸出

每日穿搭 + 打包清單

5

行動

一鍵導購缺的單品

第 5 步「導購」是把使用情境直接轉成營收的關鍵節點——當 AI 建議「你需要一件輕量防風外套」,旁邊就是可一鍵購買的合作商品。這一步同時服務了使用者體驗與被動收入。

05 · 技術架構

四層堆疊,AI 是大腦

架構刻意精簡、可外包執行,符合「指揮與委派」的開發節奏。以下為建議選型方向,正式開發前需就 API 配額與授權再行驗證。

層級建議方案說明
① 天氣資料層 台灣:中央氣象署 CWA 開放資料
海外:Open-Meteo / OpenWeatherMap
取逐日/逐時預報、體感溫度、降雨機率、紫外線。Open-Meteo 免費且含全球逐時預報,適合 MVP。
② AI 決策層 Claude API(Haiku 路由 / Sonnet 主力 / Opus 精修) 把天氣 + 風格 + 行程組成結構化 prompt,輸出穿搭與打包清單。可沿用你既有的模型分層與 Prompt Caching 策略壓低成本。
③ 商品 / 內容層 聯盟電商 API(Shopee / 品牌聯盟)+ 專家內容 CMS 將 AI 建議的單品對應到可購買商品,回填圖片與導購連結;專家建議以 CMS 維護。
④ 應用 / 後端層 前端:React Native(雙平台)
後端:Supabase / Firebase + 雲函式
帳號、訂閱、行程儲存、推播。輕後端即可支撐 MVP,營運自動化程度高。
06 · 商業模式

四條金流,兩台被動引擎

設計上刻意讓主要金流不依賴持續人力投入——使用者越多,收入越自動累積,這也是這個產品真正的長期價值。

① 訂閱 Freemium

高度自動

免費版:單一行程、基本天氣穿搭。Premium(月/年費):多行程、無限 AI 建議、專家內容、離線打包清單。系統自動續訂,邊際成本趨近於零。

② 穿搭聯盟導購

高度自動

AI 建議的單品直接對應合作電商商品,使用者一鍵購買、平台抽佣。這是核心被動收入引擎——你只需建立一次商品對應規則,之後 24 小時運轉。

③ B2B 白標授權

半自動

授權給旅行社、航空公司、訂房平台嵌入「天氣穿搭建議」功能,收年費或拆帳。單筆金額大,需業務開發。

④ 品牌合作 / 廣告

半自動

戶外機能、旅遊用品、服飾品牌的情境置入與季節企劃。流量到一定規模後具高議價力。

建議順序:以 ①訂閱 建立穩定基本盤、②聯盟導購 作為規模化被動引擎優先衝刺;待用戶基數成形後,再以 ③④ 放大單位營收。

07 · 開發路線

三階段,先驗證再放大

Phase 1 · 約 0–3 個月|MVP 驗證

把核心主線做到「好用到想分享」

  • 天氣 → AI 穿搭 + 打包清單(核心引擎)
  • 覆蓋台灣 + 少數熱門海外城市(日韓、東南亞)
  • 基本風格建檔、Freemium 訂閱上線
  • 目標:驗證使用者願意為「決策結果」付費
Phase 2 · 約 3–6 個月|變現與黏著

讓產品開始自己賺錢

  • 行程整合、在地專家建議模組上線
  • 穿搭聯盟導購串接(被動收入引擎啟動)
  • 擴充全球目的地覆蓋
Phase 3 · 約 6–12 個月|規模化

從工具走向平台

  • 穿搭分享社群、用戶內容(UGC)
  • B2B 白標授權對外洽談
  • AI 穿搭視覺生成、語音助手等進階體驗

執行可信度 · 為什麼能快又穩地做出來

路線圖只回答「做什麼」;真正決定成敗的是「怎麼確保做得出來、且上線後穩」。以下三個刻意的方法選擇,直接影響資本效率、上線穩定度與未來的擴張成本。

支柱 01

極簡 MVP 優先

資源集中在單一核心主線(天氣 → 穿搭),先驗證付費意願再逐步擴充,避免預算耗在次要功能。時程與現金流可控,把前期風險壓到最低。

支柱 02

AI 輔助防禦性開發

開發初期即以結構化 AI 流程寫入完整錯誤處理(斷網、驗證失敗、資料異常),把上線後的閃退與客訴壓到最低——穩定度直接牽動訂閱留存與口碑。

支柱 03

Serverless 託管架構

採 Supabase / Firebase 成熟託管後端,免去前期伺服器建置與維運人力;用戶量成長時彈性擴展,營收規模化不必等比增加人力成本。

這三者共同構成一個關鍵特性:用戶越多、單位成本越低,而不是越做越重。這正是產品能長期趨近「自動營運」的技術基礎——與訂閱、聯盟導購兩台被動引擎相互支撐。

08 · 競品定位

沒有人同時做這三件事

類型代表能給結論的穿搭結合行程導購變現
天氣 App各家氣象✗ 只報數字
行程規劃 App旅遊行程工具部分
穿搭 / 衣櫥 App個人穿搭工具△ 日常為主部分
衣途本產品✓ AI 直接給結論✓ 核心

衣途的護城河不在單一功能,而在「旅遊情境下、把天氣翻譯成穿搭決策並直接導購」這條完整鏈路的整合。後進者要複製,得同時補齊天氣、AI、商品三端。

09 · 風險與對策

先想清楚會卡在哪

天氣準確度

長天期預報誤差大。對策:7 天內給精準建議,更遠日期以「歷史氣候 + 區間」呈現並標註信心度。

建議品質

AI 穿搭若不接地氣會失去信任。對策:以「做三次成 Skill」精煉 prompt,建立穿搭規則庫與人工抽查。

冷啟動

導購需流量、流量需內容。對策:以專家內容與分享機制換取早期自然流量,再啟動變現。

下一步 · Next Steps

建議從一個能跑的 MVP 開始

不必一次做完所有功能。先把「輸入地點日期 → AI 給穿搭與打包清單」這條主線做成可用原型,丟給真實使用者驗證付費意願,再循序加上行程、導購與 B2B。

我可以幫你接著做:MVP 規格書 / Prompt 設計 / 原型