把状态、文档和反馈放到同一处
这类问题通常不只需要一篇文档或一个按钮，团队更需要把相关页面放到同一个流程里看清楚。
当前 released 链路以蓝湖 → Unity、蓝湖 → Cocos、Figma → Cocos 为主；Figma → Unity 仍按 Beta 方式评估。
团队协作比单点功能更重要
工作流问题通常不只关心“能不能转”，还关心谁来确认状态、谁来处理阻塞。
community 是流程的一部分
对于生产工作流，公开反馈板和社区支持不是补充，而是重要组成部分。
建议推进顺序
1
先明确项目当前要走哪条链路
从设计源、目标引擎和当前阶段出发，不要把所有平台放到同一个计划里。
2
用路线图校对当前成熟度
released、Beta 和 planned 的边界，会直接影响你该怎么安排团队试点与回归。
3
把准备和文档动作分开放好
prerequisites、docs hub、FAQ 和功能页分别承担不同职责，别让首页继续吞掉一切。
4
把真实阻塞回流到社区
流程型问题最终都需要回到 community 和反馈板，形成可追踪的改进路径。
更适合这些场景
- 团队想梳理“设计稿 -> 开发交付 -> 问题反馈”的整体路径。
- 除了能力状态，还关心接入阻塞、反馈渠道和后续路线图变化。
- 希望用一条稳定的公开路径把问题、状态确认和下一步动作串起来，而不是继续在 docs 和 FAQ 之间来回找入口。
立项前先确认
- 更适合用来梳理工作流方案，不替代具体功能页和接入文档。
- 如果你现在已经明确只关心 Unity 链路，先看 unity UI delivery 场景页会更聚焦。
- 如果你只是在比较不同实现方式，compare 页面更适合当前阶段。
能力状态
先确认当前交付边界，再决定接入节奏
当前已发布、Beta 与规划中的能力，以路线图页的统一状态为准。
当前 released 链路以蓝湖 → Unity、蓝湖 → Cocos、Figma → Cocos 为主；Figma → Unity 仍按 Beta 方式评估。
正式版
蓝湖 → Unity
Beta
蓝湖 → Cocos、Figma → Unity、Figma → Cocos
规划中
Unity 之外的平台扩展，以及 Agent / 插件市场
FAQ
常见问题
为什么 community 放得这么靠前？
因为工作流问题往往不是单点文档能解决的，真实项目阻塞和能力需求最终都要回到社区和反馈板。
为什么还要先看 roadmap？
因为 roadmap 提供事实状态；工作流页负责把状态、文档、功能页和社区反馈串成一个工作流。
我该从哪一页继续？
如果已经明确链路，回对应功能页；如果还在判断状态，先看 roadmap；如果已经遇到项目问题，回 community。