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