用途：把遗留 SQL 转换为模块化的 dbt 模型，适用于将存储过程、视图或原始 SQL 文件迁移到 dbt 的场景。
主要能力与工作流：先分析遗留 SQL（cat <legacy_sql_file>），识别其中引用的所有表；再检查已有模型与 source 定义（grep -r "<table_name>" models/ --include=".sql" --include=".yml"，find models/ -name "*.sql" | xargs grep -l "<table_name>"）。若某表既无模型也无 source，需询问用户是否创建为 source，待所有依赖就绪后再进入中间层与 mart 层。随后创建缺失的 source（models/staging/sources.yml，含 name、schema、tables 及 description），按每个源表一个 staging 模型构建，遵循项目既有命名规范，并用 dbt build --select <staging_model> 验证；必要时抽取复杂 join 与逻辑到 intermediate 模型并增量构建；最后构建面向业务的 mart 聚合模型。
验证方式：dbt build --select +<final_model> 构建完整血缘，dbt show --select <final_model> 查看结果。迁移清单包括：识别并记录所有源表、创建带描述的 sources.yml、staging 与源 1:1 并重命名列、intermediate 抽取业务逻辑、mart 完成最终聚合、每层编译与构建成功、行数与原始一致（人工校验）、为关键约束添加测试。
常见模式：嵌套子查询拆为独立模型（staging→intermediate→mart）；临时表用 {{ config(materialized='ephemeral') }}；硬编码值改用 {{ var("name") }}。
反模式：把整个遗留查询转成单个 dbt 模型、跳过 staging 层、未逐层验证、保留硬编码值、迁移中不记录业务逻辑。
限制：资料未提供具体支持的数据库平台、版本要求、收费或价格信息。