这两年，"平台工程"是个高频词。不少公司都在建内部开发者平台（IDP），搭自助服务门户，做CI/CD编排，搞基础设施抽象层。方向没问题——谁不想让开发者少操心环境配置，把精力还给业务？

但我在实际观察中看到一个反常现象：平台建得越大、功能越全，开发者反而越不愿意用。不是平台不好，是平台太大了，大到没人搞得懂它到底能干什么、该怎么用。

这个问题不在技术能力，在认知负荷。

平台的第一性原理：降低认知负荷，不是增加

Team Topologies那本书里有个概念叫"认知负荷上限"。每个团队能消化的复杂度是有边界的。平台团队的职责，是帮业务团队屏蔽掉他们不需要关心的复杂度——基础设施、部署流水线、日志采集、权限管理这些。

但现实常常反过来。平台团队为了"能力完整"，把能做的全做了：自助工单系统、多环境编排、金丝雀发布配置器、自定义Helm Chart模板库、服务网格治理面板……每多一个功能，平台就多一层学习成本。对于业务团队来说，他们不是不想用，是真的没时间学。

我见过一个平台，光是创建一个新的微服务，开发者需要在三个系统之间跳转，填写十几个表单，选择六种部署策略之一，还要理解平台自定义的资源配额模型。整个过程文档写了两万字，但没人读完过。

这就是平台工程最容易掉进去的坑：把"功能完整"当成了"用户体验好"。

认知超载的代价，是影子系统的滋生

当平台太难用，开发者不会乖乖排队等平台团队优化。他们会自己搞一套——写脚本绕过平台、用Excel手动管理、甚至直接在服务器上手动部署。

这些"影子系统"才是组织最大的技术债。它们不在架构图上，不出现在技术雷达里，但每天都在跑生产流量。出了事故，平台团队说"这个不在我们管辖范围内"，业务团队说"平台太难用我才自己搞的"。两边都有道理，但系统风险实实在在地摆在那。

我在金融业务中常见类似场景。合规团队要求所有变更走审批流，平台团队把审批流做成了七步串行流程。结果呢？紧急修复的开发者直接找运维手动改配置。审批流形同虚设，合规风险反而更大了。

平台的成功指标不应该是"功能覆盖率"，而应该是"开发者自愿使用率"。如果大部分人是在被迫使用你的平台，那这个平台就是在增加认知负荷，而不是降低。

平台的合理规模，由组织的消化能力决定

这里有个判断框架：平台每新增一个能力，问三个问题。

第一，这个能力替代了什么？如果它替代的是业务团队自己维护的一套复杂脚本，那值得做。如果它替代的是一个"大家已经会用而且没什么问题"的工具，那可能是在制造迁移成本。

第二，学习成本有多高？一个新功能如果看5分钟文档就能上手，认知负荷可控。如果需要参加内部培训、读完一份Wiki、还要找平台团队的人答疑，那这个功能的"组织成本"已经超过了它的技术价值。

第三，能不能渐进式采用？好的平台能力应该是"可以独立使用，也可以和其他能力组合"。而不是一旦接入就必须全盘切换。渐进式采用降低了单次认知负荷的增量，让团队有时间消化。

一个实际的例子：某平台团队把CI/CD流水线从Jenkins迁移到自研平台。迁移计划做得很完整——模板库、自动转换脚本、灰度迁移策略。但他们忽略了一件事：研发团队已经形成了围绕Jenkins插件生态的一系列工作习惯。换平台不只是换工具，是换肌肉记忆。最终这个迁移花了比预期多一倍的时间，不是因为技术问题，而是因为组织消化的速度跟不上。

文化契合，比技术架构更重要

平台工程的另一个容易被忽视的维度：文化契合。

有的组织文化是"自助优先"——开发者习惯自己查文档、自己排查问题、自己写脚本扩展。这种文化下，平台可以做得功能丰富、暴露足够多的API和扩展点，开发者会很开心。

有的组织文化是"服务优先"——开发者期望平台团队提供端到端的支持，出了问题有人兜底。这种文化下，平台功能可以少一些，但每个功能背后的文档、支持响应、故障处理必须到位。

用错了模式，平台就成了负担。自助型平台遇到服务型文化，开发者觉得"平台团队不管我们"；服务型平台遇到自助型文化，开发者觉得"平台限制太多"。

这不是技术问题，是组织设计问题。平台团队在动手写代码之前，应该先搞清楚自己组织的"服务模式偏好"。最简单的办法：问三个业务团队的开发者，"你希望平台团队做什么？"如果三个回答差不多，说明组织共识已经形成。如果三个回答完全不同，那可能连需求收集都不该开始。

平台演进的方向：从功能堆叠到路径收敛

成熟平台团队的标志，不是"又加了多少功能"，而是"让多少路径收敛了"。

什么意思？比如部署一个新服务，原来有五条路径——有人用Terraform，有人用Helm，有人用自研CLI，有人手动SSH，有人找运维帮忙。平台的目标不是增加第六条路径，而是让其中三条自然消亡，只留下两条：一条标准化的自助路径，一条有审批的托管路径。

路径收敛的好处是降低选择成本。开发者不用纠结"我应该用哪种方式"，因为可选的方式就那么几个，每个都有明确的适用场景。

但收敛不靠强制。靠的是让目标路径的体验足够好——好到大家自愿放弃旧路径。如果一个新平台比老工具难用十倍，哪怕你用行政命令推，也推不动。

我之前了解到一个案例，平台团队做了个"部署助手"——开发者只需要描述"我要部署一个Node.js服务，2C4G，连接MySQL和Redis"，平台自动生成IaC模板、配置监控告警、注册服务发现。整个流程从之前的两天缩短到十五分钟。没有人强制要求大家用这个工具，但三个月后，80%的新服务都通过这个助手创建了。这就是路径收敛的自然力量。

小结

平台工程的核心矛盾，不是"能不能做更多"，而是"该不该做这么多"。

技术人天然倾向于追求完整和优雅——功能齐全、架构漂亮、覆盖所有边界场景。但平台的用户是活生生的人，他们有认知上限、有习惯依赖、有各自的偏好。忽视这些人性因素的平台，注定会成为"技术上好，但没人用"的尴尬存在。

好的平台，不是功能最全的那个，而是开发者愿意用的那个。愿意用，说明认知负荷在可控范围内，说明文化契合做到了，说明路径收敛生效了。

这可能是平台工程最难的地方——你不仅要解决技术问题，还要理解人的问题。而后者，往往比前者复杂得多。