开发者旅程
这篇文档是端到端交付地图。
它不重复每一种接入方案的细节。如果你还没决定路线，请先看 接入决策树；这篇文档只负责描述从想法到具备发布条件的顺序。
阶段 1：定义生成器
在开始实现之前，先确认：
- 生成器身份与
appKey - 目标技术栈
- 是否存在模板页场景
- 需要哪些平台能力
- 目标是新生成器还是旧生成器改造
阶段 2：选择接入路径
先决定：
- 手动工程，还是 AI 协助工作流
- 官方壳层，还是自定义壳层
- 生成器(Runtime) 发布模板协议 是现在补齐，还是分阶段收敛
这个决策会直接影响后续结构，所以应在真正写代码之前完成。
阶段 3：搭建或改造生成器(Runtime)
生成器(Runtime) 负责：
- 业务状态
- 渲染逻辑
- 参数 schema
- 导出数据生产
如果生成器需要发布模板能力和模板预览，这一阶段应收敛到 发布模板协议。
阶段 4：接入平台能力
根据真实需求接入 generator-sdk，例如：
- 登录鉴权
- 计费与积分
- 导出动作
- 云保存与历史记录
- 模板辅助能力
到了这一步，生成器才从“独立工具”变成“平台连接应用”。
阶段 5：选择统一UI布局
如果你要官方统一UI布局和样式，就用 应用壳层。
如果产品已经有自己的样式布局，就保留自定义壳层。
无论哪种方式，都要保持这三条边界稳定：
- 生成器(Runtime) 负责行为
- SDK 负责平台 API
- 应用壳(workbench)负责宿主 UI
阶段 6：验证标准化程度
在宣称“标准化完成”之前，至少验证：
- 所需平台能力已接入
- 需要时，发布模板协议(runtime contract) 已存在
- 需要时，生成器页(
full) / 模板页(embed) 已可用 - 模板场景已被真实处理
- 壳层行为稳定
对于旧生成器，务必明确区分：
- Compatibility Refactoring
- Standardization Refactoring
它们不是同一个交付里程碑。
阶段 7：为发布做准备
一个可发布的生成器通常还需要：
- 稳定的环境配置和应用身份
- 已验证的集成行为
- 可交给发布流程的构建产物
- 与改造相关的迁移说明或发布说明
这个仓库主要关注集成和交付准备度；平台侧审核与发布发生在之后。
阶段 8：发布后持续迭代
发布之后，工作通常会朝三个方向继续：
- 增加更多平台能力
- 提升标准化质量
- 从阶段性兼容继续收敛到完整标准 生成器(Runtime)
常见路径
新标准生成器
- 定义身份
- 选择 starter 和技术栈
- 接入 SDK
- 决定是否使用应用壳(workbench)
- 暴露 发布模板协议(runtime contract)
- 验证导出与模板行为
旧生成器改造
- 先判断是兼容性改造还是标准化改造
- 保持现有行为不回归
- 增加 SDK 能力
- 包装或实现发布模板协议(runtime contract)
- 决定是否接入应用壳(workbench)
- 诚实记录剩余缺口
下一步
- 如果你关心 AI 专项流程，请读 Vibe Coding 工作流。
- 如果你想看系统结构视图，请读 整体架构。