不要把“协作工具替代”与“交付链路补齐”混成一件事
设计工具和交付工具解决的问题不同，混在一起容易把判断方向带偏。
VectoUI 更偏向设计稿交付链路，而不是通用设计协作平台的完全替代品。
真正缺的是设计到引擎的交付链路
当团队在搜索替代方案时，很多时候是在找更稳的 Unity/Cocos 交付路径。
现阶段更重要的是边界清晰
先确认当前支持链路，再决定是否值得进入体验，而不是只被“替代方案”四个字带走。
关键差异
先把对比维度拆开，再决定要不要试
| 维度 | 当前做法 | VectoUI |
|---|---|---|
| 主要解决的问题 | 设计协作、标注和设计文件管理。 | 设计稿到 Unity / Cocos UI 交付的承接与验证。 |
| 是否直接回答交付路径 | 通常不会按 released / Beta / planned 给出引擎交付边界。 | 路线图会明确当前每条设计源 → 引擎链路的成熟度。 |
| 试用前要看什么 | 更多停留在设计协作场景内。 | 更适合继续看功能页、docs、pricing 和 community 来决定是否试用。 |
建议判断顺序
1
先识别你要替代的到底是什么
如果问题是设计协作本身，这里不是最终答案；如果问题是交付给开发，这一类判断才更贴题。
2
确认当前目标链路
把需求落到蓝湖/Figma 与 Unity/Cocos 的具体组合上，再看 released/Beta 状态。
3
用功能页和 docs 验证落地性
确定目标组合后，继续进入对应功能页、docs 和 prerequisites。
4
用价格与社区决定是否试用
在链路和准备事项明确后，再看体验方式、套餐和问题反馈路径。
更适合这样使用
- 团队真正的痛点是设计稿怎么更稳地交给 Unity/Cocos 开发，而不是单纯要换掉设计工具。
- 希望在比较阶段就把 released/Beta 的边界和 next step 说清楚。
- 需要一个能直接回答“替代方案”判断问题的公开页。
做决定前先确认
- 它不承诺替代所有设计协作能力，主要承接交付链路判断。
- 如果你的目标是 Figma 路径，要额外确认当前是否为 released 还是 Beta。
- 如果你更关心手工交付和自动化交付的效率差异，应该继续看 manual prefab 对比页。
能力状态
先确认当前交付边界，再决定接入节奏
当前已发布、Beta 与规划中的能力，以路线图页的统一状态为准。
VectoUI 更偏向设计稿交付链路，而不是通用设计协作平台的完全替代品。
正式版
蓝湖 → Unity
Beta
蓝湖 → Cocos、Figma → Unity、Figma → Cocos
规划中
Unity 之外的平台扩展，以及 Agent / 插件市场
FAQ
常见问题
VectoUI 是蓝湖的完全替代品吗？
不是。它更像是在设计稿到 Unity/Cocos UI 交付这个环节补上能力，而不是替代所有设计协作场景。
我该先看哪一条功能页？
取决于你的设计源和目标引擎，先把链路明确成蓝湖/Figma 到 Unity/Cocos 的具体组合。
如果团队还没准备好试用怎么办？
先看路线图、准备文档和 FAQ，把边界与准备动作说清楚，比直接注册更稳。