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

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

其實，出了bug沒關(guān)系，最重要的是要充分利用發(fā)現(xiàn)的bug，挖掘bug的根源，才能有效修復(fù)，避免再犯。

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

傳統(tǒng)互聯(lián)網(wǎng)的triage過程相對比較簡單，代碼的層級不會太深。比如，一個對外鏈接斷了，八成是因為那個鏈接已經(jīng)挪了地方。

而自動駕駛則復(fù)雜很多。肉眼可見的只有那輛車以及坐在車?yán)锟梢泽w驗到的乘坐感受。背后卻有成百上千個代碼組成部分，每一個組成部分內(nèi)部又有多層分級。一旦自動駕駛車出現(xiàn)問題，很難馬上判斷出到底是哪里需要修改。

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

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

1. Bug識別

2. Bug分揀

3. Bug追根溯源

第一階段：Bug識別

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

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

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

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

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

第二階段：Bug分揀

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

因此，負(fù)責(zé)分揀bug的人必須對各個團(tuán)隊的業(yè)務(wù)了如指掌，幫助工程師對bug進(jìn)行分揀。至少做到將bug及時分發(fā)到對應(yīng)的小組手上，從而節(jié)省各個團(tuán)隊的的時間。

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

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

第三階段：Bug追根溯源

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

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

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

其實，很多bug的根本問題不在于技術(shù)本身，而在于公司團(tuán)隊的組織架構(gòu)設(shè)計不合理，或是高層的技術(shù)決策出現(xiàn)失誤。團(tuán)隊的領(lǐng)導(dǎo)者要認(rèn)清事實，敢于及時止損。