阅读材料: 第21部分. Qwen Code 流程用于 DataLakeHouse

模块「第21部分. Qwen Code 流程用于 DataLakeHouse」中第 1 / 5 节课

您正在未登录状态下查看课程。请登录，以保存进度并参加测试。

来源

第 21 部分. DataLakeHouse 的 Qwen Code 流程

现在可以将该流程组织成 Qwen 流程：

/sdd:profile -> /sdd:contract -> /sdd:build -> /sdd:verify -> /sdd:release

核心思想：一道命令不应完成整个流程。在银行数据中，由智能体自行完成源分析、自行决定契约、自行编写 SQL 并自行复核是危险的。

项目命令

示例中包含：

.qwen/commands/sdd/profile.md
.qwen/commands/sdd/contract.md
.qwen/commands/sdd/build.md
.qwen/commands/sdd/verify.md
.qwen/commands/sdd/release.md

命令按人工确认节点划分：

profile 收集数据源的事实；
contract 拟定或检查契约承诺；
build 修改 dbt 模型；
verify 运行检查并查找漂移；
release 汇总证据包。

技能与子智能体

data-contract-review 保存复核检查清单。data-profiler 读取数据源并返回清单，但不写入模型。生成器与复核器必须是不同的角色。否则，智能体就是在检查自己的猜测。

在 /clear 之后，以只读模式运行的复核器尤其重要：如果它无法

通过仓库文件理解更改，说明作者将含义留在了聊天中。

钩子

钩子可以在以下情况下阻止写入 models/marts/：当变更添加了 pii_ 字段，或在未经确认标记的情况下修改了契约 YAML。在教学示例中，钩子以概念方式描述；应在第一次实践通过后再编写它，因为此时团队已经了解哪些违规行为会反复出现。

最小输出

汇总流程图：

/sdd:profile -> Schema Manifest
/sdd:contract -> ODCS/ODPS 更新
/sdd:build -> dbt 模型变更
/sdd:verify -> dbt build + 验证事实
/sdd:release -> 证据包
data-contract-review -> 复核报告

如果团队没有留下任何工件，那么在第一轮中就不需要它。

给读者的解析

本章中的 Qwen 命令不应变成一个神奇的控制面板。它们的含义在于责任划分。/sdd:profile 观察数据源。/sdd:contract 拟定承诺。/sdd:build 更改模型。 /sdd:verify 查找差异。/sdd:release 汇总证据。如果一道命令完成所有工作，它就会抹去人工确认，再次将 SDD 变成自动驾驶。

技能和子智能体的价值在于它们缩小了角色范围。Data-profiler 不应写入 marts。契约复核者不应修改 SQL。生成器不应自行认定其变更的安全性。这种划分看似形式化，但一旦出现错误，正是角色指明了谁本应注意到问题，以及哪个工件本应捕捉到该问题。

钩子是更高层次的纪律，但如果流程尚未成熟，则不应过早编写它。如果团队还不了解哪些违规行为会反复出现，钩子要么过于宽松，要么令人烦躁。一个好的钩子能够拦截已知的危险变更类别： models/marts/ 中的 PII、没有审批标记的契约 YAML、没有影响说明的 grain 变更。它无法取代复核，但能防止明显的错误到达复核环节。

本章将整卷内容串联为一个工作循环。读完本章后，读者应当能够指出用哪个命令收集数据源事实、用哪个命令检查契约、用哪个命令构建模型、用哪个命令运行检查、用哪个命令准备发布。如果没有这种划分，智能体将再次获得对数据过大的权力。