智能駕駛產(chǎn)品開發(fā)中如何貫徹“正向開發(fā)”理念

本文將從智能駕駛開發(fā)的一般流程出發(fā)，并通過硬件方案和軟件方案的正向定義，結(jié)合項(xiàng)目實(shí)例，說明如何在智能駕駛開發(fā)過程中貫徹正向開發(fā)的理念。

一 正向開發(fā)的優(yōu)勢

我們先談一個(gè)跟正向開發(fā)相對的概念：逆向開發(fā)。

逆向開發(fā)，即先鎖定固定的配置、技術(shù)，然后再反推這些配置和技術(shù)能夠?qū)崿F(xiàn)什么樣的功能。逆向開發(fā)表面上能夠降低開發(fā)成本、縮短開發(fā)周期，因?yàn)橐磺卸际菍ΜF(xiàn)有產(chǎn)品的“拿來主義”。

但是，逆向開發(fā)出來的產(chǎn)品，上限永遠(yuǎn)只能是別人家已有的方案，并且由于缺乏對產(chǎn)品的深刻理解，只“知其然”，不能“知其所以然”，導(dǎo)致產(chǎn)品質(zhì)量難以保證，并且產(chǎn)品效果難以提升。

同時(shí)，逆向開發(fā)過程中如果出現(xiàn)技術(shù)難題，可能會(huì)無法解決，從而出現(xiàn)項(xiàng)目整體停滯的情況，原因就是逆向開發(fā)的本質(zhì)是歸納和復(fù)刻，缺乏正向開發(fā)所具備的對產(chǎn)品整體的深刻理解，以及對各項(xiàng)技術(shù)的整體把控。

以熱門話題“去高精地圖”為例，如果采用逆向開發(fā)的理念，圍繞是否配置高精地圖，可能會(huì)有一輪又一輪的多部門討論、開會(huì)、決策，最后公司領(lǐng)導(dǎo)拍板：“高精地圖太貴了，要去掉，但是要保證功能不打折?！?/p>

在逆向開發(fā)的認(rèn)知中，城市NOA功能不是目的，是否需要高精地圖才是最大的問題。但是，實(shí)際上，在感知算法的水平不足的情況下，缺乏高精地圖，是很難實(shí)現(xiàn)城市NOA等高階功能的。

相比之下，正向開發(fā)理念將開發(fā)目標(biāo)回歸到需求層面，所有的設(shè)計(jì)和后續(xù)開發(fā)工作，都是為了滿足用戶需求，達(dá)成產(chǎn)品效果。

還是以“去高精地圖”為例，如果采用正向開發(fā)的理念，思路就會(huì)變成這樣：因?yàn)橐钶d城市NOA功能，所以要么提升感知算法水平，要么讓高精地圖更精準(zhǔn)，應(yīng)該綜合評估哪種方式更容易實(shí)現(xiàn)、成本更低。

在正向開發(fā)理念中，高精地圖不是一個(gè)問題或者結(jié)論，而是一種措施和手段，最終目標(biāo)是實(shí)現(xiàn)城市NOA功能，而不是解決高精地圖的有無問題，因?yàn)槌烁呔貓D，還會(huì)有其他多種因素，影響城市NOA功能的落地。

正向開發(fā)需要從零開始，對產(chǎn)品整體和開發(fā)過程的每一步都有深入的理解和完整的把握。雖然看起來正向開發(fā)需要更長的開發(fā)周期和更高的成本，但當(dāng)整體流程打通后，正向開發(fā)的優(yōu)勢會(huì)顯而易見：

它能夠幫助開發(fā)者更好地理解用戶需求、關(guān)注用戶體驗(yàn)，并將需求和開發(fā)目標(biāo)貫徹始終，從而提升產(chǎn)品質(zhì)量和用戶滿意度，進(jìn)而提高產(chǎn)品的競爭力和市場占有率。

不僅能確保產(chǎn)品開發(fā)目標(biāo)得到完全落實(shí)，從根源上提升產(chǎn)品實(shí)力，還能讓整體開發(fā)過程有序、嚴(yán)謹(jǐn)，項(xiàng)目的關(guān)鍵節(jié)點(diǎn)更容易得到保證，從而順利達(dá)成預(yù)期的產(chǎn)品和項(xiàng)目效果。

如果從哲學(xué)的維度來說，正向開發(fā)更像是一種“道”，逆向開發(fā)更像是一種“術(shù)”。短期來看，“術(shù)”可以解決一些問題，但長期主義者，更應(yīng)該去追求“道”，通過正向開發(fā)理念，把目標(biāo)聚焦在根源，開發(fā)出經(jīng)得起時(shí)間考驗(yàn)的產(chǎn)品。

二 智能駕駛的正向開發(fā)流程

基于正向開發(fā)的理念，在智能駕駛的開發(fā)過程中，可以借鑒軟件開發(fā)的V型流程，形成適用于智能駕駛開發(fā)的V型流程體系，如圖1所示。

圖1 智能駕駛的V型開發(fā)流程

可以看到，按照工作流的順序，智能駕駛V型流程依次包含產(chǎn)品設(shè)計(jì)與定義、系統(tǒng)分析與設(shè)計(jì)、硬件分析設(shè)計(jì)、軟件分析設(shè)計(jì)、硬件開發(fā)、軟件開發(fā)、軟件模塊測試、臺(tái)架仿真測試、實(shí)車測試等關(guān)鍵階段。

圖1的開發(fā)流程是典型的正向開發(fā)流程，智能駕駛方案從產(chǎn)品設(shè)計(jì)與定義開始，經(jīng)過對智駕系統(tǒng)的詳細(xì)分析與架構(gòu)設(shè)計(jì)，將開發(fā)目標(biāo)傳遞到硬件和軟件層面，硬件和軟件分別根據(jù)產(chǎn)品需求，開展具體的開發(fā)工作；再經(jīng)過軟件測試、臺(tái)架測試、實(shí)車測試等不同等級的測試驗(yàn)證，確認(rèn)達(dá)到產(chǎn)品開發(fā)目標(biāo)，最終完成開發(fā)任務(wù)并交付。

產(chǎn)品設(shè)計(jì)與定義通常由產(chǎn)品經(jīng)理負(fù)責(zé)，基于市場發(fā)展和用戶調(diào)研，結(jié)合公司戰(zhàn)略和技術(shù)水平，并考慮法規(guī)政策限制，完成功能原理、邏輯流程、場景分解、關(guān)鍵參數(shù)等，形成產(chǎn)品需求文檔（Product Requirement Document，PRD）。

系統(tǒng)分析與設(shè)計(jì)通常由系統(tǒng)工程師或架構(gòu)工程師負(fù)責(zé)，根據(jù)PRD、法規(guī)和技術(shù)標(biāo)準(zhǔn)，制定系統(tǒng)架構(gòu)、功能狀態(tài)機(jī)、軟硬件接口、信號(hào)定義、詳細(xì)性能參數(shù)等，形成系統(tǒng)技術(shù)規(guī)范（System Technical Specification，STS）。

硬件分析與設(shè)計(jì)通常由硬件工程師負(fù)責(zé)，根據(jù)產(chǎn)品需求和系統(tǒng)技術(shù)規(guī)范，制定硬件詳細(xì)需求與方案，包括硬件的型號(hào)、參數(shù)和技術(shù)規(guī)范等，形成零部件技術(shù)規(guī)范（Component Technical Specification，CTS）。

軟件分析與設(shè)計(jì)通常由軟件算法工程師負(fù)責(zé)，根據(jù)產(chǎn)品需求和系統(tǒng)技術(shù)規(guī)范，制定軟件詳細(xì)需求與方案，形成軟件需求說明書（Software Requirement Specification，SRS）。

硬件開發(fā)包括各類傳感器以及智駕域控制器的開發(fā)，通常由專業(yè)的硬件供應(yīng)商完成，但也有主機(jī)廠會(huì)參與開發(fā)部分硬件，如激光雷達(dá)、毫米波雷達(dá)等。

軟件開發(fā)包括操作系統(tǒng)、中間件和應(yīng)用層算法等模塊的開發(fā)，是目前行業(yè)內(nèi)爭奪和競爭最為激烈的環(huán)節(jié)，主機(jī)廠想要自研、Tier 1想要把控、各類算法供應(yīng)商想堅(jiān)持黑盒，但最終都會(huì)完成各類功能的軟件算法模塊。

硬件與軟件開發(fā)完成后，進(jìn)入到測試和驗(yàn)證階段。首先在軟件層面搭建軟件測試環(huán)境，設(shè)計(jì)測試用例與腳本，制定軟件模塊測試方案，并完成軟件模塊測試；然后將智能駕駛的軟件算法搭載到控制器上，搭建臺(tái)架測試環(huán)境，完成基于臺(tái)架的集成仿真測試，又稱為硬件在環(huán)測試（Hardware-In-Loop，HIL）；最后，將所開發(fā)的智能駕駛系統(tǒng)，裝載到實(shí)車上，通過場地和道路測試，最終驗(yàn)證智能駕駛產(chǎn)品的效果，包括功能、性能、交互、用戶體驗(yàn)等內(nèi)容。

可以看出，對于正向開發(fā)來說，智能駕駛的開發(fā)應(yīng)該嚴(yán)格遵循圖1所示的V型流程，在產(chǎn)品設(shè)計(jì)與定義階段，明確產(chǎn)品需求與開發(fā)目標(biāo)，并逐層傳遞到具體的開發(fā)工作中，然后再逐步集成化測試，在整車層面驗(yàn)證產(chǎn)品達(dá)到目標(biāo)的效果。

不過，在現(xiàn)階段，由于市場競爭激烈、缺乏統(tǒng)一規(guī)范等原因，智能駕駛實(shí)際的開發(fā)過程，往往難以遵循正向開發(fā)流程，出現(xiàn)了一些違背正向開發(fā)理念的做法，導(dǎo)致產(chǎn)品質(zhì)量難以保證，用戶體驗(yàn)不佳，并增加了大量的改進(jìn)成本。

下面，我們分別從硬件方案和軟件方案2個(gè)方面，展開講述在智能駕駛開發(fā)過程中，如何按正向開發(fā)流程開展工作，并避免出現(xiàn)簡單歸納法思維以及逆向開發(fā)的情況。

三 硬件方案的正向定義

【本文提到的硬件方案，有些已經(jīng)是眾所周知的知識(shí)，但我們?nèi)韵Ｍㄟ^本文的解釋，能讓讀者“知其然，更知其所以然”，獲得“先有產(chǎn)品定義，后有硬件方案”的正向開發(fā)理念?！髡咦ⅰ?/p>

我們經(jīng)常在發(fā)布會(huì)上聽到這樣的說法：“我們的產(chǎn)品配置了激光雷達(dá)，擁有三十多個(gè)傳感器，還用了先進(jìn)的高算力芯片，是先進(jìn)的智能駕駛?！?/p>

也經(jīng)常在工作中聽到這樣的說法：“我們?nèi)ズ?a class="article-link" target="_blank" href="/manufacturer/1000151/">英偉達(dá)/地平線合作，先把芯片定下來，再看看能做到什么程度。”

甚至?xí)牭焦靖邔舆@么說：“你們?nèi)タ纯葱※i/蔚來/理想/大疆的選型方案，我們跟他們用一樣的，效果應(yīng)該差不多?！?/p>

以上現(xiàn)象的背后，是一種典型的硬件方向逆向開發(fā)的思維方式。在逆向開發(fā)的認(rèn)知中，“配置了高端的硬件，就有了高端的智能駕駛；把市場上別人用的硬件方案歸納一下，選擇差不多的方案，就能做出類似的效果”。

但事實(shí)很可能是：你用8M像素的攝像頭，做出的功能體驗(yàn)不一定比得上別人5M攝像頭的效果；你用100TOPS算力的芯片，實(shí)現(xiàn)的功能未必有別人30TOPS芯片實(shí)現(xiàn)的功能多。

這種情況與軟、硬件的綜合能力有關(guān)，但更本質(zhì)的原因還是在于：沒有按照正向開發(fā)的思路，前期開發(fā)目標(biāo)不明確。

根據(jù)前面提到的正向開發(fā)流程，在定義硬件方案前，更重要的是做好產(chǎn)品層面、系統(tǒng)層面的分析、設(shè)計(jì)與定義。也就是說，硬件方案應(yīng)該是服務(wù)于功能需求、性能要求和產(chǎn)品整體開發(fā)目標(biāo)的，應(yīng)該是“需求先行”，而不是“硬件先行”。

下面，我們以功能需求展開，說明如何按照正向開發(fā)流程，根據(jù)功能需求定義硬件（傳感器+計(jì)算平臺(tái)）方案。

在九章智駕之前的文章《詳解智能駕駛的功能與場景體系》中，已經(jīng)系統(tǒng)化地總結(jié)了目前主要的智能駕駛功能，包含行車功能、泊車功能、主動(dòng)安全功能等。

智能駕駛的傳感器主要包括攝像頭、毫米波雷達(dá)、超聲波雷達(dá)與激光雷達(dá)，通過在車身的不同位置布置多種類型的傳感器，實(shí)現(xiàn)對車輛周圍區(qū)域的檢測；廣義的傳感器還包括地圖定位。傳感器的分布和作用，大部分人已經(jīng)非常熟悉，在此不作贅述，直接參考圖1即可。

智能駕駛各項(xiàng)功能的實(shí)現(xiàn)，依賴于傳感器對相關(guān)區(qū)域的檢測，因此不同的功能需求，對應(yīng)著不同的傳感器方案。根據(jù)各項(xiàng)智駕功能的效果，以及圖1所示的傳感器檢測范圍，可以得出各項(xiàng)功能所需的傳感器配置，如表1所示。需要說明的是，表1中勾選的傳感器配置，是該功能至少需要的傳感器，如果成本允許，當(dāng)然是越多傳感器越好。

表1 智駕功能與傳感器對應(yīng)關(guān)系

根據(jù)表1，在定義傳感器方案時(shí)，對于行車功能，單車道L2級功能如LCC只需前視攝像頭+前向毫米波雷達(dá)；多車道L2級功能涉及相鄰車道，還需要前、后角毫米波雷達(dá)；點(diǎn)到點(diǎn)的領(lǐng)航駕駛功能，需要增加側(cè)視攝像頭與后視攝像頭，而城區(qū)路況更加復(fù)雜，因此C-NOA還需要激光雷達(dá)。

對于泊車功能時(shí)，停車位區(qū)域的自動(dòng)泊車需環(huán)視攝像頭+超聲波雷達(dá)，而停車場范圍的記憶泊車、智能召喚、自主代客泊車等功能，涉及低速行駛的場景，因此需要增加行車功能相同的傳感器。

主動(dòng)安全功能的傳感器，主要與功能所覆蓋的方位有關(guān)。

在定義傳感器配置方案時(shí)，通?？梢愿鶕?jù)產(chǎn)品的功能需求，參考表1的匯總結(jié)果，根據(jù)功能，逐一確定所需配置的傳感器類型。至于傳感器的具體參數(shù)、型號(hào)，則需進(jìn)一步根據(jù)產(chǎn)品性能要求，按照同樣的思路來定義。

智能駕駛的計(jì)算平臺(tái)，主要是指域控制器，其重點(diǎn)是SoC芯片與MCU芯片。其中SoC芯片主要用于AI計(jì)算，即處理大量的環(huán)境感知與定位數(shù)據(jù)，以及作出任務(wù)決策和軌跡規(guī)劃等；MCU主要負(fù)責(zé)執(zhí)行指令，以及安全可靠性。

SoC芯片的最重要任務(wù)是處理環(huán)境感知與定位信息，因此，智駕方案對SoC的AI算力的需求與環(huán)境數(shù)據(jù)的豐富程度緊密相關(guān)。

根據(jù)正向開發(fā)流程，在傳感器配置方案完成后，應(yīng)該根據(jù)各傳感器的數(shù)據(jù)量，評估SoC芯片所需的算力水平。由于各家的算法不同，不同SoC芯片的內(nèi)部架構(gòu)不同，因此同一套傳感器配置，可能會(huì)出現(xiàn)不同的AI算力要求，但算力水平的大概量級，應(yīng)該是一致的。

例如，單車道L2級智能駕駛只需要前視攝像頭與前向毫米波雷達(dá)，5TOPS以內(nèi)的AI算力足以滿足；多車道L2級智能駕駛還需要角毫米波雷達(dá)，因此需要5TOPS以上的AI算力；高速領(lǐng)航駕駛H-NOA還涉及側(cè)視攝像頭的數(shù)據(jù)，通常需要30TOPS以上的AI算力；城區(qū)領(lǐng)航駕駛C-NOA由于需要處理大量的激光雷達(dá)點(diǎn)云數(shù)據(jù)，通常要求AI算力達(dá)到200TOPS以上。

表2匯總了現(xiàn)階段的主要智駕SoC芯片。在確定智駕產(chǎn)品所需的AI算力水平后，可以從表2中，選取相應(yīng)的SoC芯片，完成計(jì)算平臺(tái)的核心選型。不過，在實(shí)際應(yīng)用中，AI算力只是關(guān)鍵參數(shù)，此外還要綜合考慮軟件與芯片的匹配度、平臺(tái)成熟度、成本等多種因素，定義出最適合自己的方案。

表2 智駕SoC芯片匯總

以上，就是從功能需求→硬件方案的正向定義方法，這種正向演繹的思維，能夠從功能需求出發(fā)，在充分理解各傳感器用途和算力分布的基礎(chǔ)上，定義出最優(yōu)的硬件方案。

四 軟件方案的正向定義

在軟件方案中，操作系統(tǒng)和中間件往往是成熟的方案，并且難以在產(chǎn)品效果層面直接體現(xiàn)；但應(yīng)用層算法，尤其是各項(xiàng)功能的實(shí)現(xiàn)邏輯和關(guān)鍵參數(shù)，是影響智駕產(chǎn)品最終效果的重要因素。

按照正向開發(fā)的流程，智能駕駛算法的邏輯和參數(shù)，應(yīng)該是在產(chǎn)品設(shè)計(jì)與定義階段提出，經(jīng)系統(tǒng)分析與設(shè)計(jì)階段細(xì)化后，傳遞到軟件開發(fā)層面。但在實(shí)際的開發(fā)過程中，往往容易出現(xiàn)需求定義不清、具體模塊開發(fā)人員不聞不問，隨便拍腦袋，甚至直接照搬其他車型方案的情況，導(dǎo)致最終開發(fā)出來的功能，偏離最初的開發(fā)目標(biāo)。

下面通過幾個(gè)功能的真實(shí)案例來說明，軟件方案的常見逆向開發(fā)做法，以及正確的正向開發(fā)方式。

案例一：自動(dòng)泊車APA

某公司的APA功能開發(fā)時(shí)，由于項(xiàng)目時(shí)間緊任務(wù)重，在缺乏產(chǎn)品需求和系統(tǒng)關(guān)鍵參數(shù)的情況下，算法工程師認(rèn)為“目前市場上的APA功能已經(jīng)很成熟，可以直接拿來用”。在簡單了解了某款車型的泊車關(guān)鍵參數(shù)后，就迅速開展工作，達(dá)到了與該車型大概相同的自動(dòng)泊車效果。

但在實(shí)車測試時(shí)發(fā)現(xiàn)，車輛泊車完成后的位置，不能夠根據(jù)周圍環(huán)境自動(dòng)調(diào)整，導(dǎo)致在周圍有障礙物時(shí)，有時(shí)距離障礙物過近，不方便用戶開門下車。并且，在泊車過程中，多次出現(xiàn)方向盤大幅左右晃動(dòng)、車身不穩(wěn)的情況。

根源就是因?yàn)檐浖?shù)不是通過正向開發(fā)得到的，而是工程師歸納式簡單參考的結(jié)果。

原本可以通過正向開發(fā)避免的問題，由于急功近利的逆向開發(fā)方式，導(dǎo)致泊車功能缺乏亮點(diǎn)，無法讓用戶滿意，沒有達(dá)到預(yù)期的產(chǎn)品效果。

對于這種情況，按照正向開發(fā)的流程，首先應(yīng)該考慮的是在產(chǎn)品設(shè)計(jì)與定義階段，通過競品分析、用戶調(diào)研等方法，提前考慮到泊車過程中對舒適度的要求，明確對橫向控制穩(wěn)定性的要求，以及泊車完成后的車身位置要求。即使項(xiàng)目時(shí)間緊張，也可以壓縮各階段的項(xiàng)目周期，而不能直接“裁剪”掉最重要的源頭階段。

案例二：自適應(yīng)巡航ACC

有一次，ACC功能開發(fā)過程中，我們遇到了ACC目標(biāo)車速變更和ACC跟車停止邏輯的問題。

在開發(fā)ACC功能時(shí)，我們團(tuán)隊(duì)的產(chǎn)品經(jīng)理經(jīng)過市場對標(biāo)和用戶體驗(yàn)分析后，在產(chǎn)品需求中明確提出：用戶使用ACC功能時(shí)，通過“短按”方向盤的車速調(diào)節(jié)按鍵，控制目標(biāo)車速按步長5kph不變化，通過“長按”按鍵，控制目標(biāo)車速按步長1kph變化。

原因是，在道路中行駛時(shí)，車速變化1kph的場景極少且沒有明顯意義，因此通過“長按”的方式來控制；車速變化5kph對于改變車速更有意義，因此通過“短按”這一更為簡單的方式來控制。

但是，在開發(fā)過程中發(fā)現(xiàn)，負(fù)責(zé)對應(yīng)開發(fā)模塊的工程師，忽略了產(chǎn)品需求，通過自己的判斷和市場上某一款車型的做法，私自更改產(chǎn)品需求，導(dǎo)致開發(fā)結(jié)果偏離目標(biāo)。

這種簡單的經(jīng)驗(yàn)式歸納，直接導(dǎo)致該功能的效果是由軟件需求反向影響產(chǎn)品需求，也降低了產(chǎn)品效果。雖然最終得到了改正，但對項(xiàng)目整體來說，產(chǎn)生了額外的成本。

另外，ACC控制車輛停車時(shí)，出于功能一致性和連續(xù)性的考慮，產(chǎn)品需求中要求在任何時(shí)候，用戶踩下制動(dòng)踏板，ACC功能都應(yīng)該完全退出，但在開發(fā)過程中，負(fù)責(zé)對應(yīng)模塊的工程師，忽略了產(chǎn)品需求，自行定義為“車輛靜止?fàn)顟B(tài)下，哪怕用戶踩下制動(dòng)踏板，ACC功能仍然能保持”。這不僅違背了功能整體邏輯，也額外增加了軟件工作量。

以上情況，雖然開發(fā)過程是按照正向流程，產(chǎn)品→系統(tǒng)→軟件，但在執(zhí)行過程中，軟件模塊的開發(fā)人員仍沒有意識(shí)到正向開發(fā)的重要性，按照個(gè)人經(jīng)驗(yàn)去逆向定義甚至忽略產(chǎn)品的需求，導(dǎo)致偏離開發(fā)目標(biāo)，也導(dǎo)致項(xiàng)目的時(shí)間和人力成本增加。

這種是個(gè)典型的“有流程，但沒有意識(shí)”的案例。很多時(shí)候，公司高層和項(xiàng)目負(fù)責(zé)人已經(jīng)認(rèn)識(shí)到正向開發(fā)的重要性，并且制定了具體的工作流程，但公司的一些研發(fā)人員卻沒有正向開發(fā)的意識(shí)，仍然按照個(gè)人經(jīng)驗(yàn)，照搬過去的做法，導(dǎo)致正向開發(fā)難以完全貫徹落實(shí)，新產(chǎn)品的亮點(diǎn)難以得到百分百地呈現(xiàn)。

針對這種意識(shí)、觀念層面的問題，我們能做的就是首先在團(tuán)隊(duì)整體明確正向開發(fā)的理念和方法，然后去培養(yǎng)工程師的正向開發(fā)思維，通過團(tuán)隊(duì)的影響力，帶動(dòng)個(gè)人的意識(shí)提升。

案例三：高速領(lǐng)航H-NOA

H-NOA功能開發(fā)過程中，我們遇到了默認(rèn)車道策略和進(jìn)入匝道前變道時(shí)機(jī)的問題。

團(tuán)隊(duì)在定義H-NOA功能時(shí)，對默認(rèn)的行駛車道沒有作出明確定義，僅要求“在合理的車道中行駛”。算法人員在開發(fā)時(shí)，為降低感知的難度，將默認(rèn)車道設(shè)定為高速公路的最左側(cè)車道。

實(shí)際上，根據(jù)大量老司機(jī)的駕駛經(jīng)驗(yàn)，以及《道路交通安全法》的要求，高速公路中的長時(shí)間行駛車道應(yīng)該是左側(cè)第二車道，車輛不應(yīng)該長期保持在最左側(cè)車道行駛。

同樣，對于進(jìn)入匝道前的變道邏輯，前期也沒有作明確定義，僅要求“能夠在進(jìn)入匝道前，變道至緩沖車道或最右側(cè)車道”。算法人員在缺乏溝通和調(diào)研的情況下，對變道時(shí)機(jī)的參數(shù)定義過于激進(jìn)，導(dǎo)致測試時(shí)，多次出現(xiàn)無法成功進(jìn)入匝道的情況。

這種情況是由于在項(xiàng)目前期缺乏全面的考慮，導(dǎo)致對產(chǎn)品的某些參數(shù)缺乏定義，具體開發(fā)時(shí)缺乏依據(jù)。

按照正向開發(fā)流程，在產(chǎn)品和系統(tǒng)層面，相關(guān)人員應(yīng)該盡可能地全面定義各項(xiàng)關(guān)鍵參數(shù)；對于NOA這類相對復(fù)雜的功能，如果前期確實(shí)遺漏了某些參數(shù)的定義，那么具體模塊的開發(fā)人員在缺乏依據(jù)時(shí)，應(yīng)該主動(dòng)向產(chǎn)品或系統(tǒng)人員確認(rèn)、溝通，而不是自作主張地“拍腦袋”。

前期產(chǎn)品需求全面細(xì)致，各具體模塊負(fù)責(zé)人員主動(dòng)溝通，這樣才能讓正向開發(fā)的流程更好地推進(jìn)，產(chǎn)品效果得到保證；否則，如果需求定義不清，后續(xù)模塊人員自作主張，那么實(shí)際上又變成了逆向開發(fā)的模式，正向開發(fā)也就成了表面文章。

五?結(jié)語

以上，就是智能駕駛的正向開發(fā)方法，以及如何在實(shí)際工作中，貫徹正向開發(fā)理念的一些理論和經(jīng)驗(yàn)總結(jié)?；谘堇[法的正向開發(fā)理念，能夠讓智能駕駛產(chǎn)品在充分滿足用戶需求，保證產(chǎn)品質(zhì)量的同時(shí)，確保開發(fā)目標(biāo)合理且得到落實(shí)。

不過，本文的內(nèi)容屬于基本的思路和方法論，在具體的產(chǎn)品開發(fā)過程中，還需根據(jù)實(shí)際情況，如開發(fā)能力、成本、周期、資源等，靈活定義方案，及時(shí)調(diào)整，作出最合理、能落地的選擇。