平台能力需要产品所有权：接入团队数不是成功证据

20 个团队被强制接入统一平台，接入数翻了三倍——但每队仍花 3 小时维护渠道、故障要平台组会诊。本页定义平台的产品属性、黄金路径验收与责任边界。

平台是有用户的产品

平台不是把公共库集中起来就完成了。它应有明确用户、关键任务、自助成功率、升级策略、服务目标和支持责任；平台团队对接口与安全护栏负责，应用团队仍对自身业务结果负责。共享平台故障可能同时影响多团队，因此需有隔离、回退和服务降级方案。

统一消息平台不仅提供SDK，还拥有接入体验、版本、SLO、容量、成本、文档、值守和退出路径。团队把原来重复代码集中到一个仓库，并未自动消除接入方的配置和恢复成本。先定义谁使用、哪条任务能更快完成、平台故障影响多少业务。提供默认安全能力和必要扩展点，控制自定义分支；每接入一个业务就复制一套实现会使平台退化为分散项目。过度统一又可能压平不同成功语义，例如验证码低延迟与营销低成本不能共用无差别队列。

标准路径应覆盖主要工作负载且有合理默认值，例外流程要记录风险和到期复查。若团队普遍绕开平台，需调查可用性、等待时间和接口缺口，而不能仅增加审批。平台收益用团队交付周期、重复劳动、故障率和总成本验证。

接入和运维算例

原来20团队每月各花8小时维护渠道，160小时；平台自维护80小时，接入方每队仍需3小时共60，净节约20小时而非80或160。若平台增加统一故障影响与夜间值守，质量和成本还需再算。不能只以"接入团队数"证明价值。

方案A强制全部迁移换标准化，推进快但例外与迁移风险高；方案B自助接入、分层配额与兼容窗口，采用较慢但能测真实收益。为不可满足需求列清边界和替代，不承诺平台替业务承担所有幂等与合规责任。

可验收产物

提供一条从申请、授权、配置、发送、回执到故障恢复的黄金路径；新团队不依赖口头协助也能在隔离环境跑通。记录接入耗时、失败率、支持请求、升级停滞和单位成功成本，低采用率先访谈障碍，不立即增加更多功能。

弃用版本有清晰时间、兼容测试、迁移工具与回退窗口。重大变更把数据语义和外部副作用纳入评审，不能只发一个SDK升级通知。架构师必须说明平台单点、容量公平和团队责任，而不仅是画能力矩阵。

平台契约与退出路径

本页前面讲平台是有用户的产品，但没有把承诺写成契约。平台契约至少五项：SLO（平台自身可用性与延迟目标）、配额模型（按租户的令牌桶或并发上限）、降级通道（单租户故障隔离，避免全站同一队列）、版本弃用时间表、退出成本（团队迁走要付多少代价）。

用本页的规模变化算例：平台用户从 20 队涨到 100 队，增长 5 倍。三项必须补：公平配额（防止一个大租户占满队列）、租户级 SLO（全局达标不掩盖单租户全损）、跨区退出计划（平台故障时业务能迁到备用通道）。若平台没有退出路径，接入团队就被锁定，平台的"统一"变成单点故障与议价劣势。

版本弃用要有时间表：旧 SDK 或旧 API 至少保留 6 个月（本例），期间提供迁移工具、兼容测试与回退窗口。弃用通知不能只是一封邮件——重大变更要把数据语义与外部副作用纳入评审，并给出每个接入团队的迁移状态。退出成本要可估算：迁移到自建或另一平台需要多少人周、多少数据迁移、多少兼容测试。

契约还要写责任边界：平台保证自身逻辑投递与恢复，业务仍定义意图与外部可观察效果；平台不替业务承担幂等与合规责任。这句话必须出现在契约里，否则事故时会出现"平台以为业务做了、业务以为平台做了"的责任真空。

执行 python3 labs/evolution_models.py platform_contract：预期输出契约五项、tenant_growth=5.0、must_add 包含公平配额、租户级 SLO 与跨区退出计划。脚本只做字段检查，不评价真实平台。

两个合理选择：A 平台只提供 SDK，不管配额与降级，轻但接入方各自实现、故障时互相踩踏；B 平台提供完整契约（SLO、配额、降级、弃用、退出），重但可预期。本例选 B，并把"没有退出路径的平台"列为架构风险，而不是便利性取舍。

架构师变化条件

平台用户从 20 队涨到 100 队：容量公平与多租户隔离成为平台 SLO 的一部分，配额模型见租户隔离与数据生命周期。若平台故障曾造成全站发送中断，隔离与降级方案（按租户熔断、降级通道）要进入平台契约而非口头承诺。低采用率的根因若是凭据申请要走三天人工流程，改进项是黄金路径的自动化而不是更多功能。每次变化重测黄金路径与单位成功成本。

闭卷验收

本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。