第 6 部分 银行数据平台章程
数据平台章程回答的问题是：哪些决策不需要在每个数据市场中重新讨论。在基础卷中，章程固定了应用程序的使命、技术栈和路线图。在这里，它固定了 DataLakeHouse 的使命、本地技术栈、与生产环境的映射边界、PII 策略和合约变更规则。
最小文件集
specs/mission.md
specs/tech-stack.md
specs/roadmap.md
AGENTS.mdmission.md 解释平台为何存在。tech-stack.md 说明允许使用哪些工具。roadmap.md 展示工件的顺序。AGENTS.md 设定代理的行为规则。
mission 中应包含的内容
一个好的、用于教学银行的 mission：
平台为教学银行构建可复现的分析型数据市场。每个数据产品必须有所有者、消费者、粒度、PII 策略、新鲜度承诺、校验事实和评审者报告。糟糕的 mission：
打造一个现代化的银行数据平台。它听起来很宏大，但无助于代理做出决策。
不可协商的规则
记录下在单个数据市场内部不能更改的规则：
- 数据市场不暴露直接的 PII 字段；
- 粒度变更需要审批；
- 合约中的必填字段不能在没有重大变更说明的情况下删除；
- 如果 dbt 可用，
dbt build --profiles-dir .是强制检查； - 评审者通过时不应编辑文件。
如果此类规则在实施过程中首次出现，请停下来并更新章程文件，然后再继续编写 SQL。
给读者的解析
数据平台章程看起来层级很高，直到第一次冲突出现。代理希望添加一个方便的列。分析师要求更多的细节化。数据市场开始暴露以前被视为技术性的字段。如果项目中没有一个简短的规则集，每个这样的决定都会被重新做出，往往倾向于最近的任务。章程的存在是为了让最近的任务不会破坏数据的长期意义。
与普通的技术栈不同，章程不仅说明"我们使用哪些工具"，还说明"代理不会自行做出哪些决策"。对于银行数据来说，这一点尤为重要。粒度、PII 策略、SLA、重大变更和风险方法论不应作为 SQL 的副作用出现。
如果代理提议更改其中任何一项，它应该停下来请求确认，而不是事后解释变更。
好的章程简短但可验证。糟糕的章程说："遵守质量和安全"。好的章程说："数据市场不暴露直接的 PII"、"粒度变更需要人工确认"、"校验事实在 SQL 之前编写"。这些规则可以在评审中应用。如果一条规则无法被验证，它就只是一个口号，对代理没有帮助。
读者可以将章程视为与未来自己的契约。在项目开始时，一切似乎显而易见：Customer 360 是每个客户一行，同意书单独计算，风险标志是教学性的。经过十次变更后，显而易见性消失了。章程将原始决策保存在下一个代理迭代和下一个评审者能够看到的地方。
实践
为您的数据平台制定五条不可协商的规则。对于每条规则，指出它所在的位置：AGENTS.md、mission.md、tech-stack.md、合约 YAML 或模型规范。
Qwen 查询
帮助制定一个教学性银行数据平台的章程。
在写入文件之前，先就使命、技术栈、PII 策略、合约漂移和人工确认提出问题。
不要编写 SQL。最小输出
完成本章后：
specs/mission.md描述平台的用途；specs/tech-stack.md固定本地技术栈并与生产环境映射；specs/roadmap.md引导读者浏览各个工件；AGENTS.md禁止 PII 泄漏和未经批准的合约漂移。
常见错误
将章程与具体数据市场的规范混为一谈。mission.md 不应列出 mart_customer_360 的 SQL 字段；模型规范不应重新选择 DuckDB 或 dbt。
复习问题
- 哪些决策应该放在章程中，哪些应该放在模型规范中？
- 为什么 PII 策略最好在源数据剖析之前固定？
- 什么时候合约字段的变更需要单独审批？