Sift
把「可能有錯」變成可重跑的檢查。
從什麼問題開始
Go 寫的 AI code scanner。以 Semgrep rules、package verification、選擇性 LLM 分析與 SARIF 把錯誤變成可重跑檢查。
做了哪些事
- 以確定性規則先行，再用語意分析補充線索。
- 整合並行檢查、終端輸出、機器可讀報告與歷史紀錄。
資料怎麼走
點開一站，看它做什麼，以及需要注意的地方。
-
01Semgrep 規則
以靜態規則先處理能明確描述的程式碼問題。
- 產出
- 規則命中與位置
- 需要留意
- 規則命中是需要核對的線索，不等於已證實的漏洞。
-
02套件驗證
檢查程式碼引用的套件資訊，補充單看程式片段不足的脈絡。
- 產出
- 套件核對結果
- 需要留意
- 套件資訊與程式行為是不同證據，兩者需要一起閱讀。
-
03可選 LLM
在需要時使用模型補充語意分析，保留不依賴模型的規則流程。
- 產出
- 額外分析線索
- 需要留意
- 需要額外 API 設定，模型也可能誤判；不是每次掃描都必須使用。
-
04SARIF / JSON
把結果整理成機器可讀格式，供其他開發工具使用。
- 產出
- 結構化分析報告
- 需要留意
- 報告格式方便整合，但不會自動提高檢查本身的正確率。
-
05SQLite 歷史
保存分析紀錄，使結果可以追蹤與回看。
- 產出
- 歷次檢查紀錄
- 需要留意
- 可追蹤性與正確性是兩件事；重跑後仍需要閱讀結果。
