收益：
- 能够理解人工智能扩大了审核员的范围，但并没有取代它，并且在类别扫描和查找起草方面很有用。
- 能够认识到人工智能已经错过了最初的漏洞和业务逻辑错误，并且流畅的“安全”声明并不能保证
- 能够根据问题的严重程度对调查结果进行分类，并了解最终批准和专业责任由主管审核员承担。
安全审计（对智能合约的漏洞进行系统检查）是Web3最负责任的工作。审计师遗漏的一行可能会导致数百万美元的损失。在本单元中，您将学习如何使用人工智能作为审计助手；我们将通过生成线索来学习编写调查结果大纲。但最关键的一句话是：AI不控制；它是审计人员眼睛敏锐的助手。最终批准权在于承担专业责任的主管审核员。
为什么审计对于安全至关重要
审计报告向项目和投资者保证“本准则已经过审查”。如果这种保证是错误的，后果将是灾难性的：协议被利用、资金损失、项目崩溃。因此，AI在检测中的运用是这个模块最用心的部分。人工智能扩大了审核员的范围（回忆更多模式，读取速度更快），但并没有取代审核员。
为什么不通过？因为：
- 人工智能无法看到训练数据中没有的独特/新漏洞。
- 人工智能经常会忽略协议业务逻辑中的缺陷——代码在技术上是正确的，但在经济上是可利用的。
- 人工智能可以通过用流利的语言说“安全”来给予虚假的保证；这是最危险的结果。
使用人工智能进行控制的层次
1. 初始扫描和图案提醒。人工智能会像清单一样检查已知的漏洞模式：重入、访问控制、预言机操纵、抢先交易。这可以确保审核员不会错过任何类别。
2.代码解释。用通俗易懂的语言向AI解释复杂的功能，可以让审核员快速掌握逻辑；但描述总是与代码进行比较。
3. 撰写调查结果草稿。当审计员发现漏洞时，人工智能可以节省撰写报告草稿的时间（描述、影响、建议的解决方案）。
4. 产生反假设。问AI“这个功能怎么会被滥用？”询问“让我们想起攻击性的观点。
注意：仅仅因为人工智能说“我没有在这段代码中发现任何漏洞”并不意味着“这段代码是安全的”。缺席证据并不等于没有证据。人工智能无法找到某些东西的事实并不意味着审计员没有必要检查该区域。
查找严重级别
审计结果根据其严重程度进行分类。 AI在生成草稿时应该使用这个框架：
级别
含义
例子
批评的
可能直接造成资金损失/锁定
可重入提取资金
高
在某些情况下会产生严重影响
未经授权印刷（全新）
中等
影响有限或情况困难
Oracle 偏差带来的小损失
低
轻微风险，违反良好实践
缺少事件广播
信息
非安全性、可读性
缺乏国家规范
弱提示/强提示
弱提示：
这份合同安全吗？
这个问题迫使人工智能做出像“是/否”这样绝对的、毫无根据的判断——这正是我们不想要的。
强力提示：
您的角色：高级智能合约审核员助理。扫描以下合约以确保安全。一一过一遍以下类别：重入、访问控制、整数运算、输入验证、预言机/外部数据、抢先交易、gas limit。对于每个发现：(1) 相关代码行，(2) 原因风险，(3) 估计严重性（严重/高/中/低），(4) 解决方案建议。这些是有待证实的假设；不要给出“安全”的结论。标记您不确定的区域并清楚地说“让审核员确认”。
四个可复制模板
1）基于类别的浏览：
扫描此合约的以下类别：重入、访问控制、整数溢出、输入验证、预言机依赖、抢先交易、DoS/gas。对于每个类别，请说“有/没有风险/我不确定”，并将您的理由连接到代码中的行。不要做出最后的判断。
2）攻击者角度的反假设：
像攻击者一样思考：滥用该功能的方式有哪些？逐步写出每个场景并指出需要什么条件。这些场景是要测试的假设；不要生成实际的漏洞利用代码，仅描述风险。
3) 调查结果报告草稿：
用正式的审计语言报告以下经过验证的发现：标题、严重性、描述、影响、受影响的代码、重现步骤、建议的解决方案。使用谨慎的技术语言；夸张。假设审计结果已得到审计员的确认，请勿编造新的结果。
4）修复验证：
以下是一个漏洞以及开发人员应用的修复程序。检查修复是否真正消除了漏洞；标记它是否会产生新的副作用或漏洞。不要肯定地说“关闭”；以“必须通过测试确认”结束。
三个迷你箱（数量）
案例 1——人工智能阻止类别跳跃。一位审计员打算专注于 400 行合约并跳过预言机类别。人工智能的类别扫描发出警告，称“价格数据来自单一来源，容易被操纵”。审计人员检查后发现，确实属于中等风险。教训：人工智能维持覆盖范围纪律。
案例 2——虚假的“安全”保证。另一个团队问人工智能“这安全吗？”他问道； AI表示：“似乎没有什么大问题。”船员检查很轻。然后，独立审计员发现了一个业务逻辑缺陷：技术上正确的计算，但其激励措施是可利用的。教训：AI 会漏掉业务逻辑错误；不能相信他会说“安全”。
案例 3 — 起草报告节省了 3 个小时。审计员花了半天时间手动报告 8 项调查结果。当我将验证的结果交给 AI 并打印正式草稿后，时间缩短了约 3 个小时；审计员投入了时间进行深化。教训：人工智能的报告是安全高效的，因为调查结果已经过人工验证。
业务逻辑漏洞：人工智能的盲点
最昂贵的漏洞通常不是来自代码中的技术错误，而是来自业务逻辑的可利用性：奖励账户的舍入利用、闪电贷劫持投票、瞬时操纵价格。在这些情况下，代码“正确”工作，但协议可以被经济地欺骗。人工智能很可能会错过此类错误，尤其是特定于协议的错误。因此，业务逻辑审核是审计人员最耗费人力、最不依赖AI的领域。
提示：询问人工智能“如何利用该协议的经济激励？”并使用出现的场景作为起点 - 但请记住，您和您的团队应该进行真正的分析。
常见错误
- 问人工智能“安全吗？”询问并相信你的“是”。不需要绝对的判断。
- 当AI说“我找不到”时停止审核。缺席不是证据。
- 将业务逻辑审查委托给人工智能。这是他最大的盲点。
- 不使用独立工具（Slither 等）。仅靠人工智能是不够的。
- 未经验证就将AI编造的发现放入报告中。产生幻觉的风险。
- 试图将控制责任交给人工智能。责任在于专家。
综上所述
- 审计对于安全至关重要；人工智能扩大了审计人员的范围，但并没有取代它。
- AI错过了原始漏洞和业务逻辑bug；说“安全”并不能保证。
- 根据严重程度对调查结果进行分类；人工智能在生成草稿方面很有用。
- 反假设和类别筛选保留了包容性的原则。
- 最终批准和专业责任始终由主管审核员承担。
应用任务
查找包含已知漏洞的示例合约（出于教育目的，开源中提供了“易受攻击合约”的示例）。将“基于类别的扫描”提示应用于 AI。请注意人工智能是否：（1）发现了真正的漏洞，（2）产生了捏造/错误的发现，（3）做出了诸如“安全”之类的绝对判断。然后与静态分析工具进行比较。
清单
- [ ] 问AI“安全吗？”相反，我进行了基于类别的扫描。
- [ ] 我将每个发现都视为一个假设。
- [ ] 我自己/团队进行了业务逻辑审查。
- [ ] 我用独立的静态分析工具对其进行了交叉验证。
- [ ] 我已经确认人工智能没有捏造调查结果。
- [ ] 我根据严重程度对调查结果进行了分类。
- [ ] 我接受主管审核员的最终批准权。