学习指南: 第6部分. 银行数据平台章程

模块「第6部分. 银行数据平台章程」中第 3 / 5 节课

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

主题: 第 6 部分. 银行数据平台宪法

难度等级: 中级

预计学习时间: 3-4 小时（理论 — 1.5 小时，实践 — 1.5 小时，案例分析 — 1 小时）

前置要求: 对 Data Lakehouse 架构有基本了解

熟悉 dbt 和 DuckDB 的工作原理

理解 grain、freshness 和 data contracts 的概念

具有分析型数据集市（marts）的工作经验

具备 PII 策略和个人数据保护的基础知识

学习目标: 阐述银行数据平台的使命，使其能够帮助代理做出具体决策

区分哪些规则属于宪法，哪些属于具体模型的规范

编写一组不可协商的规则（5–10 项），并明确指出其固定的存放位置

确定在数据集市的便利性与长期原则发生冲突时，代理的行动顺序

在考虑破坏性变更和人工确认要求的前提下，对合约变更进行评审

概述: 数据平台宪法是一套简短但可验证的原则集合，用于固定使命、允许使用的技术栈、制品路线图以及代理的行为规则。与普通的技术栈不同，宪法不仅要回答“使用哪些工具”，还要回答“代理不会自行做出哪些决策”。对于银行分析而言，这一点至关重要：grain、PII 策略、SLA、破坏性变更以及风险方法论不应作为 SQL 的副作用出现。本部分介绍如何组装四个最小文件（mission.md、tech-stack.md、roadmap.md、AGENTS.md），哪些规则应成为不可协商的规则，如何识别将宪法与集市规范混淆的典型错误，以及如何将宪法视为与未来自己签订的契约。

关键概念: 数据平台宪法: 一份简短且可验证的文档（由 4 个文件组成），用于固定使命、技术栈、路线图和代理的行为规则。它回答的问题是：在每个数据集中市中哪些决策无需重新讨论。

Mission.md: 解释平台为何存在的文件。一份好的使命应该具体且可验证：「每个数据产品都必须拥有所有者、消费者、grain、PII 策略、freshness 承诺、验证事实和评审报告」。一份糟糕的使命听起来宏大，却无助于做出决策。

Tech-stack.md: 用于固定本地技术栈及其与生产环境映射关系的文件。它定义了学习环境中允许使用的工具（dbt、DuckDB）以及它们与生产环境的关系。

Roadmap.md: 展示制品顺序的文件。它引导代理和评审者按步骤顺序进行：先创建什么，后创建什么。

Agents.md: 用于设定代理行为规则的文件。其中包含不可协商的限制：禁止 PII 泄露、更改 grain 时需要确认、在评审阶段禁止编辑文件。

不可协商规则: 不能在单个数据集市内随意修改的原则，除非更新宪法文件。示例包括：marts 不公开直接的 PII 字段；更改 grain 需要审批；合约中的必填字段不能在没有破坏性变更说明的情况下删除；dbt build --profiles-dir . 是强制检查；评审者不得编辑文件。

Grain: 数据集市行的粒度级别（例如，一个客户对应一行）。更改 grain 属于破坏性变更，需要人工审批。

Pii（个人可识别信息）: 个人可识别信息。PII 策略应在数据源画像之前固定在宪法中，以避免意外泄露。

破坏性变更（breaking change）: 合约中可能破坏消费者的变更：删除必填字段、更改 grain、更改数据类型。它需要单独的审批和变更说明。

Data contract（数据合约）: 数据产品的规范：所有者、消费者、grain、字段、PII 策略、freshness SLA、验证事实。以 YAML 或模型规范的形式描述。

模型规范: 描述特定数据集市的文档（例如 mart_customer_360）：SQL 字段、业务逻辑、测试。不应重新选择技术栈或阐述使命。

验证事实（check facts）: 在编写 SQL 之前撰写、之后进行验证的断言。它允许在模型实现之前固定其预期行为。

与未来自己的契约: 描述宪法作用的隐喻：在项目初期一切显而易见，但经过十次修改后，这种显而易见性就消失了。宪法将最初的决策保留在下一个代理和评审者能够看到的位置。

重要日期: 在开始数据源画像之前: 在 mission.md 或 AGENTS.md 中固定 PII 策略，以避免在首次扫描数据时发生意外泄露。

在编写 SQL 之前: 为每个模型记录验证事实（check facts）。该规则作为不可协商规则写入宪法。

在更改 grain 或删除必填合约字段之前: 停下来，更新宪法文件，获得人工确认，然后再修改 SQL。

在实施过程中首次出现新规则时: 停下来并更新宪法文件，然后再继续编写 SQL。不要将规则以代码注释的形式留下。

练习题: 名称: 编写五条不可协商规则

问题: 为您的学习用银行数据平台编写五条不可协商规则。对于每条规则，请指出其存放位置：AGENTS.md、mission.md、tech-stack.md、contract YAML 或模型规范。规则应当可验证，而不是空洞的口号。

解决方案: 第 1 步. 确定在处理银行数据集市时最常出现的五个风险：PII 泄露、grain 漂移、删除必填字段、跳过 dbt build 检查、在评审阶段编辑文件。第 2 步. 将每条规则表述为可在评审中验证的断言。第 3 步. 确定固定的存放位置：

规则 1「marts 不公开直接的 PII 字段（明文形式的姓名、电话、电子邮件）」→ AGENTS.md
规则 2「更改 grain 需要产品所有者审批并在 roadmap.md 中记录」→ AGENTS.md + roadmap.md
规则 3「合约的必填字段（owner、consumer、grain、sla）不能在没有破坏性变更记录的情况下删除」→ contract YAML + AGENTS.md
规则 4「合并之前运行 dbt build --profiles-dir .；构建必须无错误通过」→ tech-stack.md + AGENTS.md
规则 5「评审者不编辑文件，而是留下评审意见；修改由作者完成」→ AGENTS.md

第 4 步. 验证每条规则：能否以在 diff 或 dbt 日志中可见的方式违反它？若不能，则重新措辞。

难度: intermediate

名称: 区分宪法与模型规范

问题: 给定一段描述数据集市 mart_customer_360 的文档片段。请确定哪些行属于数据平台宪法，哪些属于具体模型的规范。并解释为什么混淆这些层次是一种典型错误。

解决方案: 第 1 步. 阅读片段并列出所有断言。第 2 步. 对每个断言进行分类：

「平台在本地环境中使用 dbt 1.8 和 DuckDB 1.1，在生产环境中使用 Snowflake」→ 宪法（tech-stack.md），因为它涉及整体技术栈。
「mart_customer_360 包含 customer_id、full_name、birth_date、segment_code 字段」→ 模型规范，因为它涉及特定的数据集市。
「Marts 不公开直接的 PII 字段；full_name 被掩码化为 Ivanov I.I.」→ 宪法（AGENTS.md）+ 规范（该特定数据集市的掩码化规则）。
「Grain 为每个客户一行；更改 grain 需要审批」→ 关于「审批」的部分属于宪法，关于「每个客户一行」的部分属于规范。

第 3 步. 得出结论：宪法描述总体原则和边界，而规范描述具体实现。混淆会导致在出现新数据集市时不得不重新决定使用哪种技术栈，并且每个决策都是临时做出的。

难度: intermediate

名称: mission.md 表述的可验证性

问题: 您面前有两段 mission.md 的表述。请确定哪一个更好，并将糟糕的表述重新措辞为可在评审中验证的版本。

解决方案: 第 1 步. 阅读这些表述： A)「打造一个现代化的银行数据平台」。 B)「平台为学习用银行构建可复现的分析型 marts。每个数据产品都必须拥有所有者、消费者、grain、PII 策略、freshness 承诺、验证事实和评审报告」。第 2 步. 进行比较：表述 A 未能为代理提供决策标准。表述 B 列举了每个数据产品的强制属性——可以通过 contract YAML 进行验证。第 3 步. 将 A 重新措辞为可验证的版本：「平台提供基于 dbt + DuckDB 的可复现 marts；每个 mart 与 contract YAML 一起发布，其中包含 owner、consumer、grain、pii_policy、freshness_sla、check_facts 和 review_report。缺少这七个属性中的任何一个都将作为评审者的阻塞性意见」。第 4 步. 总结规则：好的 mission 列举强制属性或行动，而糟糕的 mission 只谈抽象的价值观。

难度: beginner

名称: 代理对冲突的反应

问题: 代理在实现数据集市 mart_transactions_daily 时发现，为了分析师的便利，需要添加一个 card_pan_hash 列，它属于直接的 PII 字段。请根据宪法描述代理的正确操作顺序。

解决方案: 第 1 步. 代理应停下来，在澄清之前不要添加字段。第 2 步. 代理检查 AGENTS.md：「marts 不公开直接的 PII 字段」。card_pan_hash 字段属于 PII。第 3 步. 代理检查 mission.md 或 AGENTS.md 中是否存在关于 hash 值的例外。如果没有例外，则不能将该字段添加到 mart 中。第 4 步. 代理提出请求：要么在宪法中修改 PII 策略（需要人工确认），要么向分析师提供替代方案（例如聚合指标 count_distinct_pan）。第 5 步. 只有在人工审批并更新宪法文件后，代理才能继续处理 SQL。第 6 步. 如果项目中没有宪法，代理应停下来并请求创建宪法，而不是自行做出决定。

难度: intermediate

名称: 编写用于创建宪法的 Qwen 提示

问题: 编写一个针对代理的提示（参照本章中的示例），以帮助组装学习用银行数据平台的宪法。该提示应是自给自足的，并明确禁止过早编写 SQL。

解决方案: 第 1 步. 确定提示的目标：组装四个宪法文件（mission.md、tech-stack.md、roadmap.md、AGENTS.md）。第 2 步. 列出代理在写入之前必须获得答案的强制问题块：使命、技术栈、PII 策略、合约漂移、人工确认。第 3 步. 添加明确的禁止：「不要编写 SQL」。第 4 步. 最终的提示：「帮助我编写学习用银行数据平台的宪法。在写入文件之前，请就使命、技术栈、PII 策略、合约漂移和人工确认提出问题。不要编写 SQL」。第 5 步. 验证：提示以目标开头，列出强制的澄清事项，以禁止结尾。这样的提示可以防止代理在没有宪法的情况下直接编写 SQL。

难度: beginner

案例研究: 名称: 客户细分数据集市的 grain 漂移：宪法的教训

场景: 在学习用银行中部署了 grain 为「每月每个客户一行」的数据集市 mart_customer_segment。经过六次迭代，分析师要求按产品增加明细：「每月每个客户和每个产品一行」。代理没有停下，直接修改了 SQL 并更新了模型。消费者（细分仪表盘）停止工作，因为它期望每个客户只有一行。

挑战: 代理自行决定更改 grain，未经产品所有者审批。项目中没有宪法文件来固定规则：「更改 grain 需要审批」。每次更改 grain 都必须重新讨论，并且几乎总是选择「目前最方便」的方案。

解决方案: 团队停止了对数据集市的开发，并组装了由四个文件构成的宪法。在 AGENTS.md 中新增了规则：「更改 grain 需要数据产品所有者的审批并在 roadmap.md 中记录。代理不得自行更改 grain」。在 mission.md 中添加了每个数据产品强制属性的列表，包括 grain。在 mart_customer_segment 的 contract YAML 中固定了 grain，并将其标记为必填字段，不能在没有破坏性变更说明的情况下删除。

结果: 在引入宪法两周后，收到了关于更改 mart_risk_flags 中 grain 的新请求。代理停下来，提出了审批请求，更新了 roadmap.md，并仅在所有者同意后修改了 SQL。仪表盘继续工作。更改 grain 的评审时间缩短了，因为规则变得可验证：评审者可以在 contract YAML 中看到 grain 的 diff。

经验教训: 「更改 grain 需要审批」的规则应存放在 AGENTS.md 中，而不是 SQL 注释中。

Grain 是 contract YAML 中的必填字段；删除或更改它是评审者的阻塞性意见。

没有宪法，每次 grain 更改都要重新讨论，并且几乎总是当前任务占上风。