1. 從“拼 UI”到“說 UI”我徹底回不去了先說個(gè)背景。我做前端和客戶端開發(fā)有十年了早年最常干的一件事就是“拼 UI”——拿到設(shè)計(jì)稿拆圖層、量間距、定色值然后在代碼里一個(gè)組件一個(gè)組件地搭。這套流程熟悉到閉著眼都能走但說句實(shí)話真的累。不是體力上的累而是那種“明明只是重復(fù)勞動(dòng)卻必須全神貫注”的心累。一個(gè)按鈕的 hover 狀態(tài)、一個(gè)列表的空數(shù)據(jù)占位、一個(gè)彈窗的遮罩層級任何一處漏掉后面測試就要來敲門。自從我把 AI 引入 UI 生產(chǎn)流程之后最大的變化不是“不用寫代碼了”而是思考方式變了我不再先想“這個(gè)界面由哪些標(biāo)簽組成”而是先想“這個(gè)界面要解決什么問題、給誰用、長什么樣”。剩下的布局、樣式、狀態(tài)處理交給 AI 去生成我來判斷對不對、好不好、怎么改。從“拼 UI”變成“說 UI”這個(gè)轉(zhuǎn)變讓我工作效率至少提升了一倍而且質(zhì)量比以前更穩(wěn)定。這篇不是什么理論科普就是我本人踩了大半年坑之后沉淀下來的實(shí)戰(zhàn)總結(jié)。內(nèi)容包括我怎么選工具、怎么寫提示詞、怎么把 AI 生成的 UI 接到真實(shí)項(xiàng)目里以及那些翻過車才記住的教訓(xùn)。不管你是前端開發(fā)、客戶端開發(fā)還是偶爾要寫頁面的后端同學(xué)應(yīng)該都能從中找到可以直接抄走的思路。2. AI 生成 UI 的正確姿勢不是“一句話出頁面”這么簡單很多人一上來就以為AI 生成 UI 就是輸入“幫我做個(gè)登錄頁”然后嗖的一下出來一個(gè)能直接用的頁面。實(shí)測下來這個(gè)想法對了一半。AI 確實(shí)能做到“描述即生成”但前提是你得先把幾件基礎(chǔ)事情想清楚否則生成出來的東西大概率是“看起來像那么回事一用就露餡”。2.1 先分清你的 UI 活屬于哪一類我習(xí)慣把 UI 相關(guān)的工作分成三類因?yàn)?AI 在這三類上的表現(xiàn)完全不同第一類是“還原型”也就是照著設(shè)計(jì)稿寫頁面。這類工作 AI 的強(qiáng)項(xiàng)是快速產(chǎn)出結(jié)構(gòu)清晰、命名規(guī)范的代碼但它需要你提供足夠的信息比如設(shè)計(jì)稿截圖、配色、間距規(guī)范。你給它一張圖它能幫你把布局骨架搭個(gè)八九不離十細(xì)節(jié)再人工修。第二類是“創(chuàng)作型”也就是沒有設(shè)計(jì)稿只有需求描述需要 AI 幫你從零想一個(gè)界面方案。這類工作最有價(jià)值因?yàn)?AI 可以快速給出多套布局方案、信息層級建議、交互狀態(tài)設(shè)計(jì)幫你把模糊的需求變成可視化的頁面。你可以把它當(dāng)成一個(gè)不厭其煩的設(shè)計(jì)搭檔反復(fù)討論和迭代。第三類是“縫補(bǔ)型”比如改一個(gè)按鈕樣式、加一個(gè)狀態(tài)、調(diào)某個(gè)模塊的間距。這類工作量小但頻率高AI 的上下文理解能力強(qiáng)你只需要告訴它“把購物車按鈕改成圓角膠囊樣式主色換成品牌藍(lán)”它就能精準(zhǔn)定位到代碼并修改。分清這三類之后你才能給 AI 下達(dá)正確的指令。很多人失敗的原因就是把“創(chuàng)作型”需求當(dāng)成了“一句話出稿”把“還原型”需求當(dāng)成了“AI 應(yīng)該自己會(huì)看設(shè)計(jì)稿”需求錯(cuò)位結(jié)果自然不對。2.2 選對工具別讓工具成為瓶頸我試過的 AI 輔助 UI 工具不少簡單做個(gè)分類供參考類型典型代表適合場景我的建議對話式編碼助手GitHub Copilot、Cursor、Fitten Code 這類插件在 IDE 里直接生成和修改代碼日常主力邊寫邊問效率最高通用大模型對話ChatGPT、Claude、Kimi、豆包這類需求討論、方案設(shè)計(jì)、提示詞打磨適合前期頭腦風(fēng)暴和生成整體方案圖像生成模型Midjourney、Stable Diffusion、即夢這類生成視覺稿、概念圖、素材適合“創(chuàng)作型”中的視覺探索階段UI 專用工具各類 AI 設(shè)計(jì)工具從文本直接生成可編輯的設(shè)計(jì)稿適合不會(huì)寫代碼但要做界面的人我的主力組合是“IDE 內(nèi)的編碼助手 通用大模型對話”。比如用 Cursor 寫 Vue 組件遇到復(fù)雜邏輯時(shí)切到通用大模型里討論方案再把結(jié)論帶回來讓編碼助手落地。我自己在 PyCharm 里也裝了 Fitten Code 這類插件因?yàn)槿粘＿€要維護(hù)一些 Python 工具鏈它能根據(jù)注釋生成代碼、解釋別人的代碼邏輯做 UI 數(shù)據(jù)層的時(shí)候非常好用。這里有個(gè)很容易被忽略的點(diǎn)工具不在多而在順手。你不需要把所有 AI 工具都裝一遍找到兩個(gè)能深度融入你日常流程的就夠了。我見過不少同學(xué)收藏了一堆 AI 工具結(jié)果每天光切換工具就花半小時(shí)最后又回到了手寫代碼的老路。2.3 給 AI 喂足上下文別讓它盲猜AI 生成 UI 最大的問題不是“不會(huì)寫”而是“瞎猜”。你問它“做一個(gè)用戶列表頁”它大概率會(huì)默認(rèn)給你一個(gè)表格加搜索框的模板。但你的項(xiàng)目可能需要的是卡片式布局、需要分頁、需要行內(nèi)操作按鈕這些它都不知道。所以在動(dòng)手之前我通常會(huì)給 AI 準(zhǔn)備一份“項(xiàng)目上下文”包含這幾個(gè)要素產(chǎn)品定位這是面向 C 端消費(fèi)者還是 B 端管理后臺(tái)風(fēng)格偏活潑還是嚴(yán)肅技術(shù)棧React 還是 Vue有沒有現(xiàn)成的組件庫如 Element Plus、Ant Design設(shè)計(jì)約束主色、圓角、間距基準(zhǔn)、字體體系。哪怕只說一句“參考 Material Design 風(fēng)格”也比什么都不說要好。功能清單這個(gè)頁面需要哪些模塊模塊之間的優(yōu)先級是什么。把這些信息組織成一段簡短的說明AI 的輸出質(zhì)量會(huì)提升一個(gè)檔次。我的經(jīng)驗(yàn)是上下文寫五句話比提示詞寫得花哨五倍更有用。3. 我實(shí)測過的 AI 生成 UI 完整工作流這套流程我用了大半年已經(jīng)比較穩(wěn)定。核心思路是先定方案、再出骨架、然后細(xì)化組件、最后處理狀態(tài)和交互。每一步都有 AI 的參與但參與方式不一樣。3.1 第一步用對話把需求變成界面方案我一般從需求描述開始比如“做一個(gè)工單管理頁面運(yùn)營人員需要查看所有工單的狀態(tài)、優(yōu)先級、處理人并且支持篩選和批量操作”。拿這句話去問通用大模型讓它給出頁面結(jié)構(gòu)建議。一個(gè)好的回答會(huì)包含頁面頂部是統(tǒng)計(jì)卡片待處理、處理中、已關(guān)閉數(shù)量中間是篩選區(qū)狀態(tài)、優(yōu)先級、時(shí)間范圍下方是列表最后是批量操作欄。AI 還會(huì)告訴你哪些信息應(yīng)該突出顯示、哪些操作用按鈕還是下拉菜單。這一步的價(jià)值在于你花十分鐘就能拿到一個(gè)經(jīng)過專業(yè)設(shè)計(jì)思維打磨的頁面信息架構(gòu)。以前我拿到這種需求得自己先畫草圖、列模塊、排優(yōu)先級少說也要一小時(shí)?，F(xiàn)在這個(gè)過程被壓縮到了幾分鐘。得到方案之后我會(huì)讓它輸出一個(gè) ASCII 線框圖如果你愿意也可以讓它生成一份 Markdown 格式的頁面結(jié)構(gòu)說明確認(rèn)層級關(guān)系沒問題再進(jìn)入下一步。3.2 第二步讓編碼助手生成頁面骨架方案確認(rèn)后我把完整的頁面結(jié)構(gòu)描述貼到 IDE 的 AI 助手對話框里讓它生成一個(gè)基礎(chǔ)版頁面。比如用 Vue 3 Element Plus我的提示詞大概長這樣用 Vue 3 組合式 API Element Plus 實(shí)現(xiàn)一個(gè)工單管理頁面。頁面結(jié)構(gòu)如下 1. 頂部放 3 個(gè)統(tǒng)計(jì)卡片待處理、處理中、已關(guān)閉各自顯示數(shù)量。 2. 篩選區(qū)包括狀態(tài)下拉框、優(yōu)先級下拉框、時(shí)間范圍選擇器右側(cè)放“查詢”和“重置”按鈕。 3. 主體是一個(gè) el-table列包括工單編號、標(biāo)題、狀態(tài)、優(yōu)先級、創(chuàng)建人、創(chuàng)建時(shí)間、操作。 4. 操作列包含“查看”和“處理”兩個(gè)按鈕。 5. 底部是分頁器支持頁碼切換和每頁條數(shù)切換。 請生成完整的單文件組件代碼樣式使用 scoped間距遵循 Element Plus 默認(rèn)規(guī)范。這段提示詞包含了技術(shù)棧、頁面結(jié)構(gòu)、組件要求、樣式約定四個(gè)維度的信息。AI 返回的代碼雖然不是一次就能直接用但整體完成度能達(dá)到七成以上——布局正確、組件用對、事件綁定也合理。剩下的就是細(xì)節(jié)調(diào)整。3.3 第三步組件級微調(diào)與狀態(tài)補(bǔ)全骨架生成之后真正的活才開始。我會(huì)逐個(gè)模塊檢查把發(fā)現(xiàn)的問題再丟給 AI 解決。典型的微調(diào)包括統(tǒng)計(jì)卡片需要支持?jǐn)?shù)字動(dòng)畫讓 AI 加上過渡效果表格的“狀態(tài)”列需要根據(jù)值顯示不同顏色的標(biāo)簽讓 AI 用 tag 組件的 type 屬性映射操作按鈕需要權(quán)限控制沒有權(quán)限時(shí)隱藏讓 AI 加一段簡單的權(quán)限判斷邏輯空數(shù)據(jù)時(shí)要顯示自定義的插圖讓 AI 處理好 empty 插槽這個(gè)階段我把它叫做“對話式開發(fā)”。它不是一次生成就結(jié)束而是你一句、AI 一句像和一個(gè)熟悉技術(shù)的同事結(jié)對編程。你提出修改要求它修改代碼你再檢查再提要求。這個(gè)循環(huán)通常三到五輪就能把頁面打磨到接近可交付的狀態(tài)。3.4 第四步從視覺稿到代碼的逆向生成還有一種常見場景設(shè)計(jì)同事給了一張視覺稿但切圖標(biāo)注不全、規(guī)范文檔過期。以前遇到這種我只能憑眼力一像素一像素地量現(xiàn)在可以直接把設(shè)計(jì)稿截圖丟給支持圖像理解的大模型讓它描述布局和樣式再結(jié)合編碼助手生成代碼。這個(gè)流程我試過幾次效果好的時(shí)候非常驚艷AI 能準(zhǔn)確讀出按鈕顏色、字體大小、間距值生成的代碼還原度在八成以上。效果不好的時(shí)候主要是遇到復(fù)雜圖形、漸變紋理、特殊字體這些AI 容易“想當(dāng)然”。我的處理辦法是圖形素材和漸變背景讓 UI 同學(xué)切圖導(dǎo)出AI 只負(fù)責(zé)布局和基礎(chǔ)樣式。人機(jī)結(jié)合各干各擅長的部分。4. 提示詞才是真正的分水嶺會(huì)寫和不會(huì)寫差距巨大同一個(gè) AI有些人用起來像神有些人用起來像人工智障。差距不在工具的差異而在提示詞的寫法。寫 UI 提示詞這件事我總結(jié)了一套自己的方法分享出來給大家參考。4.1 一個(gè)能用的 UI 提示詞包含四個(gè)要素我見過最多的失敗提示詞是那種只有一個(gè)短句的比如“幫我把這個(gè)頁面做好看一點(diǎn)”“生成一個(gè)注冊頁”。AI 不是不想幫你是它實(shí)在不知道你心里想的“好看”到底是個(gè)什么樣。實(shí)用的 UI 提示詞模板我總結(jié)為四段式角色與任務(wù)你是資深前端工程師幫我實(shí)現(xiàn)某某頁面。技術(shù)上下文用了什么框架、什么組件庫、什么版本規(guī)范。結(jié)構(gòu)與功能頁面包含哪些模塊每個(gè)模塊的內(nèi)容和交互是什么。風(fēng)格與約束用什么配色、什么風(fēng)格、有哪些不要做的。舉個(gè)例子你是資深前端工程師使用 React 18 TypeScript Ant Design 5 幫我實(shí)現(xiàn)一個(gè)數(shù)據(jù)報(bào)表頁面。 頁面頂部是四個(gè)指標(biāo)卡片今日訂單量、今日銷售額、退款金額、在線用戶數(shù)數(shù)值需要格式化為千分位。 中間是一個(gè)折線圖展示最近七天的銷售額趨勢X 軸顯示日期Y 軸自動(dòng)縮放。 下方是一個(gè)表格展示最近 20 條訂單記錄包括訂單號、客戶姓名、金額、狀態(tài)、下單時(shí)間。 風(fēng)格要求簡潔商務(wù)以白色和淺灰為主主色用 #1677ff不需要暗黑模式代碼使用函數(shù)組件和 hooks。這種提示詞生成出來的代碼基本就是可以直接提交的程度。核心原則是你描述得越具體AI 發(fā)揮的臆測空間就越小。4.2 用“示例”代替“形容詞”想讓 AI 理解你的審美最有效的辦法不是寫形容詞而是給示例。你說“現(xiàn)代感強(qiáng)一點(diǎn)”AI 可能理解為無邊框極簡風(fēng)你說“參考 Airbnb 的搜索頁面風(fēng)格”AI 就知道該怎么配色、怎么排版。我在項(xiàng)目里維護(hù)了一個(gè)“風(fēng)格示例庫”里面有幾段描述不同風(fēng)格的文本比如“類似 Notion 的克制型排版”“類似 Stripe 的漸變與圓潤感”“類似 Ant Design Pro 的后臺(tái)風(fēng)格”。寫提示詞的時(shí)候直接引用這些描述比我自己糾結(jié)“科技感”“高級感”靠譜得多。另外一個(gè)小技巧如果你手頭有滿意的歷史代碼直接告訴 AI“參考我項(xiàng)目里的dashboard.vue這個(gè)文件的樣式寫法”它會(huì)從你的代碼里提取風(fēng)格特征而不是憑空創(chuàng)造一套新風(fēng)格。這一點(diǎn)對保持項(xiàng)目一致性特別重要。4.3 迭代式提問一次到位是奢望三到五輪才算正常我剛開始用 AI 做 UI 的時(shí)候總希望一次提示就能生成完美代碼結(jié)果每次都不滿意然后就開始懷疑工具不行。后來想明白一個(gè)道理和人協(xié)作的時(shí)候你也不會(huì)只交代一句就讓對方把整個(gè)頁面做完而是邊做邊確認(rèn)。對 AI 也是一樣。第一輪讓它出骨架第二輪讓它調(diào)樣式第三輪讓它補(bǔ)交互第四輪讓它處理邊界狀態(tài)。每輪只提一個(gè)核心訴求AI 的完成度會(huì)明顯更高。如果你一次提五個(gè)修改要求它往往顧此失彼改完一個(gè)忘了另一個(gè)。我現(xiàn)在的習(xí)慣是“小步快跑”一次對話只解決一個(gè)具體問題改完立即檢查確認(rèn)沒問題再進(jìn)入下一個(gè)。這個(gè)習(xí)慣讓我和 AI 協(xié)作的產(chǎn)出穩(wěn)定性大幅提升也減少了很多無意義的重復(fù)修改。5. 實(shí)戰(zhàn)記錄我用 AI 重做了一個(gè)設(shè)置頁面光說理論容易飄拿一個(gè)我近期實(shí)際做的案例完整走一遍。項(xiàng)目背景是一個(gè)企業(yè)內(nèi)部工具的設(shè)置頁面原本的頁面是幾年前的舊實(shí)現(xiàn)代碼風(fēng)格混亂組件庫版本落后樣式適配也有問題。需求是“在不改變功能的前提下用新技術(shù)棧重寫界面按最新的設(shè)計(jì)規(guī)范來”。5.1 先讓 AI 做一次“代碼體檢”我沒有急著讓它重寫而是先把舊頁面代碼丟給 AI讓它分析頁面有哪些功能模塊、當(dāng)前使用的是什么組件、代碼里有哪些冗余和坑。這一步花了兩分鐘AI 給出的結(jié)論比我預(yù)想的全面得多除了我已知的幾個(gè)問題它還指出舊代碼在表單校驗(yàn)上存在邏輯漏洞某個(gè)按鈕的禁用條件寫反了。這個(gè)“先分析后動(dòng)手”的步驟值得多說兩句。很多人拿到舊代碼就直接讓 AI 重寫結(jié)果新代碼可能繼承甚至放大舊代碼的問題。先讓 AI 做一次結(jié)構(gòu)拆解和問題診斷相當(dāng)于做一個(gè)免費(fèi)的前置審計(jì)后面生成的新代碼會(huì)更有針對性。5.2 按模塊逐個(gè)生成并驗(yàn)證設(shè)置頁面一般包含基礎(chǔ)信息、賬號安全、通知偏好、外觀設(shè)置等區(qū)塊。我按照這個(gè)結(jié)構(gòu)讓 AI 每次只生成一個(gè)模塊。以“通知偏好”模塊為例我的提示詞是用 Vue 3 Element Plus 實(shí)現(xiàn)通知偏好設(shè)置模塊。 包括三個(gè)開關(guān)郵件通知、短信通知、站內(nèi)信通知。 其中短信通知開關(guān)打開時(shí)需要顯示一個(gè)手機(jī)號輸入框并在下方展示一條說明文字僅支持中國大陸手機(jī)號。 再往下是一個(gè)多選組選擇需要在哪些事件上接收通知可選內(nèi)容包括任務(wù)狀態(tài)變更、審批通過、審批駁回、系統(tǒng)公告。 最后是“保存設(shè)置”按鈕點(diǎn)擊后先做前端校驗(yàn)短信通知打開時(shí)必須填手機(jī)號且格式合法校驗(yàn)通過后調(diào)用 saveSettings 方法。AI 返回的代碼讓我很滿意不只是把功能實(shí)現(xiàn)出來了還主動(dòng)加了幾個(gè)我沒想到的點(diǎn)開關(guān)切換時(shí)保留原狀態(tài)、校驗(yàn)失敗時(shí)滾動(dòng)定位到對應(yīng)表單項(xiàng)、保存成功后彈窗提示。當(dāng)然這些“主動(dòng)行為”不一定都對比如滾動(dòng)定位在某些場景下反而干擾體驗(yàn)但我可以一處處檢查、保留合理的、刪掉多余的。5.3 讓 AI 處理“項(xiàng)目級”的樣式一致性頁面所有模塊都生成完之后還存在一個(gè)整理問題AI 分段生成的代碼在樣式上不一定完全統(tǒng)一。有的模塊用了 20px 間距有的用了 24px有的按鈕是圓角 4px有的是 6px。我的解決方案是先把頁面級的設(shè)計(jì)規(guī)范寫成一個(gè)常量文件比如間距定義、圓角定義、主色和功能色再讓 AI 把所有模塊的代碼統(tǒng)一引用這套變量。這個(gè)過程我一開始手動(dòng)做了很多輪后來發(fā)現(xiàn)可以直接告訴 AI“請檢查我生成的所有組件把硬編碼的間距、圓角、顏色值全部替換為統(tǒng)一的 scss 變量”它能快速掃描并替換效率極高。整個(gè)設(shè)置頁面從分析到交付大概用了兩個(gè)小時(shí)。放在以前這個(gè)量級的工作至少需要一個(gè)整天而且大概率還需要 UI 同學(xué)反復(fù)確認(rèn)樣式細(xì)節(jié)。6. 常見翻車現(xiàn)場與排查心得AI 做得再順也避不開翻車。這一節(jié)專門整理我在實(shí)踐中遇到的高頻問題每條都是我交了學(xué)費(fèi)換來的。6.1 生成代碼中用錯(cuò)了組件 API這是出場率最高的問題。AI 有時(shí)候會(huì)把 Ant Design 的Button的type屬性寫成round但實(shí)際應(yīng)該是shaperound或者用錯(cuò)了 Element Plus 的表格事件名導(dǎo)致篩選功能不生效。這類問題不好根除我的對策是在提示詞里明確寫清楚組件庫版本比如“Element Plus 2.6 版本”。生成代碼后先讓 AI 自查一遍“檢查這段代碼的組件 API 是否符合所用組件庫的官方文檔列出所有不匹配的地方并修正?！笨雌饋砥婀值牡胤饺ゲ橐幌鹿俜轿臋n確認(rèn)。這個(gè)自查步驟能過濾掉一半以上的 API 誤用問題強(qiáng)烈建議加入流程。6.2 布局在不同屏幕寬度下直接崩掉AI 生成的頁面有一個(gè)通病在固定寬度下看起來很正常一縮小窗口就變形。因?yàn)樗J(rèn)按 1440px 寬度來寫布局很少主動(dòng)處理響應(yīng)式。我的處理辦法是在提示詞里專門加一句“此頁面需要在 1024px 到 1920px 寬度范圍內(nèi)正常顯示使用合適的柵格布局或 flex 換行策略避免橫向滾動(dòng)條”。如果頁面已經(jīng)生成了也可以讓 AI 檢查并補(bǔ)全響應(yīng)式樣式。實(shí)測這個(gè)提示非常管用加上之后布局崩壞的問題減少明顯。6.3 交互狀態(tài)覆蓋不全界面能看、功能能跑但交互狀態(tài)缺一堆這也是 AI 生成 UI 的老毛病。典型情況包括按鈕沒有禁用態(tài)樣式、輸入框沒有錯(cuò)誤態(tài)提示、表格行沒有 hover 高亮、彈窗沒有關(guān)閉后的回調(diào)處理。對此我的心得是在需求描述階段就把狀態(tài)清單列出來告訴 AI“請覆蓋 hover、active、disabled、error、empty、loading 這些狀態(tài)”。如果忘了說也沒關(guān)系后面檢查時(shí)發(fā)現(xiàn)缺哪個(gè)狀態(tài)單獨(dú)提一句讓 AI 補(bǔ)上即可。關(guān)鍵是你要有“狀態(tài)齊全”的意識不能拿到能跑的頁面就覺得大功告成。6.4 常見問題速查表問題現(xiàn)象主要原因解決方案代碼跑不起來、報(bào)錯(cuò)組件 API 用錯(cuò)或依賴缺失讓 AI 自查 API 文檔檢查 import 是否完整樣式和設(shè)計(jì)稿差距大缺少視覺規(guī)范上下文提供色值、間距、截圖參考少用抽象形容詞響應(yīng)式崩壞未聲明目標(biāo)寬度范圍提示詞里加響應(yīng)式要求或讓 AI 補(bǔ)全 media query頁面生成了但交互不完整沒列狀態(tài)清單要求覆蓋 hover、disabled、error、loading 等狀態(tài)組件之間樣式不統(tǒng)一多輪生成缺少共享規(guī)范定義設(shè)計(jì)變量常量文件AI 統(tǒng)一替換硬編碼值A(chǔ)I 修改一個(gè)地方帶崩另一處一次給出多個(gè)修改訴求一次只提一個(gè)修改要求改完驗(yàn)證再繼續(xù)6.5 一個(gè)容易被忽視的坑AI 會(huì)在你不注意時(shí)“加戲”AI 有個(gè)讓我又愛又恨的習(xí)慣——自作主張加功能。比如你讓它生成一個(gè)登錄表單它可能在頁面上塞一個(gè)“忘記密碼”鏈接外加一個(gè)“注冊賬號”入口。這些不一定是你想要的。所以我現(xiàn)在的驗(yàn)收流程里多了一步讓 AI 列出它“主動(dòng)添加但未在需求中提到”的內(nèi)容清單。這個(gè)功能看似簡單卻能避免很多“驚喜”。你可以在生成代碼后追加一句“請檢查你的輸出列出所有超出需求描述范圍的內(nèi)容?！盇I 會(huì)老老實(shí)實(shí)告訴你它加了什么你再?zèng)Q定是留下還是刪掉。7. 用 AI 拼 UI 的邊界哪些活它干不了哪些活你會(huì)更值錢用 AI 半年多我對它的能力邊界有了比較清醒的認(rèn)識。它擅長的是“執(zhí)行”也就是把明確的需求翻譯成結(jié)構(gòu)清晰的代碼和樣式它不擅長的是“判斷”尤其是涉及產(chǎn)品感覺、業(yè)務(wù)邏輯和用戶體驗(yàn)取舍的時(shí)候。舉個(gè)例子讓 AI 決定“這個(gè)頁面是放表格還是放卡片列表”它給出的選擇可能合理但它不明白你的業(yè)務(wù)場景里用戶每天要處理上百條工單表格的密集排版更適合快速掃描。這種決策還是需要你來判斷。AI 可以給你備選方案但你才是那個(gè)知道業(yè)務(wù)訴求和用戶習(xí)慣的人。正因如此我反而覺得 AI 時(shí)代的 UI 開發(fā)者不是貶值了而是轉(zhuǎn)型了。以前時(shí)間花在“拼組件、調(diào)間距”這些執(zhí)行層面現(xiàn)在這些交給 AI 之后省出來的時(shí)間可以用來做更值的思考信息架構(gòu)合不合理、交互流程順不順、邊界狀態(tài)處理全不全、性能表現(xiàn)好不好。這些“人的判斷力”恰恰是 AI 最缺乏的。我現(xiàn)在的日常工作流里AI 大概承擔(dān)了七成左右的 UI 實(shí)現(xiàn)工作量省下的時(shí)間我用來做代碼審查、性能優(yōu)化和設(shè)計(jì)評審。這個(gè)比例我試過往上調(diào)但效果并不好——AI 目前還沒有那個(gè)能力獨(dú)立負(fù)責(zé)一個(gè)模塊的完整質(zhì)量。最后說幾句實(shí)在話從“拼 UI”到“說 UI”本質(zhì)上是把精力從“怎么實(shí)現(xiàn)”轉(zhuǎn)移到了“實(shí)現(xiàn)什么”和“為什么這么實(shí)現(xiàn)”上。我個(gè)人在實(shí)際操作中的體會(huì)是AI 改變的不是某一個(gè)具體工具或某種寫法而是整個(gè)工作節(jié)奏和思維方式。以前一個(gè)頁面的交付周期是“一天”現(xiàn)在是“半天甚至兩小時(shí)”但前提是你得掌握跟它打交道的方法。如果你現(xiàn)在還在煩惱“AI 生成的代碼沒法用”我的建議是先別急著懷疑 AI回去看看自己給它的信息夠不夠。給它說清楚你要什么、限制什么、風(fēng)格參考什么它回饋給你的往往超出預(yù)期。把這個(gè)協(xié)作模式練熟之后你會(huì)和我一樣再也不想回到那個(gè)純手工拼 UI 的時(shí)代了。