前陣子我終止了一個做到一半的專案。
不是因為做不出來,也不是因為沒時間。是因為我終於去 Google 搜了一下我打算做的東西,然後發現已經有人做了,而且做得比我能做的更好。
那次搜尋花了十分鐘。而在那之前,我已經投入了三天。
這篇想把整個過程寫下來,包括我一開始的推論、實際做了什麼、以及那個轉折點。因為我覺得做錯的部分比做對的部分更值得記錄。
起點:一台 24 小時開著的電腦
我有一台 Mac mini M4,平常拿來跑排程和自動化,幾乎不關機。
某天我開始想:既然它反正開著,有沒有什麼專案是「必須要有一台 24 小時運轉的機器」才能做的?如果只是每天跑一次的排程,那用雲端的免費排程服務就好,根本不需要本機。
我列了一輪,最後收斂到一個概念:易逝資料。
意思是那種「當下有公開,但沒有人保存歷史」的資料。這類資料有個特性:你今天不開始收,三年後也補不回來。護城河不是技術,是時間。
台灣有不少這種資料流,而我挑了停車場即時空位。
理由很簡單:空位數是隨機的,不像捷運有班表可以推導,所以歷史統計才有訊息量。而且沒有任何官方單位在保存這些數值的歷史——「這個停車場週六下午通常還有沒有位」這個問題,即時查詢回答不了,只有累積過的人能回答。
聽起來很合理。我現在還是覺得這個推論本身沒錯。
我建立了一套關卡制度
因為之前踩過「先做再說,做完發現沒人要」的坑,這次我先寫了一份計畫書,把專案切成七個關卡,每關都有明確的通過條件和中止條件。
大致是這樣:
Gate 0 市場空缺調研 Gate 1 資料源盤點(到底有幾個單位真的有即時資料) Gate 2 Schema 凍結(不可逆決策一次定案) Gate 3 收集管線上線 Gate 4 資料成熟度檢查(等 8–12 週) Gate 5 展示層與 SEO Gate 6 變現與 RPM 分析
我還寫了一份專案層的規則檔,把血淚教訓寫死進去。最重要的一條是:
離線絕不填補。 來源回傳空值或特殊碼時,一律記為 unknown。絕不填 0,絕不沿用前一筆數值,絕不插補。
這條看起來很基本,但它是這類專案最容易無聲失敗的地方——資料被污染的當下你不會知道,幾個月後才會發現,而那時候已經來不及了。
這套制度本身是有效的。 它最後也確實救了我——只是救的方式跟我預期的不一樣。
實際做了什麼 資料源探測
第一件事是搞清楚到底有多少資料。結果比預期好:
路外停車場:1,444 個場,其中 911 個有即時車位數 路邊停車格:1,199 個路段,約 45,051 格 收費標準、費率等欄位也都拿得到
過程中還有個意外收穫。官方的即時查詢頁面是用 Blazor Server 做的,資料靠 SignalR 推送,一般的爬取方式讀不到。但攔截網路請求之後,發現背後其實有幾個一般的 JSON 端點,不需要登入、不需要金鑰,而且資料完整度比官方開放平台的靜態清冊還高。
那一刻我確實有點興奮。感覺像是找到了別人沒發現的東西。
24 小時觀測
接著我遇到一個問題:路邊停車格的「使用格位數」到底是哪來的?
如果是地磁感測器,那反映的是實際佔用,統計價值高。 如果是收費開單系統,那反映的是已開單格位,夜間免費時段完全沒資訊,價值就要打折。
這個差別很關鍵,而且沒有文件可以查。所以我寫了一支觀測腳本,挑了六個路段和二十個停車場,每五分鐘取樣一次,連續跑 24 小時。
這裡踩到第一個技術坑:第一次跑只跑了 20 分鐘就中斷了,因為 macOS 睡眠。更麻煩的是腳本沒察覺,留下一個看起來正常、其實只有五輪資料的 CSV。差一點就拿它去做分析。
第二次用 caffeinate 護航,順利跑滿 23.25 小時。
結果很有意思:
有四個路段在半夜出現連續 9–12 小時數值完全不動,白天則有幾十到上百次變化——比較像收費系統,不像感測器 有兩個路段整整 24 小時都是 0,其中一個查到它「只在週五六日及國定假日收費」,而我的觀測全程是平日
還有一個我原本完全沒預期的發現:停車場的異常碼不是各自獨立發生的。
整個 24 小時裡有五個時間窗,每次持續十五到二十分鐘,會有十幾個停車場同時變成異常值、然後同時恢復,而且每次受影響的幾乎是同一批。
這代表那是上游資料源的批次故障,不是個別設備壞掉。兩者的意義完全不同,監測的設計也應該不一樣。
到這裡為止,我覺得一切都很順利。
然後我搜尋了一下
計畫書裡,Gate 0(市場調研)排在 Gate 1(資料探測)之前。順序是對的。
但實際執行時,我卡在一個地方:關鍵字搜尋量要用 Google Keyword Planner,而我的新帳戶被鎖在智慧模式,付款設定怎麼樣都填不完成,拿不到搜尋量數字。
於是我做了一個當下看起來很合理的決定:先跳過 Gate 0,去做 Gate 1。反正收資料的成本是零,晚一天開始就少一天資料,而調研可以之後補。
這是整件事裡唯一真正的錯誤。
因為 Gate 0 裡面其實有兩件事:關鍵字搜尋量,和 SERP 檢查。只有前者需要 Keyword Planner。 後者只需要開一個無痕視窗,搜三個關鍵字,看前十名是誰。
我把整個階段一起延後了,包括那個根本不需要工具的部分。
幾天後我終於去做了。搜了「駁二 停車」「六合夜市 停車」「漢神巨蛋 停車」。
第一頁有一個網站,三個關鍵字全部都上榜。它的頁面長這樣:每個停車場一頁,顯示即時空位、費率、月租價格。
也就是我打算做的東西,一模一樣。
URL 裡藏著答案
真正讓我確定沒得玩的,是它的網址結構。
那些頁面的路徑長這樣:/parking-space/khh-kha00126。
KHA00126——這正是高雄停車管理中心的場站代碼格式,跟我探測到的一模一樣。
換句話說,對方跑在同一份公開資料上,做出同樣形態的頁面,而且已經被索引、已經在排名。
我花三天摸索出來的資料源,人家早就在用了。
而且不只他們。另一個停車資訊站也在做類似的事。至於地標型的關鍵字,上半部被 Google 自己的地圖區塊佔住,剩下的位置是官方網站,加上一批寫得很紮實的部落格攻略——有照片、有比價、有動線說明的那種,不是內容農場。
我唯一還沒被佔的縫隙,是「時段統計」。
但那要用一個新網域,去挑戰一個已經佔位、有相同資料、隨時可以補上同樣功能的對手,而且賭的是一個論壇上幾乎沒人在問的需求。
我終止了計畫。
為什麼我覺得這是好結果
沉沒成本是三個 commit、一次探測、一次 24 小時觀測。管線根本還沒建,也沒有東西留在背景跑。
如果沒有那套關卡制度,我大概會這樣:先把收集管線做好、跑三個月、開始寫展示層、上線、等索引、等流量,然後在四五個月後發現排不上去。
那才是真正的浪費。
關卡制度沒有阻止我犯錯,但它把犯錯的代價從「五個月」壓縮到「三天」。
帶走的三件事
一、驗證要按「殺傷力 ÷ 成本」排序,不按邏輯順序
SERP 檢查十分鐘、不用工具、直接致命。它應該是第一件事,而不是最後一件。
我原本的順序(先調研再探測)在邏輯上沒錯,但我沒有把「最便宜又最可能殺死專案的測試」單獨挑出來優先跑。
二、工具卡住的時候,拆解那個階段,不要整包延後
這是這次真正的錯誤。Keyword Planner 拿不到,不代表 SERP 也看不了。 一個階段裡如果有子項目不依賴那個受阻的工具,就該拆出來先做。
三、「已經有很多 App」這個觀察沒有資訊量
我一度以為「市面上停車 App 很多」是壞消息,但其實不是——App 不會出現在搜尋結果裡,跟搜尋通路幾乎不重疊。
真正的競爭者是排在那個關鍵字第一頁的東西。要看的是 SERP,不是 App Store。
順帶一提,調查競品的時候先看它的 URL 結構,ID 格式常常直接指向它的資料來源。這個技巧我會一直用下去。
那些程式碼我留著了。端點探測的手法、長時觀測的腳本骨架、資料異常的判讀方式,下一個資料型專案可以直接複用。
repo 沒有刪,只是在決策紀錄裡加了一行終止原因,還有那個我最後沒去驗證的問題:對手到底有沒有做時段統計?
萬一哪天答案是「沒有」,而我又剛好有更好的通路,這份筆記還在。