Figma 讓 AI agent 審了一年程式碼：先修精準度，AI 才值得信任
上線第一週 27 個回報只有 4 個是真的。Figma 沒急著衝覆蓋率，先把精準度做對——順手把十年資安知識壓成 68 條判例，寫出一份比工具更值錢的威脅模型。
去年八月，Anthropic 放出一個能自動掃程式碼漏洞的審查工具，Figma 資安團隊當天就接上線。第一週的成績單很難看：系統回報了 27 個漏洞，只有 4 個是真的，命中率 15%。工程師被這種準確率洗版幾次，就再也不會點開它的留言。
Figma 的選擇有點反直覺。他們沒有先衝「能抓到多少漏洞」，而是先把「回報的東西有多少是真的」拉上來。這篇由三位資安工程師寫的復盤，記錄了一套 AI agent 怎麼從沒人信任的吵雜工具，長成每個 pull request 都得先過的關卡。真正值錢的東西在後頭：為了讓 agent 變準，他們被迫把公司十年的資安知識寫成一份文件，而那份文件本身，比工具更重要。
Figma 把「用 agent 對付漏洞」拆成三個階段：程式碼還在寫的時候就先防、每個 PR 送出時審一遍、對已經十年的 monorepo 做全面稽核。三個階段跑在同一套政策（policy）上。這篇大半篇幅落在中間那塊——PR 審查（review），因為它是最先做的，改進迴圈也最快，另外兩件事都是靠它先跑通才長出來的。
同一套政策同時管三件事：程式碼生成時，用 agent hook 在寫下危險寫法的當下就出手糾正；PR 審查時，讓 agent 讀 diff 找漏洞、直接留言給作者；稽核時，把 agent 指向整個十年的 monorepo，翻歷史留下的地雷。三個階段共用一份威脅模型，所以那份文件只要寫一次。
先看審查，因為它是整套系統的引擎——精準度、覆蓋率的訊號都從這裡冒出來，另外兩塊再拿去用。
審查之所以先做，是因為它的改進迴圈比生成和稽核都快，靠三個特性撐著：它是普遍的（universal）——每個 PR 都會過一遍；它是自助的（self-serve）——審查者留言，作者當場回應；它兩個方向都插了量測——精準度和覆蓋率各有各的訊號。
精準度的訊號來自作者本人：極少數被標出問題的 PR，作者按讚或倒讚，通常還附一句為什麼。覆蓋率則是拿「已知有 bug 的 commit」回放，數系統漏掉幾個。他們同時跑兩個模型——Claude Code 配 Opus 4.8 開到 xhigh、Codex 配 GPT-5.6 Sol 開 high——因為兩者漏的 bug 不一樣，只要有一個抓到就冒上來。成本低到不構成限制：每個 PR 審一次中位數約 0.5 美金，因為大多數 PR 根本沒東西可標。
2025 年八月，他們把 Anthropic 的 Claude Code Security Reviewer 上線，但先跑「影子模式」——回報只進 Slack 和 Datadog，不直接留在 PR 上。第一週 27 個回報只有 4 個成立，命中率 15%。這正是 OpenAI 那個論點背後的信任問題：一個工具老是丟出低品質回報，開發者很快就整個略過它。
所以精準度得先修，這個順序有點違反直覺。你會以為「已經找到過的舊 bug」是最大的起跑優勢，但那些 bug 拿來當 eval，只能量覆蓋率，對你最先需要的精準度一點忙都幫不上。團隊把門檻訂在兩週回看穩定過 70%、而且沒有丟臉的誤報，才把留言開給開發者看。為了達標，他們把審查器對前八週的 PR 全部回放，親手把誤報一個個標出來，再從中寫出 agent 該遵守的政策。
政策的寫法是這篇最值得設計人偷學的地方。他們刻意用「判例」（precedent）取代「規則」——判例是一個帶著情境的例子，說明某個回報在這個脈絡下為什麼成立或不成立。比起一條乾巴巴的規則，判例保留了 agent 推理時真正需要的那層脈絡。
舉例來說，他們不會寫「別在 dbops 標 SQL injection」這種硬規則，而是寫成「dbops 只有高權限操作者能執行，他們本來就有資料庫的直接存取權」。前者是命令，後者是理由——給了理由，模型才知道遇到相似但不完全一樣的情況該怎麼推。這跟你寫 prompt、寫設計規範是同一件事：把「為什麼」寫進去，對方（不管是 AI 還是隊友）才接得住你沒明說的那些狀況。
99 行、2560 字、68 個判例之後，這份工作長出一個沒人事先規畫的副作用：他們寫出了一份完整的威脅模型，而且大致就是你會希望新人第一天上工就讀的那種形式。原文用一句話收束：政策，就是威脅模型本身。
Agent 需要的資安脈絡，得是明確的、結構化的、而且解析度異常地高。Figma 十年下來，這些脈絡散在文件、事故檢討、還有一堆存在資深工程師腦袋裡的直覺，從沒被整理到 agent 讀得動的解析度。被 agent 逼著寫下來的這份文件，才是真正的回報——因為後面的安全程式碼生成、整個 repo 的稽核，都跑在同一份威脅模型上，他們再也不用把這件事做第二次。
到了 2025 年十二月，這套東西已經從原型變成基礎設施：PR 審查成了合併的必要條件，沒過審查就進不了主線。他們補上供應商故障切換、重試機制、Datadog 與 Slack 的遙測，還有修復率追蹤——因為最終目的是把漏洞修掉，讓它被看見只是第一步。同一時間他們也把系統重寫了三次：搬進獨立的 TypeScript 服務、把大半 prompt「消融」（ablate）掉、再加一個複審者（adjudicator）專門回頭看那些被第一輪講掉的邊緣案例，光這一步就把覆蓋率相對拉高了約三成。
最漂亮的實驗是這個：他們把整份 Figma 政策全部拿掉，只留「find vulnerabilities」加模型和工具，同一個審查器在高價值漏洞的加權評分上仍有 44.4%。把政策裝回去，同一個審查器爬到 64.2%。前沿模型光靠自己就能找到不少漏洞，但那份用判例堆出來的政策，實打實地把數字往上推了 20 個百分點。
這是他們自己摸出來、也最容易被忽略的一課：精準度和覆蓋率的來源完全不一樣。覆蓋率可以回放——拿你已經找到過的 bug 重跑，數漏抓幾個。他們有一套 66 個任務的語料庫，每個都是真的漏過人工審查、進到程式碼裡的漏洞，其中 46 個標記自 HackerOne 抓漏計畫（光是某一位頂尖研究者就貢獻了 24 個）。就算把這個難度拉滿的語料庫跑到 75.8% 的聯合命中率，那也只是「所有既有防線都漏掉的 bug」裡的 75.8%。
精準度沒有固定標的可以回放，而且每次改政策都會牽動它——你為了拉覆蓋率做的任何動作，都可能反過來影響精準度。真實的漏洞回報太稀有，要靠離線評估湊足夠的樣本，得把審查器跑過多到不可能人工檢查的 PR。所以精準度只能在 production 量：審查器本來就每個 PR 都跑，寫這段 code 的作者第一個判斷，另一個 agent 定期回頭重讀，還留著爭議的案子交給資安 on-call 拍板。
這是一篇資安工程的復盤，但它最能遷移的部分，跟資安沒什麼關係。真正的主線是：當你要把一件事交給 AI，你逼自己把腦袋裡的脈絡寫下來的那份文件，往往比 AI 這個工具本身更值錢。Figma 被 agent 逼著把十年資安知識壓成 68 條判例，順手就得到一份新人都讀得懂的威脅模型。
設計端有一模一樣的對應物。你命名清楚的圖層、拆得乾淨的 component、寫得明白的 variables 和 design token，就是你交給 AI（也交給接手的隊友）的高解析度脈絡。差別在於，大部分人是「先有需求才硬湊」，而這套做法告訴你：把脈絡整理到夠高的解析度，本身就是最保值的資產。收尾借原文一句話——他們的資安工程師，從一次修一個 bug，變成寫下那份能抓上百個、也防上百個的政策。工作本質沒變，只是槓桿變大了。
