用好傳統的SAST，防止Token消耗失控

在AI輔助開發工作流中，程式碼審查正成為新的成本瓶頸。隨著AI程式設計代理快速生成程式碼變更，審查環節的負擔急劇增加。傳統上，人類評審者需要面對越來越大的差異（diff），而AI代理的迴圈機制會導致token消耗呈指數級增長——每次呼叫都會累積之前的工具輸出和對話歷史，使成本遠超預期。

確定性的靜態分析提供了一種高效的解決方案。秘密掃描器和SAST規則不需要推斷意圖，它們直接檢測已知模式，返回結構化的結果。這意味著模型無需在每次檢查時都載入完整的規則集。更關鍵的是，確定性分析的結果是可預測的，適合作為CI/CD中的硬性門控，而不僅僅是一個建議。

LLM的真正價值在於處理需要綜合判斷的任務，比如將程式碼變更與需求票據進行對比，或者解釋多個發現之間的關聯。如果讓LLM反覆確認一個已知的漏洞模式，那就是在浪費其核心能力。正確的做法是讓確定性檢查作為第一道過濾器，只將真正模糊的問題留給模型處理。

在設計確定性優先的審查管道時，本地IDE和CLI的檢查應最先觸發，在開發者輸入時就發現格式、秘密和基本SAST問題。這些檢查在程式碼到達PR之前就已解決，從而減少了後續步驟的負載。當代理被呼叫時，它應接收一份確定性發現的摘要，而不是被要求重新發現所有已知問題。

在Git和PR階段，確定性發現應與AI生成的摘要結合，使審查更加高效。CI/CD階段則負責證明檢查確實執行過，並留存結果以供審計。整個流程的關鍵反饋迴圈是：每當一個不良模式被反覆拒絕，就應該將其轉化為永久規則，而不是在每次提示中重新討論。

對於工程領導者而言，最重要的指標是token消耗是否與真正的模糊性相關，而非用於重新發現本應由規則捕獲的問題。跟蹤每次PR的token消耗與程式碼量的比例，可以揭示確定性預檢查是否真正發揮了作用。同時，審查週期時間的下降，如果伴隨質量穩定或提升，則表明自動化移除了正確的工作。

總之，確定性靜態分析與AI推理的結合，不是要取代LLM，而是要最佳化其使用場景。透過先用規則清理低價值問題，模型可以更專注於高價值的決策，從而在降低成本的同時提升審查質量。此外，團隊應建立反饋機制，將重複出現的拒絕模式轉化為永久規則，避免每次審查都消耗token重新討論。這種最佳化不僅適用於大型團隊，對初創公司同樣關鍵，因為每一分預算都需用在刀刃上。