搭中和新蘆線，車子到底往蘆洲還是迴龍？2026 年 8 月，我把這個問題做成一個非官方迷因網站：橘線開票所。

網站的口號是「您的終點，由民主決定」。使用者選擇剛上車的車站，接著看一段開票動畫，最後宣布蘆洲派或迴龍派當選。當然，這不會改變列車目的地，也沒有讓旅客真正投票的功能；乘車仍要看現場資訊。

畫面背後，其實是班次推定

原型支援南勢角到大橋頭的共同區間，方向限往蘆洲／迴龍。選站後，後端依台北時間，從臺北捷運官方站別時刻表找出接近當下的預定班次。

程式對尚未離站的候選班次加一點權重上的懲罰，讓選擇略偏向「剛剛已經離站」的車。時間差太大，或資料無法取得時，則退回示範模式。凌晨的班表選擇也需要處理前一個服務日。

這些都是用預定班表作推定，還沒有接上即時列車定位。畫面上的可信度則來自時間差的啟發式分數，不能當成經過實車驗證的正確機率。班次推定程式把這些條件保留下來，可以直接對照。

票數來自哪裡？

只有目的地還不像開票，所以原型也呈現推估票數。但公開資料沒有告訴我「這班車上現在有幾個人」。能用的是歷史每日分時各站 OD 流量，再配合時刻表做估算。

目前的概念是：

單班推估人數 ≈ 該站該時段的歷史平均斷面流量 ÷ 該時段官方班次數

模型只計入進出站都能確定屬於橘線、而且會通過所選斷面的部分 OD 配對，因此沒有完整涵蓋跨線轉乘旅客。程式把它命名為 lower-bound 模型；但歷史流量再除以班次的平均估算，不能保證每一班的推估值都低於實際人數。

開票動畫最後把推估票數放到推定目的地那一派，另一派是零票。這是呈現方式，不能解讀成旅客的選擇，更不能當成實際載客量或即時擁擠度。人流估算程式與專案說明列出了方法及限制。

把資料處理和線上請求分開

原型以 Astro 配合 Cloudflare Workers 提供頁面與 API。較大的 OD 資料先由更新腳本整理成 profile，線上請求讀取整理好的資料，避免每次開票都重新下載原始檔。

倉庫設定了每月檢查資料更新的 GitHub Actions 工作。這代表有排程，不代表每次排程都一定成功；使用時仍要看頁面標示的樣本月份。國定假日服務日曆、即時到站資料校正和實車驗證，也仍是需要繼續處理的部分。

2026 年 9 月整理本文時，網站可以完成選站與開票流程，結果頁也顯示了資料來源、推估人數與樣本月份。這確認了原型可以操作，但沒有驗證它在實際列車上的判定準確率。

AI 幫忙製作，資料的意思仍要自己負責

原始貼文提到，我用 ChatGPT 協助把這個想法做出來。沒有完整的開發過程紀錄，就不把每個元件或每次修正細分成 AI 和人的功勞。

對我而言，這個小作品值得留下來的地方，是把開放資料變成另一種可以被體驗的介面。同時，也必須讓人分得清楚：哪些來自官方班表，哪些是歷史資料推估，哪些只是動畫和笑話。

程式以 MIT 授權公開在 GitHub。想繼續改進的人，可以從資料校正、服務日處理或更清楚的推估說明開始。