AI Coding 論文閱讀分析：模型最危險的，不一定是不懂安全，而是最後一刻把安全讓給了格式與方便

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Surgical Repair of Insecure Code Generation in LLMs
• 副標：From Mechanistic Diagnosis to Deployment-Ready Intervention
• 作者：Gustavo A. Sandoval、Brendan Dolan-Gavitt、Siddharth Garg
• 年份：2026
• 來源：arXiv:2604.16697
• 論文連結：https://arxiv.org/abs/2604.16697
• DOI：10.48550/arXiv.2604.16697
• 主題：AI Coding Security、Mechanistic Interpretability、Secure Code Generation、Activation Steering、LLM Safety、AppSec

這篇 Surgical Repair of Insecure Code Generation in LLMs 最值得看的地方，不是它又證明一次「LLM 會寫出有漏洞的程式」，而是它把問題往前推了一步：很多時候模型不是不懂安全，而是明明知道正確答案，到了真正要寫 code 的那一刻，卻被格式要求、任務完成壓力與表面可用性擠掉了。

作者把這個現象叫做 Format-Reliability Gap。意思是：同一個模型在 code review 情境下，能指出 sprintf 會造成 buffer overflow，也知道應該改用 snprintf；但一旦你叫它直接產生程式碼，而且 prompt 又順手加了「快速一點」「簡單一點」「只輸出函式本體」這類格式與產出限制，它就很容易重新生成那個自己剛剛才說危險的實作。

這個 framing 很重要，因為它把 AI coding 的失敗從「知識不足」改寫成推理與生成階段的優先序錯置。這和很多團隊的直覺不太一樣。大家常以為模型產生不安全 code，是因為它沒學會 secure coding；但這篇論文在說的其實是：模型可能早就學會了，只是安全訊號在生成流程裡輸給了更強的格式服從需求。

這篇在挑戰什麼老假設？

AI coding 安全討論裡有一個很常見的預設：如果模型會寫出漏洞，那就代表它安全知識還不夠，所以解法大概是再 fine-tune、再補資料、再做更多 secure coding 訓練。

這篇論文直接反駁這個假設。作者先做了一個很直白的對照：在 code review 問題裡，模型對多種常見漏洞其實辨識得不差，甚至可以清楚說出問題與修法；但換成 code generation 任務後，安全表現明顯掉下去，尤其在 buffer overflow、memory safety、SQL injection 這類類型上，review 能看懂，不代表 generation 會照做。

也就是說，失敗不是發生在「知不知道」，而是發生在「要不要把知道的東西真的帶進輸出」。

這點很貼近實務。真實開發流程裡，工程師給模型的 prompt 很少是純理想化安全題，通常會混著一堆別的要求：

• 介面要長怎樣
• 回傳格式要固定
• 要跟既有 API 對齊
• 要短、快、可直接貼進專案
• 甚至會加上「先求能跑」這類潛台詞

當這些要求一起上來時，模型未必會把安全放在最高優先。論文的關鍵提醒就是：不安全輸出很多時候不是因為模型被惡意攻擊，而是因為正常產品流程本來就在不斷獎勵格式服從與快速交付。

Format-Reliability Gap 到底是什麼？

作者用一個很典型的例子說明這件事。對 Llama-3.1-8B-Instruct 而言：

• 當你問它 sprintf 和 snprintf 的差異，它多半知道前者危險、後者有 bounds checking。
• 當你丟一段使用 sprintf 的 C 程式請它 review，它常能點出 buffer overflow 風險，還會建議修法。
• 但當你改成「幫我寫一個格式化 log 的 C 函式，快一點，只輸出實作」之類的 code generation prompt，它卻又很容易自己寫回 sprintf。

這不是單點 anomaly，而是作者跨多種 CWE、跨多個模型家族都看到的模式。論文把漏洞大致分成三層：

• 完整知識但生成失手：像 CWE-787、CWE-119、CWE-89，review 幾乎懂，但 generation 仍大幅退步。
• 部分理解、部分失手：像 command injection、XSS，review 也不是全懂，但 generation 一樣不可靠。
• 只看出語法怪、沒真正理解安全語義：像某些格式字串類型，連 review 的安全理解都偏弱，因此 gap 反而較小。

這個結果的含義很尖銳：我們不能再把 code review 能力直接當成 secure generation 能力的代理指標。 模型能解釋漏洞，並不代表它在真實寫 code 時會自動遵守那些原則。

作者怎麼證明這不是單純資料不足？

如果只是一般行為實驗，很多人還是會說：也許模型只是背答案、或是某些 prompt 恰好比較容易。但這篇論文野心更大，它直接往 mechanistic interpretability 走，試著找出安全表徵到底在模型裡怎麼流動。

作者的核心發現是：安全相關表徵其實從很早的 layer 就已經存在，但在大多數中間層都處於「知道歸知道，還沒真的影響下一個 token」的狀態；直到最後一層附近，這些表徵才突然對輸出變得有決定性。

論文把這個現象稱為 hierarchical convergence。白話一點講，就是：

• 模型早期就把安全訊號編進去了；
• 但這些訊號一路上都沒有真正贏過其他生成需求；
• 到了接近輸出的最後階段，安全與格式服從才正面衝突；
• 而在這個節點，格式要求常常把安全壓掉。

作者還用 token-level ablation 去驗證，發現那些看似無害的格式指令，真的會在因果上壓抑安全計算。這就是為什麼論文不是在講「模型不知道」，而是在講模型的安全計算被別的需求蓋過去。

為什麼這個機制發現很重要？

因為它直接決定你應該怎麼修。

如果問題本質是知識不足，那合理解法是補訓練資料、微調模型、或持續灌更多 secure coding corpus。但如果問題其實是最後輸出階段的競爭機制，那再多資料也不一定打中病灶，甚至可能付出很高代價，例如：

• fine-tune 造成其他能力退化
• 安全 alignment 被後續調整洗掉
• 每次修一類漏洞都要重訓整個模型
• 很難清楚解釋修正到底在什麼地方生效

這篇論文想做的，就是把修補從大手術改成局部外科。既然問題集中在特定 layer 的最後競爭點，那就不要每次都重訓整個模型，而是直接在那個點做 activation steering。

所謂 Surgical Repair 是怎麼做的？

作者的方法很俐落：針對不同 CWE 類型，學出對應的 steering vector，然後在推論時把這個向量加到特定 layer 的 hidden states 上，讓模型在關鍵時刻把生成方向推回更安全的 API 或實作。

這個做法有幾個很值得注意的地方：

• 它是 per-vulnerability 的。 不是拿一個通用安全向量硬打天下，而是針對不同漏洞各自學自己的修補方向。
• 它是 inference-time intervention。 不需要重訓整個 base model，也不需要重新部署一個新模型家族。
• 它有機制上的對應點。 不是純黑箱調參，而是建立在前面 mechanistic diagnosis 找到的 suppression layer 上。

成效也不差。論文裡在 CWE-787 的 held-out scenario 上，per-CWE steering vector 讓 secure generation 顯著上升，對不安全輸出的抑制可達到 74% 左右。更關鍵的是，作者強調統一型向量的效果明顯比不上 per-CWE 向量，代表不同漏洞類型在模型內部雖然都屬於「安全」問題，但其實並不是同一個可互換表徵。

這件事很值得記。它意味著未來如果你想做 deployment-grade 的安全修補，可能不能只靠一個很抽象的「安全模式」，而要承認不同風險類型在模型裡本來就是不同路徑。

作者還補上了真正可部署的一層

如果只有 steering vector，大家第一個疑問通常會是：那系統怎麼知道現在該打哪一個向量？總不能每個 prompt 都人工分類。

所以作者再往前做了一步：用 probe-gated routing 先在較早 layer 判斷 prompt 比較像哪一種漏洞風險，再自動選對應的 per-CWE vector。這讓整個方案不只是研究玩具，而比較像一個可部署的安全 middleware。

論文聲稱這套路由在 prompt 分類上有不錯的準確率，而且整體 latency overhead 很低，約在幾個百分點內。這對實務很重要，因為太多 AI safety 方案最後不是沒效果，而是有效但太重，重到產品團隊根本不會上線。

這篇最討喜的地方就在這裡：它沒有停在「我們找到一個有趣的內部機制」，而是一路把這個發現推向 deployment viability。

這篇對 AI coding 團隊真正有什麼啟發？

我覺得至少有四個。

• 第一，code review 能力不能拿來替代 secure generation 評估。 模型會講安全，不代表它在交付程式碼時會照做。
• 第二，prompt 裡的格式與效率要求本身就是安全變數。 「簡潔一點」「快一點」「只給可執行版本」這些看似中性的要求，都可能把模型往危險實作推。
• 第三，修補不一定只能靠 retraining。 如果失敗集中在特定計算節點，局部 steering 可能比全面微調更便宜、更可控。
• 第四，安全防線應該前移到生成時，而不是只靠生成後掃描。 論文也提到，像 CodeQL 這類工具在不完整 snippet 上常常受限；等 code 產生完再掃，很多風險其實已經進到 workflow 裡了。

對企業來說，這裡最現實的 takeaway 是：如果你把 LLM 當成 production coding pipeline 的一部分，真正該監控的不是它答不答得出 secure coding quiz，而是它在壓力下最後交付什麼。

這篇也有它的邊界

當然，這篇不是萬能解藥。它目前聚焦的是特定 CWE 與特定模型家族，主要討論的是 code generation 階段的漏洞偏移，而不是整個軟體生命週期中的所有安全風險。像是：

• 商業 closed model 能不能同樣精準插入 steering？
• 更多語言、框架與大型專案上下文裡效果會不會下降？
• 如果 prompt 本身混雜多個風險型態，routing 會不會變得困難？
• 面對新型漏洞或 domain-specific secure coding 規範時，要不要重新學新的向量？

但我認為這些都不減損它的價值。因為它至少很清楚地做對了一件事：它把「模型為什麼明明知道卻還是做錯」這個問題，從模糊抱怨變成可以被定位、被干預、被工程化的機制問題。

我的看法：這篇真正修的不是模型知識，而是組織對失敗位置的誤判

我最喜歡這篇的地方，是它其實也順手修正了我們對 AI coding 風險位置的想像。很多團隊把風險放在 training data、alignment、或外部 jailbreak；但這篇提醒你，真正讓不安全 code 落地的，也可能只是最後那一小段輸出競爭邏輯。

這種觀點很有用，因為它讓安全團隊有機會把防禦策略設計得更細：不是所有問題都要靠重訓，不是所有錯誤都代表模型完全不懂，也不是所有 mitigation 都非得是笨重的 post-hoc scanning。

換句話說，這篇 paper 最有價值的，可能不是那個 74% 的數字，而是它把 AI coding 安全帶進一種更成熟的工程視角：先找出失敗實際發生在哪裡，再針對那個位置做最小但有效的修補。

總結

Surgical Repair of Insecure Code Generation in LLMs 真正重要的，不只是它提出 activation steering 這個補丁，而是它很有力地說明：LLM 生成不安全程式碼，很多時候不是不懂，而是在最後輸出時把安全讓位給了格式服從與任務完成。

作者用 mechanistic analysis 把這個失敗定位到特定 layer 的競爭節點，再用 per-CWE steering vectors 做局部修補，最後還補上 probe-gated routing，讓整件事開始有 deployment 的味道。這比單純再喊一次「模型要更安全」有用得多。

如果你正在評估 AI coding、secure-by-default 開發流程，或想降低 LLM 產生漏洞程式碼的機率，這篇很值得讀。因為它講的不是抽象口號，而是一個很具體也很不舒服的現實：模型常常知道什麼是安全，但真正決定風險的，是它最後到底選了哪個 token。

一句話總結這篇：真正麻煩的，不是模型完全不懂 secure coding，而是它常常在最後一刻把安全讓給了格式、方便與完成任務的衝動。