Behind Dashy HUD: 與 AI 雞同鴨講的開發日誌
Vibe Coding 的代價：當「感覺」無法被 AI 翻譯
如果你是 dragonpilot 的使用者，你可能已經玩過那個可以用瀏覽器開啟的儀表板——Dashy HUD。簡單來說，它就是把 openpilot 的 UI 介面，透過 JavaScript (Web 技術) 重新實作了一遍。
這篇文章想聊聊這背後的開發故事。這不僅僅是技術迭代的紀錄，更多的是關於我如何透過 “Vibe Coding”（憑感覺寫 Code），在無數次與 AI 「雞同鴨講」的過程中，把這個專案磨出來的血淚經歷。
什麼是 Dashy HUD？為什麼要做？
這一切的起點，其實是為了一個有點異想天開的需求：「如果能支援沒有螢幕的設備呢？」
雖然這後來被證明不切實際（因為設備出問題時，還是需要實體螢幕來進行 Reset），但我轉念一想：如果我能把它做成投射/反射式的 HUD (Head-Up Display)，駕駛是不是就不用頻繁轉頭看掛在旁邊的螢幕了？ 甚至，在夜間駕駛時，我們可以直接把刺眼的螢幕關閉，只留下擋風玻璃上淡淡的數據倒影。
為了這個念頭，我打開了 IDE，也開始了跟 AI 的漫長對話。
第一版：Canvas 與那些「難以形容」的幾何學 (2025/07)
第一版開發了近一個月，最痛苦的不是寫程式，而是校正。 要在 Canvas 上畫出準確的車道線，需要精準的幾何投影。這也是「雞同鴨講」最嚴重的時候。
我心裡清楚我要的是什麼——那是一種視覺上的「正確感」，一種透視角度的微調。但我發現，很難用文字精準地向 AI 描述這種「感覺」。
我說：「路看起來太『平』了，要有深度。」
AI 回覆：「幫你加了陰影。」（不是！是矩陣變換！）
我說：「線條的彎曲度怪怪的，不像真的路。」
AI 回覆：「幫你把線條加粗了。」（暈倒...）
AI 很擅長寫 Code，但很不擅長理解「人類的視覺直覺」。我常常花了大把時間在解釋一個我腦中很清晰、但 AI 怎麼改都改不到位的細節。最後往往只能放棄溝通，自己動手去調那些該死的參數。
第二版：Three.js 與那些「完美的」副作用
為了追求 1:1 的完美復刻，第二版我決定導入 Three.js。 這一次，我跟 AI 的合作彷彿進入了「蜜月期」。在電腦模擬器上，我們完成了一個驚人的成就：
完美的 1:1 Replicate。
這不只是「像」而已，是真正意義上的複刻。每一個 UI 元素都精準地落在它該在的位置，大小分毫不差。我們甚至還做了一套完美的自動縮放邏輯 (Auto-scaling)，無論你投射在什麼尺寸的畫面上，介面都能自動調整，確保所有資訊完美呈現。
看著電腦螢幕上那個精緻、流暢、佈局完美的 HUD，我心想：「這就是我要的終極型態。」
但一上實車，現實給了我一記重拳。
連線開始瘋狂 Drop，畫面卡頓到幾乎無法使用。 這裡進入了另一種層面的「雞同鴨講」。AI 完美地執行了我對「視覺」的所有指令，但它完全忽略（或者說我沒辦法讓它理解）這是一台正在跑自動駕駛模型的嵌入式設備。
我看到的：一個完美的 UI。
硬體感覺到的：你為什麼要在我要算路徑的時候，叫我去算幾萬個 3D 多邊形？
AI 給出了滿分的程式碼，但對於這台硬體來說，這卻是致命的毒藥。這讓我學到了一件事：在 Vibe Coding 的世界裡，AI 不會阻止你做蠢事，它只會盡全力幫你把蠢事做得非常完美。
第三版：Rollback 與中二魂的爆發 (2025/09)
面對那個「完美但不能用」的 V2，我只能忍痛 Rollback 回第一版。 雖然心有不甘，但我把 V2 學到的架構邏輯，整合回 V1 的 Canvas 基礎上，發布了第一個穩定版 (dp 0.10.0)。
接下來的四個月，趁著 comma 4 出現，我決定用 Tailwind 重構，把 dp 設定頁移過來，順便滿足我的中二魂——加入各種主題：
Openpilot: 原生風格。
Flight: 模仿飛機儀表的介面（男人的浪漫）。
Navigation: 純導航模式。
Split: 分割畫面。
為了提升 GPS 的流暢度，我還加入了 gpsd 服務 (dp 0.10.3)。這期間一切看起來都很美好，直到...
第四版：WIP 與 歷史的幽靈 (Déjà vu)
現在正在進行的第四版，目標原本是把 Navigation On Openpilot (NOO) 加回去。 有了之前的經驗，我以為我已經學乖了，以為我知道怎麼控制 AI 不要寫出太肥的 Code。
結果，歷史幽默地重演了。
在電腦模擬器上，一切行雲流水。導航指引清晰、Code 看起來也比 V2 簡潔多了。 但當我把它推送到車上時，那個熟悉的惡夢回來了：
commIssue (通訊錯誤)
螢幕上跳出黃色的警告，數據流再次斷裂。 我才驚覺，我又掉進了 Vibe Coding 的陷阱。AI 在我的指揮下，寫出了瘋狂監聽數據的代碼。它預設你的 CPU 是 M3 Max，但現實是我的 openpilot 正在為了維持 20Hz 的控制頻率而拼命喘氣。
看著電腦上跑得完美的程式，我意識到我又得親手把它拆爛，因為它在真實世界裡「水土不服」。
這也讓我不得不面對一個現實的抉擇。
結論
所以，Dashy HUD 到底是什麼？ 它是 openpilot 的 UI 復刻，它是我的中二魂展現，它更是我用破英文跟 AI 互相折磨幾個月後的產物。
未來的 V4 會怎樣？老實說，我也不確定。可能會有導航，也可能為了不讓通訊報錯（commIssue）而砍掉重練。 這就是嵌入式開發的日常——在「看起來很帥」和「車子還能動」之間，做一個卑微的選擇。
如果你在下個版本沒看到導航，請不要怪我。 請怪那個只想著寫 Three.js 特效，卻不懂 openpilot 只有一顆小 CPU 的 AI 吧。
(P.S. 原本發願每個月要寫四篇 Substack，但光是跟 AI 吵架和修這些 Bug 就飽了，看樣子一個月能產出兩篇就很不錯了 XD)
✍️ 本文在 gemini 協力下完成，一起調校的不只是 openpilot，還有這篇文章。
我們盡量以最簡單易懂的方式說明，若有任何錯誤也麻煩各位指正。未經授權請勿任意轉發，轉發請註明出處，謝謝。