先明确要查哪一种文档
“区块链审计公司案例的设计文档怎么查”需要先区分对象：项目设计文档解释系统预期如何工作，审计报告记录特定范围内的检查与发现，审计公司的内部工作文档则可能不公开。本文讨论智能合约案例中公开技术文档的查找与核验，不涉及某家公司的已核实案例。
从案例线索追溯设计依据
查找时可以从审计公司的案例页面或项目方公布的报告入手，寻找项目名称、代码仓库、审计范围、版本标识和参考文档链接。再沿这些线索查找项目的技术说明、仓库说明文件与设计讨论。这里列出的是查找路径，不代表每个案例都会公开这些材料。
检索词可组合项目名与“设计文档”“架构”“技术规范”，也可使用 design、architecture、specification。找到文件后，应记录其对应版本；当前文档可能已经更新，不能直接用于解释历史审计结论。
怎样判断文档是否有核验价值
有核验价值的设计说明应让读者理解合约职责、角色权限、关键操作的前提条件，以及系统需要始终满足的约束。阅读时可以逐项追问：谁能执行敏感操作，异常输入如何处理，哪些状态变化必须被阻止，这些规则在何处得到测试。
以太坊开发者安全指南强调访问控制、条件检查、多种测试方式及独立审查，也指出清晰的代码文档有助于审计。由此可以把设计规则与实现、测试相互对照，但不能仅凭文档齐全就认定系统安全。
以权限设计为例交叉核验
OpenZeppelin 的访问控制说明区分了单一所有者与角色权限模型，并说明角色管理员负责授权与撤销权限。核验设计时，既要查看谁能执行某项操作，也要查看谁能改变执行权限。
例如，文档若写明铸币与管理权限分离，可进一步对照角色定义、初始化配置和授权逻辑。这个例子只说明核验方法；出现多个角色名称并不足以证明实际控制权已经分散，也不能据此推断某个具体项目不存在权限风险。
文档缺失与审计结论的常见疑问
只有审计报告，能否还原完整设计？报告中的系统概述可以提供线索，但未覆盖的模块与业务规则仍需另行核实。代码可以帮助理解实现行为，却未必能解释设计取舍。
找不到设计文档，是否意味着没有做审计？不能这样判断，公开材料不足只能说明外部核验受到限制。审计通过也不意味着没有漏洞；判断结论是否适用，应核对报告范围、代码版本，以及修复是否经过复核。