用Codex構建響應式前端設計：丟張截圖它直接全自動搞定，還能自己開瀏覽器糾錯

前兩日寫文分享咗Codex入門最佳實踐，反應好好，一句講曬：學Codex最好嘅地方就係OpenAI嘅官方Codex文檔

https://developers.openai.com/codex

今日分享點樣用Codex構建響應式前端設計

截圖掉入去，程式碼自己出嚟

Codex入面專門用嚟解決前端開發最浪費時間嘅事：將設計圖變成可以執行嘅程式碼。

你只需要將截圖、設計稿或者任何可以說明UI係點樣嘅參考材料掉畀Codex，話俾佢知你想實現啲咩，佢就負責將呢啲視覺資訊轉成具體嘅程式碼實現。

官方畀咗一套完整嘅起始提示詞

在當前項目中，根據我提供的截圖和說明實現這套UI。

要求：

複用已有的設計系統組件和設計變量。把截圖轉化為項目裏實際使用的工具類、組件封裝、顏色系統、字體規範、間距變量、路由方式、狀態管理和數據請求模式，不要另起爐灶搭一套平行體系。間距、佈局、層級關係和響應式表現要儘量貼近截圖。遵循項目已有的路由、狀態和數據請求規範。頁面在桌面端和移動端都要響應式適配。如果截圖裏有模糊的細節，選最簡單的實現方式，同時簡短說明你的判斷依據。

驗收標準：

對照截圖檢查最終UI的外觀和交互是否一致。用Playwright互動技能打開真實瀏覽器，與參考截圖逐一比對，反覆迭代直到結果吻合。

呢段提示詞嘅設計思路：先定要求，再定驗收方式。驗收唔係靠人眼檢查，而係叫Codex自己用Playwright打開瀏覽器，同截圖比對，發現唔啱就繼續改。

同Playwright聯動，自動比對、自動修改

呢套流程入面有個關鍵配件：Playwright呢個skill工具。

先喺Codex安裝一下技能：

Codex用佢直接打開一個真實嘅瀏覽器，將生成嘅UI界面同你提供嘅參考截圖擺埋一齊比。唔同屏幕尺寸都檢查到，手機端定桌面端，改到邊度一目瞭然。發現唔啱嘅地方，繼續迭代。

咁樣一來，驗收標準就唔係「程式碼行到」，而係「睇起嚟同原稿一唔一樣」。

畀Codex嘅材料越豐富，結果越準

一張截圖可以起步，但係得一張截圖，Codex要估嘅地方就多咗。

最好嘅情況係將多種狀態都覆蓋到：桌面端嘅樣、移動端嘅樣、滑鼠懸停係乜效果、選中狀態係點樣、數據為空時點展示、加載中嘅狀態係點。

呢啲參考材料唔需要係專業設計軟件匯出嘅精確稿，粗略嘅草圖或者截圖都得，關鍵係令Codex對間距、層級關係、整體方向有清晰嘅認知，唔使靠估。

想要結果不一般，描述就要不一般

有一點要注意。

Codex預設傾向於生成高頻出現嘅通用樣式。如果你唔額外說明，出嚟嘅嘢好可能睇起嚟同其他AI生成嘅UI差唔多，比較平。

如果想要有設計感、有特色嘅結果，就需要喺交互方式同視覺風格上講多幾句，或者提供更多參考圖。輸入越具體，輸出越有辨識度。

已有項目同從零開始，有啲唔同

如果係向已有程式碼庫加新功能，Codex通常可以自己讀懂項目入面已經用緊嘅組件同設計規範，然後順住呢套體系嚟寫，唔會另起爐灶搞一套新嘅。

如果係從零開始建項目，呢個前提就唔存在。呢個時候建議主動話畀Codex：按鈕、輸入框、卡片、標題呢啲基礎元素用邊啲，顏色同間距嘅變數喺邊度定義，路由同數據請求按咩模式嚟寫。

無論邊種情況，有個原則係一致嘅：截圖裏面嘅視覺目標要實現，但實現方式要用項目本身已經有嘅嗰套工具，唔好喺外面再搭一層平行體系。

第一次唔係終點，來回跑幾輪先正常

對於佈局簡單嘅頁面，Codex一次就可以畀出方向基本正確嘅結果。

複雜嘅佈局、動效、多種交互狀態疊加嘅情況，就需要多輪調整。呢個時候可以追加截圖，或者用幾句話說明邊度仲唔啱，引導Codex繼續改。

遇到衝突時有個優先順序：優先保留項目設計系統裏面嘅規範，喺呢個基礎上做最小幅度嘅間距同尺寸調整，去還原目標設計嘅整體感覺。

前兩天寫文章分享了Codex 入門最佳實踐，反響很不錯，一句話：學習codex最好的地方就是OpenAI的官方codex文檔

https://developers.openai.com/codex

今天分享如何用codex 構建響應式前端設計

截圖扔進去，代碼自己出來

Codex中專門用來解決前端開發裏最耗時間的事：把設計圖變成可以跑起來的代碼。

你只需要把截圖、設計稿、或者任何能說明UI長什麼樣的參考材料丟給Codex，告訴它你想實現什麼，它來負責把這些視覺信息轉成具體的代碼實現。

官方給出了一套完整的起始提示詞

在當前項目中，根據我提供的截圖和說明實現這套UI。

要求：

複用已有的設計系統組件和設計變量。把截圖轉化為項目裏實際使用的工具類、組件封裝、顏色系統、字體規範、間距變量、路由方式、狀態管理和數據請求模式，不要另起爐灶搭一套平行體系。間距、佈局、層級關係和響應式表現要儘量貼近截圖。遵循項目已有的路由、狀態和數據請求規範。頁面在桌面端和移動端都要響應式適配。如果截圖裏有模糊的細節，選最簡單的實現方式，同時簡短說明你的判斷依據。

驗收標準：

對照截圖檢查最終UI的外觀和交互是否一致。用Playwright互動技能打開真實瀏覽器，與參考截圖逐一比對，反覆迭代直到結果吻合。

這段提示詞的設計思路：先定要求，再定驗收方式。驗收不是靠人眼檢查，而是讓Codex自己用Playwright打開瀏覽器，和截圖比對，發現不對繼續改。

和Playwright聯動，自動對比、自動修改

這套流程裏有個關鍵配件：Playwright這個skill工具。

先在codex安裝一下技能：

Codex用它直接打開一個真實的瀏覽器，把生成的UI界面和你提供的參考截圖擺在一起比。不同屏幕尺寸都能檢查，手機端還是桌面端，改到哪兒了一目瞭然。發現不對的地方，繼續迭代。

這樣一來，驗收標準就不是"代碼能跑"，而是"看起來和原稿一不一樣"。

給Codex的材料越豐富，結果越準

一張截圖可以起步，但只有一張截圖，Codex能猜的地方就多了。

最好的情況是把多種狀態都覆蓋到：桌面端的樣子、移動端的樣子、鼠標懸停是什麼效果、選中狀態長什麼樣、數據為空時怎麼展示、加載中的狀態是什麼。

這些參考材料不需要是專業設計軟件導出的精確稿，粗略的草圖或者截圖都行，關鍵是讓Codex對間距、層級關係、整體方向有清晰的認知，不用靠猜。

要想結果不一般，描述就得不一般

有一點需要注意。

Codex默認傾向於生成高頻出現的通用樣式。如果你不額外說明，出來的東西很可能看起來和其他AI生成的UI差不多，比較平。

如果想要有設計感、有特色的結果，就需要在交互方式和視覺風格上多說幾句，或者提供更多參考圖。輸入越具體，輸出越有辨識度。

已有項目和從零開始，有點不一樣

如果是往已有代碼庫里加新功能，Codex通常能自己讀懂項目裏已經在用的組件和設計規範，然後順着這套體系來寫，不會另起爐灶搞一套新的。

如果是從零開始建項目，這個前提就不存在了。這時候建議主動告訴Codex：按鈕、輸入框、卡片、標題這些基礎元素用哪些，顏色和間距的變量在哪裏定義，路由和數據請求按什麼模式來寫。

不管哪種情況，有個原則是一致的：截圖裏的視覺目標要實現，但實現方式要用項目本身已有的那套工具，不要在外面再搭一層平行體系。

第一次不是終點，來回跑幾輪才正常

對於佈局簡單的頁面，Codex一次就能給出方向基本正確的結果。

複雜的佈局、動效、多種交互狀態疊加的情況，就需要多輪調整。這時候可以追加截圖，或者用幾句話說明哪裏還不對，引導Codex繼續改。

遇到衝突時有個優先順序：優先保留項目設計系統裏的規範，在這個基礎上做最小幅度的間距和尺寸調整，去還原目標設計的整體感覺。