文章庫

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 工具和自動化實踐。

完成