01
提案：类型、原因与负责人
02
影响：下游模型、指标、应用
03
兼容：新增、别名或双写
04
弃用：期限、通知与迁移
05
移除：验证、回滚与审计
结论：兼容性是生产数据的接口承诺
字段名、类型、含义、粒度和枚举都可能被报表、指标、API 和 AI 语义引用。上游直接修改会造成编译失败，更危险的是查询仍运行但含义已变。
契约应声明哪些变化允许自动发布，哪些需要版本升级、下游确认和迁移窗口。
先分类兼容与破坏性变化
新增可空字段通常兼容；收紧非空、改变类型、重命名、删除、改变枚举含义或粒度通常具有破坏性。修正文档看似安全，但如果改变业务定义，也应按语义变更处理。
为每类变化定义测试、审批和发布策略，不能只依赖代码评审者经验。
识别真实依赖和动态使用
静态血缘可以找到 SQL、模型和报表引用，但自然语言问数可能通过字段描述、同义词或检索动态选择字段。依赖分析还应覆盖语义配置、问题回归集和导出接口。
记录资产负责人和最近使用情况；“未找到依赖”不等于无人使用。
用并行版本完成弃用
重命名可先新增字段并保留旧别名，类型变化可发布新版本，语义变化可双跑旧新结果。公布弃用日期、迁移说明和负责人。
只有下游测试通过、使用量归零或获得明确批准后才移除。保留回滚路径和旧版本数据的访问策略。
选型时模拟一次破坏性变更
修改被指标、报表和 AI 问题引用的字段，检查工具能否阻断、列出依赖、通知负责人、并行发布、回归和回滚。
BuildTable 可作为 AI 友好数据契约路径候选；实际兼容规则、血缘粒度、弃用工作流和跨工具通知需要 POC 验证。