為什麼 AI 生成的 UI 圖很漂亮，落到頁面卻總是跑偏？

AI 生成嘅 UI 圖睇落好順嘅時候，最易令人放鬆警惕。後台彈出嗰條留言嘅時候，我正係睇緊一張啱啱生成嘅 SaaS 後台圖。圖好順，陰影、留白、層級都好似係咁回事，第一眼真係會令人心入面一鬆：今次應該可以直接落碼啦。

但係真係將佢塞入瀏覽器，事情即刻變咗。數據一長，卡片開始互相逼；屏幕一縮，按鈕同列表就逼埋一齊；幾個狀態頁未補齊，頁面睇落就好似少咗骨架。嗰一刻好直觀：靚，係視覺嘅事；跑得鬱，係結構嘅事。

嗰條留言將呢件事講得好直接：

呢句話冇喺抬槓，佢只係將好多人都有經歷過嗰道坎，直接擺咗上枱面。圖靚，唔等於頁面跑得鬱。

呢條留言最有價值嘅地方，唔係佢“評價咗 image2”，而係佢將真正嘅問題講清楚咗：你最終要交付嘅，唔係圖，而係頁面。AI 生成嘅 UI 圖再靚，都唔能夠代替頁面本身嘅結構判斷。

好多人第一次見到 AI 生成嘅 UI 圖，都會先俾外觀呃到。深色背景、柔和陰影、整齊卡片、似樣嘅圖標，放喺一張圖裏面睇，真係好有完成度。但係一旦將佢掟入真實業務裏面，事情即刻變複雜：數據一長，卡片就撐；屏幕一窄，佈局就塌；按鈕一多，主次就亂。

呢個唔係“AI 唔得”咁簡單。更準確咁講，係你俾佢嘅輸入，本來就唔夠佢做工程判斷。

好多人會下意識將“睇落似介面嘅圖片”當成“UI 設計稿”。呢個誤會好常見，因為佢哋喺第一眼上太似啦。

但佢哋嘅職責完全唔同。圖片負責嘅係“生咩樣”，UI 設計稿負責嘅係“點樣組織、點樣響應、點樣切換、點樣複用”。前者係外觀，後者係骨架。

喺評審會上將同一張圖放到大屏同手機預覽裏面，差異會放大得好快。大屏上睇落完整嘅模塊，一入窄屏就逼成兩層；原本睇落舒服嘅留白，換成真實數據之後就會被撐得發緊。嗰種“圖好穩、頁面好飄”嘅感覺，幾乎都係呢一步暴露出來嘅。

你可以將佢理解成睇效果圖起樓。效果圖可以睇到大約嘅風格，但唔會話俾你知承重牆、管線、樓板同動線點樣排。頁面都係一樣，得圖，代碼工具只能靠估。

呢張表嘅意思其實好簡單：單張圖唔係唔用得，而係唔可以單獨當源頭。

佢可以幫你定風格、定氛圍、定視覺密度，但佢解決唔到頁面落地最麻煩嗰部分事情。嗰啲事情唔係“好睇”，而係“可實現、可維護、可擴展”。

image-to-code 真正嘅難點，唔係“將圖翻譯成代碼”，而係“根據視覺表象估結構”。

佢睇得到三個好似嘅卡片，但未必知道呢三個卡片其實應該抽成同一個組件。佢睇得到一個好光嘅按鈕，但未必知道佢係業務主操作定次要操作。佢睇得到一塊炫光效果，但未必知道嗰只係裝飾，唔應該變成複雜嘅絕對定位。

所以你會見到一種好典型嘅結果：生成速度好快，返工亦好快。第一眼覺得用得，第二眼就開始改，第三眼已經喺手動重構。

如果只係喺“圖”同“代碼”之間來回跳，最終大概率都係會返到手改。更穩陣嘅做法，係喺中間補一層 UI Spec。好多人將呢一步理解成概念包裝，其實佢解決嘅就係 AI 生成嘅 UI 圖落地跑偏時最缺嗰層結構判斷。

呢層嘢唔需要寫得好玄，佢本質上就係一份結構化界面規範。可以係 YAML，亦可以係 JSON，重點唔係格式，而係將工程判斷提早寫清楚：

1. 頁面要解決啲咩問題。 2. 主路徑同次路徑分別係乜嘢。 3. 邊啲模塊可以複用。 4. 邊啲狀態必須補齊。 5. 響應式規則點樣變。

有咗呢層嘢，gpt-image-2 呢類模型再去出圖，就唔再係“憑感覺畫一張靚圖”，而係圍繞一個已經被約束過嘅結構去做視覺探索。圖嘅角色亦都會變輕：佢更似情緒板，唔係唯一標準。

新嘅工作流可以理解成呢一條鏈：

呢條鏈裏面最關鍵嘅一步，唔係視覺圖，而係 UI Spec。因為佢決定咗你後面係喺“估頁面”，定係喺“按結構執行”。

如果將順序理順，成條鏈路會更似真實工作現場，而唔係一次性嘅演示。

1. 先將需求意圖收窄，確認頁面到底要解決啲咩問題。 2. 再將 UI Spec 寫實，將結構、狀態、響應式、複用關係講清楚。 3. 然後俾 gpt-image-2 去做視覺探索，用圖確認氛圍同密度。 4. 接着俾 Codex / Cursor 呢類嘅代碼工具拎住 Spec 同圖一齊落碼。 5. 頁面跑起咗之後，再用截圖對比去睇差異，局部修正，形成閉環。

喺呢套工作流裏面，圖片俾人拉落咗神壇，佢唔再係唯一嘅準則，而只係一個視覺參照。真正嘅中樞大腦，係嗰份 UI Spec。

呢篇文章係呢個系列嘅開篇。如果你都厭倦咗“每次用 AI 寫前端都要手動重構”嘅痛苦，呢條鏈路值得繼續睇落去。

接下來嘅14日裏面，我會將呢套工作流掰開揉碎，一步步帶住你實操落地。我哋會繼續拆，由0到1跑完整條鏈路。

UI工作流嘅合集：AI UI 落地工作流實戰：由靚圖到可上線頁面

🎁 粉絲專屬福利：我將上面呢套底層邏輯同核心 Prompt 整理成咗一份《AI UI 落地工作流資料包》。後續如果你要繼續做系列內容，可以沿住呢條鏈路繼續補。

💬 你而家用 AI 做 UI 或者寫頁面，最卡頸嘅環節係邊一步？係唔識出圖，定係結構冇寫清，定係代碼落地後返工太重？

👉 下一篇預告：點解我唔建議直接 image-to-code，而係先俾 AI 寫一份 UI Spec。

AI 生成的 UI 圖看起來很順的時候，最容易讓人放鬆警惕。後台彈出那條留言的時候，我正盯着一張剛生成的 SaaS 後台圖看。圖很順，陰影、留白、層級都像那麼回事，第一眼確實會讓人心裏一鬆：這次應該能直接落碼了。

可真把它塞進瀏覽器，事情馬上變了。數據一長，卡片開始互相擠；屏幕一縮，按鈕和列表就擠成一團；幾個狀態頁沒補齊，頁面看着就像少了骨架。那一刻很直觀：漂亮，是視覺的事；能跑，是結構的事。

那條留言把這件事說得很直接：

這句話沒有在抬槓，它只是把很多人都經歷過的那道坎，直接擺到了桌面上。圖漂亮，不等於頁面能跑。

這條留言最有價值的地方，不是它“評價了 image2”，而是它把真正的問題說清楚了：你終究要交付的，不是圖，而是頁面。AI 生成的 UI 圖再漂亮，也不能替代頁面本身的結構判斷。

很多人第一次看到 AI 生成的 UI 圖，都會先被外觀騙到。深色背景、柔和陰影、整齊卡片、像樣的圖標，放在一張圖裏看，確實很有完成度。可一旦把它扔進真實業務裏，事情馬上變複雜：數據一長，卡片就撐；屏幕一窄，佈局就塌；按鈕一多，主次就亂。

這不是“AI 不行”這麼簡單。更準確地說，是你給它的輸入，本來就不夠它做工程判斷。

很多人會下意識把“看起來像界面的圖片”當成“UI 設計稿”。這個誤會很常見，因為它們在第一眼上太像了。

但它們的職責完全不同。圖片負責的是“長什麼樣”，UI 設計稿負責的是“怎麼組織、怎麼響應、怎麼切換、怎麼複用”。前者是外觀，後者是骨架。

在評審會上把同一張圖放到大屏和手機預覽裏，差異會被放大得很快。大屏上看着完整的模塊，一進窄屏就擠成兩層；原本看起來舒服的留白，換成真實數據以後就會被撐得發緊。那種“圖很穩、頁面很飄”的感覺，幾乎都是這一步暴露出來的。

你可以把它理解成看效果圖蓋房子。效果圖能看出大概的風格，卻不會告訴你承重牆、管線、樓板和動線怎麼排。頁面也是一樣，光有圖，代碼工具只能猜。

這張表的意思其實很簡單：單張圖不是不能用，而是不能單獨當源頭。

它可以幫你定風格、定氛圍、定視覺密度，但它解決不了頁面落地最麻煩的那部分事情。那些事情不是“好看”，而是“可實現、可維護、可擴展”。

image-to-code 真正的難點，不是“把圖翻譯成代碼”，而是“根據視覺表象猜結構”。

它看得到三個很像的卡片，卻未必知道這三個卡片其實應該抽成同一個組件。它看得到一個很亮的按鈕，卻未必知道它是業務主操作還是次要操作。它看得到一塊炫光效果，卻未必知道那只是裝飾，不該變成複雜的絕對定位。

所以你會看到一種很典型的結果：生成速度很快，返工也很快。第一眼覺得能用，第二眼就開始改，第三眼已經在手動重構。

如果只是在“圖”和“代碼”之間來回跳，終究大概率還是會回到手改。更穩的做法，是在中間補一層 UI Spec。很多人把這一步理解成概念包裝，其實它解決的就是 AI 生成的 UI 圖落地跑偏時最缺的那層結構判斷。

這層東西不需要寫得很玄，它本質上就是一份結構化界面規範。可以是 YAML，也可以是 JSON，重點不是格式，而是把工程判斷提前寫清楚：

1. 頁面要解決什麼問題。 2. 主路徑和次路徑分別是什麼。 3. 哪些模塊可以複用。 4. 哪些狀態必須補齊。 5. 響應式規則怎麼變。

有了這層東西，gpt-image-2 之類的模型再去出圖，就不再是“憑感覺畫一張漂亮圖”，而是圍繞一個已經被約束過的結構去做視覺探索。圖的角色也會變輕：它更像情緒板，不是唯一標準。

新的工作流可以理解成這一條鏈：

這條鏈裏最關鍵的一步，不是視覺圖，而是 UI Spec。因為它決定了你後面是在“猜頁面”，還是在“按結構執行”。

如果把順序理順，整個鏈路會更像真實工作現場，而不是一次性的演示。

1. 先把需求意圖收窄，確認頁面到底要解決什麼問題。 2. 再把 UI Spec 寫實，把結構、狀態、響應式、複用關係講清楚。 3. 然後讓 gpt-image-2 去做視覺探索，用圖確認氛圍和密度。 4. 接着讓 Codex / Cursor 之類的代碼工具拿着 Spec 和圖一起落碼。 5. 頁面跑起來以後，再用截圖對比去看差異，局部修正，形成閉環。

在這套工作流裏，圖片被拉下了神壇，它不再是唯一的準則，而只是一個視覺參照。真正的中樞大腦，是那份 UI Spec。

這篇文章是這個系列的開篇。如果你也厭倦了“每次用 AI 寫前端都要手動重構”的痛苦，這條鏈路值得繼續往下看。

接下來的 14 天裏，我會把這套工作流掰開揉碎，一步步帶着你實操落地。我們會繼續拆，從 0 到 1 跑完整條鏈路。

UI工作流的合集：AI UI 落地工作流實戰：從漂亮圖到可上線頁面

🎁 粉絲專屬福利：我把上面這套底層邏輯和核心 Prompt 整理成了一份《AI UI 落地工作流資料包》。後續如果你要繼續做系列內容，可以沿着這條鏈路繼續補。

💬 你現在用 AI 做 UI 或寫頁面，最卡脖子的環節是哪一步？是不會出圖，還是結構沒寫清，或者是代碼落地後返工太重？

👉 下一篇預告：為什麼我不建議直接 image-to-code，而是先讓 AI 寫一份 UI Spec。