研發自動駕駛的核心就是開發新的駕駛技能，然后測試該技能。測試中如果發現了問題，再逐一攻克。

而問題是，工程師們往往只擅長寫代碼，卻忽視了通過測試找到代碼中的問題。花一個月時間做好了一個新的駕駛技能，就以為萬事大吉了。車一旦上路，問題（bug）卻層出不窮。

其實，出了bug沒關系，最重要的是要充分利用發現的bug，挖掘bug的根源，才能有效修復，避免再犯。

這就涉及到triage的學問。Triage字面意思是指對問題進行分揀，其實也泛指對問題尋根溯源（root-causing），也包括分揀時所需的工具。

傳統互聯網的triage過程相對比較簡單，代碼的層級不會太深。比如，一個對外鏈接斷了，八成是因為那個鏈接已經挪了地方。

而自動駕駛則復雜很多。肉眼可見的只有那輛車以及坐在車里可以體驗到的乘坐感受。背后卻有成百上千個代碼組成部分，每一個組成部分內部又有多層分級。一旦自動駕駛車出現問題，很難馬上判斷出到底是哪里需要修改。

比如，肉眼所看到的是，自動駕駛車沒能及時躲避一位正在過馬路的行人。這可能是攝像頭的問題，可能是雷達的問題，可能是行為預測的問題，可能是定位的問題，也可能是高精地圖的問題，等等。因此，我們需要一個高效、嚴謹的過程，快速找到bug根源。

我們可以將triage分為三個階段。

1. Bug識別

2. Bug分揀

3. Bug追根溯源

第一階段：Bug識別

發現bug的最直接方式就是在路上測試，然后將錯誤標注出來。準確的標注可以讓工程師更快了解bug的類別。比如使用“突然剎車”、“偏離車道”這些關鍵詞。

然而，大部分的bug很難通過駕駛直接體現出來。如果代碼里有100個bug，很可能在駕駛中只能體現出兩三個。有的bug只能在特定情境下才會被觸發，平時不會被發現。而且有的bug可以被重現，有的則不能。今天在某個地方突然剎車，明天這個問題可能又沒了。

因此，必須首先盡量將減少測試中的變量，不要等到上路測試才發現bug。比如，如果利用仿真進行測試，就可以對變量進行有效地控制，快速確認bug。

Bug識別的工具也有很多，比如可以通過指標報表，某項指標一旦發生變化，就報錯。也可以通過各種前端工具，將車的探測結果進行可視化，錯誤就能一目了然。

讓系統自動報錯雖然省時省力，但問題是，報錯的數據中往往有很多雜音（noise），報告100個bug，其中也許只有幾個是真正有價值的bug。因此，報錯系統必須不斷提升，才能提高信噪比（signal-to-noise ratio）。

第二階段：Bug分揀

團隊越大，bug分揀就越困難。假設一家公司里同時有二十個團隊在過去一個月里碰過代碼，那么如果出現了問題，這二十個團隊就都有可能承擔責任。如果不去對bug進行分揀，每遇到一個bug就讓所有團隊研究一次bug，會浪費很多工程師的寶貴時間。

因此，負責分揀bug的人必須對各個團隊的業務了如指掌，幫助工程師對bug進行分揀。至少做到將bug及時分發到對應的小組手上，從而節省各個團隊的的時間。

分揀bug時往往需要一些基本的決策樹，比如，如果看到了某種現象，那么bug的原因就一定是A或B。再根據另一種現象，可以推斷出一定是B。隨著代碼不斷更新，這個決策樹也需要不斷更新。

Bug分揀之后，要對bug的重要等級進行排序。并不是所有的bug都需要馬上被修正。根據團隊在當下階段的主要目標，比如該季度中自動駕駛車左轉的bug最為重要，就要把和左轉有關的bug找出來，視為priority 1。

第三階段：Bug追根溯源

Bug分配到正確的團隊的手上之后，就需要被追根溯源，看看根本問題到底出現在哪里。越復雜的bug牽扯出來的問題就會越多，根本原因也埋得越深，修正所需要的時間也越長。

針對相對容易的bug，效率就是一切。如果容易的bug都修復不了，就會拖其他復雜bug的后腿，bug越積越多，最終造成惡性循環。因此，團隊必須在控制代碼質量的基礎上，遵守定時修復bug的流程。

因為一些bug修正起來太困難，所以很多團隊會選擇進行“熱修復”，即hotfix，而不去從根本上解決問題。Hotfix什么時候該用，什么時候不該用，也需要各個團隊做到統一。否則代碼的核心質量無法保證。

其實，很多bug的根本問題不在于技術本身，而在于公司團隊的組織架構設計不合理，或是高層的技術決策出現失誤。團隊的領導者要認清事實，敢于及時止損。