AI 幫你寫程式，但從不檢查它引用的套件——軟體供應鏈的信任真空

凌晨三點，一位工程師讓 AI 助理裝了三個套件、改了五個檔案，程式跑起來了。但他不知道的是，助理挑選依賴套件時，看的從來不是下載量背後的維護狀態、簽章或發布歷史。一篇於 Hacker News 引發熱議的 arXiv 論文（https://arxiv.org/abs/2609.07754）直指:AI 編碼助理幾乎不檢查供應鏈信任訊號。對高度依賴開源生態的台灣軟體業，這不是學術題目，而是每天部署時都在累積的風險。

信任訊號是什麼？AI 為什麼視而不見

人類工程師挑套件時有一套直覺:看維護者活躍度、看 issue 回應、看有沒有被接管過。這些「信任訊號」散落在 npm、PyPI、GitHub 等平台，格式不統一、多半不可機器讀取。AI 助理的訓練資料來自網路文字與既有程式碼，它學到的是「大家怎麼寫」，而不是「這個套件可不可信」。模型生成推薦的速度是毫秒級，驗證機制卻根本不存在於推理流程裡。這是架構問題，不是提示詞能修的。

硬體圈同月上演同一齣戲

時間點微妙。就在論文討論延燒的隔天，Reddit 的 ESP32 社群出現一則警告文，發文者宣稱 Waveshare 把未標示的 ESP32-P4 Rev 1.3 預量產晶片流入供應鏈，經銷商也未把關（https://www.reddit.com/r/esp32/comments/1wbkqnj/warning_waveshare_has_dumped_unlabelled/）。軟體與硬體、AI 與晶片，看似兩件事，實為同一個病:供應鏈的中間環節沒有誘因做驗證，而消費端（無論是工程師還是模型）預設信任眼前的一切。

對台灣的三層意義

第一層是台廠風險。台灣硬體代工與模組廠身處同一條鏈上，流出未標示版次的零組件若成為產業慣性，傷的是「台灣製造」整體信任。第二層是開發流程。台灣新創普遍擁抱 AI 編碼工具衝刺速度，但資安人力本就稀薄，驗證缺口只會放大。第三層是機會——供應鏈信任的機器可讀驗證（簽章、溯源、SBOM 整合進 AI 工具鏈）本身是門生意，而台灣在硬體溯源上有地利。

情境推演

樂觀情境:模型供應商把供應鏈驗證內建成為推薦流程的一部分，信任訊號成為新的競爭差異化。基準情境:工具鏈出現獨立驗證層，成本轉嫁給企業端，中小團隊暴露在風險中。悲觀情境:一次大規模的套件投毒事件透過 AI 助理的複製貼上效應擴散，才逼出改變。

這套分析可能錯在哪

發文者的 Waveshare 指控是單一社群討論的轉述，未經第三方證實；arXiv 論文的具體實驗細節也僅能從討論串側面理解。若模型供應商已在閉門修補此問題，產業風險時程可能比本文推估的更短。

下一個問題是:當你的程式碼有一半是 AI 寫的，資安事故的責任，該算誰的？