我如何使用 AST + AI 自动化 Web3.py v6 到 v7 的迁移
Source: Dev.to
Web3.py v7 引入了一个比普通依赖升级更痛苦的迁移问题。它改变了中间件架构、提供者名称、异常导入方式以及命名空间的使用方式，这些改变如果机械化迁移，极易导致生产代码崩溃。
我构建了 Web3.py v7 Zero‑BS Migrator，通过混合方式自动化升级：对可静态证明的更改使用确定性的 AST 转换，对无法仅凭语法规则安全翻译的中间件模式使用高度受限的 AI 重写层。
项目链接
- DoraHacks 提交：
- 演示视频：
- GitHub PR：
- 在线应用：
问题
Web3.py v7 最大的破坏性改动是从函数式中间件迁移到基于类的中间件。这意味着许多现有代码库无法仅通过简单的搜索‑替换完成升级，因为中间件通常包含自定义逻辑和项目特定行为。
迁移还包括诸如 WebsocketProviderV2 → WebSocketProvider、.ws → .socket，以及异常和 AttributeDict 的更新。在真实的代码库中，这些改动重复出现，容易遗漏，手动审查成本高昂。
设计
第 1 层：确定性 AST 转换
第一层使用基于 Tree‑Sitter 的 AST 转换，处理可以确定性转换的迁移模式。覆盖提供者重命名、异常导入调整、AttributeDict 的更改以及 .ws → .socket 等命名空间更新。
只要可以仅凭语法证明转换的正确性，就应使用确定性规则而非 AI。
第 2 层：受限 AI 用于中间件迁移
第二层仅针对函数式中间件保留，因为确定性翻译不足以完成。工具在沙箱化的 NVIDIA NIM Llama‑3‑70B 中对相关函数节点进行重写，而不是对整个文件进行处理。
这样可以将 AI 组件限制在唯一能提供实际价值的区域，同时通过上下文注入、缩进跟踪、重试逻辑和废弃处理等安全控制，使重写在实际使用中保持可靠。
结果
- 120 文件测试套件
- 共发现 142 条模式
- 自动化处理 130 条
- 自动化覆盖率 91.5 %
- 误报 0 条
- 评估得分 98.59
关键教训很简单：尽可能使用确定性转换，只有在迁移涉及架构层面而非纯语法时才使用 AI。如果迁移工具能尊重这一边界，它既可以快速又可信。
在实际操作中，从 Web3.py v6 升级到 v7 的团队可以快速自动化大部分迁移工作，同时将自定义中间件视为受控且可审查的重写步骤。
演示与链接
- DoraHacks 提交：
- 演示视频：
- GitHub PR：
- 在线应用：
结束语
构建此工具的最大收获是，迁移工具在将确定性代码转换与架构判断分离时效果最佳。Web3.py v7 正是说明这种区分为何重要的典型案例：有些破坏性改动只是简单的重写，而另一些则需要更深入的意图理解。如果迁移工具能尊重这一边界，它既能快速又可信。