Uber把Figma文档塞进AI，7个技术栈的翻译活从几周缩到几

设计稿和技术文档之间的鸿沟，大概是每个跨职能团队都踩过的坑。设计师在Figma里调了八百遍的组件，工程师拿到手还得重新"翻译"成代码实现，中间漏掉的细节能再开一轮评审会。

Uber的解法是给这个翻译环节装了个自动流水线。他们在Cursor编辑器里塞了个AI代理，直连本地Figma桌面端，像爬虫一样遍历组件树，把设计token、变体轴、无障碍属性这些零散信息打包成技术规格书。原本需要人工逐页核对的几百页设计稿，现在几分钟就能出一份完整文档。

uSpec的运作逻辑：从"视觉"到"技术规格"的编译器

这个系统的核心架构被Uber工程师Ian Guisard称为"Visual-to-Technical Spec"编译器。名字听着唬人，拆解开来就是三层：感知层、理解层、输出层。

感知层靠Figma Console MCP（模型上下文协议）打通，AI代理通过WebSocket桥接本地Figma会话，实时读取组件的层级结构和属性字段。理解层做两件事：一是提取设计token（颜色、间距、字体等原子级定义），二是识别变体轴（比如按钮的size、state、theme组合）。输出层最麻烦——Uber要同时维护7个平台技术栈和3套无障碍框架，uSpec得把同一份视觉设计翻译成7份不同的技术实现规范。

过去这个翻译过程纯靠人力，设计师改一版按钮圆角，文档工程师要在7份规格书里同步更新。现在AI代理自动遍历组件树，把Figma里的图层属性映射到各平台的技术约束，生成带平台特定代码片段的文档。

无障碍文档：从"事后补票"到"自动生成"

Uber设计流程里有个特别耗时的环节：给每个组件写完整无障碍描述。屏幕阅读器标签、焦点顺序、语义化角色——这些属性在设计稿里往往是隐性的，工程师实现时容易漏掉，测试阶段再返工。

uSpec的做法是让AI代理在爬取组件时强制读取无障碍属性面板，把Figma里的accessibility标注自动提取成结构化字段。对于没填写的属性，系统会标记待补充而不是跳过，相当于给设计师开了个待办清单。

「我们维护着数百页设计文档，横跨7个平台和3个无障碍框架，任何设计变更都是组合爆炸式的工作量。」Guisard在博客中写道。这句话的潜台词是：没有自动化之前，团队要么牺牲文档完整性，要么接受进度delay——现在两个都不必选了。

为什么选Cursor+MCP，而不是从头造轮子

Uber没自研IDE，而是把AI代理塞进Cursor这个现成的AI编辑器。这个选择本身就有产品权衡：Cursor已经集成了代码补全、上下文理解、多文件编辑这些能力，团队只需要专注做Figma到技术规格的"最后一公里"映射。

MCP（模型上下文协议）是Anthropic去年开源的标准，让AI系统能安全地连接外部数据源。Uber用它做WebSocket桥接，相当于给Figma桌面端开了个只读API，AI代理能实时查询但无法修改设计稿——这个权限边界很重要，毕竟没人想让AI不小心把生产设计稿搞乱。

技术选型上还有个细节：uSpec跑在本地环境，设计数据不出内网。对于Uber这种有合规压力的公司，这比调用云端API的方案更容易过安全评审。

行业影响：设计工程化的下一个战场

uSpec的真正价值不只是省时间。它把"设计文档"这个原本依附于人力的环节，变成了可版本控制、可自动化测试的技术资产。

以前设计系统更新后，文档滞后是常态——设计师改了组件，文档工程师可能下周才有空同步。现在Figma里的变更可以触发自动化流水线，文档随设计稿实时更新，工程师看到的永远是最新有效版本。

这个模式对中大型设计系统团队有参考意义。不是每个公司都有7个技术栈要维护，但"设计-文档-实现"三者脱节的问题普遍存在。uSpec证明了一件事：当AI代理能可靠地读取结构化设计数据，中间环节的翻译成本可以被压到极低。

Uber已经在内部把uSpec跑起来，下一步是观察它能不能扛住更大规模的设计系统迭代。Guisard提到团队正在收集工程师反馈，看自动生成的规格书在实际开发中省了哪些沟通成本——这个反馈闭环本身，可能比技术实现更值得同行关注。