第 2 部分. 为什么银行数据需要规范说明
银行数据特别不能容忍「大致正确」。在 web 功能中，错误通常对用户可见。 在数据产品中，错误可能看起来像一张正常的表：行有，字段有，测试是绿色的， 但含义已经被破坏了。正因如此，银行领域便于学习 SDD Data：它迫使人们 明确地写出承诺、约束和证据。
风险高于一般的地方
在教学型银行中，我们关注五类风险：
- PII 和直接标识符；
- 支付和风险信号；
- 数据访问的同意；
- 信贷组合和逾期；
- 报表与计算的可复现性。
每一类风险不仅需要 SQL，还需要可验证的规则。「不披露个人数据」过于宽泛。 一个可工作的规则听起来是这样的：models/marts/ 不包含 pii_email、phone、 passport_number 等直接标识符列，且评审者在发布前会检查这一点。
为什么 dbt 测试不够
dbt 测试可以很好地捕获 not_null、unique、accepted values 以及部分 自定义不变量。但它们并不知道 customer_360 被承诺为「每个客户一行」， 除非你把这一点写进规范。它们也不知道添加 product_code 会改变消费方契约。 它们也不知道 risk_flag 是教学信号，而不是信贷评分的最终决定。
因此 SDD Data 中存在多个层级：
- dbt 测试检查形式和部分事实；
- ODCS 记录技术契约；
- ODPS 描述数据产品和消费方；
- 模型规范描述 grain（粒度）和验收事实；
- 评审者报告将变更与承诺关联起来。
不好的规范示例
为分析师做一个客户数据集市。添加关于账户和交易的有用字段。
检查数据质量。问题：
- 未指定 grain（粒度）；
- 未说明是否可以披露 PII；
- 未定义「有用字段」；
- 没有 SLA 和数据时效性；
- 「数据质量」未转化为事实；
- 没有接受漂移的所有者。
好的版本
数据产品：customer_360。
消费方：客户组合和分支网络的分析师。
数据集市：mart_customer_360。
粒度：每个 `customer_id` 一行。
PII：数据集中无直接 PII。
数据时效性：24 小时。
必需事实：`customer_id` unique/not_null，`total_balance_rub` not_null，
`risk_event_count_7d` 存在，被禁止的直接 PII 列表检查通过。这样的规范并不能解决整个产品，但它设定了智能体不应去猜测的边界。
为读者解读
选择银行示例并非为了戏剧效果。它的便利之处在于，几乎每个假设都有后果。 在网店中，一个有错误的数据集市也可能造成损害，但在银行中，即使是教学实体 也会立即引发这些问题：能否展示这个字段，谁有权更改方法论，如何证明可复现性， 下游报告会发生什么。这些问题比抽象的销售示例更能约束读者。
特别重要的是要区分「表已构建」和「数据可以使用」。绿色的 dbt build 表明 图可执行且声明的检查已通过。它并不能说明选择了正确的粒度。它不知道在同 一个数据集中不能混用客户和账户。它看不到一个字段看起来像是评分输出， 而实际上只是来源的教学标志。这不是 dbt 的缺点，而是工具的边界。
读者练习使用不好的规范是有益的。不好的规范通常听起来很自信：「做一个有用 的数据集市」、「加入质量」、「考虑风险」。它几乎没有明显的错误，因为它几乎什么 也不承诺。相反，好的规范看起来更窄。它说：每个客户一行，禁止直接 PII， 时效性 24 小时，必需字段是这些，检查是这些。这里的狭窄不是弱点，而是使 工作可验证的方式。
本章重要的不是记住银行风险列表，而是习惯于「这如何被证明？」这个问题。 如果一条规则不能转化为命令、SQL 查询、人工评审步骤或人员确认， 它对智能体来说尚未准备就绪。一个好的智能体不应该猜测「正确」意味着什么； 它应该获得一个可以据此拒绝其工作的标准。
实践
从 README 中取一个 mart，为它写出三个风险：grain（粒度）、PII 和契约漂移。 对每个风险，不要写口号，而要写出一条可验证的规则。如果规则无法验证， 将其重写为命令或人工评审步骤。
最小输出
本章之后，创建一个简短的笔记：
# 数据风险笔记
## PII
## Grain（粒度）
## Freshness（时效性）
## 契约漂移
## 人员确认在每个部分填写一条规则。如果规则无法验证，将其重写为命令、SQL、模式评审 或人员确认。
常见错误
在 AGENTS.md 中写：「遵守银行要求」。这对智能体几乎没用。它需要具体的 禁止项、允许的输入模型、契约字段和检查。
复习问题
- 为什么绿色的
dbt build不能证明数据产品的正确性？ - 哪种缺陷更危险：SQL 语法错误还是 grain 不易察觉的改变？
- 在哪里最好地记录 PII 政策：聊天中、SQL 注释中还是规范中？