← Retour aux guides

用 Claude 构建代码迁移工具：7 个可落地的开发技巧

1. 先把“迁移”定义成可验证的规则

不要直接把整个仓库交给模型并要求“升级代码”。先把任务拆成原子规则，例如：将某个 SDK 的初始化方式替换为新写法、把废弃函数映射到目标函数、补齐新增参数。每条规则应包含触发条件、目标改动、禁止改动范围和验收标准。规则越明确，Claude 输出的补丁越稳定，也更容易定位失败原因。

2. 用 AST 找文件，用 Claude 做语义判断

代码迁移工具不应只依赖正则替换。先使用 TypeScript Compiler API、Babel、tree-sitter 或语言自带解析器扫描导入、调用表达式和类型声明，筛出候选文件；再将相关函数、类型定义和少量调用上下文发送给 Claude。AST 负责精确定位，Claude 负责判断复杂业务语义，例如回调改 Promise、配置拆分或异常处理差异。

3. 控制上下文：只发送必要代码

为每个候选点构造紧凑上下文：目标代码前后各 50 至 100 行、关联 import、被调用接口签名，以及迁移规则。大型文件可按函数或类切片，并给每段附上文件路径和行号。要求模型返回统一 diff 或结构化 JSON，例如包含文件路径、替换区间、修改后代码和理由。这样可以避免模型重写无关部分，也便于程序自动应用补丁。

4. 设计严格的提示词输出契约

提示词应明确要求：不修改未命中的代码；保留现有格式与注释；无法安全迁移时返回 needs_review；禁止虚构不存在的 API。对于 JSON 输出，要求字段固定且不包含额外文本。调用后先做 JSON Schema 校验，再校验文件路径、行号和补丁是否冲突。把“模型建议”与“实际写盘”分离，能显著降低批量误改风险。

5. 建立三层校验链路

• 语法校验：应用补丁后立即运行解析器或编译器，拦截括号、导入和类型错误。
• 静态校验：执行 ESLint、类型检查和依赖扫描，确认新 API 的使用方式合法。
• 测试校验：优先运行受影响模块的单测，再按风险决定是否执行完整测试套件。

校验失败时，不要让 Claude 在原文件上无限重试。应把错误日志、当前补丁和原始规则作为新的受限输入，最多重试两到三次；仍失败则标为人工审核。

6. 让每次迁移可审计、可回滚

每次运行创建独立 Git 分支或工作区，记录模型名称、提示词版本、输入文件摘要、响应、补丁、校验结果和耗时。为每个变更生成迁移报告，按“自动通过、需要审核、失败”分类。实际合并前通过 pull request 展示 diff，开发者只需重点审查高风险变更。这个机制也能帮助团队持续改进规则与提示词。

7. 用 59API 把批量迁移成本降下来

代码迁移通常需要大量小请求：扫描后的候选点判断、补丁生成、失败修复和测试日志分析。59API 提供按量付费的 Claude Opus、Sonnet、Haiku、Fable 及 GPT 模型访问，API Base URL 为 https://api.59api.com，并兼容 Claude Code、Codex 与 OpenAI SDK。可将 Haiku 用于初筛和分类，将 Sonnet 用于常规补丁，把 Opus 留给跨文件、高风险迁移，以更低成本获得原生官方质量模型能力。需要长期批量处理仓库时，可注册 59API 并结合其推荐返佣机制进一步优化支出。

真正可靠的 AI 迁移工具，不是一次生成大量代码，而是把模型放进“定位、生成、验证、审查、回滚”的工程闭环。先从一条可测试的迁移规则开始，再逐步扩大自动化覆盖范围。

Tarifs · Docs