不要再直接把 UI 圖轉成代碼了，先看這份 UI Spec 模板
整理版優先睇
先寫 UI Spec 再出圖，唔好直接將 UI 圖轉代碼，否則頁面落地會走樣。
呢篇文章係 MaxKing 分享嘅真實經驗，佢見到好多人直接將 AI 生成嘅 UI 圖丟俾圖片轉代碼工具，結果頁面落地就出問題——數據一長就逼爆、屏幕一窄就塌、狀態漏曬。作者指出，圖只係視覺表達，決定頁面能否跑嘅係結構，工程判斷先係關鍵。
為咗解決呢個問題，作者提出先寫 UI Spec——一份結構化界面規範，用 YAML 或 JSON 寫清楚頁面目的、目標用戶、主要動作、佈局類型、模塊、狀態（loading/empty/error/normal）、響應式規則、視覺 Token 同驗收標準。呢層架構可以幫 AI 唔再靠估，而係根據規範做視覺探索。
作者用交易儀表盤做例子，示範點樣用 UI Spec 穩定生成頁面，並畀出四步法：自己填一版 Spec → 叫 AI 檢查有冇漏 → 用 Spec 生成視覺圖 → 用 Spec 加參考圖生成代碼。佢強調只要前面寫清楚，後面 AI 生成頁面會穩定好多。文章最後附送完整模板，可以回覆「UI工作流」領取。
- 直接將 UI 圖轉代碼會忽略結構、狀態同響應式，導致頁面落地跑偏，返工成本高。
- UI Spec 係結構化規範，用 YAML 或 JSON 寫，定義頁面骨架，唔係淨係外觀。
- 圖片只能表達視覺，工程判斷（組件級別、狀態、響應式）係 AI 靠估嘅原因。
- 建議流程：需求 → UI Spec → 視覺參考 → 代碼實現，跳過呢步好易走歪。
- 實戰案例：交易儀表盤先寫 Spec 再出圖，產出穩定好多，唔會第一眼靚第二眼改。
最小可用 UI Spec 模板
YAML 格式嘅 UI Spec 模板，包含 page、sections、states、responsive、visual_tokens、acceptance 等字段。
點解唔好直接將圖轉代碼？
有人將一張 AI 生成嘅後台圖貼上羣，問可唔可以直接丟俾 圖片轉代碼工具。圖本身好靚，陰影、留白、層級都在，但作者一望就知有問題：呢張圖冇話俾工具知呢個頁面畀邊個用、先睇咩、狀態點補、手機點摺。
結果你都估到：數據一長，卡片就逼爆；屏幕一縮，按鈕同列表互相頂撞；狀態頁冇補齊，頁面似冇咗骨架。作者直言：圖能畀 AI 視覺結果，畀唔到工程判斷。
好多人第一次見到 AI 生成嘅 UI 圖，都會俾外觀呃到。深色背景、柔和陰影、整齊卡片，一張圖睇好有完成度。但放入真實業務，問題即刻浮面：數據一長卡片就撐、屏幕一窄佈局就塌、按鈕一多主次就亂。呢個唔係「AI 唔得」，而係輸入本來就唔夠做工程判斷。
作者特別提到羣裏一條留言點出真問題：UI Spec 唔係多寫一步，而係先講清楚結構，再叫工具去畫、去寫、去落地。
UI Spec 到底係咩？
好多人將「睇起嚟似界面嘅圖片」當成 UI 設計稿。呢個誤會好常見，因為第一眼真係好似。但兩者要解決嘅事唔同：圖片主要答「長成點」，設計稿仲要答「點組織、點響應、點切換、點複用」。前者偏外觀，後者更接近頁面骨架。
同一張圖，大屏睇好完整，切到手機預覽就開始逼；佔位文案睇得舒服，換成真實數據後留白同卡片邊界即刻緊曬。嗰種「圖好穩、頁面好飄」嘅感覺，就係喺呢度暴露。而前端真正要落地嘅，正正就係呢啲工程信息。
- 組件層級：單張圖提供唔到，AI 好易平鋪成一堆 div，似但結構散。
- 交互與頁面狀態：冇 Hover、Loading、Empty、Error，頁面似靜止海報。
- 響應式規則：一到手機端就跑版，文字擠壓，模塊互相頂撞。
- 設計 Token：顏色、字號、間距靠估，後面好難接入統一體系。
- 真實數據邊界：佔位符一換成長文本，卡片即刻撐爆。
單張圖唔係唔用得，但唔可以單獨當源頭。佢可以幫你定風格、定氛圍、定視覺密度，但頁面落地最麻煩嘅部分，係「能唔能夠實現、能唔能夠維護、能唔能夠繼續擴展」。
最小可用 UI Spec 模板
如果只喺「圖」同「代碼」之間來回跳，好大機會回到手改。更穩嘅做法，係中間補一層 UI Spec。呢一步唔係概念包裝，而係要解決 AI 生成嘅 UI 圖落地時最易缺嘅結構判斷。格式唔重要，YAML 或 JSON 都得，重點係先將工程判斷寫清楚：
- 1 頁面要解決咩問題
- 2 主路徑同次路徑分別係咩
- 3 邊啲模塊可以複用
- 4 邊啲狀態必須補齊
- 5 響應式規則點變
MaxKing.cc
page:
name: 頁面名稱
purpose: 頁面目的
target_user: 目標用戶
primary_action: 用戶核心動作
layout_type: dashboard / form / list / detail / landing
sections:
- name: 模塊名稱
purpose: 模塊作用
priority: high / medium / low
component_type: Card / Table / Form / Tabs / Chart
states:
- loading
- empty
- error
- normal
responsive:
desktop: 桌面端佈局
tablet: 平板端佈局
mobile: 移動端佈局
visual_tokens:
color_style: 視覺風格
density: 信息密度
radius: 圓角規則
spacing: 間距規則
acceptance:
- 驗收標準 1
- 驗收標準 2有咗呢層嘢，AI 再出圖就唔係「憑感覺畫靚圖」，而係圍繞被約束過嘅結構去做視覺探索。圖嘅角色會變輕，似情緒板多過唯一標準。
點樣用呢份模板？以交易儀表盤為例
作者用自己嘅交易儀表盤做例子。佢唔會直接講「幫我生成一個高級交易後台」，因為咁樣 AI 好易生成一個好型但唔一定用得嘅頁面。佢會先寫一份 UI Spec：
MaxKing.cc
page:
name: 交易儀表盤
purpose: 幫助用戶快速查看賬户風險、持倉和交易信號
target_user: 個人交易者 / 專業交易員
primary_action: 查看當前賬户風險
layout_type: dashboard
sections:
- name: 賬户概覽
component_type: Metric Cards
priority: high
- name: 風險預警
component_type: Alert Card
priority: high
- name: 持倉表格
component_type: Data Table
priority: medium
- name: 信號面板
component_type: Signal Cards
priority: medium
states:
- loading
- empty
- error
- normalAI 睇到呢份 Spec 就知：呢個頁面唔係單純展示數據，而係要幫用戶快速判斷賬户風險；風險預警同賬户概覽係高優先級，持倉表格同信號面板係中等優先級；仲要考慮四種狀態。用呢份 Spec 去生成視覺圖，結果會穩定好多。
- 1 自己填一版：唔使完美，先寫頁面目標、核心用戶、主要模塊。
- 2 叫 AI 檢查：問佢有冇缺模塊、缺狀態、缺響應式規則，有冇唔適合工程落地嘅位。
- 3 用 UI Spec 生成視覺圖：呢個階段先叫 AI 做視覺探索，唔好等佢憑空決定結構。
- 4 收口時用 UI Spec + 參考圖生成代碼：代碼階段唔好只追求還原圖片，要根據 Spec 做組件化實現。
如果你都踩過「圖好靚，頁面一落地就跑偏」嘅坑，歡迎喺留言區分享最卡嘅一步。完整 UI Spec 模板已經放咗入資料包，關注公眾號，回覆 UI工作流 領取。
MaxKing寶藏
全棧開發者 × 量化交易 × AI 重度用戶。呢度記錄我用 AI 提升效率、解決問題、優化流程 嘅真實實踐，仲分享工具背後嘅判斷、踩坑同可複用方法。
有人將一張啱啱生成嘅後台圖貼咗落羣組，順口問咗句：呢張圖都幾似樣，可唔可以就咁掟俾圖片轉代碼工具？我望住嗰張圖睇咗兩秒，第一個反應唔係「好唔好睇」，而係佢到底有冇話俾個工具知，呢個頁面係俾邊個用、優先睇咩、狀態點樣補、手機版點樣摺。
張圖的確順眼，陰影、留白、層次都有，第一眼好容易令人放低戒心。但真係將佢放落瀏覽器，數據一長，卡片就開始逼；屏幕一縮，按鈕同列表就互相頂；幾個狀態頁未補齊，個頁面睇起嚟就好似冇咗骨架。嗰一刻會特別直觀：圖可以俾 AI 視覺效果，但俾唔到工程判斷。
嗰條留言其實講得好準：UI Spec 唔係多寫一步，而係先將結構講清楚，再俾個工具去畫、去寫、去落地。
01
-MaxKing.cc-
點解唔好直接將圖轉成代碼？
呢條留言最有價值嘅地方，唔係評價緊 image2，而係點出咗真正嘅問題：你要交付嘅唔係圖，係頁面。
好多人第一次見到 AI 生成嘅 UI 圖，都會先俾外觀呃到。深色背景、柔和陰影、整整齊齊嘅卡片、似樣嘅圖標，放喺一張圖入面睇，的確好有完成度。
但只要將佢放落真實業務入面，問題好快就會彈出嚟：數據一長，卡片就撐爆；屏幕一窄，佈局就塌；按鈕一多，主次就亂。
呢個唔係「AI 唔得」咁簡單。
更準確啲講，係你俾佢嘅輸入，根本唔夠佢做工程判斷。
02
-MaxKing.cc-
UI Spec 到底係乜嘢？
好多人會將「睇起嚟似介面嘅圖片」直接當成 UI 設計稿。呢個誤會好常見，因為佢哋第一眼真係好似。
但兩者要解決嘅嘢唔一樣。圖片主要回答「生咩樣」，設計稿仲要回答「點樣組織、點樣響應、點樣切換、點樣重用」。前者偏外觀，後者更接近頁面骨架。
一張圖可以話你知顏色同氛圍，但好難話你知層級、約束同狀態。
同一張圖，放喺大屏幕睇可能好完整，切到手機預覽就開始逼；預設文字睇落舒服，換成真實數據之後，留白同卡片邊界即刻緊咗。嗰種「圖好實、頁面好浮」嘅感覺，通常就係喺呢度暴露出嚟。
而前端真正要落地嘅，正正就係呢啲工程資訊。
可以將佢理解成睇效果圖起樓。效果圖睇到大約風格，但唔會話你知承重牆、管線、樓板同動線點樣排。頁面都一樣，得張圖，代碼工具只能靠估。
圖片唔係源頭，佢只係視覺表達。
頁面行唔行得掂，決定權喺結構，唔係像素。
03
-MaxKing.cc-
最細可用 UI Spec 模板
| 組件層次嵌套 | div，睇落似，結構卻散。 | |
| 互動同頁面狀態 | ||
| 響應式規則 | ||
| 設計 Token | ||
| 真實數據邊界 |
呢張表嘅意思好簡單：單張圖唔係用唔到，而係唔可以單獨做源頭。
佢可以幫你定風格、定氣氛、定視覺密度，但頁面落地最麻煩嘅部分，唔係「睇落好唔好睇」，而係「做唔做到、維唔維護到、繼唔繼續擴展到」。
04
-MaxKing.cc-
點解 image-to-code 成日都會走樣
image-to-code 真正嘅難點，唔係「將圖翻譯成代碼」，而係「根據視覺表象去估結構」。
佢睇到三個好似嘅卡片，但未必知道呢三個卡片其實應該抽成同一個組件。佢睇到一個好光嘅按鈕，但未必知道佢係業務主要操作定次要操作。佢睇到一塊閃光效果，但未必知道嗰啲只係裝飾，唔應該變成複雜嘅絕對定位。
所以你會見到一種好典型嘅結果：生成速度好快，返工都好快。第一眼覺得用得，第二眼就開始改，第三眼已經喺手動重構。
問題唔係在於個工具唔識畫，而係佢唔知應該先理解啲乜。
佢係喺度估結構，唔係翻譯結構。
05
-MaxKing.cc-
破局嘅關鍵，係先補返 UI Spec
如果淨係喺「圖」同「代碼」之間來回跳，好大機會都會返去手改。更穩陣嘅做法，係喺中間補一層 UI Spec。
呢一步唔係乜嘢概念包裝。佢要解決嘅，就係 AI 生成嘅 UI 圖喺落地時最容易欠缺嗰層結構判斷。
呢層嘢都唔需要寫得太玄。佢本質上就係一份結構化介面規範，可以係 YAML，亦可以係 JSON。格式唔係重點，重點係先將工程判斷寫清楚：
1. 頁面要解決啲乜問題。 2. 主路徑同次路徑分別係乜。 3. 邊啲模組可以重用。 4. 邊啲狀態一定要補齊。 5. 響應式規則點樣變。
先寫結構，再講好睇。
下面呢份就係我而家會先寫出嚟嘅最細模板：
有咗呢層嘢，gpt-image-2 呢類模型再去出圖，就唔再係「憑感覺畫一張靚圖」，而係圍繞一套已經俾約束過嘅結構去做視覺探索。圖嘅角色都會變輕：佢更似情緒板，唔係唯一標準。
06
-MaxKing.cc-
用交易儀錶板舉個例子
例如我要做一個交易儀錶板，我唔會直接話：幫我生成一個高級嘅交易後台頁面。
呢種講法太模糊
AI 好容易生成一個好型但未必用得嘅頁面。
MaxKing.cc
咁樣 AI 至少知道：呢個頁面唔係單純展示數據，而係要幫助用戶快速判斷賬户風險。風險預警同賬户概覽係高優先級，持倉表格同信號面板係中等優先級，頁面仲一定要考慮 loading、empty、error、normal 四種狀態。
07
後面再用呢份 UI Spec 去生成視覺圖，結果會比「隨便生成一個交易後台」穩定好多。再攞呢份 UI Spec 加上參考圖去生成代碼，都比就咁掟一張圖俾圖片轉代碼工具更容易落地。
-MaxKing.cc-
呢份模板點樣用？
我嘅建議好簡單，跟四步做就夠。 先自己填一個版本。
唔使追求完美，先將頁面目標、核心用戶、主要模組寫出嚟。 再俾 AI 檢查。
你可以直接問佢：呢份 UI Spec 係唔係缺模組、缺狀態、缺響應式規則？有冇唔適合工程落地嘅地方？ 然後用 UI Spec 生成視覺圖。
呢個時候再俾 AI 做視覺探索，而唔係等佢憑空決定頁面結構。 收尾時用 UI Spec + 參考圖生成代碼。
代碼階段唔好淨係追求還原圖片，而係要根據 UI Spec 做組件化實現。
我嘅經驗係，只要前面呢一步寫清楚，後面 AI 生成頁面會穩定好多。佢唔一定一次完美，但至少唔會完全走樣。
頁面需求 → UI Spec → 視覺參考 → 代碼實現 → 截圖修正
下一步可以咁樣做
如果你都喺度做 AI UI，先將呢份 UI Spec 模板收藏起嚟，下一次唔好再從一張圖直接開工。
如果你已經踩過「圖好靚，頁面一落地就走樣」嘅坑，歡迎將你最卡嘅一步留喺留言區，講清楚問題就夠。
需要繼續睇後續拆解嘅話，可以轉俾正在做頁面嘅同事，下一篇會繼續講點樣將結構寫啱。 UI工作流 領取。
完整 UI Spec 模板我已經放咗落資料包，關注公眾號，回覆
- END -
關於 MaxKing寶藏
我係 MaxKing，全棧開發者、量化交易實踐者，亦係 AI 重度用戶。呢度分享嘅唔係遙遠概念，而係我喺真實使用、搭建同踩坑之後留低嘅判斷。如果呢篇文章對你有啓發，歡迎點讚、在看、轉發
MaxKing寶藏
全棧開發者 × 量化交易 × AI 重度用戶。這裏記錄我用 AI 提升效率、解決問題、優化流程 的真實實踐，也分享工具背後的判斷、踩坑和可複用方法。
有人把一張剛生成的後台圖貼到羣裏，順手問了一句：這圖已經挺像樣了，能不能直接丟給圖片轉代碼工具？我盯着那張圖看了兩秒，第一反應不是“好不好看”，而是它到底有沒有告訴工具，這個頁面給誰用、先看什麼、狀態怎麼補、手機端怎麼折。
圖確實順，陰影、留白、層級都在，第一眼很容易讓人放鬆警惕。可真把它放進瀏覽器，數據一長，卡片就開始擠；屏幕一縮，按鈕和列表就互相頂；幾個狀態頁沒補齊，頁面看起來就像少了骨架。那一刻會特別直觀：圖能給 AI 視覺結果，給不了工程判斷。
那條留言其實點得很準：UI Spec 不是多寫一步，而是先把結構說清楚，再讓工具去畫、去寫、去落地。
01
-MaxKing.cc-
為什麼不要直接把圖轉成代碼？
這條留言最有價值的地方，不是在評價 image2，而是把真正的問題挑明瞭：你要交付的不是圖，是頁面。
很多人第一次看到 AI 生成的 UI 圖，都會先被外觀騙到。深色背景、柔和陰影、整齊卡片、像樣的圖標，放在一張圖裏看，確實很有完成度。
但只要把它放進真實業務裏，問題很快就會冒出來：數據一長，卡片就撐；屏幕一窄，佈局就塌；按鈕一多，主次就亂。
這不是“AI 不行”這麼簡單。
更準確地說，是你給它的輸入，本來就不夠它做工程判斷。
02
-MaxKing.cc-
UI Spec 到底是什麼？
很多人會把“看起來像界面的圖片”直接當成 UI 設計稿。這個誤會很常見，因為它們第一眼確實很像。
但兩者要解決的事不一樣。圖片主要回答“長什麼樣”，設計稿還要回答“怎麼組織、怎麼響應、怎麼切換、怎麼複用”。前者偏外觀，後者更接近頁面骨架。
一張圖能告訴你顏色和氛圍，卻很難告訴你層級、約束和狀態。
同一張圖，放在大屏上看可能很完整，切到手機預覽裏就開始擠；佔位文案看着舒服，換成真實數據以後，留白和卡片邊界立刻緊起來。那種“圖很穩、頁面很飄”的感覺，通常就是在這裏暴露的。
而前端真正要落地的，恰恰就是這些工程信息。
可以把它理解成看效果圖蓋房子。效果圖能看出大概風格，卻不會告訴你承重牆、管線、樓板和動線怎麼排。頁面也是一樣，光有圖，代碼工具只能猜。
圖片不是源頭，它只是視覺表達。
頁面能不能跑，決定權在結構，不在像素。
03
-MaxKing.cc-
最小可用 UI Spec 模板
| 組件層級嵌套 | div，看着像，結構卻散。 | |
| 交互與頁面狀態 | ||
| 響應式規則 | ||
| 設計 Token | ||
| 真實數據邊界 |
這張表的意思很簡單：單張圖不是不能用，而是不能單獨當源頭。
它可以幫你定風格、定氛圍、定視覺密度，但頁面落地最麻煩的部分，不在“看起來好不好看”，而在“能不能實現、能不能維護、能不能繼續擴展”。
04
-MaxKing.cc-
為什麼 image-to-code 總會跑偏
image-to-code 真正的難點，不是“把圖翻譯成代碼”，而是“根據視覺表象猜結構”。
它看得到三個很像的卡片，卻未必知道這三個卡片其實應該抽成同一個組件。它看得到一個很亮的按鈕，卻未必知道它是業務主操作還是次要操作。它看得到一塊炫光效果，卻未必知道那只是裝飾，不該變成複雜的絕對定位。
所以你會看到一種很典型的結果：生成速度很快，返工也很快。第一眼覺得能用，第二眼就開始改，第三眼已經在手動重構。
問題不在於工具不會畫，而在於它不知道該先理解什麼。
它是在猜結構，不是在翻譯結構。
05
-MaxKing.cc-
破局的關鍵，是先補 UI Spec
如果只在“圖”和“代碼”之間來回跳，大概率還是會回到手改。更穩的做法，是在中間補一層 UI Spec。
這一步不是什麼概念包裝。它要解決的，就是 AI 生成的 UI 圖在落地時最容易缺掉的那層結構判斷。
這層東西也不需要寫得很玄。它本質上就是一份結構化界面規範，可以是 YAML，也可以是 JSON。格式不是重點，重點是先把工程判斷寫清楚：
1. 頁面要解決什麼問題。 2. 主路徑和次路徑分別是什麼。 3. 哪些模塊可以複用。 4. 哪些狀態必須補齊。 5. 響應式規則怎麼變。
先寫結構，再談好看。
下面這份就是我現在會先寫出來的最小模板：
有了這層東西，gpt-image-2 之類的模型再去出圖，就不再是“憑感覺畫一張漂亮圖”，而是圍繞一套已經被約束過的結構去做視覺探索。圖的角色也會變輕：它更像情緒板，不是唯一標準。
06
-MaxKing.cc-
用交易儀表盤舉個例子
比如我要做一個交易儀表盤，我不會直接說：幫我生成一個高級的交易後台頁面。
這種說法太空了，AI 很容易生成一個很酷但不一定能用的頁面。
我會先寫成這樣：
這樣 AI 至少知道：這個頁面不是單純展示數據，而是要幫助用戶快速判斷賬户風險。風險預警和賬户概覽是高優先級，持倉表格和信號面板是中等優先級，頁面還必須考慮 loading、empty、error、normal 四種狀態。
後面再用這份 UI Spec 去生成視覺圖，結果會比“隨便生成一個交易後台”穩定很多。再拿這份 UI Spec 加上參考圖去生成代碼，也比直接丟一張圖給圖片轉代碼工具更容易落地。
07
-MaxKing.cc-
這份模板怎麼用？
我的建議很簡單，按四步走就夠了。
先自己填一版。 不用追求完美，先把頁面目標、核心用戶、主要模塊寫出來。
再讓 AI 檢查。 你可以直接問它：這份 UI Spec 是否缺模塊、缺狀態、缺響應式規則？有沒有不適合工程落地的地方？
然後用 UI Spec 生成視覺圖。 這時候再讓 AI 做視覺探索，而不是讓它憑空決定頁面結構。
收口時用 UI Spec + 參考圖生成代碼。 代碼階段不要只追求還原圖片，而是要根據 UI Spec 做組件化實現。
我的經驗是，只要前面這一步寫清楚，後面 AI 生成頁面會穩定很多。它不一定一次完美，但至少不會完全跑偏。
頁面需求 → UI Spec → 視覺參考 → 代碼實現 → 截圖修正
下一步可以這樣做
如果你也在做 AI UI，先把這份 UI Spec 模板收藏起來，下一次別再從一張圖直接開工。
如果你已經踩過“圖很好看，頁面一落地就跑偏”的坑，歡迎把你最卡的一步留在評論區，說清楚問題就夠了。
需要繼續看後續拆解的話，可以轉給正在做頁面的同事，下一篇會接着講怎麼把結構寫對。
完整 UI Spec 模板我已經放進資料包了，關注公眾號，回覆 UI工作流 領取。
- END -
關於 MaxKing寶藏
我是 MaxKing，全棧開發者、量化交易實踐者，也是 AI 重度用戶。這裏分享的不是遙遠概念，而是我在真實使用、搭建和踩坑後留下的判斷。
如果這篇文章對你有啓發，歡迎點贊、在看、轉發，也歡迎加我好友交流 AI 工具和自動化實踐。