從 PAM 4.1、AI 輔助開發到軟體維護，新版指南的影響不只是評估規則更新，而是汽車軟體治理範圍的進一步擴大。 導入 Automotive SPICE，過去常把重點放在流程建立、工作產品完整性、雙向追溯及評估等級。然而，隨著軟體定義車輛、生成式 AI、平台化開發與 OTA 更新逐漸成為日常，企業面對的品質問題已不再止於「開發專案是否依流程執行」。
真正的新問題是：AI 產生的工程內容如何被管理？軟體交付後的維護責任如何銜接？不同評估員能否根據相同證據得出一致結論？企業蒐集的大量流程指標，能否進一步支持量化管理與持續最佳化？
2026 年發布的《Automotive SPICE Guidelines》第三版黃皮書，相較於 2023 年以 Automotive SPICE PAM 4.0 為基礎的 Guidelines 2.0，新版草案以 PAM 4.1 為主要參考，這次改版不只是修正文句或重新編排章節，而是進一步處理 AI 輔助開發、軟體維護、評分規則語意，以及能力等級 4、5 等議題。
黃皮書意見徵集已於2026年5月12日截止
VDA QMC 的黃皮書，是正式 VDA 標準發布前的公開草案，已於 2026 年 5 月 12 日截止。目前這份文件已離開公開徵詢階段，進入意見整合及正式 Blue-Gold Volume 的準備流程。 黃皮書不是最終正式版。草案內仍可發現 PAM 4.0／4.1 引用、出版日期及部分 Rating Rule 編號不一致的情況。因此，不宜在正式版發布前，直接把所有草案文字轉成強制性的內部或供應商要求。 黃皮書已清楚顯示 VDA AK13 的發展方向。企業現在可以進行影響分析、流程盤點與試行，等正式版發布及客戶轉換政策明確後，再進行受管制的基準版本切換。
新版首先改變的，是評估判斷方式
過去企業準備 ASPICE 評估時，容易把 Rating Rule 當成另一套查檢表：符合就保留評分，不符合就機械式降評。 新版增加完整的 Rating Rule 語意說明，明確區分有條件與無條件規則，也說明多條降評規則同時成立時，不代表必須按照規則數量逐級降低評分。
最終評分仍須回到三個核心：
- 實際評估情境
- 可追溯的客觀證據
- 已識別的流程風險
如果評估員偏離適用的 Rating Rule，必須在評估報告中說明具說服力的理由；反過來說，單純引用一條 Rating Rule，也不能取代完整的弱點描述。 弱點不能只是把 PAM 指標改寫成否定句。例如，「未充分執行需求分析」並不是一個完整的弱點。報告必須進一步說明缺少哪些分析、有哪些客觀證據、可能導致什麼產品或專案風險，以及為何影響該項評分。 這項變化將直接提高評估報告的專業門檻，也增加主任評估員對評分一致性與證據鏈品質的責任。
AI 可以使用，但工程責任不能交給 AI
筆者認為新版最受關注的內容之一，是新增「AI assistance in development」。 指南沒有禁止使用生成式 AI，也沒有規定只能採取特定開發方法。Automotive SPICE 關注的是流程必須達成什麼結果，而不是工程人員一定要使用什麼工具。因此，使用 AI 產生需求、設計、程式碼、測試案例或文件，本身不會自動造成負面評分。真正的評估重點，在於組織是否仍能證明產出經過適當檢查、修正與接受，並符合原有設計、編碼、測試與品質要求。
企業後續可能需要管理的證據包括：
- 哪些 AI 工具可以在專案中使用
- AI 工具、模型與設定採用哪一個版本
- Prompt 是否需要納入組態管理
- AI 使用的輸入資料是否受到適當控制
- AI 產出由誰驗證及核准
- 驗證準則與抽查方法為何
- 發現錯誤、偏差或不可重現結果時如何處理
- 是否涉及機密資料、智慧財產或受限制程式碼
這些議題可能同時影響 SUP.1 Quality Assurance、SUP.8 Configuration Management、PA 2.2 Work Product Management，以及實際使用 AI 的工程流程。 對企業而言，重點不是另外建立一套龐大的「AI 文件系統」，而是將 AI 納入既有的工具管理、組態、審查、驗證及責任架構。
ASPICE 的視角開始跨越 SOP
另，我關注到新版另一項重要發展，是新增軟體維護與交付後生命週期的指引。傳統汽車專案常以 SOP 作為主要交付終點，但軟體定義車輛的實際生命週期可能持續多年。OTA 更新、資安漏洞修補、平台版本演進、底層硬體更換，以及不同客戶專案間的軟體延伸，都需要在量產後持續管理。
新版指南涵蓋的維護情境包括：
- 功能持續擴充
- 操作設計域調整
- 平台對不同客戶的適配
- 底層硬體替換
- 錯誤及不完整版本修正
- 資安漏洞排除
- 其他專案或組織接手既有成果
這不表示每個開發專案都必須立即建立一個完整的維護組織。評估重點是：在目前能夠控制的範圍內，專案是否已為未來維護建立合理準備。 例如，企業是否清楚定義交接責任、供應鏈介面、軟體組態、版本關係、維護所需文件、修補流程及後續工具可用性。 如果維護責任等到 SOP 後才開始討論，企業很可能會發現原開發團隊已解散、供應商合約已結束、工具版本不可取得，或者產品架構根本無法支援安全且可追溯的更新。
能力等級4與5不再只是模型上的遙不可及的目標
資料查核說明
Automotive SPICE Guidelines 第三版黃皮書的六週意見徵集期已於2026年5月12日結束。VDA QMC的一般黃皮書程序，是在回饋期後彙整意見、完成修訂並經核准後，發布正式 Red Volume 或 Blue-Gold Volume。企業實際採用日期仍應以VDA QMC正式出版資訊、客戶要求及評估合約為準。
過去多數汽車專案的評估目標集中在能力等級 2 或 3，對 CL4、CL5 的實務經驗相對有限。第三版 Guidelines 因此新增專章，解釋量化管理及流程最佳化的基本邏輯。 CL4 的核心，是從企業目標導出資訊需求與量測指標，建立合理的控制界限，持續蒐集各流程實例的資料，並識別個別專案中的特殊原因變異。 CL5 則進一步觀察不同流程實例間的共同原因變異，改善組織標準流程，並確認改善是否真正降低變異。 這裡有一個重要前提：CL4 必須建立在穩定的 CL3 之上。
如果不同專案使用的流程定義、資料口徑及量測方式都不一致，即使企業擁有大量儀表板，也很難進行有意義的跨專案比較。資料很多，不代表已經具備量化流程管理能力。 新版並未強制每家公司追求 CL4 或 CL5，也沒有指定必須使用某一種統計。