模型選擇器? Tell me why?
最近，社群中有朋友建議：「可以新增一個『模型選擇器』嗎？」
這是一個很棒的想法，我自己也曾深入思考過。然而，在經過審慎的技術評估後，dragonpilot 目前的答案依然是：不會加這個功能。
這篇文章的目的，就是想和大家分享這背後的技術考量，這關乎系統的穩定性、駕駛體驗的一致性，以及長期的維護複雜度。
核心問題：模型與控制的「耦合程度」
一個常見的觀點是，openpilot 的駕駛模型（.onnx 檔案）就像一個可以隨意更換的「大腦」。但事實上，模型 (modeld) 與其下游的控制模組 (controls) 之間，並不是完全解耦的，而是存在不同層次的耦合關係。
更貼切的比喻是：它們是「大腦」與「神經系統」，透過一套「溝通語言」交換訊息。這套語言，就是模型輸出的 schema 與其對應的語意 (semantics)。
當模型僅僅更新權重，輸出 schema 與語意保持一致時：controls 不需要任何改動，舊版或新版模型可以互換，差別只在於駕駛效果（例如車道檢測更穩定或路徑預測更平順）。
當模型更新時輸出 schema 或語意改變：controls 就必須同步更新，才能正確解讀新訊息。否則可能會產生 jerk 或「騎馬感」，甚至無法正常運作。
過去的例子像 Tomb Raider 7、Tomb Raider 14，模型更新時也同時更新了 Longitudinal Planner，這就是因為輸出語意有改變。換句話說，這種情況下，模型與控制是「強耦合」的。
「混搭」為何不是最佳解？
確實，有些 fork 提供了模型選擇器。這的確能在 schema 沒有變 的情況下正常使用，但並沒有解決耦合的根本問題：
使用者若不小心混用「舊 controls + 新 schema 模型」或反過來，體驗會不一致，甚至造成不穩定。
測試組合會呈現 N 個模型 × M 個 controls 的龐大矩陣，大幅增加維護與驗證的成本。
這也是為什麼我們認為，與其給使用者一個「表面的自由」，不如維持官方的版本一致性，來確保可預測性與穩定性。
正確的做法（以及為何它如此困難）
如果我們真的要打造一個最正確、最安全的「模型選擇器」，它該是什麼樣子？
答案是：它必須像一個時光機。 切換模型時，必須完整地還原當時與之配套的 modeld 和 controls 模組，才能確保系統的一致性。
舉個最實際的例子：如果一個好的切換器能做到這點，那麼受「騎馬感」所苦的 SDSU 使用者，就應該能直接切換回 openpilot 0.9.7 (North Dakota Model) 的完整「模型 + 控制」組合包，從而根本性地解決問題。
那想體驗最新模型該怎麼辦？
讀到這裡，你可能會想：「我理解耦合的風險了，但我就是想走在最前線，體驗最新的模型，並為社群做出貢獻，該怎麼辦？」
答案很簡單：直接安裝最新的 openpilot master 分支。
這才是最正確、最純粹的體驗方式。因為你的駕駛體驗不會被任何 fork 維護者的客製化調校所影響，而你回報給 openpilot 官方團隊的數據與問題，才最具參考價值，能真正幫助 openpilot 進步。
dragonpilot 的目標是提供穩定可靠的方案，而 openpilot master 分支則是為開發與實驗而生。選擇最適合你的路，才是最好的方案。
結語：穩定，才能 Chill
openpilot 的核心理念與標語是「make driving chill」。一個需要使用者時時擔心模型是否匹配、體驗是否降級、甚至花時間去研究哪個組合才是最佳解的系統，一點也不 chill。
dragonpilot 堅持不加入「模型選擇器」，正是基於這個理念。
我們深知 openpilot 雖然有時候模型和控制是鬆耦合的，但在許多關鍵更新中仍然是緊密耦合的。唯有透過完整的版本驗證，才能確保系統的每一個部分都能和諧運作。
✍️ 本文在 gemini 協力下完成，一起調校的不只是 openpilot，還有這篇文章。
我們盡量以最簡單易懂的方式說明，若有任何錯誤也麻煩各位指正。未經授權請勿任意轉發，轉發請註明出處，謝謝。