關(guān)注+星標公眾號，不錯過精彩內(nèi)容
翻譯 | 安富萊電子
素材來源 | IAR官方博文
https://www.iar.com/blog/ai-writes-the-code.-who-guarantees-the-quality
速度不是瓶頸,證據(jù)才是
AI 編程助手已經(jīng)改變了一名開發(fā)者在一個上午能產(chǎn)出的代碼量。曾經(jīng)需要數(shù)小時草擬的代碼，現(xiàn)在幾秒鐘就能生成。對于探索性工作和快速原型開發(fā)而言，生產(chǎn)力提升是實實在在的。
但在受監(jiān)管的嵌入式開發(fā)領(lǐng)域——ISO 26262 下的汽車軟件、IEC 62304 下的醫(yī)療器械、IEC 61508 下的工業(yè)控制系統(tǒng)——速度從來不是瓶頸，證據(jù)才是。不是證明代碼能運行的證據(jù)，而是證明代碼是在既定實踐下產(chǎn)出、對照正確標準檢查過、從需求到測試可追溯的證據(jù)。
這是 AI 輔助工具在典型部署方式下令人不安的真相：它加速了原本就不是問題的環(huán)節(jié)（編寫代碼），同時給原本就昂貴的環(huán)節(jié)（驗證、確認和合規(guī)認證）施加了更大的壓力。
AI 生成代碼，但不生成合規(guī)性
現(xiàn)代 AI 工具確實能力強大。它們能建議實現(xiàn)方案、補全函數(shù)、生成測試骨架。當你要求用 C 語言計算 RPM 時，你會得到語法正確、通常邏輯也成立的結(jié)果。
但這份輸出不會自帶合規(guī)性。
一個簡單的 AI 生成函數(shù)乍看沒問題。執(zhí)行 MISRA C 2012 Rule 10.3 的靜態(tài)分析器會把隱式類型轉(zhuǎn)換標記為缺陷——這種缺陷必須先解決，代碼才能追溯到某個已驗證的需求。
這個模式在嵌入式團隊遵循的每一項標準中反復(fù)出現(xiàn)：
1、MISRA C/C++： 安全關(guān)鍵型 C 和 C++ 開發(fā)的基線。將語言限制在一個明確定義的子集內(nèi)，可最小化未定義行為的風險——這在汽車、工業(yè)和醫(yī)療領(lǐng)域是不可妥協(xié)的。隨著 AI 工具生成越來越多的 C/C++ 代碼，MISRA 合規(guī)成為一切進入代碼庫前的關(guān)鍵關(guān)卡。
2、CERT C/C++： 側(cè)重于預(yù)防攻擊者可利用的編碼模式。MISRA 針對安全，CERT C/C++ 針對安全防護——這兩個關(guān)注點在互聯(lián)嵌入式系統(tǒng)中日益重疊。
3、CWE： 一份在各代碼庫中反復(fù)出現(xiàn)的軟件弱點目錄。對于審查 AI 生成代碼的團隊來說，CWE 提供了一套結(jié)構(gòu)化的詞匯表，用于識別模型可能從訓練數(shù)據(jù)中無意復(fù)制的漏洞——因為模型從所有數(shù)據(jù)中學習，合規(guī)的和不合規(guī)的都一樣。
這些標準沒有一項由模型來執(zhí)行。那是開發(fā)者的責任，需要合適的工具鏈來支持。
驗證瓶頸
在安全關(guān)鍵型項目中，驗證和確認已經(jīng)消耗了研發(fā)預(yù)算的 40% 或更多。這不是低效，而是構(gòu)建監(jiān)管機構(gòu)和認證機構(gòu)所需的證據(jù)鏈的成本。
當 AI 加速了編寫但讓證據(jù)鏈原封不動時會發(fā)生什么？更多代碼涌入驗證管道。瓶頸擴大。資深安全工程師要審查更大的追溯矩陣。發(fā)布關(guān)卡紋絲不動。
AI 工具攻擊的是開發(fā)曲線上從來不是約束的那部分。約束始終在后半段：靜態(tài)分析、動態(tài)測試、覆蓋率度量、可追溯性和簽字放行。在未解決后半段的情況下加速編寫，對于交付認證固件的團隊來說不是生產(chǎn)力提升——而是給本已吃緊的流程施加了上游壓力。
質(zhì)量真正所在之處
彌合差距意味著把靜態(tài)分析、動態(tài)分析和覆蓋率度量納入開發(fā)循環(huán)——不是作為下游審計，而是作為持續(xù)的、內(nèi)嵌的活動。正確的工作流不會把代碼生成和合規(guī)檢查割裂開來；它把兩者整合在一起。
1、靜態(tài)分析與構(gòu)建內(nèi)嵌
C-STAT 是 IAR 工具鏈的一部分，在代碼錄入點就標記出 MISRA C、MISRA C++、CERT C 和 CWE 違規(guī)——在代碼到達評審委員會或認證審計之前。AI 建議，開發(fā)者審查，C-STAT 驗證。
2、調(diào)試會話中的動態(tài)分析
C-RUN 在調(diào)試會話期間對代碼進行插樁，檢測內(nèi)存泄漏、越界訪問、整數(shù)溢出和未處理的 switch 分支——這些缺陷靜態(tài)分析不一定能捕獲，因為它們依賴于執(zhí)行狀態(tài)。在 AI 輔助的工作流中，生成的代碼可能結(jié)構(gòu)健全但行為出人意料，運行時插樁不是可選項。
模型建議、開發(fā)者判斷
以上任何一條都不是反對 AI 的理由。生產(chǎn)力提升是真實的。在嵌入式軟件領(lǐng)域，熟練開發(fā)者稀缺、項目復(fù)雜性日增，任何能加速編寫的工具都有真正價值。
但在 AI 輔助的工作流中，開發(fā)者的角色從代碼作者轉(zhuǎn)變?yōu)橘|(zhì)量策展人。手藝沒有消失，它重新定位了。開發(fā)者不再從零編寫每一個函數(shù)，而是用領(lǐng)域知識評估 AI 建議，把建議放進分析工具中跑，做出沒有任何模型能做出的判斷：邏輯是否符合安全意圖，測試套件是否覆蓋了正確的場景，架構(gòu)是否仍然自洽。
正是這一判斷層把生成的代碼轉(zhuǎn)化為經(jīng)過認證的代碼。經(jīng)過認證的代碼才是受監(jiān)管行業(yè)所要求的。
CI/CD：讓證據(jù)自動化
內(nèi)嵌工具在工作站捕獲問題。但在團隊環(huán)境中，僅靠工作站級別的檢查是不夠的。流水線才是執(zhí)行點——每一次提交都會自動對照組織承諾的標準進行測試，無論代碼是如何產(chǎn)出的。
當一次開發(fā)者會話能產(chǎn)出比過去一周還多的代碼時，手動觸發(fā)質(zhì)量檢查就不再可擴展。檢查必須自動運行，在每一次推送時。
IAR Build Tools 提供了與 IAR Embedded Workbench 中相同的編譯器、鏈接器和工具鏈，封裝為可在 CI 中無頭執(zhí)行的形式。無論流水線運行在 Jenkins、GitHub Actions 還是 Azure DevOps 上，CI 中的構(gòu)建與開發(fā)者機器上的構(gòu)建完全一致。ISO 26262 和 IEC 62304 都要求用于產(chǎn)出發(fā)布制品的工具配置是可文檔化、可復(fù)現(xiàn)的。IAR Build Tools 讓這一點可被證明。
C-STAT 在 CI 中無頭運行。違規(guī)作為構(gòu)建輸出上報。覆蓋率趨勢隨時間被追蹤。架構(gòu)漂移立即可見。合規(guī)證據(jù)無需在發(fā)布時才組裝——它在整個項目過程中持續(xù)累積。最后，我們提倡工作中借助AI寫代碼，但我們絕不能完全相信AI生成的代碼，想要軟件項目長期穩(wěn)定可靠，方便后期迭代升級、維護，AI生成的代碼必須經(jīng)過人工審查才行，大家覺得呢？------------ END ------------內(nèi)存和PCB都漲上天了，它為什么依舊“真香”？
Cursor即將消失！SpaceX 600 億美元收購，最快下周五就能完成！
