用途：开发与排查 dbt 增量（incremental）模型，帮助选择物化策略、设计 unique_key 并处理边界情况。默认建议：除非有明确性能理由，否则用 table。源数据小于 1000 万行用 table；大于 1000 万行考虑 incremental；原地更新用 merge；仅追加（日志、事件）用 append；分区表在支持时用 insert_overwrite。
主要能力：按“确认是否需要增量—理解源数据模式—选择策略—设计唯一键—编写模型—先全量刷新—测试增量逻辑—处理模式变更”的工作流推进，并给出 merge 重复键、无分区裁剪、迟到数据、模式漂移、数据漂移等常见问题的排查与修复方式。
策略要点：append 无需 unique_key，最快，仅用于只追加数据；merge 需 unique_key，处理更新与插入，最常用；delete+insert 先删匹配行再插入，适合批量重处理或 merge 出现重复键时；insert_overwrite 替换整个分区，适合 BigQuery/Spark 分区表。策略可用性因适配器而异，需查阅对应仓库的 dbt 文档。
必要用法：先检查源表规模，例如 dbt show --inline "select count(*) from {{ source('schema', 'table') }}"；先验证唯一性再建模型；首次务必全量刷新验证：dbt build --select <model_name> --full-refresh，随后 dbt build --select <model_name> 跑增量并核对行数。模式变更用 on_schema_change（ignore、append_new_columns、sync_all_columns、fail）。迟到数据用回看窗口，如 where updated_at >= {{ dbt.dateadd('day', -3, dbt.current_timestamp()) }}。
限制与注意：应始终先用 --full-refresh 测试；确认 unique_key 在源与目标中真正唯一；定期全量刷新防止数据漂移；避免对小表用增量、对可更新数据用 append、用非唯一键 merge、依赖精确时间戳而无回看窗口等反模式。具体适配器支持情况与价格等信息暂未提供。