审计不是一次性事件：上线前清单与可辩护的 Agent 决策

一键发币： x402兼容 | Aptos | X Layer | SUI | SOL | BNB | ETH | BASE | ARB | OP | Polygon | Avalanche

一句话结论：审计覆盖的是一个 commit，不是你的部署脚本、配置和下周合并的三个 PR。 本文编译 2026 年 10 月的三篇新材料：一份"审计前就该做完"的准备清单（@bloqarl，dev.to，10-13）、一篇"AI 让找 bug 变便宜之后"的经济学（@bloqarl，10-09，含 SCONE-bench 数据），以及一次把 Agent 放进审计流程后的复盘——决策可辩护的四个控制（@dailycontext / Anirudh，dev.to，10-14）。三篇合起来回答同一个问题：当"审计过"不再等于"安全"，你还能拿什么来证明自己尽到了责任。（原文作者分别在 zaelynX 与 Fieldguide 任职，文内已披露；Hacken Q3 的 77% 数据见本系列前一篇。）

一、审计前几天：把钱花在理解，而不是猜意图

一次审计通常是早期团队请人做的最大一次检查。而头几天里，很大一部分时间花在与找 bug 无关的事上：搞清楚协议到底要做什么、哪些文件在范围内、测试为什么跑不起来、现在看的到底是哪个 commit。这些钱你无论如何都要付——区别只在于，它们是花在"审计员理解你的系统"上，还是花在"攻击你的逻辑"上。

下面这份清单不需要大预算，大多是几个晚上的工作量。

1. 把"代码要做什么"写下来

• 每一个 public / external 函数都有 NatSpec：@notice、@param、@return。这听起来很枯燥，但它是最好的 bug 发现器之一：如果注释写"收 1% 手续费"而代码算的是 0.1%，读到第二行的人立刻会发现不一致；没有注释，错误数字看起来就像设计选择。
• 一页"运行理论"（theory of operation）：钱怎么走、谁能做什么、什么绝对不能发生。有治理、解锁、拍卖、清算这类生命周期的话，补一张调用图与状态机图。
• 一页威胁模型：谁是被信任方（owner、keeper、预言机），每一方叛变能破坏什么，以及你最不放心的那一个假设。这是审计员最想先看到的一页——一个发现是否成立，取决于你的信任假设；没有这页，每份报告都会变成"什么算攻击者范围内"的争论。
• 一段 20–30 分钟的视频走查：主程屏幕共享架构与资金流。这是把陌生人从零带到"能干活"最快的方式。

2. 打扫干净

• 跑 linter（Solhint / prettier-plugin-solidity）。审计报告里的风格建议，是花钱买免费工具就能做掉的事。
• 删死代码：未使用的函数、注释掉的块、留在生产合约里的测试辅助。死代码不一定真的死——一个内部辅助函数在后续重构里被暴露出来，是旧假设回归的经典路径。
• 锁定编译器与依赖：用精确版本（pragma solidity 0.8.x 而不是 ^0.8.0），锁定依赖版本。你部署的字节码应当来自被审计的那份代码。

3. 测试"难过"的路径

• 看分支覆盖率，不是行覆盖率。行覆盖只说明代码跑过；分支覆盖才说明每个 require、每个 if 正反都进过。大多数有意思的 bug 住在"本该 revert 却没有"的路径里。
• 跑静态分析（Slither）并处理所有告警：Slither 只需要几秒。修掉，或者写下为什么是误报。递过去 50 条未分诊的告警，等于让花钱请的人替你分诊。
• 在审计前跑一遍 AI 扫描：找明显问题的成本今年已经降得很低——对你也对部署后看代码的人都是如此。先跑掉、修掉真问题，人类审计的效率会更高。
• 写不变量并 fuzz（Foundry / Echidna）：单元测试检查你想得到的用例，不变量测试检查你没想到的。写几条必须永远成立的性质（比如"用户余额之和永远不超过合约持有量"），让 fuzzer 去打破它。哪怕只有几条好不变量，也能让审计员看出你怎么思考系统。

4. 冻结代码

• 打 tag（git tag audit-v1）并别再碰。审计期间推"小修复"会移动行号、让笔记失效，还会变成一份你额外付费的差异评审。中途自己发现的问题记下来，在整改轮里修——最好告诉审计员，让他们看看那附近。
• 把范围写进 scope.txt：精确到文件，排除 mock、部署脚本和未修改的库（如 OpenZeppelin）。如果改过某个库，明确写出来——这正是"我们只是用了 OZ"里最容易被藏住的东西。

一句话版本：文档（NatSpec + 运行理论 + 一页威胁模型）、代码（linter 干净、无死代码、编译器与依赖钉死）、测试（分支覆盖、难过路径、几条长时间 fuzz 的不变量）、工具（Slither 与 AI 扫描，每条告警修掉或解释）、冻结（tag + scope 文件 + 视频走查）。

二、"审计过"的真实边界：它覆盖的是一个 commit

原文有一段话值得原样保留思路：审计覆盖的是一个 commit——不包括你的部署脚本、你的配置、以及你在审计后那一周合并的三个 PR。

所以上线计划必须单独做：能后续提高的上限、一个你真的测试过的暂停开关、能叫醒人的告警。这和本系列前一篇的结论是同一条线：审计告诉你的东西有边界，而 77% 的季度损失来自审计范围之外的供应商、开发工具与特权组件（Hacken Q3，见 合约管理员是谁）。把审计范围扩展到预言机、桥、托管系统、签名权限，比把合约再审计一遍更值钱。

如果这周只做一件事：今晚就在核心合约上跑一遍 Slither。它标出你从没看过的东西——那就是你"准没准备好"的答案。

三、AI 把"找 bug"变便宜了：安静窗口消失

原文用一组数字说明环境变了：

• Debian 一次内核安全更新修了 1,313 个 CVE，The Register 的判断很直白："我们强烈怀疑这个数字是 LLM 机器人在找 bug 导致的"；
• Immunefi 称之为"漏洞末日（Vulnerability Apocalypse）"：CVE 提交量 2020–2025 年增长 263%，2026 年第一季度又高了 33%；NIST 只对其中 15–20% 做完整分析；
• 智能合约不是例外：Anthropic 的 SCONE-bench 研究里，AI Agent 为 405 个真实被黑合约中的 207 个写出了可用的利用；在 2,849 个新部署合约中发现 2 个新零日。平均每次 Agent 运行成本：$1.22。

作者的解读："找 bug"过去是安全里最贵的部分，现在接近免费——而且对"先跑扫描的人"免费。部署后的安静窗口没有了：有人可以在你上线那一小时用不到一杯咖啡的钱把 Agent 对准你的代码。"等有起色再审计"从来是一场赌注，现在是一场更差的赌注。

但这不是末日论：防守方拿到的是同样的工具，而且你的代码在攻击者看到之前，已经在你的仓库里放了几周。真正变稀缺的是判断力——AI 产出大量"听起来合理"的发现，而判断哪一条在你的系统、你的信任假设下是真实利用路径，才是现在贵的那部分。作者团队在 Immunefi 的 Quantus 审计竞赛中拿到 98 名研究者里的第 2 名，而所有人用的是同样的模型：差别在于把模型指向哪里、以及扔掉了什么。

对建造者的行动项：

1. 在别人之前扫描，并持续扫描：把 AI 安全检查当作测试——每个有意义的变更都跑，而不是上线前一周跑一次；
2. 把威胁模型写下来：一条发现只有相对于"你信任谁、什么绝不能坏"才是真的；没有这一页，你和你的审计员都无法分诊 AI 的输出；
3. 假设你的合约在上线第一天就被扫描：带着护栏上线——存款上限、对特权调用与偿付能力的监控、赏金、以及一个"坏日子"预案。审计覆盖的是一个 commit，不是之后发生的事。

原文给出的主网前三件套：一份干净的 AI 扫描结果、一页威胁模型、一份带护栏的上线计划（可后续提高的上限、真的测试过的暂停、能联系到人的告警、以及存好 SEAL 911）。

四、Agent 走进审计流程：四个控制 + 人在哪

如果 AI 已经进入"发现"环节，那它同样会进入"执行"环节——比如让 Agent 做银行对账这类高重复、高量级的审计程序：把公司账、对账表、银行证据都喂给它，把审计方法写进提示词，用往年被复核过的审计作样例，再从历史审计里造一个评测，最后由人签字。

问题出在"被抽中复核"的那一天：没人关心评测分数，也没人关心用户满意度——他们问的是：这一份审计、这一个具体决定，为什么是这样做的？

原文引用审计标准给"可辩护"下的定义："一位有经验但没做过这项工作的审计员，能够顺着你的过程读下去"——翻译过来就是"能顺着 Agent 读下去"。它被拆成四个控制：

四者之外还有一条主线：每个失败案例里都有"本该交给人"的时刻——当 Agent 即将改动人签过的工作、当重跑与记录不一致、当证据与条目不匹配、当必需规则不通过。而"升级"的设计原则是：升级要容易验证，而不是容易批准。触发时问一个具体问题、把冲突证据并排展示、并记录人的回答。

这些控制不只属于银行对账或金融审计。一笔被拒绝的贷款、一条被关闭的 AML 告警、一次价格裁定，同样的四个问题每次都适用：这个动作被允许吗？能展示它跑了什么吗？每个声明都绑定到正确的来源了吗？这个基准可信吗？只要 Agent 的财务决定可能被质疑，"可辩护"而不只是"正确"，就是标准线。

五、给你的上线前清单

把三篇合成一份可以直接照做的清单：

审计前

• [ ] 所有 public/external 函数的 NatSpec + 一页运行理论 + 一页威胁模型 + 视频走查；
• [ ] linter 干净、删死代码、编译器与依赖精确锁定；
• [ ] 分支覆盖率、难过路径测试、Slither 告警全部修掉或解释、审计前先跑一遍 AI 扫描；
• [ ] 写不变量并长时间 fuzz；
• [ ] git tag audit-v1 冻结 + scope.txt 明确到文件（改过的库要注明）；
• [ ] 审计期间不再推代码；自己发现的问题留到整改轮。

上线前

• [ ] 部署脚本、配置、权限初始化单独评审（它们不在审计范围内，却同样可能持有初始化、升级、转账等特权——用前一篇的 cast 命令清单自行核实"谁能换掉代码、谁能动钱"）；
• [ ] 可后续提高的存款/仓位上限、真的测试过一次的暂停开关、能叫醒人的告警、SEAL 911；
• [ ] 用 Revoke 收掉部署/测试钱包里不再需要的代币授权，特权地址与签名权限按前一篇的方法逐条核实；
• [ ] 对特权调用与偿付能力做监控；上一条"监控谁签了名"和"监控钱还在不在"同样重要。

Agent 进流程之后

• [ ] 授权到"对象 + 状态 + 时刻"，不只是"身份 + 工具"；
• [ ] 每个决定可被拆到步骤级重放（输入、输出、模型版本、稳定 ID）；
• [ ] 引用绑定文档 ID/版本/哈希，并校验证据属性；
• [ ] 金标准标签带方法论与期间，漏判与命中一起审计，按切片报告；
• [ ] 明确"交给人"的触发条件；升级设计成容易验证，不是容易批准；
• [ ] 记住一句：评测通过不等于可辩护——前者回答"分数够不够"，后者回答"能不能顺着它读下去"。

相关阅读

• 合约管理员是谁：146 个 Morpho 金库的权限实测
• 链上核验清单：收据、钱包与授权，别只看表面
• Agent 支付安全：x402 六种错误交易与 25 微秒护栏
• 加密钱包安全自查手册 2026：从 Ledger 供应链到授权撤销
• 专题：链上数据 / 安全与调查完全指南

本系列另两篇：Agent 审计日志：证人即嫌疑人，怎么让谎言留下痕迹（当行动者与记录者是同一个进程，"证据"该长什么样）与 别用眼睛验收 3D 产物：44 行探针与网格体检（同一套"先量再信"落到 3D 动画与网格审计上）。

来源

• @bloqarl, What to have ready before your first smart contract audit（dev.to，2026-10-13；改编自 zealynx.io 清单，AI 辅助起草、观点为作者本人）：https://dev.to/bloqarl/what-to-have-ready-before-your-first-smart-contract-audit-580b
• @bloqarl, Finding bugs just got cheap. For everyone.（dev.to，2026-10-09；含 SCONE-bench 与 Immunefi Quantus 竞赛数据）：https://dev.to/bloqarl/finding-bugs-just-got-cheap-for-everyone-36ip
• @dailycontext（Anirudh，Fieldguide 安全负责人）, Your Financial Agent Passed Every Eval. Can You Defend Its Decision?（dev.to，2026-10-14）：https://dev.to/dailycontext/your-financial-agent-passed-every-eval-can-you-defend-its-decision-1npg

本文由 DefiPlot 翻译整理，转载请注明出处。

免责声明

本文仅用于学习与研究目的，不构成任何投资建议、财务建议或交易建议。文中的统计数据与审计经验来自原文作者自述及公开研究（SCONE-bench、Hacken 等），未做独立复测；相关作者与所在机构均带有各自立场（已在文内披露）。任何审计、扫描与检查清单都不能替代你自己的核验与 DYOR（Do Your Own Research）。加密资产与链上交互存在合约漏洞、权限升级、预言机、跨链桥与钓鱼风险；请勿使用无法承受损失的资金参与。

本文属于「链上数据 / 安全」专题。查看专题全部文章 →

免责声明：本站资源仅用于学习目的，也不应被视为投资建议，读者在采取任何行动之前应自行研究并对自己的决定承担全部责任。