Cloudflare 揭露 AI 程式碼審查可被騙
Cloudflare 測試 7 個 AI 模型後發現，隱藏註解可讓程式碼審查誤判，大片檔案的偵測率甚至掉到 12%。
Cloudflare 發現，AI 程式碼審查會被隱藏註解誤導，大片檔案時偵測率還會掉到 12%。
說真的，這結果有點刺眼。Cloudflare 這次測了 7 個模型，總共跑了 18,400 次 API 呼叫。Cloudforce One 的研究顯示，AI 不是看不懂程式碼，而是太容易被註解帶風向。
更麻煩的是，這不是傳統 jailbreak。攻擊者不用拆模型，也不用塞一堆亂碼。只要把話藏進原始碼註解，AI 就可能把危險程式碼判成安全。
| 指標 | 結果 |
|---|---|
| 測試模型數 | 7 |
| API 呼叫次數 | 18,400 |
| 惡意或濫用 Workers 腳本 | 100 |
| 基準偵測率 | 67.3% |
| 繞過區偵測率 | 53.3% |
| 註解比例超過 25% | 97.9% |
| 註解比例超過 50% | 98.9% |
| 檔案大於 3MB | 12% 到 18% |
Cloudflare 測了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這份研究鎖定 Cloudflare Workers 腳本。團隊拿 100 份惡意或濫用腳本來測，看看 AI 會不會被內嵌註解帶歪。
重點在於，攻擊者不需要真的破解模型。只要在註解裡塞暗示，例如說這段程式很正常、很安全、很合法，AI 就可能偏向放行。
這種攻擊很像在跟審查員聊天。問題是，審查員是 LLM，不是人。它會把自然語言和程式邏輯混在一起看，這就給了攻擊者可乘之機。
- 測試涵蓋 7 個模型。
- 總共做了 18,400 次 API 呼叫。
- 低註解量時，偵測率掉到 53.3%。
- 3MB 以上的大檔，偵測率只剩 12% 到 18%。
為什麼繞過區很要命
Cloudflare 把註解比例低於 1% 的情況，稱作繞過區。這裡最危險。因為看起來很正常，模型反而比較容易吞下去。
在這個區間，平均偵測率從 67.3% 掉到 53.3%。對安全流程來說，這不是小波動。這代表每 100 次判斷，可能多放掉 14 次。
有趣的是，註解不是越多越好。當註解超過檔案的 25%，偵測率反而升到 97.9%。超過 50% 時，更到 98.9%。模型開始覺得太吵，直接提高警戒。
“The fact that detection accuracy plummets to 12% when payloads are buried in large library bundles suggests that adversaries no longer need to convince the AI that their code is safe-they only need to make the malicious signal too small for the AI to find.”
這句話很直白。攻擊者不用說服 AI，相反地，只要把惡意訊號藏到它找不到就好。
這也解釋了為什麼很多 AI 安全流程會翻車。模型不是每次都被騙，但只要漏掉幾次，就足夠讓風險進 production。
檔案大小比措辭更兇
這次研究最狠的變數，不是註解內容，而是檔案大小。500KB 以下的 Workers，偵測率幾乎維持在 100%。
但一旦檔案大於 3MB，偵測率就掉到 12% 到 18%。就算惡意邏輯還在 context window 裡，模型也很難把重點抓出來。
Cloudflare 提到，這種情況常出現在大型 bundle。像 React SDK，或 TON 元件，都可能把真正的風險包在一堆合法程式碼裡。
- 500KB 以下，偵測率接近 100%。
- 3MB 以上，偵測率只剩 12% 到 18%。
- 有些 frontier model 會直接輸出亂掉的結果。
- 一個非 frontier model 在 1,000 個註解時達到 91% 偵測率。
講白了，這不是單純的文字陷阱，而是結構問題。你把整包大檔丟給 AI，它就很容易看漏。
這也提醒開發團隊，AI 審查不能只看「有沒有讀到檔案」。真正該問的是，它有沒有抓到最危險的那一段。
不同模型，反應差很多
Cloudflare 的測試顯示，模型差異很大。有一個非 frontier model，在只加 20 個註解後，偵測率就從 90% 掉到 67%。
另一個模型在中等和極端註解量下，幾乎沒什麼變化。還有一個模型，反而因為重複內容變多而更警覺，最後在 1,000 個註解時達到 91% 偵測率。
這代表不能只看「是不是 GPT」或「是不是大模型」。同樣是 LLM，對 prompt injection 的耐受度差很多。拿便宜、快的模型做自動初審，風險真的不小。
- 有些模型在 20 個註解後就明顯退化。
- 有些模型對重複內容比較敏感。
- frontier model 較穩，但不是無敵。
- 低成本模型可能放大攻擊面。
我覺得這裡最現實的問題是成本。很多團隊想省錢，就把 AI 審查當第一道門。
但如果第一道門本身會被註解騙過，那省下來的錢，最後可能變成資安事故的成本。
語言偏誤也會出事
Cloudflare 還看到另一個麻煩：語言偏誤。某些模型看到俄文、中文或阿拉伯文註解時，會把風險分數拉高。
相反地，有些模型對愛沙尼亞文註解比較信任。這表示模型可能學到語言捷徑，而不是看懂程式本身。
這很危險。因為攻擊者可以測哪種語言最容易過關，再把註解改成那種語言。這不是語言學問題，是安全問題。
Cloudflare 也提到，他們在 Cloudforce One 監控 Workers 濫用時，看到不少 VPN 和 proxy tunnelling 腳本，還用了 VLESS 協定。
團隊把註解插在 statement 邊界，不是只塞在檔案開頭。這點很重要，因為它更接近真實攻擊手法。攻擊者不會只做最簡單版本。
跟其他 AI 安全問題比，這次哪裡特別
很多人談 prompt injection，只想到聊天機器人。可是在 code review 場景，風險更直接。因為結果不是「答錯一句話」，而是「把惡意程式放進去」。
這和一般 static analysis 也不同。傳統工具看的是語法、規則、行為特徵。AI 則會讀自然語言註解，這讓攻擊面變大。
如果拿這次結果跟其他工具比，差異很明顯。規則式掃描器不太會被註解騙。AI 審查器則可能因為上下文太長、註解太多，直接失焦。
- 傳統掃描器較少吃自然語言陷阱。
- AI 審查器會讀註解，也會被註解影響。
- 大檔案對 AI 的傷害特別大。
- 多模型串接，會比單一模型更穩。
所以問題不是要不要用 AI。問題是，你把它放在哪一層。
把 AI 當唯一裁判，風險太高。把它當輔助訊號，才比較合理。
接下來該怎麼做
最實際的做法很簡單。先把註解和功能碼分開看。再把大檔拆小，不要一次丟整包 bundle 給模型。
還要縮小 prompt 範圍。不要問「這段安不安全」。改問「這段有沒有符合某種惡意模式」。問題越窄，模型越不容易被帶偏。
另外，AI 審查不要單獨上線。最好搭配 static analysis、sandbox、人工複核。尤其是超過 3MB 的檔案，真的別只靠一個模型拍板。
我覺得這篇研究最有價值的地方，不是告訴你 AI 很爛。它是在提醒大家，AI 審查要先學會忽略雜訊。否則，攻擊者只要在註解裡多講幾句話，就可能把結果改掉。
如果你的團隊已經在用 AI 做 code review，下一步不是換更大的模型。先檢查流程有沒有把大檔、註解和風險訊號拆開。這比追新模型實際多了。