我們用什麼方法檢視，結果有多可信

我們請 AI 把整套系統的程式碼一行一行讀過去，像找碴一樣挑出可疑的地方；每挑出一個疑點，再另外找三個獨立的 AI 重查一遍投票表決；最後由人親自把每一條打開來確認。

為什麼要這麼麻煩？ 因為資安問題分兩種：

這次要找的是第二種。代價是慢、貴，而且不能保證每個角落都看過——這一點我們在最後一節老實交代。

第 1 步：先自己看過，圈出最可疑的地方

負責主導的人（下面稱統籌者，也是最後為結論負責的那個人）會先自己把這批程式讀一遍，圈出「最可能出事的五到八個地方」，寫成一份工作單。

這一步是刻意的——如果不先圈，AI 會漫無目的地找；圈了之後，等於先告訴它「這幾個地方我特別懷疑，你去驗給我看」。

第 2 步：交給一個人負責執行

這個人開一個獨立的環境準備動工。他不負責按下開始鍵——他只先核對「要查的東西數量對不對」，對完就停下來回報。

第 3 步：由人親手下令開始

第 4 步：找出疑點

AI 把這批程式從頭讀到尾，挑出它覺得可疑的地方。

它的標準偏嚴——要能講得出「壞人具體要怎麼做才能得手」才會提出來。所以它比較容易漏掉，不太會亂報；報出來的通常都是真的。

第 5 步：每個疑點，再找三個人重查一遍

找出疑點的那一個，不能自己說了算。

每一個疑點，都會另外找三位重新查證——他們彼此不認識、也看不到前一位的推理過程，各自從頭把相關的程式看過一遍，再各自說「我認為這是真的問題」或「我認為不是」。

第 6 步：人親自核對每一條

AI 全部跑完之後，統籌者還要自己做三件事：

一次檢視通常要一到兩個小時，最久的一次跑了五個半小時。

我們不是「把整個系統丟進去查一次」，而是切成很多小批。這不是謹慎，是不分批根本跑不完。

分批的上限是怎麼訂出來的

現在的規矩是兩條，哪條先到就停：一批不超過 15 個檔案，而且不超過兩千行程式。

真正花錢的是「重查」，不是「找」

一般人會以為「讀程式找漏洞」最花資源。其實不是——最花的是重查投票：找出幾個疑點，就要另外找幾組三個人，每一位都得從頭把程式再讀一遍。

而疑點的數量大致跟範圍成正比。所以範圍放大一倍，成本不只放大一倍。

怎麼切也有講究

範圍跨兩個程式庫時，分兩次掃

有些功能的程式一半在外部模組、一半在我們主系統。工具一次只能看一個程式庫——範圍跨兩邊時，另一邊的檔案會被安靜地丟掉，不報錯、不提醒，看起來就像「那些檔案查完沒事」。

所以這種範圍一律配對切成兩次掃：模組那邊一次、主系統那邊一次，再由執行者手動核對兩邊接起來的地方（主系統傳了什麼給模組、模組回了什麼）。稽核輪次管理那塊九輪全部這樣做，其中一條問題（稽核計畫 Word 的壓縮炸彈）兩邊各自獨立掃到，正好互相印證。

「兩千行」只是粗略的尺

真正的判準是「要讀進去多少東西」。有一個兩千五百行的單一檔案順利跑完了，反而有一批一千五百行、但分散在五個檔案的連續失敗六次——因為要在五個檔案之間來回翻。

中文註解特別多的部分，同樣行數要消化的量是英文的兩三倍。

每跑完一次，工具會自動留下一張紀錄，寫著這次找出幾個疑點、投了幾票、以及有沒有完整跑完。

這張紀錄是我們判斷「這次結果能不能採信」的依據。

還有一個陷阱：一個疑點都沒找到的時候，紀錄上也會顯示「完整跑完」——那是「沒東西可投票」，不是「這裡很乾淨」。這種情況我們會另外標出來。

%%{init: {"theme":"base","themeVariables":{"background":"#ffffff","primaryColor":"#eef2ff","primaryTextColor":"#1e293b","primaryBorderColor":"#6366f1","lineColor":"#64748b","secondaryColor":"#f1f5f9","tertiaryColor":"#f8fafc","fontFamily":"ui-sans-serif, system-ui, sans-serif","fontSize":"14px"}}}%%
flowchart LR
  A["提出疑點<br/>（要說得出壞人怎麼得手）"] --> B{"三個人<br/>獨立重查投票"}
  B -->|"三票否決"| D["不列入<br/>但人仍會看一眼"]
  B -->|"通過"| C["人親自核對<br/>打開來看／挑掉不屬於這批的／重新評估嚴重度"]
  C --> E["列入問題總表<br/>一句白話結論"]

被否決的也要看一眼。 重查的人判斷「現在打不到」通常是對的，但他只回答了「現在打不打得到」，沒有回答「這段程式本身是不是寫錯了」。

有一次，一個被三票一致否決的疑點，統籌者核對後發現：他們說「打不到」完全正確，但漏看了同一段程式裡兩行用了不同的東西在比對——那是另一個問題，只是不會被壞人利用。

也有反過來往上調的：有一個問題，重查的人只敢說「中等把握」，因為卡在一件要查資料庫才知道的事。統籌者真的去查了，確認成立，把把握度提到「高」。

這一次（2026 年 9 月）

用的是 Claude Security——Claude Code 官方推出的資安檢視外掛，由 Anthropic 開發。

白話說，它做的事是：派出幾十個獨立的 AI 去讀程式碼，一部分負責找問題，一部分負責重查投票，跑完產出一份報告和一張「有沒有做完」的紀錄。

它是 Anthropic 另一項雲端服務的**「在自己電腦上跑」的版本**：同樣的檢視能力，但整個過程都在我們自己的環境裡完成，程式碼不會傳出去。

另外兩個設計，直接支撐了這份報告的可信度：

• 重查的人是被要求「去推翻它」的，不是去附和。官方的說法是：除非能確認真的有一條可以被利用的路徑，否則就判定為誤報。沒過關的連提都不會提——「這就是為什麼報告都很短」。
• 「查得夠不夠徹底」那個紀錄，是程式算出來的，不是 AI 自己說的。也就是說，AI 不能自己宣稱「我查得很徹底」。

上一次（2026 年 7 月）

那一次用的是三個性質完全不同的工具：

那一次的成果：後端高風險的零件漏洞從 15 個降到 0，前端從 83 降到 18。

兩次的差別（這點最重要）

四個固定的盲點

兩個要知道的行為

• 指定「只看這幾行」它做不到——每次都會把整個檔案讀完。同一個檔案分兩半查，第二次的結果幾乎跟第一次重疊。
• 它不一定會交代「每個檔案都讀完了」。有一次 33 個檔案查完，沒有留下「每一支都看到結論」的紀錄。

最大的一個坑：工具本身的軟體錯誤