这几天，一篇代码审计工具的实测对比文在开发和安全圈里传得挺广。作者埋了 30 多个已知漏洞，把 Semgrep、CodeQL 和两款 AI 审计工具挨个跑了一遍，结果有点扎心：老牌工具 Semgrep 只捞出来大约一半，名不见经传的 AI 工具全检出了，连 GitHub 亲儿子 CodeQL 在 Python 上也只检出 24%。
不少朋友的第一反应是：Semgrep 是不是过时了，该换了？先别急。这篇文章把实测的细节、各家的官方说法和最近的行业动态替你捋一遍，说完你就知道这个结论的边界在哪，以及自己的项目到底该怎么选。
一、先说清楚：这场实测测的是什么
实测的环境和样本很关键：一台 22 年的 MacBook，几百行的 Python 项目，30 多个按 OWASP Top 10 人工埋进去的漏洞——SQL 注入、命令注入、硬编码密钥、不安全反序列化、SSRF、XXE 都有。
结果概览是这样：
Semgrep：30多个漏洞，它捞出来大概一半。知乎强项是 SQL 注入（部分）、弱哈希这类"模式明显"的问题，f-string 拼接注入、硬编码密钥、subprocess shell=True 全漏了
OpenCodeReview（LLM 驱动）：全部检出，还直接给 diff 格式的修复补丁
DeepAudit（多 Agent 架构）：扫描耗时 117 秒，检出 31 个问题，检出率 103%，比埋的还多一个，附带 AI 解释
CodeQL：30 多个只检出 7 个，检出率 24%，数据流分析在动态语言上吃了瘪
数字是真的，但有个前提必须知道：这次的靶子只是几百行 Python——第一次测试的靶子代码是Agent手搓的两个Python文件，user_service.py（115行）和auth_handler.py（96行），一共211行。知乎漏洞又是人工埋的"教科书式"漏洞。这类实测能说明工具的能力倾向，不能直接外推到几十万行的真实项目。要是把"AI 工具 100%、Semgrep 一半"当成结论去换工具，那就踩坑了——检出率只是选型的维度之一，而且是在特定样本上的检出率。
二、Semgrep 为什么"只检出一半"
这不是 Semgrep 偷懒，而是它明牌的设计取舍，官方明确表达过设计哲学：愿意用漏报来换取简洁性和更少的误报。知乎
它的原理是基于语法树的模式匹配：规则写成"代码的样子"，在 AST 上做语义匹配；社区版只提供函数内的数据流（污点）分析，跨文件、跨过程的分析是付费 Pro 版的能力。
这个设计换来的是三样 AI 工具暂时给不了的东西。第一，快，秒级出结果，每次提交都跑一遍也没负担。第二，确定性，它是确定性的——给定完全相同的代码、完全相同的规则和分析方式，每次执行都会产生完全相同的检测结果。知乎CI 里可复现、可追责，而 LLM 工具两次扫描结果可能不一样，这次实测 100% 不代表下次还 100%。
第三，规则可定制，Semgrep 只需学习一套规则编写语法，就能为 30 多种语言编写规则。知乎安全工程师能把自家业务的安全规范写成规则长期跑，这一点连实测作者都承认"是 LLM 工具做不到的"。
反过来，AI 工具的 100% 检出也有代价：每次扫描都要调 LLM API，CI 里高频跑成本会累积，如果 LLM 服务挂了，工具也就跟着挂了。知乎输出是自然语言描述，没有 CWE 编号，合规审计场景不够用；离线和内网环境基本没法跑。
所以问题不是"Semgrep 怎么才检出一半"，而是它本来要解决什么问题——它是 CI 流水线上的快速门禁，求的是快、稳、噪音低，不是那张把漏洞一网打尽的深网。
三、Semgrep 官方自己，已经下场做 AI 了
这里有个很多人没注意的信号：今年 6 月，Semgrep 公司自己发了一份 LLM 安全能力基准测试报告，用真实开源项目里的 IDOR 漏洞当考题，GLM-5.2 在 IDOR 漏洞检测任务上以 39% F1 分数击败了 Claude Code（Opus 4.6 为 37%、Opus 4.8/4.7 为 28%）。知乎
报告里更有意思的结论是：围绕模型搭的工程脚手架（harness）带来的收益，经常比换模型本身还大，只是这部分经常被模型升级的收益掩盖。
Semgrep 也没把 AI 当对手，而是当自己的组件，商业版里的 Semgrep Assistant 走的就是静态扫描加大模型的路子：首先使用引擎扫描，对结果用大模型来处理，找到真实告警，然后结合上下文处理，给出修复建议。知乎按官方口径，Pro 版的跨文件数据流分析可减少 25% 的误报，并发现 2.5 倍以上的真正漏洞。知乎
商业面上，2025 年 2 月 5 日，应用安全平台Semgrep宣布获得由Menlo Ventures领投的1 亿美元D 轮融资。知乎拿到钱后方向也很明确：AI 驱动的应用安全平台。同一时期，开源引擎的使用条款收紧，开源项目 Opengrep 的启动正是为了响应 Semgrep 描述为许可更新而非变更的行为。知乎如果你在用免费社区版，这个 fork 的走向值得顺手关注一下。
四、普通团队到底怎么选
把实测、官方信息和行业信号放到一起，可以抄的清单如下：
个人/小团队，写 Python、JavaScript 这类动态语言：测试已经证明，这类语言上 LLM 驱动的工具效果远好于传统静态分析。知乎Semgrep 留作 CI 门禁，PR 环节叠一层 AI 审计工具做深度检查，顺手拿修复建议，流程最短
Java、C# 这类静态类型语言为主：CodeQL 的数据流分析优势明显，还零 API 成本，可以当主力
要出合规报告、需要 CWE 编号映射：选 CodeQL 或 Semgrep 商业平台，纯 LLM 工具的自然语言输出不太适合这个场景
内网、离线环境：只有 Semgrep 和 CodeQL 可选，想用 LLM 工具得先在内网部署私有模型
团队有安全工程师，想把业务安全规范沉淀成规则：Semgrep 目前仍然不可替代
一句话收拢：Semgrep 还值得留在流水线里，但别指望它一个人干完所有活——快速门禁归它，深度审计交给 AI 工具或付费平台。分层用是最聪明的姿势，把宝全押在任何一个工具上都不明智。
想继续盯这个方向的话，留三个观察信号：Opengrep 社区版的更新节奏、Semgrep Assistant 的自动修复能力走到哪一步，以及你用的语言在 LLM 安全基准上的表现。这个领域迭代很快，今天的结论，有效期暂按 2026 年 8 月算。
