先判断痛点是否真实存在
如果项目规模很小、变化很快、输入质量很差，自动化不一定是第一优先级。
自动化是否值得开始，取决于团队是否已经出现重复返工、状态不清和设计到开发反复对齐的成本。
自动化前先确认链路状态
released 和 Beta 路径的试点方式不同，不能把所有自动化期待放在同一种成熟度假设上。
先理清流程再决定工具
先把流程、状态和试点顺序看清楚，再决定是否进入试用或继续比较方案。
建议阅读顺序
1
先确认团队现在的重复成本
判断瓶颈到底是重复搭 UI、设计到开发对齐、回归成本，还是能力状态不清。
2
再看当前要走哪条链路
明确设计源、目标引擎，以及这条路径当前是 released 还是 Beta。
3
用 docs 和一轮小试点验证
准备完成后，只在一个代表性模块上验证自动化交付方式，而不是直接全量替换。
4
再决定是否进入更正式试用
当团队已经能确认流程适配度，再去看价格、注册和后续协作范围。
更适合这些问题
- 团队已经明显感受到手工搭 UI、重复还原和对齐成本。
- 你想先判断“该不该开始自动化”，而不是直接比较某个营销口号。
- 项目需要先把流程、准备和试点范围理顺。
常见误解与开始前先确认
- 自动化不是所有项目的第一优先级，先确认痛点是否已经足够真实。
- 如果当前链路状态还没搞清楚，别急着用自动化替代所有手工流程。
- 如果输入规范太弱，先补 design guidelines 和准备动作，再谈扩面。
能力状态
先确认当前交付边界，再决定接入节奏
当前已发布、Beta 与规划中的能力，以路线图页的统一状态为准。
自动化是否值得开始，取决于团队是否已经出现重复返工、状态不清和设计到开发反复对齐的成本。
正式版
蓝湖 → Unity
Beta
蓝湖 → Cocos、Figma → Unity、Figma → Cocos
规划中
Unity 之外的平台扩展，以及 Agent / 插件市场
FAQ
常见问题
什么时候才值得开始自动化？
通常是在重复交付、设计到开发协作和回归成本已经明显拖慢团队时。
什么时候先看 compare 页？
当团队还在判断“值不值得做”时，先看 compare 更合适；如果已经准备开始，再看这份指南会更顺。
workflow 场景页还需要一起看吗？
需要。流程场景页更适合完整查看工作流；如果只是先快速判断开始顺序，这份指南会更直接。