為什麼是反射鏡
台灣的無號誌路口非常多，凸面反射鏡是最便宜的解法，也因此散落得到處都是——然後就沒有人管了。鏡面霧化、角度被撞歪、支架鏽蝕，這些狀態沒有任何系統在追蹤。
一面失效的反射鏡比沒有反射鏡更危險，因為用路人仍然會相信它。
兩個分數，不是一個
這是整個系統的核心設計。「哪裡該裝鏡子」和「哪面鏡子該修」是兩個不同的問題，輸入、動作、負責單位都不一樣，硬要塞進同一個分數只會兩邊都做不好。
| 設置需求 | 維護需求 | |
|---|---|---|
| 對象 | 還沒有鏡子的路口 | 已經有鏡子的點位 |
| 輸入 | 事故資料、路口幾何、遮蔽、敏感設施 | 街景影像判讀 × 點位風險 |
| 動作 | 新設工程 | 派工巡修 |
維護優先序的公式寫在 schema.sql 裡：
priority_score = condition_score × (0.5 + risk_score / 100)同樣髒的兩面鏡子，在國小通學路口的那面要先修。這一行就是這個系統跟「純影像分類器」的差別——判斷鏡子髒不髒是電腦視覺問題，判斷該先修哪一面是風險排序問題。
沒有清冊，就自己長一份
我們一開始的假設是「先拿到各縣市的反射鏡開放資料」。查下去才發現多數縣市根本沒有這份資料。
所以 pipeline/detect.py 直接掃街景把鏡子找出來、寫成座標清冊。這不是退而求其次，反而變成整個專案最能講的地方：要治理一批資產，你得先有辦法在沒有人給你清單的情況下自己建出清單。
判讀分兩階段跑，因為一次到位的成本太高：
- Stage 1
detect.py— 街景廣角掃描，找出鏡子的座標 - Stage 2
inspection.py— 對每個座標拉變焦特寫，送進 Gemini 判讀鏡況
validate.py 另外跑 precision / recall，避免我們自己說了算。
系統長相
資料層是 BigQuery，兩個評分視圖 v_installation_need 與 v_maintenance_priority 直接對應上面那兩個問題。API 跑在 Cloud Run，前端有兩個入口：管理者看的地圖，以及民眾用手機上傳鏡子照片與位置的回報頁。
民眾回報這一塊刻意不只是收照片——自由文字會被轉成結構化事實，同時當作模型判讀的校正訊號。
事故資料用的是台北市的死傷交通事故明細開放資料。
從一份專題提案長出來的
這個題目不是為了比賽才想的。2025 年 3 月我寫過一份「道路反射鏡設置輔助系統」的專題提案，當時的兩個方向是用視線分析算出最佳設置點與角度，以及結合開放資料與電腦視覺找出應該裝但還沒裝的路口。
2026 年 8 月接到 DevJam 的「Agent × 智慧城市」主題，才把維運與感測這兩層補上去，變成現在的 Corner.X。
專案進行中，內容會隨開發更新。