「已通過審計」跟「審計沒發現任何問題」是同一件事嗎？
不是。「已通過審計」只代表項目委託了一家審計公司做過檢查並產出報告，report 裡完全可能列出多筆 Critical 或 High 等級的發現項目——重點在於這些發現項目後續有沒有被修復。一份列出 5 個 Critical、但全部標記 Fixed 並經過複審的報告，實際上比一份「零發現」但範圍極度狹窄的報告更值得信任，因為前者代表審計團隊真的深入挖過，後者可能只是審計範圍設得太保守，根本沒機會發現問題。
判斷審計品質，不能只看「有沒有通過」這個二元標籤，要看發現了什麼、以及後續怎麼處理。
為什麼同一份合約，不同審計公司給出的意見常常不一樣？
審計本質上是專業判斷，不是像單元測試那樣「跑過就是跑過」的機械式驗證。同一段程式碼，經驗豐富的審計員可能會特別留意某類邊界條件（例如重入攻擊、整數溢位），而不同背景的審計員關注重點也會不同——這也是為什麼規模較大的協議常常會找兩家甚至更多獨立審計公司分別審計，而不是只信任單一一份報告。
這不代表審計沒有價值，而是提醒讀者：一份審計報告代表的是「這個團隊、用這個方法、在這段時間內」的檢查結果，不是「這個合約絕對安全」的終極證明。
Bug Bounty（漏洞懸賞）跟審計報告是互相替代的關係嗎？
不是替代，是互補。審計是在有限時間內、由固定團隊集中檢查一次；Bug Bounty 則是把檢查範圍開放給更廣泛的白帽駭客社群，用獎金誘因換取持續性的、長時間的觀察。審計擅長找出結構性、系統性的設計缺陷，Bug Bounty 則常常抓到審計期間沒被觸發、需要特定鏈上狀態組合才會出現的邊緣案例。
一個成熟的項目通常會兩者並用：先用審計把明顯的結構問題排除，上線後持續開放 Bug Bounty 作為長期的第二道防線，而不是把審計當成唯一且一次性的安全檢查。
如果我不是技術背景，看不懂 Severity 分級的技術細節，還能怎麼判斷一份審計報告值不值得信任？
即使不看技術細節，也可以先看幾個結構性訊號：審計公司是不是業界有名的獨立機構（而不是項目自己成立的關聯公司）；報告是不是公開可查（藏起來不公開的審計，可信度本身就打折扣）；Critical/High 項目的修復狀態欄位是不是清楚標示，還是刻意含糊帶過；審計日期是不是明顯早於項目目前的程式碼版本。
這些不需要看懂 Solidity 也能判斷，而且往往比逐行檢查技術細節更能快速抓出一份審計報告是不是「做給人看的」還是「真的拿來用的」。
看到一個 DeFi 項目寫著「已通過審計」，多數人會直接把它當成安全的保證，但這個結論本身就跳過了最關鍵的一步——審計報告到底寫了什麼、沒寫什麼。同一份審計報告，懂得看的人能從中判斷這個項目值不值得信任，不懂得看的人只會看到一個「PASSED」的標籤。要判斷一份智能合約審計報告的真正價值，關鍵在三個區塊：Scope（範圍）、Severity（嚴重程度分級）、Findings（發現項目）。
每份審計報告開頭都會寫明 Scope，也就是這次審計實際檢查的合約檔案、版本、以及對應的 commit hash。這個區塊最容易被忽略，卻是判斷一份審計「有沒有意義」的第一道關卡。常見的問題是：審計報告鎖定的 commit hash，跟項目實際部署上線的合約版本並不完全一致——中間如果有任何程式碼變更（哪怕只是「小修正」），審計報告的結論就不再適用於現在正在運作的合約。另一種常見情況是審計範圍刻意排除某些模組（例如治理合約、升級機制），如果項目只強調「已通過審計」卻不提範圍排除了什麼，這本身就是一個需要進一步追問的訊號。
審計報告的發現項目通常分成 Critical、High、Medium、Low、Informational 幾個等級，但這個分級不是客觀物理定律，而是審計團隊依據「攻擊者能實際拿到多少東西」做出的專業判斷。同一個漏洞，不同審計團隊可能給出不同等級——有些審計公司傾向保守，把邊界案例都標高；有些則偏寬鬆。看一份報告時，與其只看「有幾個 Critical」的總數，更值得花時間看的是：這些 Critical 和 High 項目最後有沒有被項目方實際修復，還是報告出爐後就沒有下文。多數審計報告會附上修復狀態（Fixed / Acknowledged / Won't Fix），Acknowledged 或 Won't Fix 的高等級項目，代表項目方知道風險存在卻選擇不處理，這比「完全沒被抓到」的漏洞更值得警惕，因為那是一個已經攤在陽光下、卻被刻意留下的破口。
2021 年 8 月的 Poly Network 事件是一個具體例子：這是一個連接 Ethereum、Binance Smart Chain 與 Polygon 三條鏈的跨鏈協議，攻擊者利用合約之間跨鏈呼叫時的權限驗證漏洞，一次性轉走約 6.11 億美元資產，是當時 DeFi 史上最大規模的單一事件。事後分析指出，問題出在跨鏈合約呼叫之間的權限控制設計，而不是外界一度傳言的單一 keeper 私鑰外洩。這起事件後續因攻擊者主動歸還大部分資金而落幕，但它凸顯的問題至今仍然存在：跨鏈橋接合約之間的權限驗證，是一類特別容易在審計範圍劃分時被切割、或在複雜度上被低估的攻擊面。
發現項目的修復狀態欄位本身也需要仔細讀。「Fixed」代表程式碼確實有對應修改，理想情況下審計團隊會做過一輪 re-audit（複審）確認修復本身沒有引入新問題；但有些項目只是自行宣稱已修復，並未經過審計團隊複審確認，這種未經複審的「自報已修復」，可信度明顯低於有複審紀錄的修復。另一個常見的文字遊戲是把「風險緩解」包裝成「風險解決」——例如原本的漏洞需要透過多簽或時間鎖增加攻擊門檻，但底層邏輯缺陷本身並未真正修正，這種情況下漏洞依然存在，只是被墊高了利用難度。
此外，審計報告只反映「審計當下」的程式碼狀態。如果項目後續有新增功能、修改邏輯，而沒有針對新增部分重新審計，那麼舊審計報告能提供的保障範圍其實在持續縮小，卻很少有項目會主動告知用戶「這部分是審計之後才加上去的」。
下次看到一個項目強調「已通過審計」時，值得多花五分鐘做三件事：找出審計報告鎖定的 commit hash 是否對應目前實際部署的合約；看一下有沒有 Critical 或 High 等級的項目被標記為 Acknowledged 或 Won't Fix；確認審計時間點是否早於項目最近一次程式碼更新。這三個動作花不了太多時間，但能讓你從「看到 PASSED 標籤就安心」，進步到「知道這個 PASSED 到底覆蓋了什麼、沒覆蓋什麼」——這中間的落差，往往就是資金安全與否的關鍵。