Platform Teams, Enabling Teams & Governance Boundaries
平台团队、赋能团队与治理边界
如果“平台组织”那张页解释的是组织为什么会长出共享能力，那么这张页更进一步处理这些能力该由什么团队形态承接、怎样避免一切问题都堆到平台身上，以及协作模式和治理边界怎样决定平台是否真能降低认知负担。
它关心的不是团队命名法，而是复杂组织怎样把平台、赋能和深度专业能力拆成不同责任。
4 类关键团队
业务流团队、平台团队、赋能团队、复杂子系统团队
核心问题是边界
不是做更多平台，而是让认知负担与协作模式匹配
强组织视角
重点不在工具栈，而在团队如何配合与互相约束
平台组织深化页
把平台从“有没有平台团队”继续下钻到团队拓扑层
前一张页更像解释“为什么需要平台”，这一张页更像解释“平台能力应该由谁承接、怎样不把组织越做越重”。
平台组织解释的是长期协作契约
它处理共享能力为什么会出现、为什么会被短期业务侵蚀，以及平台 adoption 为什么总难推进。
这一页解释的是团队形态和协作模式
它更关心哪些团队该长期面向业务流、哪些团队该做共享能力、哪些团队该做赋能，哪些深复杂度必须被单独承接。
真正的分工边界在于认知负担
如果所有复杂度都扔给业务团队，组织会越来越乱；如果所有复杂度都收进平台，平台又会变成新的瓶颈。关键是复杂度该由谁长期拥有。
认知负担
→
团队形态
→
治理边界
关键不在名字，而在组织是否把不同类型的问题交给了合适的团队形态。
最靠近用户价值和业务结果，负责把需求转成持续交付的产品与服务。它的重点不是掌握所有底层复杂度，而是把价值流做顺。
业务结果
价值流
交付
负责沉淀高频共性能力，降低业务团队重复建设和认知负担。平台不是收所有需求，而是把最值得标准化的部分做成可依赖内部产品。
复用
默认路径
共享能力
不是长期接管业务结果，而是帮助团队跨过某个能力门槛，比如测试体系、云原生迁移、可观测性建设或架构重构期的技能迁移。
Enablement
辅导
能力迁移
当某块复杂度本身就很深，比如搜索、结算、风控、编译体系或分布式数据平面，它往往需要单独团队长期拥有，而不适合被平台或业务团队随手兼任。
深复杂度
专业边界
长期拥有
组织失效往往不是因为少了某类团队，而是协作模式不清，导致平台、业务和赋能彼此互相拖拽。
短期协作不该永远常态化
赋能团队和平台团队可以在关键时期深度介入，但如果长期靠“平台帮你做”“专家帮你盯”，组织不会真正学会自己交付。
短期协作
→
能力迁移
→
回归自持
平台能力要像服务而不是审批点
如果平台提供的是清晰接口、默认路径和高可用护栏，业务团队会愿意使用；如果平台提供的是排队和解释成本，业务团队就会绕开它。
内部产品
→
服务接口
→
采用率
治理边界决定平台是否被拖垮
什么必须走平台、什么允许业务自行处理、哪些能力由复杂子系统团队长期拥有，这些规则不清楚，组织很快就会重新回到重复建设和多头协商。
边界规则
→
责任归属
→
长期稳定
这张页最适合把平台组织、研发组织和工程平台建设串成同一条组织线。
这张页适合放在“平台组织”和“平台工程 / IDP”之间，把平台化从概念层压回团队形态层。
这一页的定位: 它是“平台组织”向下长出来的一张深化页，负责解释平台团队、赋能团队和复杂子系统团队分别该承接什么复杂度，以及治理边界怎样决定平台是否真能降低认知负担。
最自然的继续阅读，是跳到研发组织与交付能力、平台工程 / IDP 和开发者体验。