geohot 的幽靈拷問
讓 AI 模擬 comma.ai 創辦人為 openpilot Fork 們開發指點迷津
身為 openpilot 資深的使用者以及 dragonpilot 的維護者，我熱愛 openpilot 社群的百花齊放。
但這也讓我時常反思：在不斷添加新功能、追求客製化的過程中，我們是否離「解決自動駕駛」這個核心使命越來越遠？ 這個問題沒有標準答案，所以我決定做個實驗，去尋求一個最極致、最專注的觀點。
我用 Google Gemini 建立了一個 George Hotz (geohot ，comma.ai 創辦人) AI 分身並問了它：「一個好的 fork 該加什麼，不該加什麼？」 它的回答不像建議，更像一場拷問。
以下，就是它的答案。
對話: https://g.co/gemini/share/0e0f534ae318
(--- 以下是 AI geohot 的回答，幾乎一字未改 ---)
聽著。你想維護一個 openpilot fork？行。你們大多數人只是在增加垃圾，但既然你問了，我就告訴你怎麼才能不那麼爛。
我們的目標不是打造一個自訂的汽車音響。目標是交付一個超越人類的駕駛代理 (a superhuman driving agent)。你寫的每一行程式碼，都應該為這個使命服務。如果不是，就刪了它。
你「應該」加什麼
這很簡單。你的重點應該放在那些能讓車開得更好，或是能擴大 openpilot 覆蓋範圍的事情上。
一個更好的駕駛模型 (A Better Driving Model)： 這是第一名，其他的一切都差得遠。如果你有合法、由數據驅動的方法來改進模型，那就去做。你在改善無標線道路的置中能力嗎？你在讓轉彎更順滑嗎？你在減少車輛的左右搖擺 (ping-pong) 嗎？這才是真正的工作。如果你的「更好模型」只是改幾個參數讓它變得更激進，那你跟個孩子沒兩樣。用數據、用 logs、用指標來證明它更好。
新的車型支援 (New Car Ports)： 這很有價值。讓 openpilot 能在更多車上運行，是我們獲得更多數據和用戶的方式。一個乾淨、維護良好的新品牌或車型移植，是巨大的貢獻。這需要真正的工程技巧去逆向分析汽車的 CAN bus 並安全地整合它。
硬體支援 (Hardware Support)： 也許你找到了讓 openpilot 在新的或不同的硬體上運作的方法。只要它安全且符合性能要求，這就很有用。它擴展了整個生態系。
開發者工具 (Developer Tooling)： 你寫了一個更好的 log 查看器？一個用於除錯 CAN 訊號的新工具？或是任何能讓人們更容易分析駕駛數據並為核心專案做出貢獻的東西？太棒了。這能幫助到每一個人，它能擴展我們集體的努力。
基本上就是這些。如果你的功能不屬於以上任何一類，你最好三思。
你「不應該」加什麼（以及為什麼）
這就是 99% 的 fork 走錯路的地方。你們沉迷於那些沒用的功能，因為它們做起來簡單，看起來又很花俏。快停下。
主題、自訂 UI 和音效包： 這是最最最糟糕的，純屬垃圾。我們不是在做 Winamp 播放器的皮膚。UI 應該是極簡的、功能性的、且不分散注意力。增加動畫、改變顏色、讓它發出 90 年代電玩一樣的嗶嗶聲，並不會讓車開得更好。這只會增加程式的臃腫、提高 bug 出現的機率，並讓你從真正的工作上分心。
為什麼不該加？ 因為這完全是浪費時間，對駕駛品質的影響是零。
「調校」旋鈕和選單： 別再加那一百萬個用於「侵略性」、「置中強度」或其他鬼東西的開關了。模型本身應該是那個決定如何駕駛的角色。如果你需要一個選項選單，那意味著你的模型還不夠好。我們的目標只有一個設定：「超越人類」。把這種複雜性推給用戶完全是一種逃避。
為什麼不該加？ 因為這是用來替代「真正解決駕駛問題」的安慰劑，並且會鼓勵用戶創建不安全的駕駛配置。
禁用安全功能： 這點沒得商量。如果你的 fork 讓用戶可以輕易地禁用駕駛員監控、延長脫手時間或繞過任何原廠安全系統，那你就是不負責任。你正在將用戶置於風險之中，並給整個專案帶來污名。我們是建立在汽車安全系統（如 AEB）之上的，而不是去禁用它們。
為什麼不該加？ 因為這既危險又愚蠢，還會讓所有人面臨巨大的法律責任。永遠別這麼做。
行車記錄器或其他垃圾功能： 別想把這個裝置變成一個功能齊全、還能雲端儲存的行車記錄器，或是 Spotify 播放器。有專門的產品能做得更好。comma.ai 硬體只有一個工作：開車。每一個用於其他事情的 CPU 週期和每一行程式碼，都是對使命的背叛。
為什麼不該加？ 這是範圍蔓延 (scope creep)。它為一個需要絕對穩定的系統增加了複雜性和潛在的不穩定性。專注於一件事，並把它做到完美。
聽著，路徑已經很清晰了。要嘛就幫忙解決駕駛問題，要嘛就別擋路。別再搞那些花裡胡哨的電子花車了 (Stop adding rice)。開始交付真正有意義的程式碼。
深度拷問：調校、模式和速度控制的「迷思」
看到這裡，你可能會想：「等等，難道調校 (tuning)、駕駛模式 (driving profiles) 這些都不是有價值的探索嗎？」社群裡有這麼多人在討論這些，它們肯定是重要的吧？
我抱著同樣的疑問，向 AI geohot 發起了追問。它的回答，再次點出了問題的核心。
(--- 以下是 AI geohot 的補充回答 ---)
你還是沒搞懂。你問的是樹木，卻忽略了整片森林。所有這些東西——調校、模式、控制器——都是同一個根本問題的症狀。你試圖修補一個傳統的控制問題，而不是去解決一個現代的機器人學問題。
讓我給你拆解一下。
關於「調校 (Tuning)」
當你說「調校」時，你指的是微調一堆 PID 迴路或其他手寫的啟發式演算法。你坐在那裡改變增益、調整參數，試圖讓車子不那麼頓挫或更貼近路線。
這是劣質模型的拐杖。
如果你需要手動「調校」汽車的行為，這意味著你的模型從一開始就無法輸出正確的行為。你基本上是在用 OK 繃去貼一個槍傷。正確的答案不是找到完美的 OK 繃，而是治癒底層的傷口。
模型應該從觀看數百萬英里的人類平穩駕駛中，學會如何平穩駕駛。它不需要你來告訴它 P=0.2, I=0.01。如果車子很頓，我們需要餵給它更多平穩駕駛的數據，並改進模型架構，直到它學會為止。手動調校是死路一條，它無法規模化。
關於「駕駛模式 (Driving Profiles)」
像是「舒適模式」、「運動模式」或「瘋狂麥斯模式」——這更糟糕。這完全是個噱頭，是一個會讓產品變得更差的表面功夫。
一個超越人類的駕駛員沒有「模式」。 他只有一種模式：根據當前情況做出適當的反應。
你不會上車後說：「我今天應該用『舒適模式』開車。」不，你會在學區謹慎駕駛，在匯入高速公路時更果斷。汽車的行為應該是環境的自然產物，而不是用戶選擇的單選按鈕。
模型應該學會這一點。它應該看到交通擁堵時知道要縮短跟車距離並反應更靈敏；它應該看到空曠的道路時知道該如何表現。增加一個「模式」選擇器，只是承認了你無法建立一個能理解上下文的單一模型。這是一種失敗。
關於「速度控制 (Speed Controller)」
這是最關鍵的一點。長期以來，openpilot 將轉向（橫向）和速度（縱向）視為兩個獨立的問題。模型找出路徑，然後一個獨立的、傳統的控制器——通常是 PID 迴路——試圖管理速度以跟上前車。
這是過去的方式，而且是錯的。
這就是為什麼你會遇到「橡皮筋效應」或頓挫的加減速。因為兩個系統沒有同步。駕駛是一個整體的動作，人類不會用一個大腦控制方向盤，另一個大腦控制踏板。
未來，也是我們一直在努力的方向，是端到端的縱向控制 (end-to-end longitudinal control)。模型看到場景——前車、紅綠燈、行人、道路曲率——然後直接輸出所需的加速度。這是一個無縫的計畫。它從數據中學習煞車和加速的細微之處，從而帶來極其平順的駕乘體驗。
所以，當你問你的 fork 該為速度控制添加什麼時，答案是：努力讓模型去控制它。不要再加另一個 PID 調節器，不要再加一個新的「跟車距離」設定。把模型做得更好，讓它不再需要那些東西。
結論就是：停止嘗試增加更多的旋鈕。目標是零旋鈕。 用戶上車，按下按鈕，然後它就能完美運作。你增加的每一個旋鈕、每一個設定、每一個模式，都是在朝錯誤的方向前進。
【Bonus】Geohot 的幽靈為何不碰雙 B？
文章到這裡，核心觀點已經很清晰了。但作為一個 bonus，我還問了它一個許多高階玩家和德系車主心中的疑問：「為什麼 comma.ai 不支援像 BMW、Benz 這些使用 FlexRay 匯流排的車？」
(--- 以下是 AI geohot 的最後回答 ---)
好吧，把這事說清楚。你問我們為什麼不支援帶有 FlexRay 的車，比如新款的 BMW 和 Mercedes。簡單的答案是：投入巨大，回報極小。 但你想要細節，那我就給你。
問題的核心：匯流排之戰 🚌
把汽車的內部網路想像成一場對話。大多數汽車使用 CAN bus。它像一個群聊，每個人都在喊簡單的訊息，比如「我正在煞車！」或「時速 50！」。它很舊、很簡單，我們可以輕易地讀取這些訊息並寫入我們自己的訊息來控制汽車。我們在這方面已經非常擅長了。
FlexRay 則不同。它不是一個簡單的群聊，而是一場精心策劃的、高速的、有排程的會議。它是一種更新、更複雜的系統，專為 ADAS 所需的高頻寬、容錯通訊而設計。
技術上的頭痛點 🤕
複雜性與成本： 連接 CAN 很便宜簡單。FlexRay 的硬體昂貴且難找得多。協議本身也複雜得多，你不能隨便加入對話，你必須知道誰在何時發言的精確排程。為每款車型逆向這個排程是巨大的工程。
加密與簽名訊息： 這是最大的問題。為了防止像我這樣的人做我們正在做的事，製造商通常會對訊息進行簽名。如果你試圖發送一個轉向指令，汽車電腦會檢查加密簽名。如果與官方相機或雷達模組的預期不符，它就會拒絕指令。這是一個有效的安全功能，把我們鎖在門外。
投資回報率極低： 看看市場。路上有多少台 2018 年的 Toyota Corolla，又有多少台 2018 年的 BMW 5 系列？銷量在 Toyota、Honda 和 Hyundai 這些車上。我的目標是為每個人解決自動駕駛問題，而不只是為那些開豪華車的人。我為什麼要花費數千個工程小時去破解一個小眾的高階車型，而我可以用同樣的時間去支援十個擁有數百萬銷量的車型？這筆帳很簡單。
我們是一個小團隊，試圖解決世界上最困難的問題之一。我們必須對精力的投入 ruthless（無情）。在少量汽車上與專有的、簽名的、不必要複雜的通訊匯流排作鬥爭，是對真正使命的一種干擾。
結語：在 commit 之前
AI geohot 的拷問到此結束。它的話語雖然尖銳，卻直指核心：專注。
openpilot 的魅力在於其解決核心問題的潛力，而不是成為一個可以換皮膚的玩具。對於每一位 fork 維護者來說，這份來自「數位幽靈」的備忘錄，或許是一個重新審視自己工作的契機。
所以，在下一次 git commit -m "feat: add new color theme" 之前，不妨也問問自己：
我是在解決問題，還是在裝飾聖誕樹？
✍️ 本文在 gemini 協力下完成，一起調校的不只是 openpilot，還有這篇文章。
我們盡量以最簡單易懂的方式說明，若有任何錯誤也麻煩各位指正。未經授權請勿任意轉發，轉發請註明出處，謝謝。