← 網誌

Culture Hop Taiwan：打造文化探索的基礎設施

2025 年 12 月 27 日 · 閱讀時間 4 分鐘

我把零散的政府開放資料重新整理，做成一個雙語、地圖優先的文化活動探索平台。這個過程主要圍繞三個問題：資料來源分散、語言不一致，以及行動端使用體驗過於笨重。

Culture Hop Taiwan 在筆電與手機上的畫面：活動清單，旁邊是一張台北地圖，上面散布著聚合的活動圖釘。
Culture Hop Taiwan：一個雙語、地圖優先的城市文化探索平台。

台灣的文化活動其實非常密集，但資訊分布在不同平台之間。對外國使用者來說，沒有一個清楚的入口；對本地人來說，也需要花不少時間在不同網站之間切換與比對。

這個專案試圖處理的，是如何把這些分散的資料重新整理成一個可以直接探索的入口。

在設計上，我用兩個維度去理解使用者行為：語言理解能力，以及行程的即時性或計畫性。最後整理成四種主要的使用情境。

系統本身則建立在一層探索層之上，把政府開放資料轉換成雙語內容，並以地圖作為主要的資訊載體。

目前已經完成一個可以自動更新的版本，同時服務旅客與在地使用者。

線上體驗：culturehoptaiwan.com/en →

語言造成的資訊不平等

台灣有豐富的文化活動，但資訊很破碎，一場展覽可能出現在文化局網站，一個市集在 Instagram，一個音樂活動則在售票平台。政府有開放資料 API，但大多停留在原始格式，沒有被整理成適合一般人閱讀的樣子。

長時間累積下來的結果是：

  • 外國人很難進入文化活動的資訊系統
  • 本地人需要在多個平台之間來回比對
  • 許多活動其實並沒有被有效看見

Culture Hop Taiwan 想處理的，就是整合這些資訊。我選擇做的不是再增加一個資訊來源，而是把這些來源收攏到同一個入口裡，讓使用者不需要先理解系統本身，就可以直接開始探索。

涵蓋度對策展度的矩陣：售票平台與各別政府場館網站策展度低，零散的 event.culture.tw 與 MOC 開放 API 的 UX 低，而「優化 UX 的策展層」就是要補的缺口。
現有的資訊來源，不是涵蓋廣但介面生硬，就是有策展概念但格式零散。要補的就是中間這層整理好的探索體驗。

使用者群像的整理方式

這個計畫沒有使用 Persona 的方式，而是用使用者群像來整理需求，以避免過度的詮釋。

我利用兩個維度作為分析：語言是否能順利理解內容，以及使用者是臨時搜尋還是有計畫地安排活動。

當這兩個維度交叉之後，形成四種不同的使用情境，用來描述真實的行為差異。

四個人物，各對應一個象限：即時的在地人、有策略的常住者、臨時起意的探索者、有意圖的旅人，各自有觀察到的行為與目標。
沿著語言能力與規劃風格兩個維度，分出四種典型的使用情境。

四種使用情境

  1. 臨時起意的非中文使用者：在街上看到活動資訊或社群推薦，就直接決定前往。整個決策過程非常短，重點在於即時性與可達性。
  2. 有計畫的非中文旅人：通常會在出發前做一些研究，希望找到更貼近在地文化的活動。他們關注的不只是活動本身，也包含背景與文化脈絡。
  3. 臨時起意的在地使用者：多半透過 Instagram 或朋友分享，在空檔時間臨時決定要去哪裡。行為上偏向即時瀏覽與快速決策。
  4. 有計畫的在地使用者：會長期追蹤藝文展覽或文化活動，並整理自己的行程。他們更在意的是資訊是否集中，而不是資訊是否存在。

這四種使用者的背景差異很大，但在實際體驗上遇到的問題很接近：資訊過於分散，而且缺乏一個可以直接進入的入口。

使用旅程中出現的斷裂

當我把整個使用流程拆開之後，可以很明顯看到幾個重複出現的問題。

  • 草根活動缺乏英文或雙語資訊
  • 不同平台之間沒有資料串接
  • 使用者需要自行拼湊時間、地點與內容
草根活動旅程：因為缺乏英文內容與活動細節，從探索、評估到導覽，易用性一路停在「斷裂」。
獨立草根活動：因為英文資訊幾乎空白，外國使用者的整段探索旅程都斷掉。
售票平台旅程：入口斷裂、散落在 10 到 20 個平台，不過詳細的描述在後段的評估與導覽有幫上忙。
主流售票平台：後段的購票與場館服務還算完整，但前期要跨平台找入口的體驗很零散。

實際的使用流程往往會變成：

搜尋 → 開啟多個網站 → 比對資訊 → 放棄或延後決定

產品設計的三個核心方向

在整理完這些問題之後，設計逐漸收斂成三個方向。

  1. 一個統一的入口：使用者不需要再判斷要去哪個平台找活動，而是從單一入口開始探索。
  2. 可以被理解的雙語內容：除了翻譯之外，更重要的是補上背景資訊，讓外國使用者可以理解活動在發生什麼。
  3. 以地圖作為主要介面：文化活動本質上與空間高度相關，因此地圖不只是輔助工具，而是主要的探索方式。

系統構成

一張表，把每個痛點對應到設計回應與所解決的工作：零散平台對應單一地圖入口、只有中文的文字對應 AI 改寫的雙語描述、缺座標對應 Supercluster 地圖加 AI 地理編碼、行動分數 27/100 對應 ISR、延遲載入與骨架畫面提升到 65。
每個痛點對應到的設計回應，以及它解決的核心任務。

資料處理流程

使用 Python 定期抓取政府與第三方平台資料，整理後統一存入 Supabase。

再透過本地 AI（Ollama + Gemma）處理內容以降低 token 花費成本，包括：

  • 翻譯成英文
  • 清理不必要的描述
  • 重寫成更適合閱讀的格式

前端呈現

前端使用 Next.js 建立。

地圖部分透過 React Leaflet 與 Supercluster 處理大量活動資料，讓使用者在行動裝置上仍然可以流暢操作。

自動更新機制

整個系統設計成一個持續循環：

資料抓取 → AI 處理 → 寫入資料庫 → 前端呈現 → 使用行為回饋 → 再次更新

四層循環：工廠(Ollama + Python)餵養倉庫(Supabase)，倉庫餵養店面(Next.js + React Leaflet)，店面餵養監測器(GA4 + Clarity)，監測器再回到工廠。
四層自動化循環：工廠、倉庫、店面到監測器，每一層餵養下一層，最後把使用回饋收回來。

開發過程中的幾個問題

行動端效能

初期版本在手機上幾乎無法正常使用，原因是一次載入過多資料。

後來透過幾個方式改善：

  • 分層載入資料
  • 延遲載入非核心內容
  • 加入骨架畫面
  • 使用 ISR 快取

才讓體驗變得穩定。

開放資料品質不穩定

實際使用政府資料時會遇到很多不一致的狀況，例如：

  • 缺少座標資訊
  • 地址格式混亂
  • 欄位定義不一致

因此另外建立了一套：

  • 場館對照資料
  • 地理編碼流程
  • 資料清洗規則

搜尋系統的複雜度

搜尋功能需要同時處理：

  • 中文標題
  • 英文改寫內容
  • 標籤系統
  • 地圖上的即時更新

這讓它的複雜度遠高於一般關鍵字搜尋。

前後對照：舊旅程要在 20 多個只有中文的平台間搜尋，最後放棄；Culture Hop 旅程則是打開一張地圖、讀雙語描述、規劃路線，然後參加活動。
改版前後對照：從多平台切換、語言障礙的混亂，收成一條連貫的流程。

從分散到可以使用

如果只看結果，變化其實很直接。

過去的流程是：

20 多個平台之間切換 → 找不到 → 放棄

現在則是：

打開地圖 → 看到活動 → 做出決定

小結

目前這個系統仍然維持輕量狀態，但已經可以穩定運行。圖片取得目前還是最大的問題，但已經可以準確地把各平台的藝文活動標在地圖上，且能夠做到基本的雙語呈現。

下一步

接下來可能會往幾個方向調整：

  • 更好的推薦邏輯
  • 更完整的雙語內容品質
  • 更細緻的分類與篩選
線上專案體驗：culturehoptaiwan.com/en →