dbt+SQLServer构建数据仓库(8)：Vibe Coding用dbt构建data vault数仓

前言

最近 AI 编程很火，"vibe coding"这个词也经常听到------就是你只需要说清楚"我想要什么"，AI 就能帮你把代码写出来。但dbt并不像其它技术那样火热，所以当前的vibe coding是否能很好的支持dbt项目生成呢？我决定拿一个数据仓库项目练手，全程用 vibe coding 的方式完成，看看效率到底怎么样。

项目目标很明确：用 dbt 在 SQL Server 上搭建一个三层架构的数据仓库，core 层"尽量"按 Data Vault 2.0 规范，mart 层用维度模型 + 宽表。

我的Vibe coding环境： VSCode + Claude Code + CC + Deepseek V4 flash。

注：我用的是火山引擎的coding plan和agent plan。

下面是完整的过程记录。

一、开局：一条提示词定方向

我在项目目录里放了一个 INIT.md，方便信息和思路的组织和整理，里面写了短短几行需求：

这个项目中，我想用dbt来搭建数据仓库。dbt已安装。

在目标数据库中，business_db是OLTP库。

stage_db是数据仓库的stage层。

core_db是core层。

mart_dw是mart层。

core层的数据按照data vault的方式进行组织，代码的实现尽量符合data vault 2.0的方式。

mart层的数据按照维度模型进行组织。此外宽表也在这一层。

就这么多------没有设计文档，没有表结构，没有技术选型细节。我把这个文件内容连同"帮我做这个项目"的意思一起丢给了 AI。

我的预期是：它至少得问我几个问题才能动手吧？毕竟 Data Vault 2.0 这么多细节要确认。

由于我安装了superpowers这个skills，所以它没有直接开干，而是启动了一个"头脑风暴"流程，开始一个问题一个问题地跟我确认。

二、你来我往：6 个关键问题把需求聊清楚

整个设计阶段，AI 通过superpowers的头脑风暴技能，一共问了我 6 个问题，都是选择题的形式，每个问题都给出了选项和推荐方案。我基本上都选了"按最佳实践来"。

问题 1：源表有哪些？先搭框架还是基于真实表？

为了让AI尽快知道我的数据环境，我没有让AI自己去看，而是直接把三张源表（customers、orders、products）的建表脚本贴了过去。三张表很经典：客户、订单、产品，订单同时关联客户和产品。

问题 2：加载方式选增量还是全量？

"全按最佳实践来。"， Hub/Link 用 insert-only，Satellite 用 hashdiff 判断版本，维度用全量，事实用增量，每种表用最合适的策略。

问题 3：Data Vault 的 hashkey 怎么生成？

选项有三个：标准 DV 2.0 的 hashkey + hashdiff、直接用业务主键、hashkey 但不用 hashdiff。我选了 A. 标准 DV 2.0：hashkey + hashdiff。既然要做就做规范的。

问题 4：Mart 层做哪些内容？

"全部做。"------维度表（客户/产品/日期）、事实表（订单事实）、宽表（订单宽表），一个都不能少。

问题 5：目录结构按层分还是按业务域分？

选了 按层划分（staging / core / mart），这是 dbt 官方推荐的方式。命名约定也按社区通用的来。

问题 6：周边特性要哪些？

测试、文档、宏、增量策略......还是那句话："按最佳实践来。"

总体来看superpowers的头脑风暴还算靠谱。我建议大家不管是什么项目，在开始之前都头脑风暴一下，即使你对相关的领域已经非常的熟悉。反正就是多聊，肯定没坏处，目前为止还没看到这个技能有问任何不靠谱的问题。

三、方案确认：两种架构思路选一个

聊完所有细节后，AI 没有直接开写，而是先给出了两种方案让我选：

方案一（推荐）：标准分层架构，严格 Data Vault 2.0，3 个 Hub + 1 个 Link + 3 个 Satellite
方案二：轻量简化版，减少模型数量

我选了方案一。既然是学习项目，就要做标准的。

然后另外一个skill被触发：superpowers:subagent-driven-development。AI 分五节把完整设计呈现给我确认：整体架构 → Stage 层 → Core 层（DV） → Mart 层 → 宏/测试/文档。每一节我确认 OK 才继续下一节。

最后还生成了一份正式的设计规格文档，存在 docs/superpowers/specs/ 目录里。

这里吐槽下目前VSCode + Claude Code的子智能体，主智能体派发任务到子智能体后，子智能体干啥细节完全看不到。前段时间用Trae，发现所有智能体都有单独的输出模块。虽然对输出的模块细节可能没人在意，但是最起码知道它还是在干活的。要知道智能体总会有假死/摸鱼的情况发生，你不踢它一脚它真的就会一直木讷在那里。

四、实施：12 个任务，全程自动推进

设计确认完之后，AI 没有让我再做任何决定。它自动生成了一份包含 12 个任务的实施计划，然后一个任务一个任务地执行，每个任务完成后还会自己做代码审查。

整个过程我就坐在旁边看，偶尔帮它点一下"继续"（因为安全分类器偶尔超时需要重试）。

任务顺序是这样的：

任务	内容
1	项目脚手架（dbt_project.yml + profiles.yml + 目录结构）
2	DV 2.0 宏（generate_hashkey / generate_hashdiff / get_current_load_date）
3	Stage 层模型 + schema.yml（3 个模型）
4	Core 层 Hub 表（3 个）
5	Core 层 Link 表（1 个）
6	Core 层 Satellite 表（3 个）
7	Core 层 schema.yml（测试 + 文档）
8	Mart 层维度表（3 个）
9	Mart 层事实表（1 个）
10	Mart 层宽表（1 个）
11	Mart 层 schema.yml（测试 + 文档）
12	全量编译 + 文档生成验证

每个任务都是"写代码 → 编译验证 → 代码审查 → 提交"的闭环。审查有问题就修复，没问题就进入下一个。

五、中途的几次更改

虽然整体流程很顺，但也不是完全一帆风顺。有几处地方我介入做了调整。

更改 1：stage 层从视图改成表

跑通了之后我发现 stage 层用的是视图，需要改成表。我说了一句"stage 的表是视图？我希望他们都是表。"

AI 直接改了 dbt_project.yml 里的一行配置（+materialized: view → +materialized: table），然后重新跑了 dbt run --full-refresh，两分钟搞定。

更改 2：dim_date 递归 CTE 语法问题

第一次跑 dbt run 的时候，dim_date 报错了：

复制代码

Incorrect syntax near the keyword 'OPTION'.

原因是 SQL Server 递归 CTE 的 OPTION (MAXRECURSION 0) 放在 dbt 生成的外层 SQL 里不工作。AI 很快把 dim_date 改成了用数字序列表（CROSS JOIN 四个 0-9 的表生成 10000 个数字）的方式，同样的效果，兼容性更好。

修复后重新跑，一次通过。

更改 3：profiles.yml 连接参数

项目模板里的 profiles.yml 是 localhost + 默认密码的占位符。我把自己机器上的实际连接配置发给 AI，它同步更新了 profiles.yml 和 dbt_project.yml 里的 profile 名称。这一步很简单，但它做了一件额外的事------自动运行了 dbt debug 验证连接是否通。

六、最终结果

全部跑完之后的数据：

15 个模型全部构建成功（3 stg + 3 hub + 1 link + 3 sat + 3 dim + 1 fct + 1 wide）
94 个数据测试全部 PASS（unique、not_null、relationships，没有一个失败）
11 个 git 提交，每个任务一个提交，提交信息规范
dbt docs 生成成功，可以在浏览器里看血缘图

三层架构的数据仓库，从 0 到跑通所有测试，花了多少时间呢？

设计确认阶段 + 实施阶段，加起来大概半天的时间。

如果我自己写，先不说代码量有多少，光是回忆 Data Vault 2.0 的各种规范（hashkey 怎么拼、satellite 的增量逻辑怎么写、link 的命名规则）就要查半天资料。更别说 15 个模型 + 两个 schema.yml + 宏，手写至少要两三天。

七、Vibe Coding 心得

经过这次实战，我对 vibe coding 有了一些具体的感受：

✅ 好的地方

不用纠结脚手架------目录结构、配置文件这些重复劳动，说一声就给你搭好了，而且比自己写的还规范。
知识密度高 ------你可能只知道 Data Vault 的概念，但 AI 知道具体怎么落地：hashkey 用 business_key + '^^' + source_system，satellite 用 hashdiff 判断变化，这些细节它直接给你最佳实践。
设计过程很舒服------不是上来就堆代码，而是先跟你确认需求，分层呈现设计，每一节都让你拍板。这个过程本身也是学习。
改需求成本极低------"我想把 stage 从视图改成表"，一句话的事，改配置 + 重跑一条龙。

⚠️ 需要注意的地方

你得先知道自己要什么------vibe coding 不是"你帮我随便做个数据仓库"就行。你得对目标有基本概念，不然连问题都听不懂。我不知道 Data Vault 2.0 大概是啥的话，那 6 个问题我也答不上来。
要会审查结果------ dim_date 的 OPTION 语法问题，AI 自己也踩坑了。你得能看懂报错，知道是它的问题还是你的问题。当然，它自己会修，但你得知道是怎么回事。
不是完全不用管------安全分类器偶尔抽风、数据库连不上、环境配置，这些还是得人来。AI 是生产力工具，不是完全替代。

🔑 我的体会

Vibe coding 最适合的场景是：你懂业务、懂设计，但具体的语法和样板代码不想自己写。你负责"要什么"和"对不对"，AI 负责"怎么写"和"写出来"。

对于这个 dbt + Data Vault 项目来说，我知道三层架构是什么、Data Vault 大概有哪些组件、维度模型怎么回事------但具体到 SQL Server 的 MD5 怎么写、dbt incremental 模型的模板长什么样、94 个测试一个个写 schema.yml，这些体力活交给 AI 效率提升非常明显。

一句话总结：vibe coding 不是让你不用思考，而是让你把思考用在更有价值的地方。

附：项目文件结构速览

复制代码

DBTSQLDV/
├── dbt_project.yml              # 三层分库配置
├── profiles.yml                 # SQL Server 连接
├── macros/                      # 3 个 DV 2.0 宏
├── models/
│   ├── staging/                  # 3 个 STG 表
│   ├── core/                     # Data Vault 2.0
│   │   ├── hubs/                 # 3 个 Hub（insert-only）
│   │   ├── links/                # 1 个 Link
│   │   └── satellites/           # 3 个 Satellite（hashdiff 版本化）
│   └── mart/                     # 维度模型 + 宽表
│       ├── dimensions/           # 客户维 / 产品维 / 日期维
│       ├── facts/                # 订单事实表
│       └── wide/                 # 订单宽表
└── docs/
    └── superpowers/
        ├── specs/                # 设计规格文档
        └── plans/                # 实施计划

感兴趣的朋友可以自己试试，dbt + Data Vault 这个组合挺适合 vibe coding 练手的------规范明确、模式固定、代码量大但重复度高，正好是 AI 最擅长的领域。