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 的流程会在意图层面裸奔，一个只有人工的流程会在覆盖率上失守。把这两件事想清楚，比争论谁更强要有价值得多。
