[首發于智駕最前沿微信公眾號]在談及自動駕駛技術時，常會陷入兩個極端，一方面是大家對“完全自動駕駛”的美好愿景，另一方面是自動駕駛技術飛速發展過程中對于“安全隱患”的擔憂。L3級自動駕駛系統（ADS）恰好處在這兩者的張力中——它需要在特定條件下代替人類完成全部動態駕駛任務，同時又必須留出人與機器之間明確的責任與邊界。為了規范自動駕駛系統技術要求、保障交通安全與合規性、推動自動駕駛行業健康發展，由中華人民共和國工業和信息化部主管，國家市場監督管理總局、國家標準化管理委員會發布的《智能網聯汽車 自動駕駛系統通用技術要求》（GB/T 44721-2024）應運而生（以下簡稱：標準），并于2024年9月29日正式實施。那標準到底規定了啥？怎樣才算是達到L3級自動駕駛標準？

標準的核心目標，并不是空講技術方向，而是把自動駕駛發展所涉及的“責任邊界”與“能力邊界”寫成一套可驗證、可執行的工程規則，讓產品在能做的事上可靠做、在做不到的時候可控退出。整個標準從總體要求到感知、決策、人員監測、接管邏輯、提示與驗證方法，都圍繞“把風險保持在合理可接受的水平”來設計。

先從“設計運行條件”（ODC/ODD的表述相關）談起。標準反復強調，ADS必須有明確的設計運行條件，并且只能在這些條件下被激活。ODC是把系統能力與外界復雜性做映射的契約。它要把道路類型、車速區間、車道標識清晰度、天氣光照、GNSS可用性或數字化路側信息等都寫清楚。把這些條件聲明清楚有兩個直接效果，第一，對用戶而言，系統的能做與不能做一目了然，減少誤用；第二，對驗證團隊而言，試驗范圍有據可依，仿真、場地與道路試驗的場景選擇能更有針對性。換句話說，把“能在哪些場景工作”寫清楚，是把“不確定性”轉化為“可驗證的假設”。標準對這一點的強調，正是把自動駕駛從概念化的能力宣稱，變成工程化的聲明與承諾。

標準部分截圖

關于系統必須做到的“目標與事件探測與響應”（OEDR），標準把感知能力的要求具體化為識別道路、道路設施、其他交通參與者、障礙物、天氣與光照等，并能測量位置和速度。從技術上探究，這要求一個融合多源傳感器的感知鏈路，從底層的傳感器標定與安裝規范到上層的目標檢測、軌跡預測與語義理解，都要形成閉環。標準不僅要求在正常狀態下的探測能力，而且明確了“當感知性能衰退時要有合理的控制策略”。這條看似被動的規定，實際上要求團隊在傳感器選型、冗余設計與性能退化策略上做充分設計：要么通過冗余傳感器保持功能能力，要么在檢測到衰退時及時限制系統激活或執行最小風險策略（MRM）。把感知退化放進規范，實質上是要求從“我能看到”到“我知道我在什么條件下能看見”這條鏈路都要被工程化。

標準部分截圖

說到最小風險策略，這是標準的另一個核心。它不是簡單的“車停下來”，而是一個有先有后的控制流程，當系統檢測到ODC即將失效、駕駛員沒有在規定時間內接管，或出現嚴重失效時，ADS要能判斷并執行可使風險降至可接受水平的控制動作。標準明確了兩個關鍵時間相關的設計點，一是介入請求必須留出足夠時間讓駕駛員接管；二是在駕駛員未響應的情況下，介入請求從發出到升級并開始執行MRM的時間應不少于10秒。這10秒并非隨意給出的數字，而是工程折衷的結果，最終目標是既要給人類足夠時間理解并接手，也要保證在駕駛員沒有接手時系統有足夠的時間完成安全降速與靠邊停車等動作。這個要求對HMI設計、駕駛員監測和車輛動力學控制提出了明確約束，提示必須快速、明確且可被感知，車輛控制必須能在提示升級到MRM前保持平穩與安全。

標準部分截圖

與最小風險策略配套的，是對“發出介入請求”和“接管能力判定”的明確規范。對于需要傳統駕駛員接管的ADS，標準要求系統具備駕駛員在位監測和駕駛員執行動態駕駛任務能力的監測，并且至少用兩種有效指標來判定駕駛員是否具備接管能力，例如眼部狀態、頭部運動或特定的人機交互動作。標準甚至給出了在位監測的直接觸發條件，駕駛員不在駕駛位超過1秒或未系安全帶時，需要按規定發出介入請求或接管能力不足提示。這意味著車企不能僅靠“方向盤轉動”的單一信號來判定人是否在位，而要設計融合攝像頭、力矩傳感器、座椅壓力傳感器等多模態判據，并設定判定周期與閾值，以確保在需要接管時真正有真人可以接手。

標準部分截圖

在人機交互（HMI）方面，標準把“提示的清晰度與層級”寫得非常具體。ADS的每一種狀態——未激活、就緒、激活、介入請求、介入請求升級、MRM、失效、退出等——都應以直觀且可區分的方式提示用戶，且介入請求至少要在光學提示基礎上附加聲學或觸覺提示，升級后還要增加持續或間歇性觸覺提示。這樣的規定源于對人感知與響應能力的實際考量，視覺提示在駕駛員分心或光照條件差時可能失效，聲學提示在噪聲環境中也可能被淹沒，觸覺（方向盤振動、座椅振動）則作為可靠的最后手段。這一要求的挑戰在于，提示的語義需要與駕駛員心理模型一致，不同提示不能互相混淆，也不能過度打擾以至于造成焦慮或驚嚇。標準把提示形式列入強約束，是為了強制廠商把HMI的研究從“好看”變為“有效且可驗證”。

標準部分截圖

標準對“激活與退出”的約束也反映了對誤用風險的關注。要求ADS必須有專用的激活與退出操縱方式，并防止可合理預見的用戶誤用；且在需要傳統駕駛員接管的系統中，只有在滿足一系列條件（例如駕駛員在位并系好安全帶、駕駛員具備DDT執行能力、沒有影響ADS的失效、DSSAD可記錄、車輛未在執行影響ADS的軟件升級等）時ADS才能被激活。這樣的規定看似繁瑣，但其防御目標明確：在系統被錯誤激活后發生事故會引發法律與倫理風險，而把激活條件做成“多門檻合格”是降低這種風險的工程手段。同時，退出邏輯同樣被嚴格限定，系統退出不得導致應急輔助功能或其他輔助功能的異常開關，退出也不應在非必要情形下觸發，除非用戶明確操作或系統執行MRM。換言之，標準在人的行為與系統能力之間建立了嚴謹的“握手協議”，保證離開自動駕駛狀態的過程受到可控管理。

對“干預”規則的細化，也體現標準的現實主義。駕駛員干預分為橫向（轉向）與縱向（制動與加速）兩類，標準明確當駕駛員的輸入超過防止誤用所設的合理閾值時，應執行人的輸入；同時系統還要能檢測駕駛員是否專注于DDT，某些閾值與駕駛員專注情況相關。這就要求轉向/制動輸入由高頻采樣的力矩/踏板傳感器、方向盤角度傳感器和駕駛員狀態監測共同決策，確保當人做出有力且明確的干預時，機器讓位，從而避免人機“拉鋸”導致的控制沖突。并且，標準允許在極端情況下基于廠商聲明對駕駛員干預進行暫緩或抑制，但要求明確說明適用場景和合理性，這為那些在極低概率但高危后果的情形里采取非直覺控制策略提供了合規路徑，同時也要求廠商承擔透明性責任。

標準部分截圖

技術體系與文件化管理同樣被強調。標準要求車輛制造商提供完整的系統描述、組件清單、布局與原理圖、單元功能說明和安裝規范，尤其對感知部件的安裝細節作出說明，位置、外表材料、尺寸形狀、光潔度以及可能影響ADS性能的安裝規范都要記錄在案。這些看似“紙上工作”的條款，實際上直接關系到量產一致性與后市場維護。感知性能不僅取決于算法，更取決于硬件安裝工藝與車身電磁兼容、線束走向、傳感器遮擋策略等。把這些要求放進標準，是為了解決在研發階段很容易控制，但在規模化生產時容易變差的“從試驗車到量產車”的性能遷移問題。

標準部分截圖

安全管理與驗證鏈路是標準另一組重量級章節。標準要求制造商建立覆蓋開發、生產、運行、服務到報廢的安全管理體系，進行功能安全（ISO26262風格）與預期功能安全（SOTIF風格）層面的危害與風險評估，并在驗證與確認階段采用“多支柱”方法——仿真、場地試驗、道路試驗與審核評估共同形成證明鏈。這主要是因為在某些極端場景在道路試驗中不可窮盡，仿真能擴展樣本空間；場地試驗能在受控條件下復現危險場景；道路試驗則驗證系統與真實交通主體的互動。把這些方法論上升為標準，是為了規范驗證策略，避免廠商只靠“路測里程”作證，而忽視了系統在邊界場景或罕見組合下的表現。除此之外，標準還要求運行階段的監控機制，比如自動駕駛數據記錄系統（DSSAD）與遠程安全監控，以便把線上的安全事件回傳并形成閉環改進。這就把產品的安全保障從單次出廠的靜態合格，擴展為“在場運行中持續可監控與可改進”的動態合格。

標準部分截圖

把標準落到工程實踐上，會遇到若干現實問題和設計權衡。首先是感知冗余與成本的權衡，滿足OEDR的探測范圍和退化策略，通常需要多傳感器融合與冗余設計；這既增加硬件成本，也提出了傳感器間時間同步、坐標對齊與故障隔離的工程難題。其次是駕駛員監測的隱私與可靠性問題，基于攝像頭的眼動/面部監測效果好，但涉及隱私與復雜光照適應；基于方向盤力矩與手勢識別可能更隱私友好，但對判定“注意力”可能不夠敏感。再有是HMI的語義一致性，提示設計要兼顧不同用戶對提示語義的認知模型，避免因詞句、顏色或振動強度不同而引起誤讀。標準并沒有直接告訴廠商該如何在每一處做選擇，而是把邊界和驗證要求明確下來，真正的工程工作就是在這些邊界下做折衷并形成可證明的驗證證據。

這部標準的發布其實具有雙重意義。一方面，它為國內企業提供了與國際接軌的技術框架，尤其是在驗證方法與安全管理方面與國際“多支柱”共識保持一致，從而降低了合規不確定性。另一方面，標準通過把文件化、試驗與運行監控變為必須條件，強化了廠商對“持續責任”的認識，自動駕駛不是交付軟件就完事的單次事件，而是需要在全生命周期里對設計假設、場景覆蓋與在線表現負責的長期工程實踐。對于廠家而言，遵循標準意味著不僅要做出能跑的算法和能穩的控制器，更要能產出可追溯的文檔、可再現的驗證結果以及面向現場數據的監控改進機制。

總之，標準把L3及以上自動駕駛系統的若干關鍵點制度化，明確設計運行條件、細化感知與OEDR要求、規定接管與MRM的時間與提示機制、約束激活/退出與干預邏輯，并把功能安全與SOTIF式的預期功能安全貫穿開發到運行的全過程。對工程實踐而言，這些規定不是“要你做文書”，而是要把那些本應就做的工程活動——場景定義、冗余設計、人機交互試驗、故障注入驗證、運行監控與數據閉環——都放在可驗證與有證據的框架下執行。對于目標是把自動駕駛推向規模化部署的團隊，這個標準給出的不是一張簡單的合格單，而是一整套能支撐產品安全可信賴落地的方法論。

審核編輯 黃宇