审查是一条可重复的生产线
每一份报告都应该能让另一个人沿着同一条证据链走完。做不到，就还只是阅读笔记。
- 固定范围
仓库 commit、合约列表、链、部署地址、排除项和已知问题。
- 构建运行
依赖锁定，原测试全绿。无法构建就停止假装审计。
- 架构资产
角色、入口、出口、代理、预言机和外部调用先画出来。
- 权限矩阵
谁能改规则，失陷后能拿走什么。
- 写下不变量
5 到 15 条系统必须永远成立的话。
- 逐函数审查
先价值转移，再管理升级，再价格会计，再回调。
- 工具与动态
静态枚举、单元、fuzz、invariant、必要时 fork。
- PoC 与严重度
路径、前提、影响，然后才标档。
- 修复复核
只看 diff。原 PoC 应失败，正常路径应仍通过。
先对齐“审计”这个词
Cyfrin 这段只有六分钟，用来建立委托方和审查方的共同语言。看完回到上面的流程，检查自己会不会把审计说成“跑一个扫描器”。
若要看完整审查示范，用 Patrick Collins 的 Security and Auditing Full Course。本课不要求看完 21 小时，需要时再按主题回看。
范围没锁死，结论全部作废
commit审查对象是一个哈希，不是“最新 main”。
deploy链、代理、实现、构造参数必须对得上。
out明确排除项。没看过的合约不要写进保证。
trust把“我们信任多签 / 预言机 / 管理员”写成假设，而不是偷偷忽略。
先画图，再逐行读
重点列出两类函数：资产损失必须经过的函数，以及能改变系统规则的函数。
钱怎么进来，怎么出去
- 存款、借款、兑换、清算
- 内部记账与真实余额是否一致
- 费用、份额和坏账怎么记
谁能改游戏
- Owner、Upgrader、Guardian、Keeper
- 暂停、参数、实现地址
- 多签与时间锁是否真的约束执行
单个 EOA 能升级并转走资产，如果文档声称去中心化，这是严重的设计或披露问题。如果文档写明了，它仍必须出现在权限矩阵里。
不变量是审查的骨架
每条不变量对应手工检查点和自动测试。不要把实现细节改写成断言。
不要用惊吓程度代替严重度
Critical可大规模、直接且现实地损失核心资产或接管系统。
High重大损失或关键功能破坏，需要一定条件。
Medium有限损失、局部 DoS、重要规则破坏或较强前提。
Low / Info影响较小、条件苛刻，或只是透明度问题。
一份 finding 要让开发者能修
复核时只看实际 diff。检查修复是否引入新路径，原 PoC 应失败，正常行为测试应继续通过。链上更新后重新核对部署交易。
对一个公开练习项目写出 5 条不变量、一张权限矩阵，以及一个带路径和影响的 finding 草稿。草稿可以判为误报，但不能没有证据结构。