撰文：Beosin
近年来，GPT-4、Claude、Gemini 等大语言模型已经具备较强的代码理解能力，能够较好地阅读 Solidity、Rust、Go 等智能合约语言，也能识别重入攻击、整数溢出等具有明显代码特征的经典漏洞。这让行业开始思考：是否可以用大模型来辅助甚至替代人工进行合约审计？
由于通用模型对具体项目的业务逻辑了解不足，在面对复杂的 DeFi 协议时，误报率较高，也容易漏掉那些需要结合跨合约交互或经济模型才能发现的漏洞。后来，业界提出了加入「Skill」机制的方案——在通用大模型的基础上，注入针对智能合约安全的专项知识库、检测规则和业务上下文，让模型在审计时有更明确的判断依据，而不是仅靠通用能力去判断代码是否存在问题。
即便加入 Skill 增强，AI 审计仍然有明确的适用范围。它擅长已知漏洞模式的扫描和代码规范检查，但对于需要深入理解整体协议设计、跨合约交互逻辑或经济模型的复杂漏洞，目前仍难以有效处理。这类问题仍然需要经验丰富的审计专家来负责，而在涉及复杂计算逻辑的场景中，还需要引入形式化验证提供更强的保障。在此背景下，Beosin 构建了 Skill 增强 AI 基线检查 + 人工深度审计 + 形式化验证的三审计模式，三者各有侧重、互为补充。
一、通用 AI 模型的审计能力边界：受控对比测试与案例分析
本文从已完成人工审计的项目库里，选取了两类复杂度差别较大的合约来做测试案例：一类是逻辑比较独立、功能边界清晰的简单合约，这类项目通常是 AI 审计工具训练数据最充足、理论上最占优势的场景；另一类则是涉及多合约交互、复杂状态机或者跨协议依赖的复杂合约，这也正是行业里讨论「AI 能不能替代人工审计」时，最常被拿出来说的高风险场景。
在对比时，我们用完全一样的代码库，先让 AI 独立跑一遍审计，生成报告后再和人工审计报告一条一条对齐。两份报告的产出过程完全互不干扰——人工审计员出报告时根本不知道 AI 的结果，避免相互影响。最后，我们会从以下四个维度来分析结果：
案例 A · 标准代币合约（BSC-USDT / BEP20USDT.sol）
第一组测试，我们选取了一个标准的 BEP-20 代币合约，使用 Solidity 0.5.16 编写。它的逻辑相对独立，功能边界很清晰，没有涉及任何跨合约交互，主要的安全风险都集中在一些常见的、已知的漏洞模式上。这类合约目前理论上是 AI 审计最占优势的场景——训练数据里这类标准代币合约非常多，规则性的漏洞特征也比较明显。
AI 共输出 6 项告警（2 高危、1 中危、3 低危/建议），从数量上看较为可观。低危与建议项基本准确，覆盖了 Solidity 版本过旧、状态变量暴露方式等常见代码规范问题，具有一定参考价值。然而，AI 输出的两项"高危"均构成误判。AI 将 owner 铸币权和权限集中标记为高危漏洞——实际上对于中心化稳定币（USDT 类），owner 拥有铸币权属于预期设计，风险评估应结合多签控制、权限治理机制及合约升级策略综合判断。这类权限结构的合理性，根本上取决于项目的业务模型而非代码本身，AI 缺乏这一层语境，只能基于模式匹配做出判断。
该测试案例显示，AI 能识别权限结构，但无法结合业务语境判断权限是否合理，所以将 USDT 类合约的 owner 铸币权直接标记为"高危漏洞"，这是典型的脱离业务实际逻辑的误判——这类误报可能干扰项目方对真实风险的判断。
案例 B · 复杂业务合约（IPC Protocol / 2025-02-recall）
第二组测试选取 Code4rena 平台公开报告中的 IPC Protocol 项目（报告链接：code4rena.com/reports/2025-02-recall）。该项目包含 Gateway、SubnetActor、Diamond 代理模式等多个相互依赖的核心组件，安全性高度依赖对协议整体架构和跨组件交互逻辑的深度理解，这是 DeFi 生态中高价值攻击的典型发生场景。下面是 AI 审计结果：
针对复杂合约，AI 审计共产出 3 项高危、6 项中危告警，从输出体量上并不逊色。但其中相当比例被审计员判定为误报——AI 对缺乏上下文的代码片段做出了错误的风险判断。与此同时，在审计员确认的 9 个 High 级漏洞中，AI 仅完整覆盖 1 项，另有 2 项被发现但定级明显偏低（实为 High，AI 报告为 Medium），其余 6 项完全未被发现。4 个 Medium 级漏洞中，AI 覆盖了 1 项，3 项完全缺失。
这些漏洞的共同特点是：都依赖对协议跨组件状态转变路径的完整推理，而非对单一函数的模式匹配。以人工审计报告中的 H-01（签名重放）为例，漏洞的利用路径需要理解多签验证的设计意图、攻击者如何构造重复签名集合、以及这一行为如何绕过权重阈值。H-06（leave() 函数重入攻击）同样如此：漏洞仅在子网 bootstrap 临界状态下存在，需要理解质押流转、bootstrap 触发条件与外部调用时序三者之间的交叉依赖。类似的深层逻辑漏洞，在 AI 的告警列表中没有任何记录。
该结果显示在复杂合约审计中：AI 的审计能力在于局部代码的模式识别，而协议级漏洞可能存在对整体业务逻辑的理解偏差。当漏洞的触发条件跨越多个合约、多个状态、多个调用层级时，AI 当前的推理能力尚无法有效覆盖。
综合两个案例来看，AI 审计并非没有价值——它在已知漏洞模式的覆盖、代码规范检查、以及部分独立视角的发现上具有实质贡献。但它的价值边界非常清晰：可以作为基线扫描，但不能直接作为安全结论。对于复杂协议，仅依赖 AI 报告做出安全判断，不仅会漏掉风险较高的漏洞，还会因为大量低质量告警占用团队大量筛查时间。这正是 Beosin 建立专属 Skill 知识库，以及在审计流程中引入三审计模式机制的核心原因。
二、专属 Skill 知识库：提升 AI 基线检查的工程化路径
为了将把 AI 审计纳入基线检查的审计流程，就必须解决其在审计真实 DeFi 协议时误报和漏报率偏高的问题。无论是权限管理、AMM 流动性机制、跨链桥的消息验证，还是借贷协议的清算逻辑，AI 目前都只能根据代码表面的特征做简单匹配，很难结合具体的业务场景和攻防逻辑来判断一段代码到底有没有问题。解决这个问题的核心，是把审计专家多年积累的经验以结构化的方式注入到 AI 的判断过程中，让它具备一定的业务理解能力。
但是需要明确的是，即使引入了 Skill 增强，AI 在审计中的定位也不会改变。对于那些涉及多合约交互、经济模型分析以及新型攻击手法的复杂问题，人工审计依然不可替代。Skill 的作用，是在 AI 能处理的范围内（比如识别常见漏洞模式，并有限地理解业务逻辑），把初步扫描的质量提升到一个真正有用的水平，为人工审计提供更有价值的初步结果，而不是制造出一堆需要反复甄别的无效告警。
2.1 从审计实战中提炼：Skill 规则的构建机制
Beosin 的 Skill 知识库，来源于超过 4000 个已完成人工审计的智能合约项目，由审计专家进行了大量归纳、总结，并逐条提炼和验证整理而成。每一条规则的形成，都完整走完了从漏洞发现到规则落地的全过程：审计师在真实项目中发现安全问题后，会对攻击路径进行完整还原，深入分析根本成因，验证修复方案是否有效，最终把这一整套攻防认知整理成带有上下文判断条件的规则条目，纳入 Skill 库，供后续审计调用。
以下为 Skill 库中的其中一个规则样本，包含漏洞模式、攻击路径、根本成因与修复建议四个维度上的结构：
[Beosin-AMM_Skill-1] 添加流动性检测通过转账顺序绕过
漏洞模式：合约通过检查 Pair 中 WBNB 余额是否超出储备量（balanceOf >= reserve + required）判断是否为添加流动性操作。该检测依赖 WBNB 先于代币到 Pair 的假设，但 Router 的 addLiquidityETH 函数固定先转 ERC-20 代币再转 WETH，且 addLiquidity 函数的转账顺序由参数顺序决定。
攻击路径：攻击者只需使用 addLiquidityETH（代币固定先转），或调用 addLiquidity(Token, WBNB, ...)使 Token 先于 WBNB 转入 Pair。检测时 WBNB 尚未到达，balanceOf == reserve，检测函数返回 false，从而完整绕过「no add liquidity」限制。
根本成因：基于 Pair 余额快照的检测方式，在设计层面本质上无法可靠地区分 swap 与 add liquidity 操作，属于架构性缺陷而非实现 Bug。
修复建议：改为禁止非白名单地址直接向 Pair 转账，所有交易通过合约内置函数完成，从架构层面根除余额快照检测的根本缺陷。
该规则并非对单一代码模式的简单标注，而是对一类攻击的系统性梳理：触发条件如何构成、攻击者沿何路径绕过检测、检测机制在哪个环节存在架构性缺陷，以及修复需要在哪个层面介入。
2.2 知识库的覆盖范围
Beosin 目前已形成覆盖 Web3 主流技术栈的专项 skill 漏洞库，包括 Solidity、Rust、Motoko、FunC、Go 及 ZK 等大类。其核心内容作为内部核心资产不对外公开，目录结构如下：
每个专项库下的 Skill 都按照漏洞类型分开管理，每一条规则都包含编号、触发条件、攻击路径还原、上下文判断逻辑以及修复建议。整个 Skill 库会随着每次新型攻击事件的出现和审计实例的积累持续迭代，确保始终与链上真实的威胁环境保持同步。
2.3 Skill 介入后的基线检查质量对比
为量化 Skill 库对基线扫描质量的实际影响，我们以第二章中的两个测试案例为基准，在相同代码库上分别运行通用 AI 与 Skill 增强 AI，并对结果进行逐项比对。
案例 A · 标准代币合约（BEP-20）对比结果：
案例 B · 复杂业务合约（IPC Protocol）对比结果：
对比结果显示，引入 Skill 后，两类合约的检测质量都有明显提升。在标准代币合约场景中，由于加入了业务语境判断能力，高危误报被彻底消除；在复杂业务合约场景中，已知漏洞模式的覆盖率从 11% 提升到 44%，误报率从约 55% 降到约 30%，严重等级判断的准确性也显著改善。这份报告可以作为基线检查，帮助项目方提前了解代码中存在的缺陷。虽然这些问题暂时不会直接造成资金损失，但对后续的项目维护和升级仍有重要的积极作用。
然而，数据也清晰地暴露了 AI 能力的固有边界：即使加入 Skill 增强后，在复杂合约中 High 级漏洞的覆盖率也仅达到 44%。那些需要跨合约状态路径推理、经济激励模型分析，或特定时序条件才能触发的深层漏洞，仍然远远超出 AI 基线扫描的能力范围。这正是我们在引入 Skill 增强之后，审计流程中依然保留完整人工审计环节的根本原因。
2.4 白皮书作为审计输入：代码实现与设计意图的一致性核查
除了漏洞特征库之外，我们在审计流程中还增加了一项重要能力：把项目的白皮书作为额外输入，让 AI 对代码实现与白皮书设计之间的一致性进行验证。
具体来说，在代码审计开始前，AI 会系统地解析项目的白皮书、技术规范和需求文档，从中提取角色权限模型、核心业务流程、信任边界定义以及预期行为约束，形成结构化的项目语境摘要。随后，在整个代码审计过程中，AI 会持续参照这个语境进行交叉比对。这一机制在实际使用中带来了两类很有价值的结果：
第一，对于代码中看似存在风险的权限结构，如果白皮书中已经明确说明了其设计意图和约束条件，AI 会据此调整判断，从而有效减少这类误报。
第二，如果代码实现与白皮书的承诺存在明显偏差，比如文档中宣称的滑点保护机制在代码里并未实现，或者治理流程的时间窗口约束没有被正确执行，AI 就会据此发出告警。这类代码与文档不一致的问题，在常规代码扫描中非常容易被忽略，但往往正是潜在的安全隐患所在，同时也帮助项目方尽可能避免，项目实际上线后出现与其预期并不相符的行为。
三、三重审计模式：协同构建智能合约安全的完整保障
智能合约一旦部署上链，任何漏洞的代价往往都是不可逆的。Beosin 以人工深度审计 + 形式化验证作为合约审计的基础，重点发现并报告那些已经可能导致资金损失或逻辑运行异常的问题。同时，我们引入了基于专属 Skill 知识库的增强 AI 基线检查，帮助客户更早地发现那些目前还只是缺陷、尚未造成实际危害的代码问题。在此基础上，Beosin 构建了人工深度审计 + 形式化验证 + 增强 AI 基线检查三审计模式，通过三者分层协作，形成覆盖更全面的安全保障体系。
3.1 人工深度审计与形式化验证：安全保障的核心支柱
人工审计的核心优势在于对协议整体设计的深度理解，以及从攻击者角度主动分析潜在风险。经验丰富的审计专家负责对项目进行全面的协议级审计，包括跨合约交互逻辑的验证、资金安全的攻击面分析、协议在极端市场条件下的逻辑分析，以及对新型攻击方式的识别与判断。这种协议级的攻防理解高度依赖对 Web3 生态的长期积累与实战经验，是工具层面目前无法独立完成的。
在此基础上，Beosin 以内部工具链将人工审计的判断结论转化为可量化的数学保证。针对审计专家确认的核心业务逻辑，如：资金流转、价格计算等最高风险的关键路径，Beosin 将 LLM 驱动的形式化规范生成能力深度集成进内部验证工具链，构建了「AI 规范生成 → 形式化穷举验证 → 反例驱动精化」的闭环引擎。工具链首先以 Beosin 积累的审计语料库为知识底座，对人工确认的高风险路径进行攻击面建模，辅助生成形式化不变量与安全属性规范的初始候选集；随后，自动形式化验证引擎对合约的完整状态转换空间进行穷举验证。当验证引擎发现反例时，系统自动区分两类情形：若反例源于规范定义与业务语义的偏差，则将反例上下文回传 AI 模块进行规范精化，驱动下一轮迭代；若反例对应合约代码的真实可利用路径，则直接作为漏洞证据输出，附带完整的攻击路径复现，供审计专家确认并跟进修复。两条路径共同驱动闭环收敛，直至数学意义上确认目标属性对所有可能输入均成立。经该闭环机制验证的关键路径，构成整个合约安全体系中确定性最强的防线，将攻击面压缩至极窄的范围。
3.2 增强 AI 基线检查：面向开发者的持续风险提示服务
同时，Beosin 也将基于 Skill 知识库的增强 AI 基线检查作为一项独立服务提供给客户。与专注于发现高危漏洞的人工深度审计不同，这项服务的定位更接近一份面向开发团队的代码健康报告。AI 基线扫描会对合约代码进行全量覆盖，系统性地梳理出那些当前不会直接造成经济损失，但在项目后续维护和迭代过程中需要开发者关注的潜在问题。例如：使用了过时的依赖库、缺失关键事件声明、不符合最佳实践的状态变量暴露方式，以及可以进一步优化的 Gas 使用模式等。这些问题在当前的业务逻辑下通常不会被攻击者直接利用，但随着协议功能扩展、代码重构或外部依赖更新，其中部分问题有可能逐步演变为真正的安全隐患。三个层次各有侧重、逐层递进，共同构建起对 Web3 项目安全的完整保障体系。
