很多人問我的 AI UI 工作流，被我完整拆成一條完整鏈路：先講需求和目標，再落 UI Spec，再做視覺探索，再進入組件化實現，最後再修復

上次出咗個文章：唔好再淨係俾 Codex 寫code啦，佢更適合接管成條 UI 生產線 本來諗住可以少用一個工具就少用一個，codex一手包辦，何必多用一個呢？

但係好多人留言講緊 AI 生成圖片，再生成代碼嘅工作流程。我喺留言入面發現最常見嘅誤區其實唔係揀錯工具，而係一開始個次序已經亂咗。

如果淨係生成一張圖，好多工具都做到。根據圖片生成一段code，而家都有唔少工具可以試。

但係真實項目入面嘅頁面，唔係一張靜態圖。

佢有業務目標，有模塊優先級，有數據狀態，有響應式適配，有組件重用，仲有後續維護成本。

所以我更鍾意將 AI UI 落地工作流程拆成完整鏈路：先講需求同目標，再落 UI Spec，再做視覺探索，再進入組件化實現，然後用截圖對比將偏差一輪一輪收返嚟。

呢篇就照呢個次序拆。

我將呢套鏈路叫做 AI UI 工作流。

佢唔係“先出一張圖，再將圖轉成code”咁簡單，而係將頁面由想法推進到可運行、可維護狀態嘅一組步驟。

呢條鏈路大致分成六步：

1. 需求與目標：先講清楚頁面服務邊個，解決咩問題，用戶核心動作係咩。 

2. UI Spec：將頁面拆成結構化說明，包括模塊、組件、狀態、響應式同驗收標準。 

3. 視覺探索：基於 UI Spec 生成視覺參考圖，睇信息層級、模塊關係同視覺風格。 

4. 組件化實現：用 Codex / Cursor 根據 UI Spec + 參考圖落 React 頁面，優先重用組件庫。 

5. 截圖對比同修正：用瀏覽器截圖同參考圖對比（script可以自動生成截圖），逐項修正佈局、間距、密度同狀態。 

6. 交付同沉澱：將 Prompt、UI Spec、組件結構、mock 數據同修正清單沉澱成模板。

最容易踩坑嘅地方，係圖睇落冇問題，真係去到實現階段先發現結構同狀態都唔啱。

好多人做 AI 頁面，會直接跳到工具層。

用邊個工具生成圖？用邊個工具將圖轉code？要唔要入 Figma？要唔要直接丟截圖？Codex、Cursor、Claude Code 應該點樣搭？

呢啲問題當然重要，但如果冇工作流程，工具越多，反而越亂。

因為出圖、寫code、修頁面，本質上係三個唔同問題。

出圖解決嘅係視覺方向。佢回答嘅係：呢個頁面大概應該係點樣。

寫code解決嘅係工程實現。佢回答嘅係：呢個頁面點樣拆組件、點樣接數據、點樣維護。

修頁面解決嘅係落地偏差。佢回答嘅係：生成結果同預期之間差喺邊度，點樣一步步收斂。

一開始俾 AI 生成圖，圖好靚；然後拎圖去轉code，發現結構唔啱；再俾 AI 改code，佢開始亂改；到頭來都係自己手動調。

呢類問題通常唔係某個工具唔得，而係前後步驟冇對齊。

每一步都要知道：

呢一環輸入咩？輸出咩？由邊個判斷？進入下一步嘅標準係咩？

只有咁樣，AI 先唔係“隨機幫你生成一下”，而係可以真正進入開發流程。

我而家做 AI 頁面，第一步唔係打開圖片生成工具，亦唔係打開code編輯器。

第一步係先問清楚：

譬如一個交易儀表盤頁面，唔可以淨係話：

呢個需求太虛喇。

更好嘅拆法，係先將人同目標講清楚：呢個頁面俾邊個用？用戶打開頁面之後最重要嘅事情係咩？頁面最重要嘅信息係咩？用戶有冇關鍵操作？頁面做到邊一步，先算滿足需求？

譬如交易儀表盤，佢唔係單純“做一個好睇嘅後台”。

更準確嘅描述應該係：

呢段話睇落普通，但佢會決定後面所有結果。

如果呢一步唔清楚，AI 會自己補腦。

佢可能會將頁面做到好靚，但風險模塊唔突出。佢可能會加好多圖表，但真正關鍵嘅持倉信息唔清楚。佢可能會做到似展示頁，但唔似一個真實可用嘅業務頁面。

需求講清楚之後，我唔會即刻俾 AI 畫圖。

我會先整理一份 UI Spec。

UI Spec 就係寫俾 AI 同工程實現睇嘅結構化頁面說明書。

佢關心嘅唔係“好唔好睇”，而係頁面目的、模塊、組件、狀態同佈局。亦即係話，佢要將一個仲比較模糊嘅頁面想法，拆成後面可以直接執行嘅結構。

譬如一個頁面至少要講清楚：

頁面目的係咩？目標用戶係邊個？核心動作係咩？頁面有邊啲模塊？每個模塊係咩組件類型？有邊啲狀態？桌面端同移動端點樣適配？頁面點樣驗收？

都係以交易儀表盤舉例，可以先寫成咁樣：

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
  - normal

呢份嘢嘅價值好大。

因為後面嘅視覺生成、code實現、截圖修正，都可以圍繞佢展開。

冇 UI Spec，AI 只能根據一句話或者一張圖估結構。

有咗 UI Spec，AI 至少知道呢個頁面應該點樣組織。

佢解決嘅係：

有咗 UI Spec 之後，我先會進入視覺探索。

呢度可以用 gpt-image-2 或者其他圖片生成工具。

但呢一步嘅目標，唔係俾 AI 隨便畫一個“高級頁面”。

我會明確同佢講：

呢張圖只係視覺參考，唔係最終設計稿。優先保證頁面結構、信息層級同模塊關係清楚。頁面要似真實 SaaS 產品界面，唔好似概念海報。唔好過度科幻，唔好複雜 3D，唔好冇意義裝飾。後續要落到 React + Tailwind + 組件庫入面。

亦即係話，視覺探索階段主要睇四件事。

用戶第一眼睇唔睇到最重要嘅信息？

賬户概覽、風險預警、持倉表格、信號面板之間嘅關係係咪清楚？

交易儀表盤唔可以太虛，亦唔可以亂成一團。

卡片、表格、按鈕、徽章、狀態提示拆唔拆到真實組件？

呢度有一個好重要嘅判斷：

圖片只係幫我哋確認視覺方向。佢唔可以決定產品結構，亦唔可以替代工程約束。

如果生成圖有啲細節好好，可以吸收。如果生成圖同 UI Spec 衝突，我會優先信 UI Spec。

視覺方向確認之後，先進入code實現。

呢一步我通常會用 Codex / Cursor 呢類 coding agent。

但我唔會淨係掟一張圖俾佢。

我會同時俾佢：

* UI Spec * 視覺參考圖 * 技術棧 * 組件庫約束 * 頁面狀態 * mock 數據要求 * 驗收標準

譬如技術棧可以先約束為：

React TypeScript Tailwind CSS shadcn/ui

同時要求佢：

優先重用 Card、Table、Badge、Button、Tabs、Alert 呢類基礎組件。唔好為咗還原視覺效果寫一堆不可維護嘅code。唔好將所有嘢寫喺一個大組件入面。mock 數據集中放喺 mockData.ts。頁面必須支援 loading、empty、error、normal 四種狀態。響應式至少支援桌面端同移動端。

呢度要接受一個現實：第一版code通常唔會完美。

佢可能佈局基本啱咗，但間距唔夠好。佢可能組件結構啱咗，但視覺密度仲要調。佢可能桌面端睇得，移動端仲要優化。

冇關係。

第一版最重要嘅係：

行得到。結構係啱嘅。組件邊界係清楚嘅。狀態冇漏掉。後續可以用截圖修正。

好多人對 AI 頁面失望，係因為佢哋期待一次生成完美結果。

我而家唔係咁期待。

我更關注佢能唔能夠進入一個穩定嘅修正閉環。

呢個閉環係：

參考圖   ↓ 代碼實現   ↓ 瀏覽器截圖   ↓ 對比差異   ↓ 局部修正   ↓ 再次截圖

呢一步非常重要。

因為瀏覽器入面嘅真實頁面，同靜態視覺圖一定會有差異。

真實頁面要處理寬度，要處理數據長度，要處理字體渲染，要處理唔同屏幕，要處理 loading、empty、error 狀態。

所以我會俾 AI 或者自己對比：

佈局結構係咪一致？模塊次序係咪正確？主次信息係咪清楚？卡片間距係咪過鬆或過緊？表格密度係咪合適？風險預警係咪突出？移動端係咪跑版？

然後一次只係修 3 到 5 個問題。

我唔建議直接話：

咁樣 AI 好容易將已經正確嘅部分都改壞。

更好嘅方式係：

好多人做到頁面用得就完咗。

但我而家更關注收尾一步：沉澱。

因為真正有價值嘅唔係呢一次頁面生成成功，而係下一次能唔能夠更快。

一個頁面做完之後，我會盡量沉澱呢啲嘢：

頁面需求拆解。UI Spec。視覺生成 Prompt。code實現 Prompt。組件拆分方式。mock 數據。截圖修正清單。驗收標準。

譬如交易儀表盤今次做完之後，後面佢就可以重用係：

賬户首頁。數據看板。風控頁面。策略監控頁面。後台管理首頁。

只需要替換業務字段、模塊優先級同視覺風格，就可以快速生成下一版。

呢啲就係 AI 工作流程真正嘅複利。

我將呢套流程整理成咗一份《AI UI 落地工作流資料包》。

上次發了一個文章：別再只讓 Codex 寫代碼了，它更適合接管整條 UI 生產線 本意是想着能少用一個工具就少用一個，codex能一手包，何必多用一個呢？

但很多人發了留言關於 AI 生成圖片，再生成代碼的工作流。我從留言中，發現最常見的誤區其實不是工具選錯了，而是順序一開始就亂了。

如果只是生成一張圖，很多工具都能做到。根據圖片生成一段代碼，現在也有不少工具可以試。

但真實項目裏的頁面，不是一張靜態圖。

它有業務目標，有模塊優先級，有數據狀態，有響應式適配，有組件複用，也有後續維護成本。

所以我更願意把 AI UI 落地工作流拆成一條完整鏈路：先講需求和目標，再落 UI Spec，再做視覺探索，再進入組件化實現，接着用截圖對比把偏差一輪一輪收回來。

這篇就按這個順序拆。

我把這套鏈路叫做 AI UI 工作流。

它不是“先出一張圖，再把圖轉成代碼”這麼簡單，而是把頁面從想法推進到可運行、可維護狀態的一組步驟。

這條鏈路大致分成六步：

1. 需求與目標：先講清楚頁面服務誰，解決什麼問題，用戶核心動作是什麼。 

2. UI Spec：把頁面拆成結構化說明，包括模塊、組件、狀態、響應式和驗收標準。 

3. 視覺探索：基於 UI Spec 生成視覺參考圖，看信息層級、模塊關係和視覺風格。 

4. 組件化實現：用 Codex / Cursor 根據 UI Spec + 參考圖落 React 頁面，優先複用組件庫。 

5. 截圖對比與修正：用瀏覽器截圖和參考圖對比（script可以自動生成截圖），逐項修正佈局、間距、密度和狀態。 

6. 交付與沉澱：把 Prompt、UI Spec、組件結構、mock 數據和修正清單沉澱成模板。

最容易踩坑的地方，是圖看起來沒問題，真到實現階段才發現結構和狀態都不對。

很多人做 AI 頁面，會直接跳到工具層。

用哪個工具生成圖？ 用哪個工具把圖轉代碼？ 要不要進 Figma？ 要不要直接丟截圖？ Codex、Cursor、Claude Code 該怎麼搭？

這些問題當然重要，但如果沒有工作流，工具越多，反而越亂。

因為出圖、寫代碼、修頁面，本質上是三個不同問題。

出圖解決的是視覺方向。它回答的是：這個頁面大概應該長什麼樣。

寫代碼解決的是工程實現。它回答的是：這個頁面怎麼拆組件、怎麼接數據、怎麼維護。

修頁面解決的是落地偏差。它回答的是：生成結果和預期之間差在哪裏，怎麼一步步收斂。

一開始讓 AI 生成圖，圖很好看；然後拿圖去轉代碼，發現結構不對；再讓 AI 改代碼，它開始亂改；到頭來還是自己手動調。

這類問題通常不是某個工具不行，而是前後步驟沒有對齊。

每一步都要知道：

這一環輸入什麼？ 輸出什麼？ 由誰判斷？ 進入下一步的標準是什麼？

只有這樣，AI 才不是“隨機幫你生成一下”，而是能真正進入開發流程。

我現在做 AI 頁面，第一步不是打開圖片生成工具，也不是打開代碼編輯器。

第一步是先問清楚：

比如一個交易儀表盤頁面，不能只說：

這個需求太空了。

更好的拆法，是先把人和目標說清楚：這個頁面給誰用？用戶打開頁面後最重要的事情是什麼？頁面最重要的信息是什麼？用戶有沒有關鍵操作？頁面做到哪一步，才算滿足需求？

比如交易儀表盤，它不是單純“做一個好看的後台”。

更準確的描述應該是：

這段話看起來普通，但它會決定後面所有結果。

如果這一步不清楚，AI 會自己補腦。

它可能會把頁面做得很炫，但風險模塊不突出。 它可能會加很多圖表，但真正關鍵的持倉信息不清楚。 它可能會做得像展示頁，但不像一個真實可用的業務頁面。

需求說清楚以後，我不會馬上讓 AI 畫圖。

我會先整理一份 UI Spec。

UI Spec 就是寫給 AI 和工程實現看的結構化頁面說明書。

它關心的不是“好不好看”，而是頁面目的、模塊、組件、狀態和佈局。也就是說，它要把一個還比較模糊的頁面想法，拆成後面可以直接執行的結構。

比如一個頁面至少要講清楚：

頁面目的是什麼？ 目標用戶是誰？ 核心動作是什麼？ 頁面有哪些模塊？ 每個模塊是什麼組件類型？ 有哪些狀態？ 桌面端和移動端怎麼適配？ 頁面怎麼驗收？

還是以交易儀表盤舉例，可以先寫成這樣：

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
  - normal

這份東西的價值很大。

因為後面的視覺生成、代碼實現、截圖修正，都可以圍繞它展開。

沒有 UI Spec，AI 只能根據一句話或一張圖猜結構。

有了 UI Spec，AI 至少知道這個頁面應該怎麼組織。

它解決的是：

有了 UI Spec 以後，我才會進入視覺探索。

這裏可以用 gpt-image-2 或其他圖片生成工具。

但這一步的目標，不是讓 AI 隨便畫一個“高級頁面”。

我會明確告訴它：

這張圖只是視覺參考，不是最終設計稿。 優先保證頁面結構、信息層級和模塊關係清楚。 頁面要像真實 SaaS 產品界面，不要像概念海報。 不要過度科幻，不要複雜 3D，不要無意義裝飾。 後續要能落到 React + Tailwind + 組件庫裏。

也就是說，視覺探索階段主要看四件事。

用戶第一眼能不能看到最重要的信息？

賬户概覽、風險預警、持倉表格、信號面板之間的關係是否清楚？

交易儀表盤不能太空，也不能亂成一團。

卡片、表格、按鈕、徽章、狀態提示能不能拆成真實組件？

這裏有一個很重要的判斷：

圖片只是幫助我們確認視覺方向。 它不能決定產品結構，也不能替代工程約束。

如果生成圖有些細節很好，可以吸收。 如果生成圖和 UI Spec 衝突，我會優先相信 UI Spec。

視覺方向確認後，才進入代碼實現。

這一步我通常會用 Codex / Cursor 這類 coding agent。

但我不會只丟一張圖給它。

我會同時給它：

* UI Spec * 視覺參考圖 * 技術棧 * 組件庫約束 * 頁面狀態 * mock 數據要求 * 驗收標準

比如技術棧可以先約束為：

React TypeScript Tailwind CSS shadcn/ui

同時要求它：

優先複用 Card、Table、Badge、Button、Tabs、Alert 這類基礎組件。 不要為了還原視覺效果寫一堆不可維護的代碼。 不要把所有東西寫在一個大組件裏。 mock 數據集中放在 mockData.ts。 頁面必須支持 loading、empty、error、normal 四種狀態。 響應式至少支持桌面端和移動端。

這裏要接受一個現實：第一版代碼通常不會完美。

它可能佈局基本對了，但間距不夠好。 它可能組件結構對了，但視覺密度還要調。 它可能桌面端能看，移動端還要優化。

沒關係。

第一版最重要的是：

能跑起來。 結構是對的。 組件邊界是清楚的。 狀態沒有漏掉。 後續可以截圖修正。

很多人對 AI 頁面失望，是因為他們期待一次生成完美結果。

我現在不這麼期待。

我更關注它能不能進入一個穩定的修正閉環。

這個閉環是：

參考圖   ↓ 代碼實現   ↓ 瀏覽器截圖   ↓ 對比差異   ↓ 局部修正   ↓ 再次截圖

這一步非常重要。

因為瀏覽器裏的真實頁面，和靜態視覺圖一定會有差異。

真實頁面要處理寬度，要處理數據長度，要處理字體渲染，要處理不同屏幕，要處理 loading、empty、error 狀態。

所以我會讓 AI 或自己對比：

佈局結構是否一致？ 模塊順序是否正確？ 主次信息是否清楚？ 卡片間距是否過鬆或過緊？ 表格密度是否合適？ 風險預警是否突出？ 移動端是否跑版？

然後一次只修 3 到 5 個問題。

我不建議直接說：

這樣 AI 很容易把已經正確的部分也改壞。

更好的方式是：

很多人做到頁面能用就結束了。

但我現在更關注收尾一步：沉澱。

因為真正有價值的不是這一次頁面生成成功，而是下一次能不能更快。

一個頁面做完以後，我會盡量沉澱這些東西：

頁面需求拆解。 UI Spec。 視覺生成 Prompt。 代碼實現 Prompt。 組件拆分方式。 mock 數據。 截圖修正清單。 驗收標準。

比如交易儀表盤這次做完以後，後面它就可以複用到：

賬户首頁。 數據看板。 風控頁面。 策略監控頁面。 後台管理首頁。

只需要替換業務字段、模塊優先級和視覺風格，就可以快速生成下一版。

這就是 AI 工作流真正的複利。

我把這套流程整理成了一份《AI UI 落地工作流資料包》。