毫不夸張的說，這個問題算是業(yè)界一個million-dollarquestion。搞懂這個問題很難，即使搞懂了，也很難在團隊實施。我在這里舉幾個例子，只能起到拋磚引玉的效果，具體還是要看各位讀者團隊的具體需求。

首先，一定要避開指標的誤區(qū)。在書中2.7.4一節(jié)中我們提到，很多團隊因為誤用指標，導致團隊研發(fā)方向發(fā)生偏移，遲遲無法交付。

比如，一些團隊的指標與他們的適用場景（ODD）毫無關(guān)系，只是照搬美國車輛管理局規(guī)定的指標。

美國車輛管理局每年11月都會要求各個無人駕駛公司上交兩份年度報告：駕駛里程數(shù)（mileage）以及人類安全駕駛員的介入次數(shù)（disengagements）。有了這兩個數(shù)據(jù)，就會用里程除以介入次數(shù)，得到每次介入間隔的里程數(shù)。這個指標越高的公司就會被認為是無人駕駛技術(shù)開發(fā)最成熟的公司。

如此衡量無人駕駛開發(fā)進度雖然簡單直接，但無疑有嚴重弊端。

首先，各個公司測試場景完全不同，所在城市也不同。有的只在高速路測試，有的在郊區(qū)街道測試，有的在擁堵的市中心測試，所以在相同的測試時間里，因為車速完全不同，路況不同，里程數(shù)就會有天壤之別。

何況，市中心的場景更為復雜，雖然車速和郊區(qū)相比慢很多，但市中心才是無人駕駛技術(shù)真正的戰(zhàn)場。Cruise公司曾表示，在舊金山市區(qū)駕駛會遇到的困難場景是郊區(qū)駕駛的46倍。在高速路上，一個小時就可以輕松積累65英里。而在鬧市區(qū)，一個小時可能只能積累5英里。如果只是為了炫耀里程數(shù)，無人駕駛公司會可以選擇一些好開的高速路。而這樣做不利于無人車學習新場景、新技能。

團隊的管理者但凡用點心思，也會為團隊另外制定一套指標。美國車輛管理局規(guī)定的指標其實只不過是給外行人看的，內(nèi)行還是要看深層的指標。

因為缺少行業(yè)規(guī)范，各個團隊在此會出現(xiàn)重大分歧。但基本可以分為兩個流派。

一個流派屬于漏洞派，即bug-driven，只看介入。如果沒有漏洞，就假設(shè)無人駕駛已經(jīng)趨于完美了。這樣的團隊不但會注重解決路上的介入，還會通過其他各種測試方法挖掘潛在的介入。

如果駕駛開始變得過于順利，介入變得太少了，就適當擴張適用場景（ODD），引入適量更多的漏洞。經(jīng)過團隊一段時間的努力，解決部分漏洞之后，再開始新一輪的ODD擴張，如此循環(huán)往復。直到ODD達到可以落地的預期效果。

在書中，我們舉了幾個指標的實例，比如計算臨近觸碰，將臨近觸碰也視為漏洞。

另外，我們可以將里程數(shù)分解為每輛車平均里程、每個城市的里程、駕駛時長。從而將各個指標細分，而不是單純只看一個指標。

書中還提到利用“初次場景”（first-timescenario）來衡量駕駛技術(shù)的generalizability，即普遍適應(yīng)性。這些都屬于漏洞派的指標。

這一流派的工作流程簡單直接，往往立竿見影，適合剛剛起步的團隊。

然而，這樣做的缺點也顯而易見。因為團隊只看重漏洞，而不去尋根溯源，所以團隊每天都會被無窮無盡的漏洞糾纏，形成惡性循環(huán)。好的時候，遇到的漏洞少，團隊能放松兩天，而其他時候，漏洞會扎堆出現(xiàn)，導致團隊十分被動。

另一個流派書中沒有提到，即“過程派”。這一流派注重的是技術(shù)本身的質(zhì)量與成熟程度，而不關(guān)注駕駛結(jié)果。

過程派的團隊會衡量每一個組成部分的指標，而不注重端到端的結(jié)果。比如，識別公交車的精確率與召回率是否都在提升？什么情況下會受影響？無人車定位的速度是否在逐步提升？規(guī)劃的路徑偏離的程度有多大？仿真與路測之間還有多少差距？

這一流派在行業(yè)內(nèi)是少數(shù)，適合技術(shù)相對成熟的團隊，或是不注重做demo、不急著籌錢的團隊。

這一流派的指標的優(yōu)點是，bug可以真正從根本上解決，技術(shù)的研發(fā)往往為長遠目標考慮，禁得起時間的考驗，團隊不至于陷于被動的境地。

而這一流派的缺點是，由于過于注重底層技術(shù)的質(zhì)量，導致最終的駕駛體驗得不到快速提升，研發(fā)周期往往過于漫長。

其實，比較理想的方式是將兩個流派結(jié)合，讓團隊內(nèi)不同級別、不同職能的人去負責不同的流派。

比如，可以讓工程師們專心提升底層技術(shù)的質(zhì)量，讓公司高層關(guān)注端到端的漏洞。如果兩個流派發(fā)生分歧，就要權(quán)衡團隊各方面的利弊，做出共同的決策。這便引出我們下一個來自讀者的問題。

問題2：長期方案與短期方案如何平衡？

這個問題大概做軟件開發(fā)的人會經(jīng)常遇到，即，針對一個棘手的問題，有一個long-term解決方案，可以從根本上解決問題，但往往要花上好幾個月的時間才能做好。為了解燃眉之急，我們是否要花一個星期的時間先做一個hack，把問題蓋住再說？

無人駕駛的研發(fā)更是如此。每開發(fā)一個新的模型都需要幾個月的時間，每增加一個新的駕駛技能都需要幾個月時間的精心調(diào)試。因此，毫不夸張地講，長期方案或短期方案這一問題幾乎每天都會遇到。如果拿不出一套解決問題的體系，真的會患上選擇困難癥，團隊內(nèi)只剩下吵架。

其實，決策方案無外乎要包含以下幾點。記住了這套方案，大部分的決策問題都可以迎刃而解。

首先，一定要回歸團隊在當下的首要目標。看看你的決策是否順應(yīng)團隊的首要目標。有時候，雖然長期方案看上去光鮮亮麗，但并不是團隊當下最重要的目標。

比如，最近無人車在某個左轉(zhuǎn)彎經(jīng)常需要介入。這個左轉(zhuǎn)彎的問題雖然很值得探索，但是團隊當下的首要目標是攻克右轉(zhuǎn)彎。如果有必要，可以考慮采取短期方案先將左轉(zhuǎn)彎的問題蓋住，等右轉(zhuǎn)彎做好之后再回頭來做左轉(zhuǎn)彎。

其次，要考慮成本。這里的成本不只是指研發(fā)所需要的成本，而是指如果給某方案投入成本，是否會對團隊的其他目標造成負面影響。比如，完成一個短期方案需要一個團隊幾個小時的時間，看上去算不上艱巨的任務(wù)，但這個團隊已經(jīng)有了非常重要的項目，這時不應(yīng)該用這些“噪音”去影響他們的進度。

最后，還要考慮“人”的因素。規(guī)定都是人制定的，也是由人來執(zhí)行的。很多主觀因素也必須要考慮。比如，某工程師的行事風格向來謹小慎微，如果要求他做一個hack，來解決短期問題，那么他多半是不會同意的。如果經(jīng)常命令這位工程師去做hack，他很可能沒過幾個月就開始否認公司文化，考慮離職了。

另外要注意，不是所有的漏洞都值得修復。工程師常常犯的錯誤就是看到漏洞就想修復。其實，一些無關(guān)緊要的漏洞完全可以置之不理。不要因為小漏洞而耽誤了更重要的項目。團隊的管理者需要制定一套體系，評估什么樣的漏洞可以暫時忽略掉。