記 2025 台北城市通黑客松：三顧茅廬終於獲獎
這次是我第三次參加台北程式通黑客松比賽，前兩次分別是微服務與儀表板，而這次又回到了微服務開發。參加了那麼多次，我們團隊成員們也開始漸漸的明白這個比賽需要怎麼樣的作品，終於在這次的比賽中，拿到了佳作！我想帶著這份喜悅，將我們的參賽經驗、本次的選題與開發經驗分享給大家。
2025-11-13黑客松比賽簡介
城市通微服務大黑客松 是 台北程式設計節 的其中一項競賽，由台北市資訊局主辦，希望能透過舉辦黑客松比賽，蒐集開發者們的的點子，在比賽中實作出能改善現有服務的功能。而這次的大主題 城市通微服務 則是需要基於 台北通 App，在上面開發一個全新的微服務，並且盡可能使用政府其他單位的開放資料與 API。
台北通是由 Flutter 實作的，我在 LINE 實習時，參與的專案剛好也是使用 Flutter，因此對我來說算是從從容容，游刃有餘。
台北程式設計節提供的獎金相當優渥，第一名高達 30 萬元，不過有個但書是要協助將得獎作品上線，因此值不值得就見仁見智了。當然身為黑客松比賽，除了獎金之外，豐盛的菜餚也是不可少，主辦單位在這個部分上給的就是豪不吝嗇了。三餐正餐外，下午茶、飲料、宵夜、零食、冰品應有盡有，甚至還有參賽者會帶空的行李箱來裝零食回去。
至於這個比賽我認為最特別的地方在於，不能使用任何的簡報，輔助講解也不行，也就是所有的報告，都必須以實際 demo 的形式展示給評審看。有了這樣的限制，讓黑客松比賽不再是亂七八糟的簡報提案比賽。所有一起競爭的點子，都是合理且可實現的。
賽前準與選題
前面有提到大主題是城市通微服務，那微服務具體來說要往哪個方向做呢？這次有三個題目：安全之都、運動之都以及未來之都。在賽前有公布這三個方向，但要到比賽開始時，每一組才會隨機被分配到其中一項。
因為與之前的模式不太一樣，在賽前說明會接收到這樣的資訊時，包含我們在內，很多組別都覺得有些不公平。畢竟每個主題難度不一，隨機分配給參賽隊伍，但或許有組別是對於某個題目特別有想法，那豈不是限制大家的發揮了。所幸後來比賽時，有宣布可以與其他隊伍交換主題，我猜想主辦單位應該是希望實作每個方向的隊伍數要平均，才會有這樣的規定吧。
但回到比賽前幾天，我們其實也不知道到底會抽到哪個題目，所以有花一些時間討論每個題目各自可以做些什麼應用。有了前面的參賽經驗，我們知道，這個比賽想要的作品，並不一定要多大或技術多困難，他們更著重於題材的創新性與實用性，以及最後 demo 的成品是不是完整。
我們一開始討論是著重在運動與安全，現在回顧之前討論的內容，吸引力 確實是完全不及我們最後實作的題目。在運動方面，我們想到可以做自行車路線規劃：因為 Google Map 的自行車路線經常會經過大馬路或或大橋，相當危險，所以我們會先整理合適的自行車路線，使用者輸入出發與目的地，系統會推薦自行車的最佳路線。安全方面，我們將焦點放在行車安全：透過 TDX 取得即時路況資訊，包含車禍、施工，並在第一時間推送通知給使用者，讓使用者在出門前可以盡量避開危險路段，同時使用者也能訂閱特定想關注的路段。
討論到未來之都時，在一片沉寂後，突然有人提出 線上求籤拜拜 的點子。我們一致認為這題材很有趣，台北通 App 上也沒見過相關的服務，而且也不難實作，也因此未來之都成為我們最想抽到的題目。
話雖如此，我們當時畢竟不知道可以換題目，所以多少還是有分配大家可以先針對每個主題做一些前期的研究。我這邊先去看了下將台北通的架構，並嘗試在裡面新增一個自己的 route，同時也有研究一下 TDX API 的使用方式。其他人有查找 Flutter 加速度感測的方法、蒐集詩籤的資料。
不得不說，現在 AI 實在是太強了，研究程式架構、看別人的 code 這種苦差事，AI 就能很好的勝任。
體驗真黑客松式的開發
如同前面提到的，當天主辦單位有允許不同的參賽隊伍之間交換題目。我們馬上就和隔壁組達成協議，將手上的運動與他們的未來交換。後來我們也根據賽前的討論和準備，快速的將前期的建置處理好了。
雖然說有做準備，但其實也不多，只是希望在現場不要太匆忙，自亂陣腳。雖然可以準備更多，但來體驗極限開發的氛圍也是蠻有趣的。
主辦單位有設置 Coding 診療室，提供給參賽隊伍技術與業務方面的諮詢。我們已經決定了作品的方向，但對於題目是不是真的能切合未來之都這個大主題，以及還有哪些部分可以加強，仍有一些不確定，因此我們也是在比賽一開始時，就前去 Coding 診療室報到。我覺得他們提供的建議確實都很有幫助，像是其中一點是，他們有建議我們可以在結束後，利用觀光局的資料，推薦台北市廟宇與周邊的觀光景點。我們後來也有將廟宇推薦的功能整合進最後的作品中。
回到開發上，我簡單得分配了大家初始的任務，讓團隊每個人都能參與開發：梳理完整的抽籤與拜拜的流程、整理詩籤的資料到 App 中、蒐集一些動畫素材等。接著再根據每個人開發的進度，動態分配頁面去實作 UI。中間當然也沒忘記到處晃晃，去覓食、聊天、偷看別人在做什麼。以黑客松來說，整個開發的過程還是挺愜意的。
到宵夜時間，我們的服務也完成得差不多了，但總覺得 拜拜 的環節少了點什麼。這時又是突然有個王世堅委員的梗劃過腦中，剛好活動開幕時，資訊局局長也是一直用他的梗圖，於是我們決定，在拜拜的流程中，加入擺放供品的互動，並將王世堅委員的圖放在眾多水果的最後，當作個小彩蛋。畢竟參加黑客松就是來玩的，寫出能讓自己開心的東西也是很重要的。
或許是因為我們選題不大、全都是 client side 的功能，或許也是我的夥伴們都超強，我後來是簡單的看過每一個頁面，並統一設計和排版，最後把彩蛋完整實作完成，大概是晚上 3、4 點，還有時間睡覺呢！
作品展示
我們將服務名稱取作 城心誠靈，並自己用向量圖工具 Inkscape 繪製了一組筊杯作為入口 logo。之所以不直接用 AI 產圖的理由很簡單，只是為了讓 logo 能與其他服務的風格對上，不要太突兀。
身為台灣人是不能沒有諧音的啊！
接下來展示幾張進入服務後的螢幕錄影：
| 頁面名稱與說明 | 螢幕錄影 |
|---|---|
| 歡迎頁面：這邊我們有做一點小巧思，讓背景有一個 流光 效果，給人一種香火鼎盛的感覺。 |  |
| 搖一搖抽籤：透過加速度感應的方式，以搖動手機模擬實際抽籤的動作，觸發抽籤動畫。 |  |
| 搖一搖擲筊（聖筊）：這裡也是可以透過搖動觸發擲筊，特別的是，我們有設定不同的加速度軸向，必須是用擲筊動作才能觸發，而不是隨意的晃動就行了。 |  |
| 搖一搖擲筊（笑筊）：如果擲出的不是聖筊，就得回頭重抽一支籤。 |  |
| 解籤：我們使用廟宇常見的 六十甲子籤 作為籤詩集，並透過 AI 進行翻譯與解籤，使用者會隨機取得其中一支籤。 |  |
| 推薦宮廟：在抽籤的最後會推薦一間台北市的廟宇，同時提供周遭的觀光景點資訊，這些資料來源都是台北市觀光局的即時 API。 |  |
| 誠心奉香：在拜拜的環節，使用者選擇廟宇後，同樣可以透過拜拜的動作觸發動畫。 |  |
| 獻貢：最後可以擺放水果到供桌上，我們可以從從容容地放置供品， |
 |
遵循台北通原專案的 GPL 3.0 授權，我們的實作有開源在 GitHub - BP-XZs/TownPass 上。有興趣的讀者也可以去參觀看看喔！另外，因為獲得佳作，我們作品最終也可能經過簡單的調整後，正式上架到台北通 App 上。
個人心得與小小的抱怨
總體來說，政府願意將程式碼開源，並召集大家一起來開發、貢獻好點子，我很贊同這樣的做法。而且整個 App 是用 Flutter 這個相對比較新的框架，看來政府也不是總是落後跟不上時代的；同時在串接政府的 API 時，也感受到政府有在積極的想要將資料數位化，提供給更多的服務使用，這也有點顛覆我對政府的既定印象。中央或其他縣市我不敢確定，但至少台北市政府值得嘉許。
不過當然活動還是有一些不盡人意的地方，去年沒得獎，說什麼可能都感覺像是在遮掩自己的能力不足。但今年得了佳作，總可以有自信的指教了吧！
餐食分配有一些狀況、音樂的氛圍不適合，這些現場都有反映給主辦單位知道，後來也有所改善，而且這些可能都比較偏向廠商的問題，在這邊簡單帶過就好。但對於決選的評審，我認為有些是不太專業的。只有趙局長的提問，我能真正的感受到問題是針對服務怎麼改善市民生活，或是隊伍真的沒有說明清楚的地方。有些評審卻總是問一些不是問題的問題，甚至可能沒搞清楚這是一個微服務的黑客松比賽。
像是我們做的線上求籤拜拜服務，竟然有評審提問，應該要用 VR 才能讓長輩有在祭祀的感覺。這是在台北通 App 上的微服務，使用受眾可預期的本來就會是青年更多，再用到 VR 那是完全離題了。再舉一個例子，有一組做施工路段警報的，他們出發點是希望用路人能提前留意或是繞道，結果評審們一個在問搭大眾運輸的怎麼辦，一個在談應該要加上工地檢舉的功能，根本都不是針對參賽作品提問。
我希望未來評審們都要事先充分了解比賽的目標、核心宗旨，不要只是為了刁難而提問。作為評審，提問時間不是應該是要釐清對作品的疑問，讓評分能夠更準確嗎？就算要提建議，也不應該充斥著那些天馬行空、不切實際的想法，畢竟這是不是一場簡報黑客松。
感謝團隊夥伴們
在文章的最後，要感謝與我一同奮戰的團隊成員（以下為他們的 GitHub 連結）：
這份榮耀是我們一起拿下的。沒意外的話，我們會繼續參加 2026 年的台北大黑客松吃好吃滿，期待下一次可以取得更好的成績！
順帶一提，這次比賽的第一名是我們同系的同學，他們做釣魚詐騙網站檢測的服務，太厲害了！