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

而問題是，工程師們往往只擅長(zhǎng)寫代碼，卻忽視了通過測(cè)試找到代碼中的問題?；ㄒ粋€(gè)月時(shí)間做好了一個(gè)新的駕駛技能，就以為萬(wàn)事大吉了。車一旦上路，問題（bug）卻層出不窮。

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

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

傳統(tǒng)互聯(lián)網(wǎng)的triage過程相對(duì)比較簡(jiǎn)單，代碼的層級(jí)不會(huì)太深。比如，一個(gè)對(duì)外鏈接斷了，八成是因?yàn)槟莻€(gè)鏈接已經(jīng)挪了地方。

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

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

我們可以將triage分為三個(gè)階段。

1. Bug識(shí)別

2. Bug分揀

3. Bug追根溯源

第一階段：Bug識(shí)別

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

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

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

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

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

第二階段：Bug分揀

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

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

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

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

第三階段：Bug追根溯源

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

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

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

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