設(shè)計稿和技術(shù)文檔之間的鴻溝，大概是每個跨職能團隊都踩過的坑。設(shè)計師在Figma里調(diào)了八百遍的組件，工程師拿到手還得重新"翻譯"成代碼實現(xiàn)，中間漏掉的細(xì)節(jié)能再開一輪評審會。

Uber的解法是給這個翻譯環(huán)節(jié)裝了個自動流水線。他們在Cursor編輯器里塞了個AI代理，直連本地Figma桌面端，像爬蟲一樣遍歷組件樹，把設(shè)計token、變體軸、無障礙屬性這些零散信息打包成技術(shù)規(guī)格書。原本需要人工逐頁核對的幾百頁設(shè)計稿，現(xiàn)在幾分鐘就能出一份完整文檔。

uSpec的運作邏輯：從"視覺"到"技術(shù)規(guī)格"的編譯器

這個系統(tǒng)的核心架構(gòu)被Uber工程師Ian Guisard稱為"Visual-to-Technical Spec"編譯器。名字聽著唬人，拆解開來就是三層：感知層、理解層、輸出層。

感知層靠Figma Console MCP（模型上下文協(xié)議）打通，AI代理通過WebSocket橋接本地Figma會話，實時讀取組件的層級結(jié)構(gòu)和屬性字段。理解層做兩件事：一是提取設(shè)計token（顏色、間距、字體等原子級定義），二是識別變體軸（比如按鈕的size、state、theme組合）。輸出層最麻煩——Uber要同時維護7個平臺技術(shù)棧和3套無障礙框架，uSpec得把同一份視覺設(shè)計翻譯成7份不同的技術(shù)實現(xiàn)規(guī)范。

過去這個翻譯過程純靠人力，設(shè)計師改一版按鈕圓角，文檔工程師要在7份規(guī)格書里同步更新。現(xiàn)在AI代理自動遍歷組件樹，把Figma里的圖層屬性映射到各平臺的技術(shù)約束，生成帶平臺特定代碼片段的文檔。

無障礙文檔：從"事后補票"到"自動生成"

Uber設(shè)計流程里有個特別耗時的環(huán)節(jié)：給每個組件寫完整無障礙描述。屏幕閱讀器標(biāo)簽、焦點順序、語義化角色——這些屬性在設(shè)計稿里往往是隱性的，工程師實現(xiàn)時容易漏掉，測試階段再返工。

uSpec的做法是讓AI代理在爬取組件時強制讀取無障礙屬性面板，把Figma里的accessibility標(biāo)注自動提取成結(jié)構(gòu)化字段。對于沒填寫的屬性，系統(tǒng)會標(biāo)記待補充而不是跳過，相當(dāng)于給設(shè)計師開了個待辦清單。

「我們維護著數(shù)百頁設(shè)計文檔，橫跨7個平臺和3個無障礙框架，任何設(shè)計變更都是組合爆炸式的工作量?！笹uisard在博客中寫道。這句話的潛臺詞是：沒有自動化之前，團隊要么犧牲文檔完整性，要么接受進度delay——現(xiàn)在兩個都不必選了。

為什么選Cursor+MCP，而不是從頭造輪子

Uber沒自研IDE，而是把AI代理塞進Cursor這個現(xiàn)成的AI編輯器。這個選擇本身就有產(chǎn)品權(quán)衡：Cursor已經(jīng)集成了代碼補全、上下文理解、多文件編輯這些能力，團隊只需要專注做Figma到技術(shù)規(guī)格的"最后一公里"映射。

MCP（模型上下文協(xié)議）是Anthropic去年開源的標(biāo)準(zhǔn)，讓AI系統(tǒng)能安全地連接外部數(shù)據(jù)源。Uber用它做WebSocket橋接，相當(dāng)于給Figma桌面端開了個只讀API，AI代理能實時查詢但無法修改設(shè)計稿——這個權(quán)限邊界很重要，畢竟沒人想讓AI不小心把生產(chǎn)設(shè)計稿搞亂。

技術(shù)選型上還有個細(xì)節(jié)：uSpec跑在本地環(huán)境，設(shè)計數(shù)據(jù)不出內(nèi)網(wǎng)。對于Uber這種有合規(guī)壓力的公司，這比調(diào)用云端API的方案更容易過安全評審。

行業(yè)影響：設(shè)計工程化的下一個戰(zhàn)場

uSpec的真正價值不只是省時間。它把"設(shè)計文檔"這個原本依附于人力的環(huán)節(jié)，變成了可版本控制、可自動化測試的技術(shù)資產(chǎn)。

以前設(shè)計系統(tǒng)更新后，文檔滯后是常態(tài)——設(shè)計師改了組件，文檔工程師可能下周才有空同步?，F(xiàn)在Figma里的變更可以觸發(fā)自動化流水線，文檔隨設(shè)計稿實時更新，工程師看到的永遠(yuǎn)是最新有效版本。

這個模式對中大型設(shè)計系統(tǒng)團隊有參考意義。不是每個公司都有7個技術(shù)棧要維護，但"設(shè)計-文檔-實現(xiàn)"三者脫節(jié)的問題普遍存在。uSpec證明了一件事：當(dāng)AI代理能可靠地讀取結(jié)構(gòu)化設(shè)計數(shù)據(jù)，中間環(huán)節(jié)的翻譯成本可以被壓到極低。

Uber已經(jīng)在內(nèi)部把uSpec跑起來，下一步是觀察它能不能扛住更大規(guī)模的設(shè)計系統(tǒng)迭代。Guisard提到團隊正在收集工程師反饋，看自動生成的規(guī)格書在實際開發(fā)中省了哪些溝通成本——這個反饋閉環(huán)本身，可能比技術(shù)實現(xiàn)更值得同行關(guān)注。