當前位置： 主頁 > 技術&應用 >

AI Coding 如何符合功能安全要求？解析程式碼品質驗證與法規遵循

本文作者：IAR 點擊： 2026-10-02 13:53

前言：

AI 加速程式開發，但無法加速法規遵循證據建立

AI 程式開發助手徹底改變了開發者在短時間內能完成的工作量。過去需要花上數小時撰寫雛形的程式碼，如今幾秒鐘內就能產生。對於探索性開發與快速原型設計而言，生產力的提升確實相當顯著。

然而，在受到法規規範的嵌入式開發領域，例如符合 ISO 26262 的汽車軟體、符合 IEC 62304 的醫療設備，以及符合 IEC 61508 的工業控制系統，速度從來都不是瓶頸，真正的瓶頸是「證據」。這裡所指的證據，不只是程式碼能夠正常執行，而是能證明程式碼是在既定開發流程下完成、依照正確標準完成檢查，並且能夠從需求一路追溯到測試的完整證據鏈。這就是目前 AI 輔助開發最令人難以忽視的事實：它加速了原本就不是問題的環節──程式碼撰寫，卻讓原本就耗時且成本高昂的工作變得壓力更大，包括驗證（Verification）、確認（Validation）以及法規遵循（Compliance）佐證。

為什麼 AI 生成程式碼仍需要 MISRA、CERT C 與 CWE 檢查？

現代 AI 工具的能力確實相當出色。它們可以提出實作建議、自動補齊函式，甚至產生測試程式架構（Test Skeleton）。當你要求它以 C 語言撰寫 RPM 計算函式時，通常都能得到語法正確、邏輯合理的程式碼。但這些輸出並不包含法規遵循能力。一段由 AI 產生、乍看之下沒有問題的函式，在套用 MISRA C 2012 Rule 10.3 的靜態分析工具檢查後，可能會因為隱含型別轉換（Implicit Type Conversion）而被標示為缺陷。在這個問題修正完成之前，該程式碼都無法建立與已驗證需求之間的可追溯性。

MISRA C/C++：安全關鍵 C/C++ 軟體開發的基礎標準。透過限制程式語言只能使用明確定義的子集合，可大幅降低未定義行為（Undefined Behavior）的風險，這在汽車、工業與醫療等領域都是不可妥協的要求。隨著 AI 持續產生大量 C/C++ 程式碼，MISRA 規範已成為所有程式碼納入程式碼庫前的重要品質關卡。

CERT C/C++： 著重於避免容易遭攻擊者利用的程式撰寫模式。MISRA 著眼於安全（Safety），CERT C/C++ 則聚焦於資訊安全（Security），而在現今高度連網的嵌入式系統中，兩者的界線正逐漸重疊。

CWE： 一套整理常見軟體弱點的知識庫。對於審查 AI 產生程式碼的團隊而言，CWE 提供了一套標準化的分類方式，用於辨識 AI 模型可能因訓練資料而無意間重現的安全漏洞，因為模型學習的內容同時包含符合規範與不符合規範的程式碼。這些標準沒有任何一項是 AI 模型本身能夠自動遵循的，而是必須由開發者搭配適當的工具鏈來落實。

AI 提高開發效率，為何驗證與確認（V&V）仍是最大瓶頸？

在安全關鍵產品開發中，驗證（Verification）與確認（Validation）通常已佔據研發成本的 40% 以上。這並非效率低落，而是建立主管機關與認證機構所要求的完整證據鏈所必須付出的成本。當 AI 加速程式碼產生，卻沒有同步改善證據鏈時，會發生什麼事？答案是：更多程式碼流入驗證流程、瓶頸變得更嚴重、資深功能安全工程師需要檢視更龐大的追溯矩陣，而產品發布關卡卻絲毫沒有因此加快。 AI 工具改善的是原本就不是限制因素的開發前半段。真正的限制始終存在於後半段，包括靜態分析、動態測試、程式碼涵蓋率量測、可追溯性，以及最終簽核。若只加速程式碼產生，而沒有同步改善後續流程，對於需要交付認證韌體的團隊而言，這並不是生產力提升，而只是讓原本就吃緊的驗證流程承受更大的前端壓力。

提升 AI 程式碼品質的關鍵：靜態分析、動態分析與 Coverage

要縮小這個落差，就必須將靜態分析、動態分析與程式碼涵蓋率量測納入日常開發流程，不是等到最後才進行稽核，而是在開發過程中持續執行。理想的工作流程，不應將程式碼產生與法規遵循檢查分開，而是讓兩者緊密整合。在建置流程中整合靜態分析作為 IAR 工具鏈的一部分，C-STAT 能在程式碼加入專案時，即時找出違反 MISRA C、MISRA C++、CERT C 與 CWE 的問題，在程式碼送交審查委員會或認證稽核之前就完成檢查。AI 提供建議、開發者負責審查，而 C-STAT 負責驗證。

圖： C-STAT 分析報告，顯示實際嵌入式專案中違反 MISRA C 2012 與 CERT C 規範的檢查結果。

在除錯階段執行動態分析

C-RUN 會在除錯過程中對程式碼進行執行期插樁（Instrumentation），偵測記憶體洩漏、陣列越界、整數溢位，以及未處理的 switch 分支等問題。由於這些缺陷與執行狀態有關，因此靜態分析未必能完全找出。在 AI 輔助開發流程中，即使程式碼結構正確，也可能在執行行為上出現意料之外的問題，因此執行期檢測並非可有可無，而是必要的一環。

圖： C-RUN 在除錯期間即時檢查 Heap 錯誤與陣列越界等執行期問題。

AI 無法取代工程師：品質判斷仍是安全關鍵軟體的核心

上述內容並不是在否定 AI。AI 所帶來的生產力提升是真實存在的。在嵌入式軟體開發領域，熟練工程師供不應求，專案複雜度也持續增加，因此任何能加速程式開發的工具都具有實際價值。

然而，在 AI 輔助開發流程中，開發者的角色已從程式撰寫者轉變為品質把關者。開發能力並沒有消失，而是重新定位。工程師不再需要從零開始撰寫每個函式，而是根據領域知識評估 AI 提供的建議，透過分析工具進行驗證，並做出 AI 無法取代的專業判斷，例如程式邏輯是否符合安全目標、測試是否涵蓋正確情境，以及整體系統架構是否仍保持一致性。

正是這一層專業判斷，才能將 AI 產生的程式碼轉化為具備驗證依據的程式碼，而這正是受法規規範產業真正需要的成果。

CI/CD：讓證據自動化累積

整合於開發流程中的工具可以在工程師工作站上即時發現問題，但在團隊協作環境中，僅靠工作站層級的檢查並不足夠。真正落實規範的是 CI/CD Pipeline，它會自動依照組織所制定的標準檢查每一次 Commit，不論程式碼是由人工撰寫或 AI 產生。當一次開發工作就能產出過去一週才能完成的程式碼量時，手動執行品質檢查已無法有效因應。所有檢查都必須在每次 Push 時自動執行。

IAR Build Tools 提供與 IAR Embedded Workbench 相同的編譯器、Linker 與工具鏈，並可在 CI 環境中以無介面（Headless）方式執行。不論 Pipeline 建立於 Jenkins、GitHub Actions 或 Azure DevOps，CI 的建置結果都能與開發者本機保持一致。ISO 26262 與 IEC 62304 均要求產出正式版本所使用的工具設定必須具備文件紀錄且可重現，而 IAR Build Tools 正是實現這項要求的重要工具。

C-STAT 可在 CI 中以無介面模式自動執行，並將違規項目直接納入建置結果。系統也能持續追蹤程式碼涵蓋率趨勢，立即發現架構偏移問題。法規遵循所需的證據不必等到正式發布時才開始整理，而是在整個專案期間持續累積。

功能安全開發平台如何支援 AI 程式碼品質與法規遵循？

上述工具若能整合至具備完善治理能力的開發平台，其價值將進一步提升。這類平台可確保建置結果具備可重現性、工具資格驗證具備完整文件，並能重建從原始程式碼到認證成果的完整證據鏈。

IAR Platform 正是依循這項需求所打造。其工具資格驗證支援涵蓋 ISO 26262（通過 TÜV SÜD 認證）、IEC 61508 與 IEC 62304。C-STAT 與 C-RUN 可直接整合至相同環境中，讓法規遵循檢查與建置流程在一致的環境下同步完成。

這就是「提升生產力」與「滿足法規遵循」之間最大的差異。關鍵並非 AI 本身，而是支撐 AI 的平台與工具鏈。

AI 負責撰寫程式碼，工具鏈負責取得認證。IAR 同時提供這兩者。

了解 IAR 如何協助 AI 程式碼符合功能安全要求

如果想了解 IAR Platform 在實務中的運作方式，可透過互動式展示深入了解安全認證編譯器、程式碼分析，以及 CI/CD 整合如何共同實現法規遵循。

進一步了解 AI 輔助工作流程如何應用於安全關鍵軟體開發可觀看隨選線上研討會「Escaping the 100 M-line Trap」，內容包含完整的實機展示。如果您的應用領域是工業自動化，則可參考「Breaking the Smart Industry Bottleneck」，深入了解通過 IEC 61508 認證的平台如何降低驗證成本，加速智慧製造（Smart Industry）專案的推動。

本月熱點 HOME

欄目熱點 HOME