用途
该技能面向分析工程（analytics engineering）而非原始数据摄取场景，帮助智能体构建可信的 dbt 项目，具备清晰的分层、可复用的模型、测试、文档以及可安全发布的业务定义。
适用时机
- 创建或修改 dbt 模型
- 构建 staging、intermediate 或 mart 层
- 添加测试、快照或 exposures
- 为分析师和 BI 工具组织业务逻辑
- 准备语义层友好的输出
不应用于为将数据摄取或编排逻辑放入 dbt 提供理由。
工作流
- 确认模型的角色。判断它属于哪一层：staging、intermediate、marts、snapshot 或语义服务层。
- 定义业务粒度和契约。记录：键、指标意图、过滤逻辑、空值处理、新鲜度预期。
- 随模型添加测试和文档。典型检查包括：unique、not null、relationships、accepted values，以及相关情况下的 source freshness。
- 保持模型边界清晰。避免在单个模型中混合原始数据清理、业务逻辑和发布语义。
- 验证下游可用性。确保输出对分析师、仪表盘和指标消费者而言是可理解的。
常见合理化借口与事实
- “这只是 SQL，不需要模型结构。”——分层不当会导致 marts 脆弱并产生重复的业务逻辑。
- “我们可以等仪表盘跑通后再加测试。”——未经测试的指标会造成难以消除的信任问题。
- “一个巨大的模型更容易维护。”——单体模型会隐藏粒度变化、假设和复用机会。
危险信号
- 模型粒度不清晰
- 业务逻辑在多个 marts 中重复
- 变更未附带 YAML 测试或文档
- 发布模型直接依赖原始数据源而没有清晰的 staging 层
验证清单
- 模型具有清晰的层级和业务目的
- 粒度、键和指标假设是明确的
- 测试和文档随模型一同交付
- 已考虑下游消费者的输出可用性