必须先有的材料
- API / 库表源与版本快照
- 字段、类型、鉴权、枚举
- 策略包：何为破坏性
- 资源责任人与团队
- 下游依赖清单
需求 / 适用前提
没有差分和责任人，破坏性就是静默的
工作台的单位是快照与变更行。没有源、策略包和责任人路由，告警只能发到群里没人认。破坏性判定依赖策略包配置，不替代发布系统。
谁在用
- 平台负责人：破坏性闸
- 接口 owner：差分与审批
- 下游调用方：影响面
- SRE：告警路由是否有人接
现在为什么对不上
- 删字段没人拦，下游空指针
- 类型收窄当兼容发了
- 告警进大群，没有责任人
- 策略口头，无法复盘
如何工作
拉取、差分、判定、路由
对应源码：源、差分、策略、告警、责任人、历史。时间线：快照 05-20 10:30 → 差异 14:21 → 影响 14:25 → 策略判定警告 → 路由审批进行中。示意 23 个影响：直接 8、间接 11、调用方 4。
- 拉取快照
- 对比差分
- 影响评估
- 策略判定
- 路由审批
- 发布闸
01 差分
当前版与提议版并排
删除字段、类型收窄、鉴权变更标成破坏性或高风险。新增可选字段走兼容。差分是证据，不是评论。
02 路由
破坏性必须到责任人，而不是大群
User 删除 email → 用户平台组张磊，状态待审批。高风险 Order.amount int→decimal 同样要人接。系统不自动发布。
对使用者的价值
静默变更不再把调用方拖垮
价值不在又一张结构图，而在破坏性有人审、告警有人接、策略可复盘。
平台负责人
破坏性计数和待审批队列在同一潮汐线上。
接口 owner
差分写清删了什么，而不是合并后再解释。
下游调用方
影响面可见，有时间改客户端。
SRE
告警路由到人，大群不再当垃圾桶。
边界
系统代劳的上限
破坏性判定依赖策略包配置。哨兵不代替发布流水线，也不自动改生产库。
- 不自动发布，破坏性必须人审。
- 策略包未覆盖的变更标不确定，不默认为兼容。
- 差分以拉取到的结构为准，口头约定不算快照。
进出角色
从哪进、从哪出
静态部署路径为 /schemawatch-ai。打开工作台：https://apps.chatsoftware.cn/schemawatch-ai/
进入
- 源、快照、提议版
- 策略包、责任人
- 下游依赖
离开
- 带判定的差分行
- 待审批路由
- 禁止发布的破坏性清单