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