信任，但要查驗：AI 寫程式助手的稽核、可靠度與成本

🧭 本單元白話講

這門課的場景是：AI 助手不只幫你寫程式，還被請來當稽核員，替程式找漏洞、審查別人送來的修改。這個單元先看兩個實例，一個講「怎麼做」，一個講「值不值得」。第一個是 Cloudflare 公開的 Security-Audit-Skill，它是一套讓 AI 編碼代理化身資安稽核員的技能包事先寫好的一份工作說明書，AI 代理照著步驟去做某一類任務。它是 Cloudflare 內部漏洞獵殺系統的種子。那個系統後來長成跨多個程式庫、多階段的正式機制，公開的這一份則是它還只針對單一程式庫時的起點。

這套技能包把稽核拆成六個階段，每個階段都由彼此獨立的代理負責，沒有誰自己檢查自己。第一階段是偵查：先畫出系統的架構、信任邊界程式裡「可信的內部」和「不可信的外部輸入」交界的地方，攻擊常從這裡下手、外界資料進來的入口，以及過去留下的證據，寫進 architecture.md 和 coverage-ledger.json。第二階段是以覆蓋為導向的搜尋：照著覆蓋台帳一張記錄「哪些程式區塊已經查過、查了什麼」的清單，用來避免漏看，把一格一格的工作分給互相隔離的獵人代理，各自記錄檢查過什麼，再由「覆蓋批評者」找出還沒查到的缺口。

接下來是查證。第三階段，每個不重複的候選弱點都交給一位全新的驗證者，它的任務是想辦法把這個弱點推翻。第四階段把結果分成三種結論，寫進 findings.json 並對照 report-schema.json 檢查格式。confirmed（已確認）代表有完整的來源追蹤與可觀察到的具體結果。needs_validation（待驗證）代表還有一個明確沒解決的事實，所以不給嚴重程度。rejected（已駁回）則記錄被推翻的候選。老實標出「還不確定」，本身就是這套設計的一部分。

第五階段，全新的代理會再核對最終寫下的原始碼說法，如果有實質更換，還會有另一位獨立驗證者複查。第六階段才從這些查證過的紀錄，加上覆蓋台帳，產出 REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md 三份文件。主控的父代理另外會跑 validate-coverage-ledger.cjs 和 validate-findings.cjs 兩支檢查程式，確認台帳與結論的格式沒有壞掉。同一個程式庫重複跑也是累加的：後面的執行會利用前次的台帳與發現去補缺口，並重新驗證有改動的原始碼，過期或未解決的工作不會被當成「已涵蓋」。

第二個實例回答另一個問題：審查程式修改時，便宜的 AI 模型夠不夠用？Entelligence 拿 50 個公開的評測用 PRpull request，工程師把改好的程式提交給團隊審閱的申請，通過後才會併入正式程式 來測，分別來自 Cal.com、Sentry、Discourse、Keycloak、Grafana，各 10 個，每個都在乾淨的基底上被埋入缺陷。便宜的 GPT-5.6 Luna 與昂貴的 GPT-6 Astra 拿到同樣的提示、同樣的程式差異。價格差在 tokenAI 計費與處理文字的最小單位，可粗略想成一小段字詞：Luna 每百萬個輸入 0.20 美元、輸出 1.20 美元，Astra 則是 10 美元與 50 美元。換算下來，單次審查是 0.0041 美元對 0.113 美元，差 28 倍。怎麼判斷抓到的是真 bug？每個 PR 的所有發現匿名混在一起，由 Astra 與 Sol 兩個模型法官各自判斷，兩位都認定是真 bug 才算通過。兩位對 91% 的發現看法一致，最後有 143 個不同的 bug 通過。作者也坦白，Astra 同時是法官之一，可能略微偏袒自己。

結果是：Luna 抓到 69 個已驗證的 bug，Astra 抓到 92 個。也就是 Luna 花了 Astra 3.6% 的錢（0.20 美元對 5.66 美元），拿到 75% 的成績，而每個已驗證 bug 的成本，Astra 貴了 20 倍。代價在可信度：Luna 提出的 93 個發現裡有 24 個查無此事，Astra 的 96 個只有 4 個，換成精確率AI 說「這是 bug」的那些發現中，真的是 bug 的比例就是 74% 對 96%。更關鍵的是資安：24 個資安 bug 裡，Luna 抓到 9 個，Astra 抓到 19 個。所以作者的結論是：這個價位的 Luna 抓日常的正確性 bug 夠用，但不會讓它單獨審查登入驗證或權限相關的程式碼。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元說到，AI 助手上工後，你的角色從寫程式的人變成稽核員。稽核的第一站不是 AI 寫出來的程式，而是這個工具本身：它在你的電腦上做了什麼，又把什麼帶去了哪裡。本課的案例是智譜推出的 AI 寫程式桌面軟體 ZCode。有位使用者原本只是想清出硬碟空間，卻發現 ZCode 存放自己資料的根資料夾 ~/.zcode 佔了 700MB 以上。他斷斷續續追查，最後得到一個連他自己都吃驚的結論。

作者確認的是：只要你處於登入狀態，ZCode 就會把整個工作區（你正在做的專案資料夾）打包，連同完整的 Git 歷史Git 是記錄程式每次修改的系統，歷史就是每一版怎麼改、改了什麼的完整紀錄、大型素材檔的快取、Git 的操作流水帳和全域設定，加密後直接送到阿里雲的 OSS阿里雲的雲端檔案儲存服務，可以想成網路上的大倉庫。打包時會排除 node_modules 等依賴。以作者的例子來說，整個專案倉庫有 10GB，扣掉依賴後剩下 345MB。他形容這 345MB 幾乎全是核心智慧財產，而且是他正在開發的商業專案。

這件事最值得停下來想的是加密的設計。用來加密的 RSA 公鑰一對配對鑰匙中只能上鎖的那一把；配對的私鑰才能開鎖，是伺服器在每次上傳時當場發給客戶端的，而對應的私鑰只放在雲端。結果是：躺在你自己硬碟裡那份幾百 MB 的密文，你解不開，連 ZCode 客戶端自己也解不開。換句話說，你手上有這個檔案，卻沒有任何辦法自己驗證裡面到底裝了什麼。

這份調查給稽核員的示範，是從一個不合理的數字開始追。作者先比較資料夾大小，鎖定 v2/checkpoints/，裡面有一個 313MB 的 .enc 檔，旁邊有一份狀態檔（見下方逐行導讀）。日誌裡卻沒有任何明確的上傳網址，於是他拆開客戶端的 app.asar桌面軟體把自己的程式碼打包成的一個檔案，拆開後就能看到它實際會連去哪些網址、做哪些事，還原出完整的上傳流程（見流程圖）。要注意的是，這一份 313MB 剛好因為失敗 564 次而卡在待上傳資料夾，但整套上傳流程是作者從程式本體還原出來的。

至於怎麼關掉：作者在文中提供了一行就能永久關閉這個上傳的防禦作法，但本課取得的素材節錄，剛好在講到上傳細節時中斷，看不到那行指令。本課不自行編造指令，請直接讀原文：https://blog.ferstar.org/en/posts/zcode-silent-workspace-snapshot-upload/ 。另外，這是單一使用者的調查紀錄，不是廠商的說明。比較穩妥的態度，是把它當成「值得在自己電腦上照著查一遍」的線索，而不是定論。

⚙️ 脈絡拆解

🔍 程式碼漫遊（點有 ● 的行看白話講解）

這是作者在 ~/.zcode/v2/checkpoints/ 裡發現的狀態檔（節錄關鍵欄位，省略最外層大括號）。逐行讀一遍，就能看出軟體在背景做了什麼。

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

上一單元我們查了「你的程式碼被帶去哪裡」，這一單元要接著問兩件更日常的事：AI 助手做事穩不穩？替 AI 打分數的評審準不準？這兩道檢查有個共通的陷阱：一個好看的數字，背後常藏著沒說出口的假設。

先看穩不穩。IBM Research 團隊的文章，拿一個以 GPT-4.1 驅動的代理程式能自己一步步規劃、操作工具去完成任務的 AI，而不只是回答問題，在 AppWorld 的測試任務上把每個任務重複跑五次。平均成功率是 77.4%，看起來相當強。但如果只數「同一個任務五次全部成功」的比例，只剩 53.0%，整整少了 24.4 個百分點。文章把這個差距叫作「一致性落差」，在比較難的任務上，落差甚至達到 30 個百分點。

這個落差為什麼重要？文章舉的例子是核對一筆金融交易，或檢查合約裡有沒有某項義務。今天做對了，不代表明天同樣的請求也會做對，這在正式使用時就是可靠度問題。多數排行榜報的是 Mean@k把同一批任務跑 k 次，把每次的通過率取平均，回答「這個 AI 平均有多好」，也就是 77.4% 那個數字。使用者真正在意的卻是 Pass^k同一個任務跑 k 次，每一次都成功才算通過的比例，回答「再問一次還會一樣好嗎」，也就是 53.0% 那個數字。

好消息是，這個落差可以量測，也可以改善。團隊做了一個診斷工具叫 Consistency Analyzer：只拿代理程式自己留下的一份操作紀錄，在每個決策點一次要求 k 個可能的做法（預設 k=5），找出「差一點就會做出不同選擇」的容易翻轉的決策點。它只需要一份紀錄，不需要標準答案，也不必把整個任務重跑一遍。再把診斷結果整理成指引後，落差從 24.4 個百分點縮到 12.0 個百分點（同任務的 Pass⁵ 提高 16.0 點，相似任務提高 13.0 點），而且平均準確度沒有因此下降。

再看評分準不準。現在很常見的做法，是請 LLM 評審讓一個大型語言模型扮演裁判，替 AI 的輸出打分數或判斷對錯 來評測。Amazon Science 的文章舉了一個例子：一套系統會先檢索一段文字再回答問題，要判斷抓回來的段落和問題相不相關。請十位評審模型判斷，八位說「相關」，兩位說「不相關」。八比二看起來很有說服力，但關鍵不只是幾票，而是這些評審有多獨立地得出同一個結論。如果它們共用同一份提示詞範本、訓練血統相近、屬於同一個模型家族，或有相同的盲點，八票可能只是同一個錯誤重複了八次，這就是 假共識看起來很多評審同意，其實只是想法太像的評審在重複同一個判斷，並不是八份獨立的證據。

多數決，以及「依歷史準確度加權」的多數決，都是常見的基準做法，但兩者都默認評審犯錯是各自獨立的。這篇論文（發表於 ICML）改用 Ising 模型一種統計模型，能描述一群「是／否」變數之間兩兩互相牽動的關係，把評審團看成一張網路：每位評審有自己的可靠度，評審之間也有「太像」或「互補」的關係。方法同時學這兩件事，再據此調整總分。它不需要人類標好的答案就能學習，在三個任務上，比最強的基準（依歷史準確度加權的評審團）在標準指標上高出 9% 到 14%。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

🧭 本單元白話講

前面兩單元我們查了程式碼被帶去哪、結果穩不穩、評分準不準；這一單元要把這些檢查變成決策：錢花在哪、哪些關卡不能省。先看價差。同樣審查 50 個真實的 PR工程師把改好的程式碼交給團隊檢查、申請合併的一份提案，便宜的 GPT-5.6 Luna 每次審查約 $0.0041，貴的 GPT-6 Astra 約 $0.113，差了 28 倍。50 個全部跑完，Luna 總共只花 $0.20，Astra 花 $5.66。

便宜的代價在哪？Luna 找到 69 個經過驗證的真 bug，Astra 找到 92 個。Luna 抓到 Astra 約 75% 的量，卻只花 3.6% 的錢。換算成每個真 bug，Luna 約 $0.0030，Astra 約 $0.061，貴了 20 倍。有一點反直覺：Luna 每次審查輸出 2,104 個 token模型計費的文字單位，大約是一小段字詞，是 Astra（688 個）的 3.1 倍，總價仍然比較低，因為它的輸出單價低了約 42 倍。代價出現在可信度：Luna 提出的 93 項發現中有 24 項驗證不過，Astra 是 96 項只有 4 項不過，用 精確率模型提出的問題裡，真的是 bug 的比例 來看就是 74% 對 96%。白話講，便宜模型會多喊一些「狼來了」，這些假警報最後要靠人花時間挑掉，這筆時間成本不在價目表裡。

最需要留意的是資安。資料集裡有 24 個安全性 bug，Luna 只抓到 9 個（不到四成），Astra 抓到 19 個（約八成）。所以文章作者的結論很具體：Luna 處理日常的正確性 bug 夠用，但登入驗證、權限控制這類程式碼，他們不會讓它獨自審查。依這個結論，可以畫出一條分工線：一般程式碼由便宜模型先全面掃過，碰到驗證與權限就升級處理。

那全部交給貴模型就能放心嗎？也不能。Astra 在 24 個資安 bug 中仍漏掉 5 個。另外，這場比較裡判定「是不是真 bug」的兩位評審之一就是 Astra 自己，作者也承認這可能略微偏袒它，這正是上一單元「評分準不準」的實戰版本。以素材的數字推論，安全性相關的最後一關必須留給人：貴模型只是把漏網率壓低，不是降到零。

另一條線是模型本身越跑越省。三元模型每個權重只能是 -1、0、+1 三種值的語言模型的每個 權重模型內部用來存放學到知識的數字 只有三種值，業界常見做法是五個值塞進一個位元組，平均每個權重占 1.625 位元電腦儲存的最小單位，一個位元只能是 0 或 1。研究者量了 29 個三元模型，發現零最多佔到 51.5%，於是設計 BITCOS：先用一張 位元圖用 0 和 1 標記每個位置「有」或「沒有」的清單 標出哪些權重非零，再只替非零的權重存正負號，平均每個權重花 2 - z 位元（z 是零的比例）。結果 29 個模型中有 26 個比五合一更省，最稀疏的降到 1.485 位元。依公式推算，零的比例只要超過 37.5%，2 - z 就會低於 1.625。速度方面，核心運算最多快 1.28 倍；實際跑整個模型時，CPU 每秒吐字最多快 1.18 倍，GPU 最多快 1.27 倍。

所以壓縮技術怎麼讓便宜模型「越來越夠用」？誠實的答案是：它降的是跑模型的成本與時間，不是判斷力。論文沒有測程式碼審查的品質，素材也沒說 Luna 是三元模型。1.27 倍的加速，跟 Luna 與 Astra 的 28 倍價差比起來很小；但方向很明確：同樣的硬體能更省、更快地跑模型，便宜這一端的可用範圍會慢慢擴大。實務上不要等壓縮技術來替你決定，用自己的 PR 抽樣重新量：便宜模型抓得到什麼、漏了什麼，再決定哪些關卡升級、哪些留給人。

⚙️ 脈絡拆解

📝 隨堂考（點選答案，立即回饋）

✅ 離開前自測（全勾＝這課真的學會了）