「紅燈它有減速，可是停不住，最後還是我踩煞車。」
這是開源 ADAS 停紅燈功能最常見的體驗。要修它，第一個問題不是「改哪個參數」，是「現在的判據到底準不準」——而多數 fork 裡的門檻，是某個人在某台車上覺得順就寫進去的數字，沒有人用資料驗過。
我們把自己車機累積的 814 段行車 log 拿出來，把每一個判斷條件都算一次。
一、先問：現用門檻命中率是多少 #
現用判據是「模型預測前方 45 公尺內要停 → 武裝停車邏輯」。用 814 段 log 逐段比對「模型說要停」與「駕駛實際停了」：45 公尺固定門檻的命中率 100%——但它缺乏科學依據，只是剛好在這台車、這種路況下夠用。
我們同時測了另一個 fork 用的「相對門檻」（隨車速變動），表現反而較差。這個結論只能靠 log 得到，猜不出來。
二、再問：誤判從哪裡來 #
把「該停沒停」與「不該停卻減速」的段落挑出來看：
- 橫向穿越的車流被誤認為前車，系統因此放棄接管——這是「有減速可是停不住」的根因。
- 「無前車才啟動」是必要的濾波條件：有前車時交給跟車邏輯，沒前車時才用停車邏輯，兩者不能同時搶方向盤。
- 一個寫在 commit 裡的「低於 15 km/h 打方向燈比較可能是靠邊停」假設，實測沒有資料支持——而路口轉彎最需要判斷的正是減速到十幾公里那段。我們把它拿掉。
三、修法與驗收 #
修了三件事：滑行到 0.5–2.0 m/s 時前車不再否決接管（握持保護）、路口交接的速度上限從 30 提到 40 km/h、彎道武裝率量化後把無謂減速降 80%。
驗收不是「開起來好像有停」，是預先定義的指標：
| 指標 | 結果 |
|---|---|
| 應介入的紅燈 | 7 次抓對 5 |
| 誤停（綠燈或無號誌卻停） | 0 |
| 綠燈放行 | 比之前提早 1.4 秒 |
沒抓到的 2 次也記錄了原因，留給下一輪。
四、方法比結論重要 #
這篇真正想講的不是 45 公尺，是流程：
- 判據要用資料驗，不用「感覺」——每個門檻都算命中率。
- 借來的做法要在自己的資料上重測——別人的相對門檻在我們的 log 上更差。
- 找根因，不疊補丁——「停不住」的答案是被誤認的前車，不是把煞車調猛。
- 驗收指標先寫好再改。
同樣的流程，我們用在太陽能系統的切換決策（近 20 天 27 次切換條件對照）和量化交易的回測驗證上。
誠實揭露 #
- 814 段是一台車、一位駕駛、大多在台灣北部市區的樣本；7 抓 5 是那一輪驗收的數字，不是通用命中率。
- 這套邏輯屬於實驗性軟體，上路的安全責任在駕駛。
你的設備或車隊也有一堆「大家覺得應該是這樣」的門檻嗎？看車載系統客製化與行車資料工程，或直接談一個 PoC。