【導(dǎo)讀】AI編程助手已經(jīng)徹底改變了一名開發(fā)者一個(gè)上午能完成的工作量。過去需要幾個(gè)小時(shí)才能理清思路、寫出草稿的代碼，現(xiàn)在幾秒鐘就能生成。對于探索性工作和快速原型開發(fā)來說，這種效率提升是實(shí)實(shí)在在的。
但在受監(jiān)管的嵌入式開發(fā)領(lǐng)域，比如汽車軟件（ISO 26262）、工業(yè)控制系統(tǒng)（IEC 61508）、醫(yī)療器械（IEC 62304），速度從來都不是瓶頸，證據(jù)才是。這里說的證據(jù)不是代碼能跑起來，而是能證明代碼是在明確的開發(fā)規(guī)范下產(chǎn)出的、經(jīng)過了相關(guān)標(biāo)準(zhǔn)的檢驗(yàn)、并且從需求到測試全程可追溯。
這正是當(dāng)前主流AI輔助方式最令人不安的地方：它加速的恰恰是原本并非瓶頸的環(huán)節(jié)（寫代碼），卻給本來就已經(jīng)很吃力的環(huán)節(jié)（驗(yàn)證、確認(rèn)與合規(guī)認(rèn)證），帶來了更大的壓力。
AI能生成代碼，卻生成不了合規(guī)性
現(xiàn)代AI工具確實(shí)很強(qiáng)。它們能建議實(shí)現(xiàn)方案、補(bǔ)全函數(shù)、生成測試框架。讓它用C語言寫一個(gè)轉(zhuǎn)速（RPM）計(jì)算函數(shù)，得到的結(jié)果往往不僅語法沒問題，邏輯上也說得過去。但這樣的代碼里，唯獨(dú)沒有合規(guī)性。
一段簡單的AI生成函數(shù)，乍一看可能挑不出毛病?？梢坏┙唤o執(zhí)行MISRA C 2012 Rule 10.3的靜態(tài)代碼分析工具，其中的隱式類型轉(zhuǎn)換就會被判定為缺陷，而這個(gè)缺陷必須先解決掉，代碼才能被追溯到已驗(yàn)證的需求上。
這樣的情況，在嵌入式團(tuán)隊(duì)必須遵循的每一項(xiàng)標(biāo)準(zhǔn)里都會反復(fù)出現(xiàn)：
MISRA C/C++：安全關(guān)鍵型C/C++開發(fā)的基礎(chǔ)標(biāo)準(zhǔn)。把語言限定在一個(gè)定義清晰的子集內(nèi)，能最大程度降低未定義行為帶來的風(fēng)險(xiǎn)。這在汽車、工業(yè)和醫(yī)療領(lǐng)域是不能讓步的底線。隨著AI工具生成的C/C++代碼越來越多，MISRA合規(guī)也就成了所有代碼進(jìn)入代碼庫前必須跨過的一道關(guān)卡。
CERT C/C++：關(guān)注的是攻擊者慣用的可利用編碼模式。如果說MISRA關(guān)注的是功能安全（Safety），CERT C/C++關(guān)注的就是網(wǎng)絡(luò)安全（Security），而在互聯(lián)嵌入式系統(tǒng)中，這兩者的邊界正變得越來越模糊。
CWE：一份記錄常見軟件缺陷的目錄。對于要審查AI生成代碼的團(tuán)隊(duì)來說，CWE提供了一套識別漏洞的通用詞匯。因?yàn)槟Ｐ褪菑乃袛?shù)據(jù)中學(xué)習(xí)的，合規(guī)與不合規(guī)的代碼它都學(xué)到了，可能在不經(jīng)意間就復(fù)現(xiàn)了訓(xùn)練數(shù)據(jù)中的漏洞模式。
模型不會自動遵守這些標(biāo)準(zhǔn)。這是開發(fā)者的責(zé)任，需要可靠的工具鏈來支撐。
驗(yàn)證環(huán)節(jié)，才是真正的瓶頸
在安全關(guān)鍵型項(xiàng)目里，驗(yàn)證與確認(rèn)早已占去研發(fā)投入的40%以上。這不是效率低，而是構(gòu)建監(jiān)管機(jī)構(gòu)和認(rèn)證機(jī)構(gòu)所要求的證據(jù)鏈所必須付出的成本。
如果AI只是加快了寫代碼的速度，卻沒有觸及證據(jù)鏈本身，會怎樣？結(jié)果是更多代碼涌入驗(yàn)證流程，瓶頸進(jìn)一步收窄。資深安全工程師要審查的追溯矩陣變得更龐大，而發(fā)布關(guān)口卻還是紋絲不動。
AI工具沖擊的，恰恰是開發(fā)曲線中本來就不是瓶頸的那一段。
真正的瓶頸，始終是后半程：靜態(tài)代碼分析、動態(tài)測試、覆蓋率測試、可追溯性，以及最終簽核。如果只加速前面寫代碼的環(huán)節(jié)，卻不去解決后半程的問題，對于要交付認(rèn)證級固件的團(tuán)隊(duì)來說，這算不上什么效率提升，反倒是給本已緊繃的流程又加了一道上游壓力。
質(zhì)量到底該在哪里落地
要填上這個(gè)缺口，就得把靜態(tài)代碼分析、動態(tài)代碼分析和覆蓋率測試真正納入開發(fā)閉環(huán)，而不是等代碼寫完了再來一輪事后審計(jì)，而是讓它成為持續(xù)、內(nèi)嵌的日常環(huán)節(jié)。理想的工作流，不會把“生成代碼”和“檢查合規(guī)”分成兩件事，而是讓兩者融為一體。
把靜態(tài)代碼分析嵌進(jìn)構(gòu)建過程
靜態(tài)代碼分析工具C-STAT是IAR工具鏈的一部分，能在代碼剛寫入的那一刻，就識別出違反MISRA C、MISRA C++、CERT C和CWE規(guī)則的地方，遠(yuǎn)遠(yuǎn)早于代碼被送去評審會或認(rèn)證審計(jì)。AI負(fù)責(zé)提建議，開發(fā)者負(fù)責(zé)把關(guān)，C-STAT負(fù)責(zé)驗(yàn)證。
圖：C-STAT分析報(bào)告，展示某實(shí)際嵌入式項(xiàng)目中MISRA C 2012與CERT C檢查項(xiàng)的違規(guī)情況
把動態(tài)代碼分析放進(jìn)調(diào)試環(huán)節(jié)
動態(tài)代碼分析工具（C-RUN）會在調(diào)試過程中對代碼做插樁，檢測內(nèi)存泄漏、越界訪問、整數(shù)溢出，以及沒處理的switch分支，這些問題往往跟運(yùn)行時(shí)的具體狀態(tài)有關(guān)，靜態(tài)代碼分析未必都能檢查出來。在AI輔助生成代碼、結(jié)構(gòu)看似沒問題但行為卻可能出乎意料的情況下，運(yùn)行時(shí)插樁檢測就不是可有可無的東西了。
圖：C-RUN在調(diào)試階段檢測堆錯(cuò)誤與越界訪問
模型負(fù)責(zé)建議，開發(fā)者負(fù)責(zé)判斷
這些都不是在反對使用AI。效率提升是真實(shí)存在的。在嵌入式軟件領(lǐng)域，熟練開發(fā)者本就稀缺、項(xiàng)目又越來越復(fù)雜，任何能加快寫代碼速度的工具，都具有真正的價(jià)值。
但在AI輔助的工作流里，開發(fā)者的角色正在從“代碼的作者”變成“質(zhì)量的把關(guān)人”，開發(fā)者不再是從零開始編寫每一個(gè)函數(shù)，而是依據(jù)領(lǐng)域知識評估AI的建議，將其放入分析工具中檢驗(yàn)，并做出模型無法替代的判斷，例如代碼邏輯是否符合安全意圖、測試用例是否覆蓋到正確場景等。
正是這層判斷，才能把“生成的代碼”變成“能站得住腳的代碼”。而受監(jiān)管行業(yè)真正需要的，就是這種經(jīng)得起推敲的代碼。
CI/CD：讓證據(jù)自動化
內(nèi)嵌工具能在工作站層面把問題攔下來。但放到團(tuán)隊(duì)協(xié)作的場景里，光靠工作站級別的檢查還不夠。真正的執(zhí)行關(guān)口在流水線，不管代碼是怎么寫出來的，每一次提交都要自動拿企業(yè)所承諾遵循的標(biāo)準(zhǔn)進(jìn)行測試。當(dāng)一次開發(fā)者單次工作產(chǎn)出的代碼量，可能比過去一整周還多的時(shí)候，人工觸發(fā)質(zhì)量檢查就不再具有可擴(kuò)展性。檢查必須自動運(yùn)行，伴隨每一次代碼推送。
IAR Build Tools提供與IAR Embedded Workbench相同的編譯器、鏈接器和工具鏈，并將其打包為可在CI環(huán)境中無頭（headless）運(yùn)行的形式。無論流水線運(yùn)行在Jenkins、GitHub Actions還是Azure DevOps上，CI中的構(gòu)建結(jié)果都與開發(fā)者本機(jī)的構(gòu)建結(jié)果完全一致。ISO 26262、IEC 61508和IEC 62304都要求，用來生成發(fā)布交付的工具配置必須留檔、可復(fù)現(xiàn)，IAR Build Tools讓這一點(diǎn)變得可驗(yàn)證。
C-STAT可在CI環(huán)境中以無頭模式運(yùn)行，違規(guī)項(xiàng)作為構(gòu)建輸出被報(bào)告，覆蓋率趨勢也會隨時(shí)間被持續(xù)追蹤，架構(gòu)層面的偏移會立即顯現(xiàn)。合規(guī)證據(jù)無需等到發(fā)布時(shí)再臨時(shí)拼湊，而是在項(xiàng)目全程中不斷累積。
支撐起這一切的平臺
上面這些工具，只有放進(jìn)一個(gè)真正受治理的開發(fā)平臺里，價(jià)值才會成倍放大。在這樣的平臺上，構(gòu)建是可復(fù)現(xiàn)的，工具認(rèn)證有據(jù)可查，從源代碼到認(rèn)證交付之間的整條證據(jù)鏈，隨時(shí)都能被完整還原出來。
IAR平臺正是圍繞這一需求設(shè)計(jì)的。它的工具認(rèn)證（經(jīng)TüV SüD認(rèn)證）支持覆蓋ISO 26262、IEC 61508和IEC 62304。C-STAT和C-RUN直接集成在這個(gè)環(huán)境中，這意味著，合規(guī)檢查和構(gòu)建過程運(yùn)行在同一上下文中。
這才是“效率”和“合規(guī)”之間真正的分水嶺。區(qū)別不在于AI本身，而在于它背后依托的平臺和工具鏈。
AI負(fù)責(zé)編寫代碼，工具鏈保證質(zhì)量與合規(guī)。IAR能實(shí)現(xiàn)兩者兼得。
