1. 從手寫(xiě)像素到對(duì)話生成UI 開(kāi)發(fā)范式正在被重寫(xiě)我做了快十年的前端和客戶端界面從最早用 Photoshop 切圖、Dreamweaver 拖表格到后來(lái)手寫(xiě) Flex 布局、調(diào) margin 調(diào)到凌晨三點(diǎn)再到組件庫(kù)時(shí)代靠 Storybook 一個(gè)個(gè)對(duì)狀態(tài)。說(shuō)實(shí)話UI 這活兒從來(lái)不是難而是碎——碎到你明明知道長(zhǎng)什么樣卻要花幾個(gè)小時(shí)把像素、間距、圓角、陰影、hover 態(tài)、禁用態(tài)、空狀態(tài)、加載態(tài)一個(gè)個(gè)碼出來(lái)。直到我開(kāi)始把 AI 真正嵌進(jìn) UI 生產(chǎn)流程才第一次有了再也不想回去手拼的念頭。這篇不是工具軟文也不是AI 取代設(shè)計(jì)師的焦慮販賣(mài)。我想聊的是當(dāng)一個(gè)有經(jīng)驗(yàn)的開(kāi)發(fā)者把 AI 當(dāng)成 UI 生產(chǎn)管線里的一個(gè)環(huán)節(jié)而不是一個(gè)玩具時(shí)整個(gè)工作流會(huì)發(fā)生什么變化。核心關(guān)鍵詞就幾個(gè)——AI、UI、PSD、Codex、prefab。它們分別對(duì)應(yīng)了設(shè)計(jì)稿輸入、代碼生成、組件資產(chǎn)化這三段鏈路。我會(huì)把每一段拆開(kāi)講清楚為什么這樣接、中間會(huì)踩什么坑、哪些環(huán)節(jié) AI 目前還靠不住、哪些環(huán)節(jié)它已經(jīng)強(qiáng)到讓我放棄手寫(xiě)。適合誰(shuí)看如果你是會(huì)寫(xiě)代碼但對(duì) UI 效率不滿意的開(kāi)發(fā)者或者是懂設(shè)計(jì)但想快速把稿子變成可運(yùn)行界面的產(chǎn)品/設(shè)計(jì)同學(xué)再或者你只是好奇AI 到底能不能真的把 UI 寫(xiě)出來(lái)這篇都能給你一套可復(fù)現(xiàn)的思路。我不假設(shè)你用什么框架React、Vue、Unity、Android 原生都行因?yàn)榈讓舆壿嬍峭ǖ陌岩曈X(jué)意圖翻譯成結(jié)構(gòu)化描述再把結(jié)構(gòu)化描述翻譯成組件代碼最后把組件沉淀成可復(fù)用資產(chǎn)。AI 在這三步里能干的活比大多數(shù)人想的多得多。先說(shuō)結(jié)論免得你看到一半覺(jué)得我在畫(huà)餅AI 目前最擅長(zhǎng)的是從明確輸入生成第一版可運(yùn)行代碼最不擅長(zhǎng)的是理解你腦子里那個(gè)說(shuō)不清的審美。所以正確的用法不是讓它替你做設(shè)計(jì)決策而是讓它把你已經(jīng)想清楚的東西以十倍速度落地。下面我按真實(shí)工作流順序一段段拆。2. 設(shè)計(jì)稿到代碼PSD 和截圖到底該怎么喂給 AI2.1 為什么直接丟 PSD 給 AI 往往翻車(chē)很多人第一反應(yīng)是我把 PSD 丟給 AI讓它直接出代碼不就行了。我試過(guò)翻車(chē)率極高。原因不在 AI 笨而在 PSD 這種格式本身對(duì)機(jī)器極不友好。一個(gè) PSD 里可能有一百多個(gè)圖層命名是圖層 1 副本 3、矩形 27圖層組嵌套五六層還有各種被隱藏的廢棄版本、被柵格化的文字、帶蒙版的智能對(duì)象。AI 拿到這種東西等于讓一個(gè)從沒(méi)見(jiàn)過(guò)你項(xiàng)目的人去猜哪塊是按鈕、哪塊是背景裝飾。更關(guān)鍵的是PSD 里沒(méi)有語(yǔ)義。它只有像素和圖層堆疊順序。而代碼需要的是語(yǔ)義這是一個(gè)可點(diǎn)擊的按鈕還是一個(gè)純展示的標(biāo)簽這個(gè)容器是固定寬度還是自適應(yīng)這些信息 PSD 里根本沒(méi)有全靠人腦補(bǔ)。所以直接喂 PSDAI 只能給你一堆絕對(duì)定位的 div改起來(lái)比手寫(xiě)還累。我的做法是PSD 只作為視覺(jué)參考不作為生成輸入。真正喂給 AI 的是我從 PSD 里翻譯出來(lái)的結(jié)構(gòu)化描述。這個(gè)翻譯過(guò)程聽(tīng)起來(lái)多了一步但實(shí)際上它逼你把設(shè)計(jì)意圖想清楚反而減少了后面返工。2.2 截圖加結(jié)構(gòu)化描述目前最穩(wěn)的輸入組合實(shí)測(cè)下來(lái)最穩(wěn)的組合是一張干凈的截圖 一段結(jié)構(gòu)化文字描述。截圖讓 AI 理解整體布局和視覺(jué)風(fēng)格文字描述補(bǔ)上截圖里看不出來(lái)的交互語(yǔ)義和約束條件。結(jié)構(gòu)化描述我一般按這個(gè)模板寫(xiě)你可以直接抄頁(yè)面登錄頁(yè) 布局垂直居中卡片卡片寬 400px屏幕小于 480px 時(shí)卡片寬度 100% 減 32px 邊距 卡片內(nèi)元素從上到下 1. Logo 圖片高 48px居中 2. 標(biāo)題文字歡迎回來(lái)字號(hào) 24px字重 600顏色 #1A1A1A下邊距 8px 3. 副標(biāo)題請(qǐng)登錄你的賬戶字號(hào) 14px顏色 #666下邊距 24px 4. 郵箱輸入框placeholder郵箱地址類(lèi)型 email必填 5. 密碼輸入框placeholder密碼類(lèi)型 password必填右側(cè)有顯示/隱藏切換 6. 登錄按鈕主色 #2563EB圓角 8px高 44px全寬loading 態(tài)顯示 spinner 7. 底部文字鏈接忘記密碼字號(hào) 13px顏色 #2563EB居中 交互提交時(shí)按鈕進(jìn)入 loading失敗在表單頂部顯示紅色錯(cuò)誤條這段描述大概兩百字但它把 AI 需要知道的全部信息都給了層級(jí)、尺寸、顏色、狀態(tài)、交互。AI 拿到這個(gè)生成的代碼基本能直接跑改動(dòng)用手指頭數(shù)得過(guò)來(lái)。對(duì)比直接丟 PSD效率差的是數(shù)量級(jí)。提示描述里一定要寫(xiě)狀態(tài)?？諣顟B(tài)、加載態(tài)、錯(cuò)誤態(tài)、禁用態(tài)——這些是 AI 最容易漏、也是手寫(xiě)時(shí)最煩的部分。你寫(xiě)清楚它就能一次生成全。2.3 用 Codex 類(lèi)工具做描述到代碼的轉(zhuǎn)換這里就要提到Codex這類(lèi)代碼生成模型了。它的價(jià)值不在于幫你寫(xiě)代碼而在于幫你把結(jié)構(gòu)化描述穩(wěn)定地翻譯成符合你項(xiàng)目規(guī)范的代碼。這兩者差別很大。前者是通用能力后者需要你給它上下文。我的做法是給 Codex 喂三樣?xùn)|西結(jié)構(gòu)化描述、項(xiàng)目里已有的一個(gè)同類(lèi)組件作為范例、以及項(xiàng)目的樣式規(guī)范比如用 Tailwind 還是 CSS Modules命名用 BEM 還是原子類(lèi)。有了范例它生成的代碼風(fēng)格會(huì)和你項(xiàng)目一致不會(huì)一會(huì)兒用 styled-components 一會(huì)兒用內(nèi)聯(lián)樣式。舉個(gè)實(shí)際例子。我要生成一個(gè)數(shù)字滾輪效果這個(gè)在熱詞里也出現(xiàn)了Unity 和 Web 都有類(lèi)似需求。我給 Codex 的描述是組件數(shù)字滾輪 行為數(shù)字變化時(shí)舊數(shù)字向上滾出新數(shù)字從下方滾入動(dòng)畫(huà) 300ms ease-out 結(jié)構(gòu)外層容器 overflow hidden內(nèi)部?jī)尚袛?shù)字垂直排列通過(guò) transform translateY 切換 約束支持 0-9 單個(gè)數(shù)字也支持多位數(shù)字逐位滾動(dòng)它給我的第一版代碼里動(dòng)畫(huà)用了 CSS transition 加 keyframes結(jié)構(gòu)是干凈的。但有個(gè)問(wèn)題多位數(shù)字時(shí)它把每一位都包了一層導(dǎo)致間距不對(duì)。我補(bǔ)了一句每位數(shù)字寬度固定為 1ch位與位之間無(wú)額外間距第二版就對(duì)了。這個(gè)過(guò)程總共花了不到五分鐘手寫(xiě)的話光調(diào)動(dòng)畫(huà)曲線就得二十分鐘。2.4 生成之后必須做的一件事語(yǔ)義化重命名AI 生成的代碼有個(gè)通病類(lèi)名和變量名是描述性的但不夠語(yǔ)義化。比如它會(huì)生成.container-1、.text-wrapper、.btn-primary-large-blue。這些名字能跑但維護(hù)起來(lái)是災(zāi)難。我養(yǎng)成的習(xí)慣是生成完立刻做一輪重命名把.container-1改成.login-card把.text-wrapper改成.form-field。這一步花不了兩分鐘但它決定了這份代碼是一次性產(chǎn)物還是能進(jìn)代碼庫(kù)的資產(chǎn)。很多人抱怨 AI 生成的代碼沒(méi)法維護(hù)其實(shí)問(wèn)題往往出在這一步偷懶了。3. 組件資產(chǎn)化prefab 思維才是效率的真正杠桿3.1 為什么單次生成不夠資產(chǎn)化才是關(guān)鍵如果 AI 只是幫你把每個(gè)頁(yè)面單獨(dú)生成一遍那效率提升是線性的。真正讓我覺(jué)得回不去了的是組件資產(chǎn)化。這個(gè)概念在 Unity 里叫 prefab在 Web 里叫組件在 Android 里叫自定義 View本質(zhì)是一回事把一段 UI 結(jié)構(gòu)和它的行為打包成一個(gè)可復(fù)用的單元下次直接實(shí)例化改一處全局生效。AI 在這個(gè)環(huán)節(jié)的價(jià)值被嚴(yán)重低估了。大多數(shù)人用 AI 是生成一個(gè)頁(yè)面而我是生成一個(gè)組件庫(kù)。區(qū)別在于前者每次都要重新描述后者描述一次、生成一次、之后所有頁(yè)面都從組件庫(kù)里拼。舉個(gè)具體場(chǎng)景。我要做一個(gè)后臺(tái)管理系統(tǒng)有二十個(gè)頁(yè)面每個(gè)頁(yè)面都有表格、篩選欄、分頁(yè)、彈窗。如果按頁(yè)面生成我得描述二十次。但如果我先讓 AI 生成一套組件——DataTable、FilterBar、Pagination、Modal——然后每個(gè)頁(yè)面只是這些組件的組合那我的工作量從寫(xiě)二十個(gè)頁(yè)面變成寫(xiě)二十段組合配置。3.2 把生成結(jié)果沉淀成 prefab 的具體做法我的流程是這樣的第一步先讓 AI 生成一個(gè)最復(fù)雜的頁(yè)面。比如列表頁(yè)因?yàn)樗吮砀?、篩選、分頁(yè)、操作按鈕、空狀態(tài)、加載態(tài)信息密度最高。第二步從這個(gè)頁(yè)面里抽出可復(fù)用的部分。表格抽成DataTable篩選抽成FilterBar以此類(lèi)推。抽的時(shí)候我會(huì)讓 AI 幫我做一件事識(shí)別哪些部分是頁(yè)面特有的哪些是通用的。它的判斷不一定全對(duì)但能給我一個(gè)起點(diǎn)。第三步把抽出來(lái)的組件單獨(dú)生成一遍這次帶上完整的 props 定義和狀態(tài)處理。比如DataTable的 props 包括columns、data、loading、emptyText、onRowClick、rowKey。這些 props 一旦定下來(lái)后面所有頁(yè)面都按這個(gè)契約來(lái)。第四步也是最關(guān)鍵的一步建一個(gè)組件預(yù)覽頁(yè)。把所有生成的組件在一個(gè)頁(yè)面里全部渲染出來(lái)每個(gè)組件展示它的所有狀態(tài)。這個(gè)頁(yè)面是我后續(xù)開(kāi)發(fā)的字典我要用哪個(gè)組件先去預(yù)覽頁(yè)看它長(zhǎng)什么樣、支持哪些 props然后直接引用。這套流程跑下來(lái)我做一個(gè)新頁(yè)面的時(shí)間從半天壓縮到一兩個(gè)小時(shí)而且風(fēng)格絕對(duì)統(tǒng)一因?yàn)樗薪M件都來(lái)自同一個(gè)源頭。3.3 prefab 的版本管理AI 生成組件后最容易忽略的坑這里有個(gè)坑我必須單獨(dú)說(shuō)AI 生成的組件會(huì)漂移。什么意思你今天讓 AI 生成一個(gè)按鈕明天又讓它生成一個(gè)按鈕兩次的結(jié)果可能不一樣——圓角差 2px、hover 顏色差一點(diǎn)、padding 不一致。如果你不做版本管理組件庫(kù)很快就會(huì)變成一鍋粥。我的解決辦法是組件一旦定稿就凍結(jié)它的生成提示詞。把生成這個(gè)組件的完整描述存成一個(gè)文件比如button.prompt.md里面寫(xiě)清楚所有規(guī)格。以后要改按鈕改的是這個(gè)提示詞文件然后重新生成而不是直接改代碼。這樣組件永遠(yuǎn)有一個(gè)唯一真相源。另外我會(huì)給每個(gè)組件寫(xiě)一個(gè)極簡(jiǎn)的測(cè)試用例。不是單元測(cè)試那種而是渲染出來(lái)長(zhǎng)什么樣的視覺(jué)快照。AI 改完組件后跑一遍快照對(duì)比顏色、間距變了立刻能發(fā)現(xiàn)。這個(gè)習(xí)慣幫我避免了好幾次改 A 頁(yè)面把 B 頁(yè)面搞崩的事故。4. 那些 AI 目前還搞不定的 UI 細(xì)節(jié)4.1 審美判斷AI 能生成對(duì)的但生成不了好的必須潑一盆冷水。AI 生成的 UI功能上通常沒(méi)問(wèn)題但審美上經(jīng)常差一口氣。它能給你一個(gè)符合規(guī)范的按鈕但給不了你一個(gè)有品牌感的按鈕。它能排出一個(gè)整齊的布局但排不出一個(gè)有節(jié)奏感的布局。這不是模型能力問(wèn)題是信息問(wèn)題。審美是大量隱性決策的集合為什么這個(gè)間距是 12 而不是 16為什么這個(gè)圓角是 6 而不是 8為什么這個(gè)陰影是兩層而不是一層這些決策背后是品牌調(diào)性、用戶心理、視覺(jué)平衡AI 沒(méi)有這些上下文只能給你平均值。所以我的做法是AI 負(fù)責(zé)結(jié)構(gòu)和功能人負(fù)責(zé)審美微調(diào)。生成完之后我一定會(huì)手動(dòng)過(guò)一遍間距、顏色、字重、圓角。這一步不能省省了出來(lái)的東西就是AI 味——能用但沒(méi)靈魂。4.2 復(fù)雜交互狀態(tài)多狀態(tài)疊加時(shí) AI 容易顧此失彼單個(gè)狀態(tài) AI 處理得很好。但多個(gè)狀態(tài)疊加時(shí)它就開(kāi)始顧此失彼。比如一個(gè)按鈕同時(shí)處于禁用 加載中 有 tooltip的狀態(tài)AI 生成的代碼可能只處理了其中兩個(gè)。再比如一個(gè)表格同時(shí)有篩選生效 排序生效 分頁(yè)在第 3 頁(yè) 有選中行AI 很容易漏掉某個(gè)組合。我的應(yīng)對(duì)策略是把狀態(tài)組合顯式列出來(lái)讓 AI 逐個(gè)處理。不要指望它自己想到所有組合。我會(huì)在描述里寫(xiě)按鈕狀態(tài)矩陣 - 默認(rèn) / hover / active / focus - 禁用不可點(diǎn)擊透明度 0.5 - 加載中顯示 spinner不可點(diǎn)擊寬度不變 - 禁用 加載中spinner 灰色透明度 0.5 - 帶 tooltiphover 時(shí)顯示禁用時(shí)也顯示這樣列出來(lái)AI 基本能全覆蓋。你不列它就默認(rèn)只處理最常見(jiàn)的兩三個(gè)。4.3 響應(yīng)式斷點(diǎn)AI 的默認(rèn)斷點(diǎn)往往和你的項(xiàng)目不匹配AI 生成響應(yīng)式代碼時(shí)默認(rèn)用的斷點(diǎn)通常是 768px、1024px 這種通用值。但每個(gè)項(xiàng)目的斷點(diǎn)體系不一樣有的用 640/768/1024/1280有的用 576/768/992/1200。如果不對(duì)齊生成的代碼在你的項(xiàng)目里就是錯(cuò)位的。我的做法是在提示詞里顯式聲明斷點(diǎn)體系并且給一個(gè)已有頁(yè)面的響應(yīng)式寫(xiě)法作為范例。這樣 AI 會(huì)照著你的體系來(lái)而不是用它自己的默認(rèn)值。這個(gè)細(xì)節(jié)很小但不注意的話每個(gè)頁(yè)面都要手動(dòng)改斷點(diǎn)累積起來(lái)很煩。5. 把 AI 接進(jìn)日常 UI 工作流的完整鏈路5.1 我的實(shí)際工作流從需求到上線的六步說(shuō)了這么多原理我把完整鏈路串一遍。這是我現(xiàn)在的真實(shí)流程你可以直接參考需求理解拿到需求先自己想清楚頁(yè)面結(jié)構(gòu)、交互、狀態(tài)。這一步不用 AI因?yàn)橄氩磺宄脑扐I 也幫不了你。結(jié)構(gòu)化描述把想清楚的東西寫(xiě)成結(jié)構(gòu)化描述就是我前面給的那個(gè)模板。這一步是核心描述質(zhì)量決定生成質(zhì)量。首版生成把描述 項(xiàng)目范例 規(guī)范喂給 Codex 類(lèi)工具生成首版代碼。語(yǔ)義重命名 狀態(tài)補(bǔ)全手動(dòng)過(guò)一遍改類(lèi)名補(bǔ) AI 漏掉的狀態(tài)。組件抽取如果這個(gè)頁(yè)面有可復(fù)用部分抽成組件凍結(jié)提示詞進(jìn)組件庫(kù)。審美微調(diào) 響應(yīng)式對(duì)齊手動(dòng)調(diào)間距、顏色、斷點(diǎn)確保和項(xiàng)目整體一致。這六步里AI 主要參與第 3 步部分參與第 5 步。第 1、2、4、6 步還是人主導(dǎo)。但就是第 3 步的加速讓整體效率提升了三四倍。因?yàn)榈?3 步原本是最耗時(shí)的碼字環(huán)節(jié)。5.2 提示詞模板我用了半年的那套我把我的提示詞模板整理出來(lái)你可以直接改改用角色你是一個(gè)資深前端/客戶端工程師熟悉 [你的框架] 和 [你的樣式方案]。 任務(wù)根據(jù)下面的結(jié)構(gòu)化描述生成組件代碼。 項(xiàng)目規(guī)范 - 樣式方案[Tailwind / CSS Modules / styled-components / ...] - 命名規(guī)范[BEM / 原子類(lèi) / ...] - 組件范例[貼一個(gè)已有組件的代碼] - 斷點(diǎn)體系[640/768/1024/1280] 要求 1. 生成完整可運(yùn)行代碼包含所有狀態(tài) 2. 類(lèi)名語(yǔ)義化不要用 container-1 這種 3. 響應(yīng)式按上面的斷點(diǎn)體系 4. 不確定的地方用注釋標(biāo)出不要瞎猜 結(jié)構(gòu)化描述 [你的描述]這套模板的關(guān)鍵在項(xiàng)目規(guī)范和組件范例兩段。沒(méi)有這兩段AI 生成的東西風(fēng)格是飄的有了這兩段它生成的東西基本能直接用。5.3 多 AI 協(xié)作什么時(shí)候該換一個(gè)模型熱詞里有多 AI 協(xié)作我實(shí)際用下來(lái)確實(shí)不同模型有不同擅長(zhǎng)。有的模型對(duì)布局理解好有的對(duì)交互邏輯強(qiáng)有的生成的代碼更簡(jiǎn)潔。我的做法是首版用最擅長(zhǎng)的那個(gè)卡殼了換一個(gè)試試。比如布局類(lèi)的問(wèn)題某個(gè)模型總是把 flex 和 grid 用混我就換一個(gè)。交互邏輯類(lèi)的問(wèn)題某個(gè)模型總是漏狀態(tài)我也換。這不是玄學(xué)是不同模型的訓(xùn)練數(shù)據(jù)分布不同。多試幾個(gè)你會(huì)對(duì)什么問(wèn)題找哪個(gè)模型有感覺(jué)。但要注意不要同時(shí)讓多個(gè)模型改同一份代碼。會(huì)亂。我的做法是一個(gè)模型生成首版人工改改不動(dòng)了再換模型問(wèn)而不是讓它們互相改。6. 踩過(guò)的坑和幾條硬經(jīng)驗(yàn)6.1 別讓 AI 碰你的設(shè)計(jì)系統(tǒng)變量這是我踩過(guò)最疼的坑。有一次我讓 AI 生成一個(gè)頁(yè)面它沒(méi)用我項(xiàng)目里定義的設(shè)計(jì)變量比如--color-primary而是直接寫(xiě)了十六進(jìn)制顏色#2563EB。當(dāng)時(shí)沒(méi)注意后來(lái)品牌色一改這個(gè)頁(yè)面就成了孤兒顏色對(duì)不上。從那以后我定了一條死規(guī)矩提示詞里必須明確寫(xiě)所有顏色、間距、字號(hào)必須引用項(xiàng)目設(shè)計(jì)變量禁止硬編碼。并且生成后我會(huì)全局搜一遍十六進(jìn)制色值和魔法數(shù)字發(fā)現(xiàn)硬編碼就改掉。這個(gè)檢查花不了一分鐘但能省掉后面無(wú)數(shù)次返工。6.2 生成代碼的看起來(lái)對(duì)陷阱AI 生成的代碼有個(gè)特點(diǎn)看起來(lái)對(duì)跑起來(lái)也對(duì)但邊界情況全錯(cuò)。比如一個(gè)列表組件正常數(shù)據(jù)渲染沒(méi)問(wèn)題但數(shù)據(jù)為空時(shí)它渲染了個(gè)空白沒(méi)有空狀態(tài)數(shù)據(jù)超長(zhǎng)時(shí)它把布局撐破了沒(méi)有截?cái)鄶?shù)據(jù)加載中它什么都沒(méi)顯示沒(méi)有骨架屏。這些邊界情況AI 默認(rèn)不處理因?yàn)橛?xùn)練數(shù)據(jù)里大多數(shù)示例都是正常情況。所以我的習(xí)慣是生成完先不看正常情況先看邊界?？諗?shù)據(jù)、超長(zhǎng)數(shù)據(jù)、加載中、錯(cuò)誤、權(quán)限不足——這幾個(gè)場(chǎng)景挨個(gè)試一遍缺什么補(bǔ)什么。這個(gè)習(xí)慣幫我攔住了大量上線后才發(fā)現(xiàn)的 bug。6.3 關(guān)于AI 一鍵生成類(lèi)工具的理性看待熱詞里有一堆AI 一鍵生成 UI的工具。我的態(tài)度是可以試但別指望。這類(lèi)工具適合做原型、做 demo、做頭腦風(fēng)暴時(shí)的視覺(jué)參考但不適合直接進(jìn)生產(chǎn)。原因很簡(jiǎn)單生產(chǎn)代碼需要符合項(xiàng)目規(guī)范、需要可維護(hù)、需要處理邊界而一鍵生成為了追求一鍵的爽感往往犧牲了這些。我的用法是用這類(lèi)工具快速出幾個(gè)視覺(jué)方案挑一個(gè)方向?qū)Φ娜缓蟀次易约旱牧鞒讨匦律梢话娣弦?guī)范的。它幫我解決從 0 到 1 的靈感我自己的流程解決從 1 到 100 的工程化。兩者不沖突。6.4 一個(gè)反直覺(jué)的經(jīng)驗(yàn)描述寫(xiě)得越細(xì)反而越快剛開(kāi)始用 AI 生成 UI 時(shí)我總想少寫(xiě)點(diǎn)讓 AI 自己發(fā)揮。結(jié)果就是反復(fù)改改到懷疑人生。后來(lái)我發(fā)現(xiàn)反過(guò)來(lái)描述寫(xiě)得越細(xì)總耗時(shí)越短。因?yàn)閷?xiě)描述花的那十分鐘省掉的是后面一小時(shí)的來(lái)回溝通?，F(xiàn)在我寫(xiě)描述的時(shí)間經(jīng)常比生成時(shí)間還長(zhǎng)。但整體算下來(lái)還是比手寫(xiě)快得多。因?yàn)閷?xiě)描述是想清楚的過(guò)程而想清楚本來(lái)就是必須的只是以前這個(gè)想清楚發(fā)生在寫(xiě)代碼的過(guò)程中現(xiàn)在提前了。7. 我對(duì)這套工作流的真實(shí)體感用到現(xiàn)在我的體感是AI 把 UI 開(kāi)發(fā)里最枯燥但最必須的那部分——把想清楚的東西翻譯成代碼——壓縮了大概百分之七十的時(shí)間。但它沒(méi)有壓縮想清楚本身也沒(méi)有壓縮審美判斷和邊界處理。所以整體效率提升是顯著的但不是十倍那種夸張更像是從一天一個(gè)頁(yè)面變成一天三四個(gè)頁(yè)面。最讓我回不去的其實(shí)是心理上的變化。以前做 UI一想到要寫(xiě)那么多狀態(tài)、那么多響應(yīng)式、那么多重復(fù)結(jié)構(gòu)就本能地拖延。現(xiàn)在我知道這些體力活有 AI 兜底我可以把精力集中在真正需要判斷的地方——布局怎么排更合理、交互怎么設(shè)計(jì)更順、視覺(jué)怎么調(diào)更有質(zhì)感。這種把精力花在刀刃上的感覺(jué)才是我說(shuō)再也不想拼 UI的真正原因。如果你剛開(kāi)始嘗試我的建議是別一上來(lái)就追求全自動(dòng)。先從生成單個(gè)組件開(kāi)始跑通描述到代碼這一小段找到手感再慢慢擴(kuò)展到整個(gè)頁(yè)面、整個(gè)組件庫(kù)。這個(gè)過(guò)程里你會(huì)踩坑但每個(gè)坑都會(huì)讓你更清楚AI 能干什么、不能干什么。等你摸清了這個(gè)邊界它就成了你手里最順手的工具而不是一個(gè)需要你伺候的祖宗。