1. 从一次真实的审计分歧说起去年年底我参与了一个中型后端服务的上线前安全评审。团队里有人提议既然现在静态分析工具已经能自动识别注入、越权、敏感信息泄露这些常见问题那是不是可以把人工审计的环节压缩掉只留一个人做最后确认当时会议室里分成了两派一派觉得工具跑一遍就够了另一派坚持人工必须完整过一遍核心链路。最后我们做了一个折中方案工具全量扫描人工只盯高风险模块。结果上线后第三周一个藏在业务逻辑深处的越权漏洞被外部反馈出来——工具没报人工也没看到因为那个模块恰好被划在了低风险范围里。这件事让我意识到AI 代码审计能不能替代人工这个问题问法本身就有点问题。真正值得讨论的不是能不能替代而是在哪些环节、哪些类型的缺陷上两种模式各自的能力边界在哪里。这篇内容就围绕这个核心展开把 AI 代码审计和人工审计放在同一张桌子上逐项拆解它们各自擅长什么、在哪里会失灵、以及一个务实的团队应该怎么把两者拼起来用。不管你是刚接触代码审计的新人还是已经在带安全评审流程的负责人都能从中找到可以直接落地的判断依据。2. AI 代码审计到底在做什么能力来源与固有盲区2.1 从规则匹配到语义推理的三级跳要谈边界先得搞清楚 AI 代码审计的能力是从哪来的。目前市面上的工具大致可以分成三代。第一代是基于规则和正则的匹配比如检测硬编码密码、检测eval调用这类工具本质上是一个高级的文本搜索器速度快但误报率高。第二代引入了数据流分析和污点追踪能追踪一个用户输入从入口到危险函数的完整路径这已经能覆盖相当一部分注入类漏洞。第三代则是基于大模型和代码语义理解的推理式审计它不再依赖预定义规则而是像人一样读代码理解上下文意图。这三代能力是叠加的不是替代的。一个成熟的 AI 审计工具通常同时跑规则引擎、数据流引擎和语义模型最后把结果做聚合和排序。理解这一点很关键因为很多人对 AI 审计的误解就来自于把大模型读代码等同于整个 AI 审计能力。实际上真正决定检出率的往往是底层的数据流分析做得好不好大模型更多是在做误报过滤和上下文补充。2.2 为什么 AI 在模式化缺陷上碾压人工在模式化缺陷这个维度上AI 的优势是压倒性的。所谓模式化缺陷指的是那些有明确特征、可以形式化描述的漏洞类型SQL 注入、命令注入、路径穿越、不安全的反序列化、硬编码凭证、弱加密算法、日志泄露敏感信息等等。这些缺陷的共同点是它们的危险信号在代码层面有稳定的形态。我做过一个粗略的统计在一个约 30 万行的 Java 项目里人工审计师完整过一遍需要大概 15 到 20 个工作日而 AI 工具全量扫描加人工复核误报大概 2 到 3 天就能收敛。更关键的是人工在连续工作几小时后对重复模式的敏感度会急剧下降第 500 个String sql select * from tableName很可能就被眼睛自动过滤掉了而工具不会疲劳。这就是 AI 在覆盖率和一致性上的核心价值。2.3 语义盲区AI 读不懂业务意图但 AI 的盲区同样明显而且这个盲区恰恰是它能力来源的另一面。AI 审计工具理解的是代码的形式语义不是业务语义。举个具体的例子一个接口接收orderId参数然后查询订单详情返回。从代码形式上看只要做了参数化查询、做了权限校验工具就会判定为安全。但如果这个接口的业务规则是只有订单所属用户才能查看而代码里只校验了用户已登录却没校验订单归属这就是一个典型的越权漏洞。工具不会报因为代码在形式上没有任何危险函数调用。这类缺陷在 AI 审计的视角里是隐形的因为它需要理解这个订单应该属于谁这个业务前提。而人工审计师只要问一句这个接口谁能调、能查到谁的数据就能立刻发现问题。这就是两种模式最本质的分界线AI 擅长发现代码写错了人工擅长发现代码写对了但逻辑错了。3. 人工审计不可替代的四类场景3.1 业务逻辑漏洞规则永远追不上业务变化业务逻辑漏洞是人工审计最坚固的阵地。这类漏洞的特点是它不违反任何编码规范甚至不违反任何安全编码原则它违反的是业务规则本身。比如优惠券可以叠加使用导致超额抵扣、退款流程可以重复触发导致资金损失、审批流程可以通过参数篡改跳过某一级。这些问题的共同点是它们只在特定的业务上下文里才成立。我见过一个很典型的案例某系统的积分兑换接口代码里对兑换数量做了上限校验看起来没问题。但审计时发现这个上限校验是在单次请求维度做的而兑换操作可以被并发调用攻击者用多线程同时发请求就能绕过上限。这个漏洞在代码形式上完全合规AI 工具不会报只有理解了兑换是一个需要原子性保证的业务操作这个前提才能发现问题。人工审计师在这里的价值不是读代码而是把业务规则翻译成对代码的质疑。3.2 跨模块的权限与信任边界现代系统的权限模型往往横跨多个模块一个请求可能经过网关、鉴权服务、业务服务、数据服务四层。AI 工具通常只能在一个代码库或一个服务内做分析跨服务的信任边界它看不到。而人工审计师可以沿着一个完整的请求链路走一遍检查每一层的信任假设是否成立。举个常见的坑网关层做了身份认证业务服务就默认进来的请求都是已认证的于是业务服务内部不再校验身份。这个假设在正常情况下成立但如果业务服务有另一个内部调用入口没走网关这个假设就崩了。这种信任边界错位的问题需要审计师对整个系统架构有全局认知AI 工具在单服务视角下几乎不可能发现。3.3 加密与密钥管理的实现细节加密相关的缺陷是另一个 AI 容易漏掉的区域。工具能检测出使用了 MD5这种明显的弱算法但对于算法选对了但用法错了的情况检出能力很有限。比如 AES 加密用了 ECB 模式、IV 固定不变、密钥从配置里读但配置没有做访问控制、加密后的数据没有做完整性校验等等。这些问题的判断需要相当深的密码学工程经验。我曾经审过一个模块用的是 AES-GCM算法没问题但代码里把 nonce 设成了固定值。从工具的角度看它调用了正确的加密 API参数类型也对不会报任何问题。但固定 nonce 在 GCM 模式下会导致密钥流复用安全性直接归零。这种缺陷只有懂密码学实现细节的人才能看出来AI 目前还做不到。3.4 供应链与第三方依赖的隐性风险第三方依赖的风险也是人工审计需要重点关注的。AI 工具通常能扫描出依赖的已知漏洞版本但对于这个依赖被用在了什么场景、引入了什么信任假设这类问题它无法判断。比如某个 JSON 解析库在特定配置下会触发反序列化工具只会告诉你这个版本有 CVE但不会告诉你你的代码里恰好用了这个危险配置。人工审计师在这里要做的是把依赖的已知问题和实际使用方式结合起来判断。一个存在漏洞的依赖如果只被用在完全可控的内部数据上风险等级可能很低而一个看起来无害的工具库如果被用在了处理外部输入的关键路径上风险就可能很高。这种基于使用场景的风险定级是 AI 目前给不出来的。4. 两种模式的能力边界对照表把前面的分析收敛成一张表会看得更清楚。下面这张表是我根据多个项目的实际审计经验整理的列出了常见缺陷类型在两种模式下的检出能力对比。缺陷类型AI 审计检出能力人工审计检出能力推荐主导方SQL 注入、命令注入高中易疲劳漏检AI 主导硬编码凭证、弱算法高中AI 主导路径穿越、SSRF高中AI 主导越权水平/垂直低高人工主导业务逻辑漏洞极低高人工主导加密实现细节错误低高人工主导跨服务信任边界极低高人工主导供应链使用场景风险中仅版本匹配高人工主导并发与竞态条件低中高人工主导敏感信息日志泄露高中AI 主导从这张表能看出一个清晰的规律凡是能形式化的AI 强凡是需要理解意图的人工强。这不是谁替代谁的问题而是两种能力覆盖的是不同的缺陷空间。一个只跑 AI 的流程会在越权和业务逻辑这两块留下巨大的空洞一个只靠人工的流程会在覆盖率和一致性上付出巨大代价。5. 把两种模式拼起来一个可落地的混合审计流程5.1 分阶段AI 做初筛人工做深挖务实做法是把审计流程分成两个阶段。第一阶段用 AI 做全量初筛目标是不漏掉任何模式化缺陷同时把结果按风险等级排序。这个阶段的关键不是追求零误报而是追求零漏报宁可多报一些让后面人工复核。第二阶段人工只处理两类内容AI 报出来的高风险项做确认以及 AI 覆盖不到的区域做定向深挖。这里有个经验AI 初筛的结果不要直接丢给人工逐条看那样人工会被大量误报淹没。更好的做法是先做一轮自动化的误报过滤比如把测试代码里的硬编码、示例配置里的默认值这类低价值告警自动降级让人工把精力集中在真正可疑的条目上。我通常会把 AI 告警按数据流可达性排序能追到外部输入入口的排前面追不到的排后面。5.2 人工深挖的清单化方法人工阶段最怕的是不知道从哪看起。我的做法是准备一份固定的深挖清单每次审计按清单走一遍保证不遗漏关键区域。这份清单大致包括所有涉及资金、权限、数据导出的接口所有跨服务调用的信任边界所有加密和密钥相关代码所有并发操作所有第三方依赖的关键使用点。清单化还有一个好处就是可以让不同的人做审计时保持一致的覆盖度。新人拿着清单也能走完流程不会因为经验不足而漏掉整块区域。当然清单不是死的每审一个新项目如果发现了清单没覆盖到的新类型问题就补进去慢慢就形成团队自己的审计知识库。5.3 让 AI 辅助人工而不是替代人工还有一个被很多人忽略的用法让 AI 去辅助人工审计而不是试图替代它。具体来说人工审计师在审一个模块前可以先让 AI 把这个模块的数据流、调用关系、外部输入点整理出来作为审计的地图。这样人工就不用花大量时间在代码里找入口可以直接进入判断环节。另一个用法是用 AI 做审计的第二双眼睛。人工审完一个模块后把 AI 的告警和人工的结论做交叉比对两边都报的优先处理只有一边报的做二次确认。这个交叉验证的过程往往能发现单靠任何一种模式都会漏掉的问题。我在实际项目里用这个方法至少抓到过三次人工觉得没问题但 AI 报了、最后确认是真问题的情况也抓到过更多AI 报了但人工判断是误报的情况两个方向都有价值。6. 几个容易踩的认知坑6.1 AI 报了就是有问题和AI 没报就是没问题这两个认知坑几乎一样常见。前者会导致团队被误报拖垮最后对工具失去信任后者更危险会让人产生虚假的安全感。我见过有团队把 AI 扫描通过当成上线门槛结果上线后出了越权漏洞回头一看那个漏洞 AI 从来就没能力发现。正确的认知是AI 的报了是一个需要验证的信号AI 的没报只代表在它的能力范围内没发现问题不代表没有问题。把 AI 的结论当成审计的起点而不是终点心态就对了。6.2 迷信大模型读代码的能力现在很多工具宣传自己用了大模型能像人一样理解代码。实际用下来大模型在代码审计里的作用主要是两个一是做误报过滤把明显不成立的告警去掉二是做上下文补充帮审计师快速理解一段代码在干什么。它直接发现深层逻辑漏洞的能力目前还远没有宣传的那么强。原因也不难理解大模型的上下文窗口有限一个大型项目不可能整个塞进去而且它对代码的理解是基于训练数据里的模式对于项目特有的业务规则它没有先验知识。所以看到大模型驱动的宣传时要关注的是它具体用大模型做了什么而不是被这个词本身唬住。6.3 把审计当成一次性动作无论是 AI 还是人工审计都不应该是一次性的。代码在变业务在变攻击手法也在变。一个务实的做法是把 AI 审计接入 CI 流程每次提交都跑一遍增量扫描把模式化缺陷挡在合并之前人工审计则按迭代或按季度做一次全量深挖。这样 AI 负责持续守门人工负责定期体检两者节奏不同但互补。7. 我对这个问题的最终判断回到最初那个问题AI 代码审计能替代人工吗我的判断是在模式化缺陷这个子集里AI 已经可以承担主要工作人工只需要做抽样复核但在越权、业务逻辑、加密实现、跨服务信任这些需要理解意图的领域人工在可预见的未来仍然是不可替代的。所谓2026 年的能力边界本质上就是这条线的位置——AI 的边界在形式人工的边界在意图。所以真正该做的不是纠结替代不替代而是把两种模式的能力拼成一张完整的网。AI 负责广度和一致性人工负责深度和判断力。一个只有 AI 的流程会在意图层面裸奔一个只有人工的流程会在覆盖率上失守。把这两件事想清楚比争论谁更强要有价值得多。