每个超级 App 创始人都迟早会撞上同一个诱人又可怕的念头：让别的开发者在我的 App 里建东西。流量是我的，供给可以是他们的。上行是真实的——微信、支付宝、Grab 都没自己把每个服务都做了。但恐惧也是真实的。开了门，就有人发个骗局、漏个数据，或者克隆你自己的功能。先混乱，再丑闻，再监管找上门。
我两边都给过建议。教训平淡但耐用：没有可控底座的开放，只是贴了 logo 的负债。底座决定「开放」意味着杠杆还是暴露。
「开放」真正的代价
开放平台的风险不在好开发者，而在长尾：一个恶意构建、一个过度要权的 App 扒通讯录、一个抽水的支付流。Apple 的 App Store 和微信的小程序平台，都用同一套工具回答这个问题——发布前审核、分级能力访问、以及一个 kill switch。代价是运营性的：你要跑一条审核流水线、一个政策团队、一套监控。但这笔代价，正是让开放站得住脚的东西。
让治理变便宜的架构，是 runtime。你不再让第三方把任意原生代码塞进你的 App，而是给他们在沙箱里一套分级的 API 面。敏感能力——支付、通讯录、细粒度定位——被设门槛，需要宿主明确批准。包在上架前签名、审核。运行时里，沙箱限制代码能碰的东西，宿主能即时把不合规的 App 从目录拽下来。
摆到桌面上
| 维度 | 「让他们随便建」（原生） | 开放目录 + runtime（宿主管控） |
|---|---|---|
| 入口门槛 | 来者不拒 | 审核 + 分级 API |
| 能力访问 | 全原生、高风险 | 分级、宿主批准 |
| 代码信任 | 未知 | 签名、审核过的包 |
| 隔离 | 无 | 沙箱隔离 |
| 下架 | 应用商店周期、慢 | 宿主即时下架 |
| 价值捕获 | 难抽水 | 宿主定规则、抽成 |
可控底座把「开放」从威胁变成护城河。宿主定义目录——谁进、能调什么、付多少。开发者拿到他们买不到的触达；宿主保留规则书、抽成率和 kill switch。这正是每个成功的开放小程序生态背后的真实结构，也是为什么「我们就开放个 API 吧」永远低估了工作量。
诚实的 caveat：runtime 不会废除开放的运营性成本。你仍需要审核、政策、监控。它做的是让这些控制在技术上可强制执行，而不是嘴上说说——区别是「指望坏人不作恶」和「能在用户感知之前就拦住他们」。
如果你想拿到供给又不想丑闻，问题不是开不开放，而是你有没有一个让你在开放的同时还能掌控的底座。
