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

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

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

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

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

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

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

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

因為缺少行業規范，各個團隊在此會出現重大分歧。但基本可以分為兩個流派。

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

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

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

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

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

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

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

另一個流派書中沒有提到，即“過程派”。這一流派注重的是技術本身的質量與成熟程度，而不關注駕駛結果。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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