"开放"是简单的那一半
任何人都建得起一个让开发者上传代码的商店。开放 catalog 难的不是"放进来"，而是之后发生的事：谁审提交、有害内容如何被抓、怎么拦住滥用、用户凭什么相信自己点的那个。承载第三方小程序的运行时，继承了和应用商店一样的信任与安全负担，而把它做好的模型已经在规模上被验证。微信运营着 430 万+ 小程序、9.45 亿月活、500 万+ 开发者，并有一套成文的运营规范——证明开放 catalog 既可以是开放的，也可以是有治理的。
治理到底管什么
治理是四件事，漏掉任何一件，catalog 都会背上再难翻身的坏名声。
| 治理层 | 约束什么 | 缺了会怎样 |
|---|---|---|
| 提交审核 | 发布前核验真实主体、类目一致性、资质（牌照） | 欺诈或无照服务直接上线 |
| 内容安全 | 文本/图片/音频扫描违法、色情、暴力、涉政风险 | UGC 与直播内容漏出危害 |
| 滥用防控 | 反分享 spam、反刷量刷单、反网赚、反外挂 | 激励循环与机器人淹没真实用户 |
| 信任信号 | 投诉通道、评分、透明下架 | 用户无救济；平台失去公信力 |
先审后发，而非事后补救
微信运营规范要求每个小程序有可核验的主体，对名称/logo/商标做筛查以避免品牌混淆与侵权，强制类目一致（服务须与注册类目和标签相符），并拒绝隐藏类目或同质化克隆。金融、医疗、政务类必须出示相应资质，否则拒收。原则很简单：身份与边界在"门口"就确立，而不是等出了事才发现。嵌入 catalog 的运行时应当继承同一道闸门——每个小程序都带着已核验的开发者与已声明、已审计的边界。
内容安全是内建控制
对 UGC 与直播内容，微信开放了内容安全 API（文本用 msgSecCheck，图片/音频用 mediaCheckAsync），基于十万级敏感词库与深度学习模型，并给出一条硬警告：自动化不能替平台免责——官方文档明确要求开发者对判为 REVIEW 以及按比例抽检的 PASS 内容保留人工复核。有治理的 catalog 采用同样的层层设防：发布前服务端扫描 + 人工抽样复核，让有害内容在边缘被拦下，而不是等它上了热度再处理。
滥用防控让 catalog 可用
运营规范定义并处罚分享 spam（强制/暗示/利诱分享）、刷量（刷票、刷粉、刷单）、网赚（有偿转发循环）、外挂（作弊/插件）、侵权与非法多级分销。处罚从限制分享/搜索能力，到下架、封号逐级升级。这套不起眼的机制，决定了开放 catalog 不会变成垃圾引擎——它必须写成平台策略，而不是留给每个开发者自行裁量。
规模化下架与问责
治理只有在违规真的被移除时才可信。微信珊瑚安全团队每月发布处置公告；在 2026 年的一个月份里，它下架了数十个违规微短剧小程序，并在一次 5 月专项中清理了 2800+ 部含不良儿童刻画的小程序。持续、公开的执法，既向开发者传递"规则是活的"，也向用户证明 catalog 有人管。
Cross Mini App 的角色
Cross Mini App 把治理当作运行时的一部分，而不是事后糊上去的补丁。catalog 里每个小程序的边界与身份都被审核、发布前被扫描、受滥用与投诉机制覆盖、可被下架——于是宿主 App 可以开放一个 catalog，而不必继承一个无人治理的 catalog。"开放"若没有护栏，只是把风险转嫁给用户；运行时的职责，是把这份风险吸收掉，让宿主不必自己扛。
