接入决策树
这篇文档是“如何选接入路径”的唯一权威页。
如果你只记住一条规则，请记住：
- 用
generator-sdk接平台能力 - 用
generator-workbench接官方壳层 - 用 发布模板协议(
Generator Runtime Contract) 解决宿主 / 生成器(runtime) 协议 - 用 MCP + skill 做 AI 协助开发
先回答五个问题
- 你是否需要登录、积分、计费、导出、导入 Studio 等平台能力？
- 你需要官方壳层，还是自己的自定义壳层？
- 生成器是否需要支持发布模板能力？
- 你是手动开发，还是通过 AI 协助开发？
- 这个生成器是否存在模板页场景？
决策流程
推荐组合
方案 1：只用 SDK
适合：
- 已经有成熟的自定义壳层(自定义 UI 布局和样式)
- 只需要平台 API
- 希望自己控制全部壳层行为
继续阅读：
方案 2：SDK + 应用壳
适合：
- 希望最快接成标准生成器壳层(平台 UI 布局和样式)
- 希望直接复用平台一致的登录、导出、计费、模板壳层行为
- 不想自己重做宿主框架
继续阅读：
方案 3：SDK + 自定义壳层 + 发布模板能力
适合：
- 希望最快接成标准生成器壳层(平台 UI 布局和样式)
- 希望直接复用平台一致的登录、导出、计费、模板壳层行为和 发布模板能力、模板预览能力
- 不想自己重做宿主框架
方案 4：AI 路线
适合：
- 希望让 AI 帮你搭建或改造生成器
- 希望 AI 通过 MCP 查询真实文档
- 希望生成结果收敛到平台标准模型
继续阅读：
什么时候发布模板协议( Runtime Contract )变成必选项
以下场景应把发布模板协议( Generator Runtime Contract) 视为必需：
- 生成器需要发布模板能力和模板预览能力
- 宿主要分别挂载 canvas 和参数面板
- 存在模板页场景
- 目标是长期标准化，而不是阶段性兼容
常见误区
- 把
generator-sdk当成壳层 - 把
generator-workbench当成业务 生成器(runtime) - 把 MCP 当成生产运行时依赖
- 只做了部分 SDK 或 bridge 接入，就宣称“标准集成完成”