平台能力不是做出来就有人用

做技术平台时，很容易把主要精力放在能力建设上。

支持更多协议，提供更灵活的配置，增加新的查询和报警方式。功能完成以后，平台团队会自然期待业务项目接入。

实际情况往往没有那么顺利。业务团队即使认可平台价值，也可能迟迟没有行动。

接入成本由谁承担

对平台团队来说，一份接入文档和一个 SDK 已经提供了完整能力。对业务团队来说，接入意味着理解文档、申请权限、修改代码、安排测试和上线，还要承担改造引起的风险。

如果业务正忙，这项工作很容易排在功能需求之后。平台收益属于长期和整体，接入成本却由当前项目立即支付。

因此，不能简单把“不接入”理解为业务团队不重视技术建设。需要先看平台是否把成本留给了使用者。

我们后来尝试把通用监控能力集成进统一框架。新项目使用框架后，HTTP、数据库和缓存等基础指标便默认具备，不再需要逐项申请和改造。

这种方式限制了部分自由，却显著降低了接入成本。业务团队只需要关注自己的自定义指标，而不是重复建设基础部分。

平台推广中，默认值往往比功能数量更重要。一个合理默认能够让大多数人先获得基本能力，再为少数特殊场景提供扩展。

平台团队熟悉内部概念，很容易写出只有自己能快速理解的文档。

有效文档应该从使用者任务出发：什么情况下需要这项能力，最短接入路径是什么，如何确认成功，出错后去哪里查看。完整列出所有参数，不等于帮助别人完成接入。

示例项目、常见问题和明确支持渠道，都属于平台使用体验，而不是附加工作。

平台可以通过强制要求获得很高接入率，但接入并不代表使用。

监控 SDK 已经部署，不代表团队查看指标；报警已经配置，也可能因为噪声过多被忽略。除了项目数量，还应该观察功能是否进入真实工作流程，是否减少了排查和重复建设成本。

平台价值最终体现在使用者行为发生变化，而不是后台多了一条接入记录。

技术平台面对的用户是其他研发团队。它同样需要理解用户目标、使用成本和反馈，只是用户就在公司内部。

这不意味着无条件满足所有需求。平台仍然要保持边界，避免为单个团队不断定制。但在拒绝之前，需要判断问题来自特殊诉求，还是平台本身难以使用。

能力做出来只是第一步。让合适的人以足够低的成本使用，并在工作中真正依赖它，才构成平台建设的完整结果。