先拆问题，而不是直接开做
交付问题通常混着状态、准备、接入和团队协作，先拆开才能更快找到下一步。
设计稿交付问题要先拆成链路状态、接入准备、试用节奏和项目阻塞四层，而不是一次性压给 docs。
不同链路成熟度不同
如果当前链路是 released，节奏和风险会和 Beta 路径完全不同。
先把步骤理顺再执行
把流程顺序看清楚后，再进入文档和具体链路页面执行会更稳。
建议阅读顺序
1
先确定设计源和目标引擎
不要只停在“设计稿交付给开发”这种泛问题，要先明确当前是蓝湖还是 Figma、Unity 还是其他目标引擎。
2
再确认当前链路成熟度
released 和 Beta 的判断方式不同，先用 roadmap 和功能页把边界核对清楚。
3
把准备和接入动作交给 docs
当链路已经明确后，再回 prerequisites 和 getting-started 文档做执行层准备。
4
最后只验证一个真实模块
先用小范围真实界面验证交付方式，而不是直接把整个项目交接逻辑都切过去。
更适合这些问题
- 团队真正关心的是“交接流程怎么组织”，而不是只看某一个 API 或按钮。
- 你需要把功能页、文档、路线图和试用动作组织成一条顺序。
- 当前项目还在交接方式评估阶段，暂时不想直接进入完整交易判断。
常见误解与开始前先确认
- 不要只停在 docs 首页，先把链路、状态和试点范围理顺。
- 如果当前问题已经收窄到单链路能力，回对应功能页会更高效。
- 如果项目阻塞已经很具体，再去 community 收口。
能力状态
先确认当前交付边界，再决定接入节奏
当前已发布、Beta 与规划中的能力，以路线图页的统一状态为准。
设计稿交付问题要先拆成链路状态、接入准备、试用节奏和项目阻塞四层，而不是一次性压给 docs。
正式版
蓝湖 → Unity
Beta
蓝湖 → Cocos、Figma → Unity、Figma → Cocos
规划中
Unity 之外的平台扩展，以及 Agent / 插件市场
FAQ
常见问题
什么时候先看 Unity workflow 场景页？
当你需要完整查看流程时，先看场景页会更合适；如果只是先理清开始顺序，这份指南更快。
什么时候需要先看功能页？
当设计源和链路已经明确时，功能页更适合查看当前状态和试用边界。
什么时候该去看价格？
当团队已经把交接顺序、链路选择和试点范围都理顺后，再看价格才更接近真实决策。