评估智能合约/区块链代码库成熟度：用 Trail of…

当你需要按统一评分标准为智能合约或区块链项目做代码成熟度评估、打分，或判断其测试与文档水平是否达标时使用。

适用场景

解决思路

1. 先做发现阶段：浏览代码库，确认项目结构与运行平台，列出合约/模块文件、测试文件和文档所在位置，掌握测试覆盖与文档可用性。
2. 逐一对 9 个类别做分析：在代码中搜索相关模式、阅读关键实现文件、对照评估标准给出发现、为每条发现附上 file:line 证据、就代码中看不到的流程提出澄清问题，最后确定评级。
3. 使用 0-4 评级体系：Missing(0) 不存在/未实现；Weak(1) 有多处重大改进点；Moderate(2) 基本够用但可改进；Satisfactory(3) 高于平均仅需小改；Strong(4) 卓越仅剩小改进空间。
4. 按逻辑定级：任一 Weak 标准命中即整体 Weak；无 Weak 但有部分 Moderate 未满足则 Moderate；全部 Moderate 满足且命中部分 Satisfactory 则 Satisfactory；全部 Satisfactory 满足且有卓越实践则 Strong。
5. 类别 1 算术：检查溢出保护机制、精度处理与舍入、公式规范、边界情况测试。
6. 类别 2 审计：检查事件定义与覆盖范围、监控基础设施、事件响应计划。
7. 类别 3 认证/访问控制：检查权限管理、角色分离、访问控制测试、密钥泄露场景。
8. 类别 4 复杂度管理：检查函数范围与清晰度、圈复杂度、继承层次、代码重复。
9. 类别 5 去中心化：检查中心化风险、升级控制机制、用户退出路径、时间锁/多签模式。
10. 类别 6 文档：检查规范与架构文档、内联代码文档、用户故事、领域术语表。
11. 类别 7 交易排序风险：检查 MEV 漏洞、抢先交易防护、滑点控制、预言机安全。
12. 类别 8 底层操作：检查汇编使用、不安全代码段、底层调用，以及这些做法的正当性与测试。
13. 类别 9 测试与验证：检查测试覆盖、模糊测试与形式化验证、CI/CD 集成、测试质量。
14. 探索代码库时执行三步：查找合约/模块文件、识别测试文件、定位文档。
15. 推进交互式评估：展示带文件引用的发现、询问代码中看不到的链下流程、讨论边界情况、与用户共同确定评级。
16. 必须完整评估全部 9 个类别并为每类提供证据，不能因为‘已发现一些问题’就提前结束。
17. 审计类别不能只看到事件定义就判定良好，还要检查日志记录的全面性、相关测试与事件响应流程。
18. 复杂度不能凭‘代码看起来简单’下结论，要分析圈复杂度、依赖深度和状态机状态转换。
19. 即使不是 DeFi 协议也不能直接判定 MEV 类别不适用，MEV 同样影响治理、NFT、游戏等项目，需先做交易排序分析再决定是否 N/A。
20. 底层类别不能因‘没发现汇编’就跳过：还要搜索外部调用、delegatecall、内联汇编等所有底层模式后再决定。
21. 即使评估耗时较长，也要完成全部 9 个类别并主动询问链下流程，不能省略。
22. 每个类别的评级都必须有 file:line 等具体代码证据支撑，不能无证据打分。
23. 报告第一步输出执行摘要：项目名称与平台、整体成熟度（平均评级）、前 3 项优势、前 3 项关键缺口、优先建议。
24. 报告第二步输出成熟度记分卡：覆盖全部 9 个类别的表格，含评级、分数与关键发现说明。
25. 报告第三步输出详细分析：逐类别拆解，附 file:line 证据、缺口与对应改进动作。
26. 报告第四步输出改进路线图：按 CRITICAL（立即）、HIGH（1-2 个月）、MEDIUM（2-4 个月）排序，并标注工时估算与影响。
27. 不要给出含糊建议：路线图必须提供具体改进项和工时估算，确保可执行。
28. 需要更细标准时查阅附带资源：ASSESSMENT_CRITERIA.md 看各类详细标准与评级阈值，EXAMPLE_REPORT.md 看完整示例报告，REPORT_FORMAT.md 看报告结构与模板。
29. 开始前向用户索取：完整代码库访问权、其对链下流程（监控、事件响应、团队实践）的了解、项目背景（DeFi、NFT、基础设施等），并告知预计耗时 30-40 分钟。

适用边界 · 注意事项

• 评估对象不是智能合约或区块链代码库时（该框架与 9 类标准专为链上合约设计），不要套用。
• 无法访问完整代码库、也拿不到链下流程信息（监控、事件响应、团队实践）时，评级会缺乏依据，不宜给出成熟度结论。
• 只想做快速印象判断或单点漏洞审计时不适合：完整评估需逐类收集证据，通常要 30-40 分钟以上。