很多人問我的 AI UI 工作流，被我完整拆成一條完整鏈路：先講需求和目標，再落 UI Spec，再做視覺探索，再進入組件化實現，最後再修復
整理版優先睇
MaxKing寶藏全棧開發者 × 量化交易 × AI 重度用戶。這裏記錄我用 AI 提升效率、解決問題、優化流程 的真實實踐，也分享工具背後的判斷、踩坑和可複用方法。上次發了一個文章：別再只讓 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 UI 落地不是圖直接轉代碼。最容易踩坑的地方，是圖看起來沒問題，真到實現階段才發現結構和狀態都不對。01-MaxKing.cc-為什麼一定要有工作流？很多人做 AI 頁面，會直接跳到工具層。用哪個工具生成圖？ 用哪個工具把圖轉代碼？ 要不要進 Figma？ 要不要直接丟截圖？ Codex、Cursor、Claude Code 該怎麼搭？這些問題當然重要，但如果沒有工作流，工具越多，反而越亂。因為出圖、寫代碼、修頁面，本質上是三個不同問題。出圖解決的是視覺方向。它回答的是：這個頁面大概應該長什麼樣。寫代碼解決的是工程實現。它回答的是：這個頁面怎麼拆組件、怎麼接數據、怎麼維護。修頁面解決的是落地偏差。它回答的是：生成結果和預期之間差在哪裏，怎麼一步步收斂。一開始讓 AI 生成圖，圖很好看；然後拿圖去轉代碼，發現結構不對；再讓 AI 改代碼，它開始亂改；到頭來還是自己手動調。這類問題通常不是某個工具不行，而是前後步驟沒有對齊。所以我的判斷很直接：AI UI 落地不能只靠單點工具，必須靠一套輸入輸出明確的工作流。每一步都要知道：這一環輸入什麼？ 輸出什麼？ 由誰判斷？ 進入下一步的標準是什麼？只有這樣，AI 才不是“隨機幫你生成一下”，而是能真正進入開發流程。02-MaxKing.cc-第一步：先拆需求與目標我現在做 AI 頁面，第一步不是打開圖片生成工具，也不是打開代碼編輯器。第一步是先問清楚：這個頁面到底要解決什麼問題？比如一個交易儀表盤頁面，不能只說：我要一個高級一點的交易後台。這個需求太空了。更好的拆法，是先把人和目標說清楚：這個頁面給誰用？用戶打開頁面後最重要的事情是什麼？頁面最重要的信息是什麼？用戶有沒有關鍵操作？頁面做到哪一步，才算滿足需求？比如交易儀表盤，它不是單純“做一個好看的後台”。更準確的描述應該是：這是一個給個人交易者 / 專業交易員使用的賬户首頁，目標是讓用戶登錄後快速查看賬户風險、當前持倉、交易信號和最近活動。頁面優先級是：風險預警 > 賬户概覽 > 持倉表格 > 信號面板 > 最近活動。這段話看起來普通，但它會決定後面所有結果。如果這一步不清楚，AI 會自己補腦。它可能會把頁面做得很炫，但風險模塊不突出。 它可能會加很多圖表，但真正關鍵的持倉信息不清楚。 它可能會做得像展示頁，但不像一個真實可用的業務頁面。先把目標、用戶、主路徑和信息優先級講清楚，後面的工作才有座標系。03-MaxKing.cc-第二步：把需求變成 UI Spec需求說清楚以後，我不會馬上讓 AI 畫圖。我會先整理一份 UI Spec。UI Spec 就是寫給 AI 和工程實現看的結構化頁面說明書。它關心的不是“好不好看”，而是頁面目的、模塊、組件、狀態和佈局。也就是說，它要把一個還比較模糊的頁面想法，拆成後面可以直接執行的結構。比如一個頁面至少要講清楚：頁面目的是什麼？ 目標用戶是誰？ 核心動作是什麼？ 頁面有哪些模塊？ 每個模塊是什麼組件類型？ 有哪些狀態？ 桌面端和移動端怎麼適配？ 頁面怎麼驗收？還是以交易儀表盤舉例，可以先寫成這樣：YAMLMaxKing.ccpage: name: 交易儀表盤 purpose: 幫助用戶快速查看賬户風險、持倉和交易信號 target_user: 個人交易者 / 專業交易員 primary_action: 查看當前賬户風險 layout_type: dashboardsections: - 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: mediumstates: - loading - empty - error - normal這份東西的價值很大。因為後面的視覺生成、代碼實現、截圖修正，都可以圍繞它展開。沒有 UI Spec，AI 只能根據一句話或一張圖猜結構。有了 UI Spec，AI 至少知道這個頁面應該怎麼組織。UI Spec 是這套工作流裏最關鍵的中間層。它解決的是：從“模糊想法”到“可執行頁面結構”的問題。04-MaxKing.cc-第三步：再做視覺探索有了 UI Spec 以後，我才會進入視覺探索。這裏可以用 gpt-image-2 或其他圖片生成工具。但這一步的目標，不是讓 AI 隨便畫一個“高級頁面”。我會明確告訴它：這張圖只是視覺參考，不是最終設計稿。 優先保證頁面結構、信息層級和模塊關係清楚。 頁面要像真實 SaaS 產品界面，不要像概念海報。 不要過度科幻，不要複雜 3D，不要無意義裝飾。 後續要能落到 React + Tailwind + 組件庫裏。也就是說，視覺探索階段主要看四件事。第一，信息層級是否清楚。用戶第一眼能不能看到最重要的信息？第二，模塊關係是否合理。賬户概覽、風險預警、持倉表格、信號面板之間的關係是否清楚？第三，視覺密度是否合適。交易儀表盤不能太空，也不能亂成一團。第四，是否適合組件化實現。卡片、表格、按鈕、徽章、狀態提示能不能拆成真實組件？這裏有一個很重要的判斷：視覺圖不是源頭，UI Spec 才是源頭。圖片只是幫助我們確認視覺方向。 它不能決定產品結構，也不能替代工程約束。如果生成圖有些細節很好，可以吸收。 如果生成圖和 UI Spec 衝突，我會優先相信 UI Spec。05-MaxKing.cc-第四步：組件化實現視覺方向確認後，才進入代碼實現。這一步我通常會用 Codex / Cursor 這類 coding agent。但我不會只丟一張圖給它。我會同時給它：* UI Spec * 視覺參考圖 * 技術棧 * 組件庫約束 * 頁面狀態 * mock 數據要求 * 驗收標準比如技術棧可以先約束為：TEXTMaxKing.ccReact TypeScript Tailwind CSS shadcn/ui同時要求它：優先複用 Card、Table、Badge、Button、Tabs、Alert 這類基礎組件。 不要為了還原視覺效果寫一堆不可維護的代碼。 不要把所有東西寫在一個大組件裏。 mock 數據集中放在 mockData.ts。 頁面必須支持 loading、empty、error、normal 四種狀態。 響應式至少支持桌面端和移動端。代碼實現階段的目標，是根據 UI Spec 做組件化實現，並儘量貼近視覺參考。這裏要接受一個現實：第一版代碼通常不會完美。它可能佈局基本對了，但間距不夠好。 它可能組件結構對了，但視覺密度還要調。 它可能桌面端能看，移動端還要優化。沒關係。第一版最重要的是：能跑起來。 結構是對的。 組件邊界是清楚的。 狀態沒有漏掉。 後續可以截圖修正。06-MaxKing.cc-第五步：截圖對比與修正很多人對 AI 頁面失望，是因為他們期待一次生成完美結果。我現在不這麼期待。我更關注它能不能進入一個穩定的修正閉環。這個閉環是：TEXTMaxKing.cc參考圖 ↓ 代碼實現 ↓ 瀏覽器截圖 ↓ 對比差異 ↓ 局部修正 ↓ 再次截圖這一步非常重要。因為瀏覽器裏的真實頁面，和靜態視覺圖一定會有差異。真實頁面要處理寬度，要處理數據長度，要處理字體渲染，要處理不同屏幕，要處理 loading、empty、error 狀態。所以我會讓 AI 或自己對比：佈局結構是否一致？ 模塊順序是否正確？ 主次信息是否清楚？ 卡片間距是否過鬆或過緊？ 表格密度是否合適？ 風險預警是否突出？ 移動端是否跑版？然後一次只修 3 到 5 個問題。我不建議直接說：這個頁面不像，重新寫。這樣 AI 很容易把已經正確的部分也改壞。更好的方式是：請不要重寫整個頁面，只修正以下 3 個問題：風險預警權重不夠、持倉表格信息過擠、移動端卡片間距過大。修改後說明涉及哪些組件和樣式。AI 頁面不是一次生成出來的，而是一輪一輪收斂出來的。07-MaxKing.cc-第六步：交付與沉澱很多人做到頁面能用就結束了。但我現在更關注收尾一步：沉澱。因為真正有價值的不是這一次頁面生成成功，而是下一次能不能更快。一個頁面做完以後，我會盡量沉澱這些東西：頁面需求拆解。 UI Spec。 視覺生成 Prompt。 代碼實現 Prompt。 組件拆分方式。 mock 數據。 截圖修正清單。 驗收標準。比如交易儀表盤這次做完以後，後面它就可以複用到：賬户首頁。 數據看板。 風控頁面。 策略監控頁面。 後台管理首頁。只需要替換業務字段、模塊優先級和視覺風格，就可以快速生成下一版。不是每次從零開始問 AI，而是把每次成功經驗變成模板。這就是 AI 工作流真正的複利。我把這套流程整理成了一份《AI UI 落地工作流資料包》。下一步可以這樣做收藏這篇，後面你做 AI 頁面時，先對照工作流順序再開工具。如果你也在做頁面落地，評論區說出你最卡的一步：需求、UI Spec、視覺、代碼還是修正。想看下一篇就關注，我會繼續把 AI 頁面前置判斷拆開。- END -關於 MaxKing寶藏我是 MaxKing，全棧開發者、量化交易實踐者，也是 AI 重度用戶。這裏分享的不是遙遠概念，而是我在真實使用、搭建和踩坑後留下的判斷。如果這篇文章對你有啓發，歡迎點贊、在看、轉發，也歡迎加我好友交流 AI 工具和自動化實踐。
MaxKing寶藏全棧開發者 × 量化交易 × AI 重度用戶。這裏記錄我用 AI 提升效率、解決問題、優化流程 的真實實踐，也分享工具背後的判斷、踩坑和可複用方法。上次發了一個文章：別再只讓 Codex 寫代碼了，它更適合接管整條 UI 生產線 本意是想着能少用一個工具就少用一個，codex能一手包，何必多用一個呢？
但很多人發了留言關於 AI 生成圖片，再生成代碼的工作流。我從留言中，發現最常見的誤區其實不是工具選錯了，而是順序一開始就亂了。如果只是生成一張圖，很多工具都能做到。根據圖片生成一段代碼，而家也有不少工具可以試。但真實項目裏的頁面，不是一張靜態圖。它有業務目標，有模塊優先級，有數據狀態，有響應式適配，有組件複用，也有後續維護成本。
所以我更願意把 AI UI 落地工作流拆成一條完整鏈路：先講需求和目標，再落 UI Spec，再做視覺探索，再進入組件化實現，接着用截圖對比把偏差一輪一輪收回來。這篇就按呢個順序拆。我把這套鏈路叫做 AI UI 工作流。它不是“先出一張圖，再把圖轉成代碼”這麼簡單，而是把頁面從想法推進到可運行、可維護狀態的一組步驟。這條鏈路大致分成六步：1. 需求與目標：先講清楚頁面服務誰，解決什麼問題，用戶核心動作是什麼。2. UI Spec：把頁面拆成結構化說明，包括模塊、組件、狀態、響應式和驗收標準。3. 視覺探索：基於 UI Spec 生成視覺參考圖，看信息層級、模塊關係和視覺風格…
- 很多人問我的 AI UI 工作流，被我完整拆成一條完整鏈路：先講需求…
- 很多人問我的 AI UI 工作流，被我完整拆成一條完整鏈路：先講需求…
- 很多人問我的 AI UI 工作流，被我完整拆成一條完整鏈路：先講需求…
- 很多人問我的 AI UI 工作流，被我完整拆成一條完整鏈路：先講需求…
- 很多人問我的 AI UI 工作流，被我完整拆成一條完整鏈路：先講需求…
可記低 Prompt
MaxKing寶藏全棧開發者 × 量化交易 × AI 重度用戶。這裏記錄我用 AI 提升效率、解決問題、優化流程 的真實實踐，也分享工具背後的判斷、踩坑和可複用方法。上次發了一個文章：別再只讓 Codex 寫代碼了，它更適合接管整條 UI …
內容片段
page: name: 交易儀表盤 purpose: 幫助用戶快速查看賬户風險、持倉和交易信號 target_user: 個人交易者 / 專業交易員 primary_action: 查看當前賬户風險 layout_type: dashboardsections:
- 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: mediumstates:
- loading
- empty
- error
- normal整理版
MaxKing寶藏全棧開發者 × 量化交易 × AI 重度用戶。這裏記錄我用 AI 提升效率、解決問題、優化流程 的真實實踐，也分享工具背後的判斷、踩坑和可複用方法。上次發了一個文章：別再只讓 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 UI 落地不是圖直接轉代碼。最容易踩坑的地方，是圖看起來沒問題，真到實現階段才發現結構和狀態都不對。01-MaxKing.cc-為什麼一定要有工作流？很多人做 AI 頁面，會直接跳到工具層。用哪個工具生成圖？ 用哪個工具把圖轉代碼？ 要不要進 Figma？ 要不要直接丟截圖？ Codex、Cursor、Claude Code 該怎麼搭？呢啲問題當然重要，但如果沒有工作流，工具越多，反而越亂。因為出圖、寫代碼、修頁面，本質上是三個不同問題。出圖解決的是視覺方向。它回答的是：呢個頁面大概應該長什麼樣。寫代碼解決的是工程實現。它回答的是：呢個頁面怎麼拆組件、怎麼接數據、怎麼維護。修頁面解決的是落地偏差。它回答的是：生成結果和預期之間差在哪裏，怎麼一步步收斂。一開始讓 AI 生成圖，圖很好看；然後拿圖去轉代碼，發現結構不對；再讓 AI 改代碼，它開始亂改；到頭來還是自己手動調。這類問題通常不是某個工具不行，而是前後步驟沒有對齊。所以我的判斷很直接：AI UI 落地不能只靠單點工具，必須靠一套輸入輸出明確的工作流。每一步都要知道：這一環輸入什麼？ 輸出什麼？ 由誰判斷？ 進入下一步的標準是什麼？只有咁樣，AI 才不是“隨機幫你生成一下”，而是能真正進入開發流程。02-MaxKing.cc-第一步：先拆需求與目標我而家做 AI 頁面，第一步不是打開圖片生成工具，也不是打開代碼編輯器。第一步是先問清楚：呢個頁面到底要解決什麼問題？比如一個交易儀表盤頁面，不能只說：我要一個高級一點的交易後台。呢個需求太空了。更好的拆法，是先把人和目標說清楚：呢個頁面給誰用？用戶打開頁面後最重要的事情是什麼？頁面最重要的信息是什麼？用戶有沒有關鍵操作？頁面做到哪一步，才算滿足需求？比如交易儀表盤，它不是單純“做一個好看的後台”。更準確的描述應該是：這是一個給個人交易者 / 專業交易員使用的賬户首頁，目標是讓用戶登錄後快速查看賬户風險、當前持倉、交易信號和最近活動。頁面優先級是：風險預警 > 賬户概覽 > 持倉表格 > 信號面板 > 最近活動。這段話看起來普通，但它會決定後面所有結果。如果這一步不清楚，AI 會自己補腦。它可能會把頁面做得很炫，但風險模塊不突出。 它可能會加很多圖表，但真正關鍵的持倉信息不清楚。 它可能會做得像展示頁，但不像一個真實可用的業務頁面。先把目標、用戶、主路徑和信息優先級講清楚，後面的工作才有座標系。03-MaxKing.cc-第二步：把需求變成 UI Spec需求說清楚以後，我不會馬上讓 AI 畫圖。我會先整理一份 UI Spec。UI Spec 就是寫給 AI 和工程實現看的結構化頁面說明書。它關心的不是“好不好看”，而是頁面目的、模塊、組件、狀態和佈局。也就是說，它要把一個還比較模糊的頁面想法，拆成後面可以直接執行的結構。比如一個頁面至少要講清楚：頁面目的是什麼？ 目標用戶是誰？ 核心動作是什麼？ 頁面有哪些模塊？ 每個模塊是什麼組件類型？ 有哪些狀態？ 桌面端和移動端怎麼適配？ 頁面怎麼驗收？還是以交易儀表盤舉例，可以先寫成咁樣：YAMLMaxKing.ccpage: name: 交易儀表盤 purpose: 幫助用戶快速查看賬户風險、持倉和交易信號 target_user: 個人交易者 / 專業交易員 primary_action: 查看當前賬户風險 layout_type: dashboardsections: - 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: mediumstates: - loading - empty - error - normal這份東西的價值很大。因為後面的視覺生成、代碼實現、截圖修正，都可以圍繞它展開。沒有 UI Spec，AI 只能根據一句話或一張圖猜結構。有了 UI Spec，AI 至少知道呢個頁面應該怎麼組織。UI Spec 是這套工作流裏最關鍵的中間層。它解決的是：從“模糊想法”到“可執行頁面結構”的問題。04-MaxKing.cc-第三步：再做視覺探索有了 UI Spec 以後，我才會進入視覺探索。這裏可以用 gpt-image-2 或其他圖片生成工具。但這一步的目標，不是讓 AI 隨便畫一個“高級頁面”。我會明確告訴它：這張圖只是視覺參考，不是最終設計稿。 優先保證頁面結構、信息層級和模塊關係清楚。 頁面要像真實 SaaS 產品界面，不要像概念海報。 不要過度科幻，不要複雜 3D，不要無意義裝飾。 後續要能落到 React + Tailwind + 組件庫裏。也就是說，視覺探索階段主要看四件事。第一，信息層級是否清楚。用戶第一眼能不能看到最重要的信息？第二，模塊關係是否合理。賬户概覽、風險預警、持倉表格、信號面板之間的關係是否清楚？第三，視覺密度是否合適。交易儀表盤不能太空，也不能亂成一團。第四，是否適合組件化實現。卡片、表格、按鈕、徽章、狀態提示能不能拆成真實組件？這裏有一個很重要的判斷：視覺圖不是源頭，UI Spec 才是源頭。圖片只是幫助我們確認視覺方向。 它不能決定產品結構，也不能替代工程約束。如果生成圖有些細節很好，可以吸收。 如果生成圖和 UI Spec 衝突，我會優先相信 UI Spec。05-MaxKing.cc-第四步：組件化實現視覺方向確認後，才進入代碼實現。這一步我通常會用 Codex / Cursor 這類 coding agent。但我不會只丟一張圖給它。我會同時給它：* UI Spec * 視覺參考圖 * 技術棧 * 組件庫約束 * 頁面狀態 * mock 數據要求 * 驗收標準比如技術棧可以先約束為：TEXTMaxKing.ccReact TypeScript Tailwind CSS shadcn/ui同時要求它：優先複用 Card、Table、Badge、Button、Tabs、Alert 這類基礎組件。 不要為了還原視覺效果寫一堆不可維護的代碼。 不要把所有東西寫在一個大組件裏。 mock 數據集中放在 mockData.ts。 頁面必須支持 loading、empty、error、normal 四種狀態。 響應式至少支持桌面端和移動端。代碼實現階段的目標，是根據 UI Spec 做組件化實現，並儘量貼近視覺參考。這裏要接受一個現實：第一版代碼通常不會完美。它可能佈局基本對了，但間距不夠好。 它可能組件結構對了，但視覺密度還要調。 它可能桌面端能看，移動端還要優化。沒關係。第一版最重要的是：能跑起來。 結構是對的。 組件邊界是清楚的。 狀態沒有漏掉。 後續可以截圖修正。06-MaxKing.cc-第五步：截圖對比與修正很多人對 AI 頁面失望，是因為他們期待一次生成完美結果。我而家不這麼期待。我更關注它能不能進入一個穩定的修正閉環。呢個閉環是：TEXTMaxKing.cc參考圖 ↓ 代碼實現 ↓ 瀏覽器截圖 ↓ 對比差異 ↓ 局部修正 ↓ 再次截圖這一步非常重要。因為瀏覽器裏的真實頁面，和靜態視覺圖一定會有差異。真實頁面要處理寬度，要處理數據長度，要處理字體渲染，要處理不同屏幕，要處理 loading、empty、error 狀態。所以我會讓 AI 或自己對比：佈局結構是否一致？ 模塊順序是否正確？ 主次信息是否清楚？ 卡片間距是否過鬆或過緊？ 表格密度是否合適？ 風險預警是否突出？ 移動端是否跑版？然後一次只修 3 到 5 個問題。我不建議直接說：呢個頁面不像，重新寫。咁樣 AI 很容易把已經正確的部分也改壞。更好的方式是：請不要重寫整個頁面，只修正以下 3 個問題：風險預警權重不夠、持倉表格信息過擠、移動端卡片間距過大。修改後說明涉及哪些組件和樣式。AI 頁面不是一次生成出來的，而是一輪一輪收斂出來的。07-MaxKing.cc-第六步：交付與沉澱很多人做到頁面能用就結束了。但我而家更關注收尾一步：沉澱。因為真正有價值的不是這一次頁面生成成功，而是下一次能不能更快。一個頁面做完以後，我會盡量沉澱呢啲東西：頁面需求拆解。 UI Spec。 視覺生成 Prompt。 代碼實現 Prompt。 組件拆分方式。 mock 數據。 截圖修正清單。 驗收標準。比如交易儀表盤這次做完以後，後面它就可以複用到：賬户首頁。 數據看板。 風控頁面。 策略監控頁面。 後台管理首頁。只需要替換業務字段、模塊優先級和視覺風格，就可以快速生成下一版。不是每次從零開始問 AI，而是把每次成功經驗變成模板。這就是 AI 工作流真正的複利。我把這套流程整理成了一份《AI UI 落地工作流資料包》。下一步可以咁樣做收藏這篇，後面你做 AI 頁面時，先對照工作流順序再開工具。如果你也在做頁面落地，評論區說出你最卡的一步：需求、UI Spec、視覺、代碼還是修正。想看下一篇就關注，我會繼續把 AI 頁面前置判斷拆開。- END -關於 MaxKing寶藏我是 MaxKing，全棧開發者、量化交易實踐者，也是 AI 重度用戶。這裏分享的不是遙遠概念，而是我在真實使用、搭建和踩坑後留下的判斷。如果這篇文章對你有啓發，歡迎點贊、在看、轉發，也歡迎加我好友交流 AI 工具和自動化實踐。
MaxKing寶藏
全棧開發者 × 量化交易 × AI 重度用戶。這裏記錄我用 AI 提升效率、解決問題、優化流程 的真實實踐，也分享工具背後的判斷、踩坑和可複用方法。
上次發了一個文章：別再只讓 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 UI 落地不是圖直接轉代碼。
最容易踩坑的地方，是圖看起來沒問題，真到實現階段才發現結構和狀態都不對。
01
-MaxKing.cc-
為什麼一定要有工作流？
很多人做 AI 頁面，會直接跳到工具層。
用哪個工具生成圖？ 用哪個工具把圖轉代碼？ 要不要進 Figma？ 要不要直接丟截圖？ Codex、Cursor、Claude Code 該怎麼搭？
這些問題當然重要，但如果沒有工作流，工具越多，反而越亂。
因為出圖、寫代碼、修頁面，本質上是三個不同問題。
出圖解決的是視覺方向。它回答的是：這個頁面大概應該長什麼樣。
寫代碼解決的是工程實現。它回答的是：這個頁面怎麼拆組件、怎麼接數據、怎麼維護。
修頁面解決的是落地偏差。它回答的是：生成結果和預期之間差在哪裏，怎麼一步步收斂。
一開始讓 AI 生成圖，圖很好看；然後拿圖去轉代碼，發現結構不對；再讓 AI 改代碼，它開始亂改；到頭來還是自己手動調。
這類問題通常不是某個工具不行，而是前後步驟沒有對齊。
所以我的判斷很直接：AI UI 落地不能只靠單點工具，必須靠一套輸入輸出明確的工作流。
每一步都要知道：
這一環輸入什麼？ 輸出什麼？ 由誰判斷？ 進入下一步的標準是什麼？
只有這樣，AI 才不是“隨機幫你生成一下”，而是能真正進入開發流程。
02
-MaxKing.cc-
第一步：先拆需求與目標
我現在做 AI 頁面，第一步不是打開圖片生成工具，也不是打開代碼編輯器。
第一步是先問清楚：
這個頁面到底要解決什麼問題？
比如一個交易儀表盤頁面，不能只說：
我要一個高級一點的交易後台。
這個需求太空了。
更好的拆法，是先把人和目標說清楚：這個頁面給誰用？用戶打開頁面後最重要的事情是什麼？頁面最重要的信息是什麼？用戶有沒有關鍵操作？頁面做到哪一步，才算滿足需求？
比如交易儀表盤，它不是單純“做一個好看的後台”。
更準確的描述應該是：
這是一個給個人交易者 / 專業交易員使用的賬户首頁，目標是讓用戶登錄後快速查看賬户風險、當前持倉、交易信號和最近活動。頁面優先級是：風險預警 > 賬户概覽 > 持倉表格 > 信號面板 > 最近活動。
這段話看起來普通，但它會決定後面所有結果。
如果這一步不清楚，AI 會自己補腦。
它可能會把頁面做得很炫，但風險模塊不突出。 它可能會加很多圖表，但真正關鍵的持倉信息不清楚。 它可能會做得像展示頁，但不像一個真實可用的業務頁面。
先把目標、用戶、主路徑和信息優先級講清楚，後面的工作才有座標系。
03
-MaxKing.cc-
第二步：把需求變成 UI Spec
需求說清楚以後，我不會馬上讓 AI 畫圖。
我會先整理一份 UI Spec。
UI Spec 就是寫給 AI 和工程實現看的結構化頁面說明書。
它關心的不是“好不好看”，而是頁面目的、模塊、組件、狀態和佈局。也就是說，它要把一個還比較模糊的頁面想法，拆成後面可以直接執行的結構。
比如一個頁面至少要講清楚：
頁面目的是什麼？ 目標用戶是誰？ 核心動作是什麼？ 頁面有哪些模塊？ 每個模塊是什麼組件類型？ 有哪些狀態？ 桌面端和移動端怎麼適配？ 頁面怎麼驗收？
還是以交易儀表盤舉例，可以先寫成這樣：
這份東西的價值很大。
因為後面的視覺生成、代碼實現、截圖修正，都可以圍繞它展開。
沒有 UI Spec，AI 只能根據一句話或一張圖猜結構。
有了 UI Spec，AI 至少知道這個頁面應該怎麼組織。
UI Spec 是這套工作流裏最關鍵的中間層。
它解決的是：
從“模糊想法”到“可執行頁面結構”的問題。
04
-MaxKing.cc-
第三步：再做視覺探索
有了 UI Spec 以後，我才會進入視覺探索。
這裏可以用 gpt-image-2 或其他圖片生成工具。
但這一步的目標，不是讓 AI 隨便畫一個“高級頁面”。
我會明確告訴它：
這張圖只是視覺參考，不是最終設計稿。 優先保證頁面結構、信息層級和模塊關係清楚。 頁面要像真實 SaaS 產品界面，不要像概念海報。 不要過度科幻，不要複雜 3D，不要無意義裝飾。 後續要能落到 React + Tailwind + 組件庫裏。
也就是說，視覺探索階段主要看四件事。
第一，信息層級是否清楚。
用戶第一眼能不能看到最重要的信息？
第二，模塊關係是否合理。
賬户概覽、風險預警、持倉表格、信號面板之間的關係是否清楚？
第三，視覺密度是否合適。
交易儀表盤不能太空，也不能亂成一團。
第四，是否適合組件化實現。
卡片、表格、按鈕、徽章、狀態提示能不能拆成真實組件？
這裏有一個很重要的判斷：
視覺圖不是源頭，UI Spec 才是源頭。
圖片只是幫助我們確認視覺方向。 它不能決定產品結構，也不能替代工程約束。
如果生成圖有些細節很好，可以吸收。 如果生成圖和 UI Spec 衝突，我會優先相信 UI Spec。
05
-MaxKing.cc-
第四步：組件化實現
視覺方向確認後，才進入代碼實現。
這一步我通常會用 Codex / Cursor 這類 coding agent。
但我不會只丟一張圖給它。
我會同時給它：
* UI Spec * 視覺參考圖 * 技術棧 * 組件庫約束 * 頁面狀態 * mock 數據要求 * 驗收標準
比如技術棧可以先約束為：
同時要求它：
優先複用 Card、Table、Badge、Button、Tabs、Alert 這類基礎組件。 不要為了還原視覺效果寫一堆不可維護的代碼。 不要把所有東西寫在一個大組件裏。 mock 數據集中放在 mockData.ts。 頁面必須支持 loading、empty、error、normal 四種狀態。 響應式至少支持桌面端和移動端。
代碼實現階段的目標，是根據 UI Spec 做組件化實現，並儘量貼近視覺參考。
這裏要接受一個現實：第一版代碼通常不會完美。
它可能佈局基本對了，但間距不夠好。 它可能組件結構對了，但視覺密度還要調。 它可能桌面端能看，移動端還要優化。
沒關係。
第一版最重要的是：
能跑起來。 結構是對的。 組件邊界是清楚的。 狀態沒有漏掉。 後續可以截圖修正。
06
-MaxKing.cc-
第五步：截圖對比與修正
很多人對 AI 頁面失望，是因為他們期待一次生成完美結果。
我現在不這麼期待。
我更關注它能不能進入一個穩定的修正閉環。
這個閉環是：
這一步非常重要。
因為瀏覽器裏的真實頁面，和靜態視覺圖一定會有差異。
真實頁面要處理寬度，要處理數據長度，要處理字體渲染，要處理不同屏幕，要處理 loading、empty、error 狀態。
所以我會讓 AI 或自己對比：
佈局結構是否一致？ 模塊順序是否正確？ 主次信息是否清楚？ 卡片間距是否過鬆或過緊？ 表格密度是否合適？ 風險預警是否突出？ 移動端是否跑版？
然後一次只修 3 到 5 個問題。
我不建議直接說：
這個頁面不像，重新寫。
這樣 AI 很容易把已經正確的部分也改壞。
更好的方式是：
請不要重寫整個頁面，只修正以下 3 個問題：風險預警權重不夠、持倉表格信息過擠、移動端卡片間距過大。修改後說明涉及哪些組件和樣式。
AI 頁面不是一次生成出來的，而是一輪一輪收斂出來的。
07
-MaxKing.cc-
第六步：交付與沉澱
很多人做到頁面能用就結束了。
但我現在更關注收尾一步：沉澱。
因為真正有價值的不是這一次頁面生成成功，而是下一次能不能更快。
一個頁面做完以後，我會盡量沉澱這些東西：
頁面需求拆解。 UI Spec。 視覺生成 Prompt。 代碼實現 Prompt。 組件拆分方式。 mock 數據。 截圖修正清單。 驗收標準。
比如交易儀表盤這次做完以後，後面它就可以複用到：
賬户首頁。 數據看板。 風控頁面。 策略監控頁面。 後台管理首頁。
只需要替換業務字段、模塊優先級和視覺風格，就可以快速生成下一版。
不是每次從零開始問 AI，而是把每次成功經驗變成模板。
這就是 AI 工作流真正的複利。
我把這套流程整理成了一份《AI UI 落地工作流資料包》。
下一步可以這樣做
收藏這篇，後面你做 AI 頁面時，先對照工作流順序再開工具。
如果你也在做頁面落地，評論區說出你最卡的一步：需求、UI Spec、視覺、代碼還是修正。
想看下一篇就關注，我會繼續把 AI 頁面前置判斷拆開。
- END -
關於 MaxKing寶藏
我是 MaxKing，全棧開發者、量化交易實踐者，也是 AI 重度用戶。這裏分享的不是遙遠概念，而是我在真實使用、搭建和踩坑後留下的判斷。
如果這篇文章對你有啓發，歡迎點贊、在看、轉發，也歡迎加我好友交流 AI 工具和自動化實踐。