团队形态
二人 Unity 独立工作室
来自首页公开反馈中的团队背景，而不是额外补写的客户资料。
案例页 · 蓝湖 → Unity 接入
一支小型 Unity 团队，如何把蓝湖设计稿收口到首轮 Prefab 验证
这不是另一页泛化宣传文案，而是把当前公开的 released 链路、docs 接入截图和首页已公开反馈放到同一条路径里，说明一个小团队如何从手工还原切到先验证、再扩面的接入节奏。
证据边界：本页只引用当前公开的蓝湖 → Unity released 状态、公开 docs 截图、首页 compare 流程和首页公开反馈，不补写未公开客户数据。
证据摘要
- 当前公开事实源已经足够支持蓝湖 → Unity 的首轮接入验证，不必只靠首页口号判断。
- 一个二人 Unity 团队的公开反馈显示：一个界面从一天半缩到“直接绑逻辑”，但这类提效表达只作为公开反馈引用，不写成统一 benchmark。
- released 路径适合先做单模块验证，再决定是否扩大，而不是一开始就全项目替换。
案例定义
目标链路
蓝湖 → Unity
当前在 roadmap 中属于 released 路径，是首批最稳的公开验证对象。
验证方式
先做一个真实模块
按 integration guide 和 prerequisites 先收口第一轮接入，再考虑扩面。
原来怎么做
- 美术完成设计后，还要手动导出切图与效果图，再发给客户端研发。
- 研发需要垫底效果图，手动逐个创建 UI 节点、核对 Anchor、字号和层级。
- 一旦设计改动，返工和走查会回到同一轮手工对齐流程。
用 VectoUI 后怎么做
- 研发先按公开 docs 完成插件安装、免责声明确认、API Key 绑定和设计源凭证准备。
- 在真实模块上进入 Generate Prefab 流程，先验证资源落地、层级还原和首轮输出结果。
- 通过首轮模块验证后，研发直接进入逻辑绑定，而不是继续把所有精力耗在手工还原上。
这页能明确证明什么
公开反馈中的时间变化
一个界面从一天半到直接绑逻辑
来自首页公开反馈原话，只作为个体反馈引用，不写成统一团队 benchmark。
接入可跟随性
安装、绑定、生成都已有公开截图
用户不用只靠抽象文案猜路径，当前接入过程已经有公开 docs 截图支撑。
试点节奏
先小范围验证，再决定扩面
这一节奏同时符合 released 路径的稳定性表达，也更符合小团队试错成本。
哪些环节仍需人工
- 交互逻辑默认仍由研发自行绑定，不会因为生成 Prefab 就自动替代业务逻辑。
- 设计源 token、API Key 和第三方平台访问权限仍需用户合法自行提供。
- 项目级后处理、自定义组件规则和特殊规范仍需要团队按工程现实配置。
公开截图证据
下一步
蓝湖 → Unity 功能页
如果你还要先确认当前功能边界，再回功能页看 released 状态与下一步。
蓝湖 → Unity 功能页手工 UI 前后对比证据
如果你要看的不是接入案例，而是交付前后差异，可以继续看这页。
手工 UI 前后对比证据Unity UI 自动化交付指南
当问题从“怎么接”转成“什么时候开始自动化”时，继续看这份指南。
Unity UI 自动化交付指南FAQ
邀请码、交互逻辑、字体映射和能力边界问题继续在 FAQ 收口。
FAQFAQ
常见问题
为什么这个案例不用真实客户名称做标题？
因为当前公开素材里只有个人反馈和团队背景，没有完整可公开引用的客户访谈或品牌授权，所以本页按“公开接入案例”而不是客户品牌案例来表达。
这页能证明所有 Unity 项目都能同样提效吗？
不能。这里引用的是公开反馈和公开流程证据，用来说明 released 路径已具备真实接入条件，不代表所有项目都会得到同样时间结果。
如果团队还没准备好输入规范怎么办？
先回 design guidelines、prerequisites 和 FAQ，把输入质量、权限和边界问题解决，再开始接入验证会更稳。