很多人問我的 Codex + gpt-image-2 工作流，我用一個真實頁面完整跑一遍

果日我喺度睇 Codex + gpt-image-2 呢套工作流，想將佢落到 iTrading 嘅信號監控頁上面。右邊日誌一行一行咁跳，左邊工作台仲掛住一條待處理信號。留言區又彈出一句話：理論幾好，但半點都睇唔到解決方案。屏幕上係個頁面，我個腦就諗緊一個更現實嘅問題：呢套工作流，到底係咪可以繼續行落去。

我冇先講模型，都冇先講原理，反而係將個頁面入面嘅四個嘢擺埋一齊睇：連接狀態、賬户、待處理、日誌。只要呢四個位置企唔穩，後面無論出圖幾快，都係會返轉頭返工。

所以呢篇唔講抽象口號。我就用呢個頁面，將 Codex 先拆頁、gpt-image-2 再出視覺稿，再返去組件同截圖修正呢條線完整拆開。

真正值得寫嘅，唔係「AI 可唔可以生成 UI」，而係頁面入面一旦有狀態、有抽屜、有日誌、有風控，邊個先睇、睇啲乜、邊度要停低判斷。

果日我冇由模型開始睇，而係先將個頁面攤開。信號監控頁頂部要同時交代幾件事：連接仲喺唔喺度，賬户啱唔啱，待處理信號有幾多，自動執行有冇開。左邊係導航，中間係工作台，右邊係日誌。用戶先睇邊忽、後睇邊忽，都會影響佢點樣理解呢個頁面。

我而家越來越唔信一句話就生成完整 UI。

所以睇下 Codex + gpt-image-2 呢條線可唔可以繼續行，第一眼睇嘅唔係幅圖好唔好睇，而係個頁面會唔會被誤讀。

我將個滑鼠指標停喺待處理信號嗰一欄，又㩒過去右邊日誌，反覆睇嘅係邊個先出現、邊個後收口。呢個時候個頁面先唔係一張圖，而係一串會影響下一步動作嘅選擇。

iTrading 呢組頁面啱啱好夠用：概覽頁、工作台頁、AI 分析頁、日誌頁、信號詳情抽屜，全部擺喺同一條鏈路入面。佢哋唔係孤立截圖，而係可以繼續推進嘅工作現場。留言區嘅回饋、真實後台頁面、截圖對比同組件回寫，呢四個證據定錨點，啱啱好撐起咗呢篇文章。

我俾 Codex 嘅第一件事，唔係直接寫頁面，而係先將頁面拆開：資訊優先級、區域結構、核心組件、狀態列表、互動路徑同風險點。拆到呢一步，頁面就唔再只係一個模糊嘅「後台界面」，而係一組可以繼續判斷、繼續修改嘅結構。

我會先俾 Codex 將頁面目標、資訊優先級同危險點寫成可以檢查嘅條目，再將呢啲內容轉成 prompt。咁樣交俾 gpt-image-2 嘅時候，收到嘅就唔係概念海報，而係可以討論嘅視覺方向。佢嘅價值唔係代我做曬設計，而係先將頁面嘅層級、主次同語義攤開，令後面嘅代碼落點更清晰。

我望住概覽頁、工作台頁同日誌頁來回切，其實係睇緊同一個問題：呢條鏈路入面，啲乜嘢一定要擺喺枱面，啲乜嘢可以收埋入抽屜，邊啲地方要留俾人做最終判斷。

真正令我警惕嘅，係睇到圖之後就即刻叫 Codex 跟住抄。圖像模型輸出嘅係畫面，唔係組件系統；如果唔先拆組件，頁面好容易變成寫死嘅結構、散曬嘅狀態同唔易駁數據嘅層級。

只要狀態、抽屜同日誌冇先拆清楚，跟住圖寫代碼就一定會返工。

所以我會先將頁面拆成 AppShell、Sidebar、TopStatusBar、SignalTable、ProjectSettings、ActivityLog、LogDetailDrawer 呢一類結構，再返去代碼。咁做嘅好處好現實：一旦數據駁入嚟，組件邊界清楚咗，後面改佈局、改狀態、改抽屜，唔會每次都牽連一大片。

呢個唔係理論上嘅潔癖。真實落地嘅時候，頁面一旦駁上數據，組件邊界清楚唔清楚，分別即刻就會出嚟。好多時候，頁面唔係俾人「整壞」嘅，而係開頭冇拆清楚而拖壞嘅。

我睇生成圖嘅時候，唔先問似唔似，而係先問仲可唔可以繼續改。資訊優先級啱唔啱，操作路徑順唔順，異常狀態有冇位放，組件可唔可以落地，視覺有冇過度設計。後台產品最怕嘅唔係唔夠靚，而係睇落順眼，但接唔住真實業務。

截圖對比最有用的地方都喺呢度：每一輪淨係改一類問題，先明確保留啲乜，再明確淨係改啲乜。佈局唔啱，就淨係調網格同間距；狀態色唔清，就淨係收緊狀態標籤；抽屜太平，就淨係改層級同底部操作區，唔好一口氣將成個頁面重寫。

下圖藍色序號係加咗標註功能嘅位置（codex自帶瀏覽器打開後右上角嘅標註功能）

先將頁面目標、主路徑同異常狀態寫清楚，唔好淨係話「做個頁面」。

再將結構翻譯成 gpt-image-2 理解到嘅視覺 prompt，畀邊界，唔畀空話。

生成視覺稿之後，先拆組件，再判斷保留項同修改項。

迭代時淨係改一類問題，例如佈局、狀態色、抽屜或日誌，唔好一口氣重寫。

呢套 AI UI 工作流唔係代你做判斷，而係將判斷放喺更早嘅位置。真正慳到嘅，唔係幾行 CSS，而係來回修改嘅時間。

那天我在看 Codex + gpt-image-2 這套工作流，想把它落到 iTrading 的信號監控頁上。右側日誌一行一行往下跳，左側工作台還掛着一條待處理信號。評論區又冒出一句話：理論挺好，半點看不到解決方案。屏幕上是頁面，腦子裏是一個更現實的問題：這套工作流，到底是不是能繼續往前走。

我沒有先講模型，也沒有先講原理，而是把頁面裏的四個東西擺到一起看：連接狀態、賬户、待處理、日誌。只要這四個位置沒站穩，後面不管出圖多快，都會回到返工。

所以這篇不講抽象口號。我就用這個頁面，把 Codex 先拆頁、gpt-image-2 再出視覺稿，再回到組件和截圖修正這條線完整拆開。

真正值得寫的，不是“AI 能不能生成 UI”，而是頁面裏一旦有狀態、有抽屜、有日誌、有風控，誰先看、看什麼、哪裏該停下來判斷。

那天我沒有從模型開始看，而是先把頁面攤開。信號監控頁頂部要同時交代幾件事：連接還在不在，賬户對不對，待處理信號有多少，自動執行有沒有打開。左邊是導航，中間是工作台，右邊是日誌。用戶先看哪一塊、後看哪一塊，都會影響他怎麼理解這個頁面。

我現在越來越不相信一句話生成完整 UI。

所以我看 Codex + gpt-image-2 這條線能不能繼續跑，第一眼看的不是圖好不好看，而是頁面會不會被誤讀。

我把光標停在待處理信號那一欄，又切去右側日誌，反覆看的是誰先出現、誰後收口。這個時候頁面才不是一張圖，而是一串會影響下一步動作的選擇。

iTrading 這組頁面正好夠用：概覽頁、工作台頁、AI 分析頁、日誌頁、信號詳情抽屜，全都擺在同一條鏈路裏。它們不是孤立截圖，而是能繼續推進的工作現場。評論區的反饋、真實後台頁面、截圖對比和組件回寫，這四個證據錨點，剛好把這篇文章撐住了。

我給 Codex 的第一件事，不是直接寫頁面，而是先把頁面拆開：信息優先級、區域結構、核心組件、狀態列表、交互路徑和風險點。拆到這一步，頁面就不再只是一個模糊的“後台界面”，而是一組可以繼續判斷、繼續修改的結構。

我會先讓 Codex 把頁面目標、信息優先級和危險點寫成可檢查的條目，再把這些內容翻成 prompt。這樣交給 gpt-image-2 時，拿到的就不是概念海報，而是能討論的視覺方向。它的價值不是替我做完設計，而是先把頁面的層級、主次和語義攤開，讓後面的代碼落點更清楚。

我盯着概覽頁、工作台頁和日誌頁來回切，其實是在看同一個問題：這條鏈路裏，哪些東西必須擺在枱面上，哪些可以收進抽屜，哪些地方要留給人做最終判斷。

真正讓我警惕的，是看到圖以後馬上讓 Codex 照着抄。圖像模型輸出的是畫面，不是組件系統；如果不先拆組件，頁面很容易變成寫死的結構、散掉的狀態和不好接數據的層級。

只要狀態、抽屜和日誌沒有先拆明白，照圖寫代碼就一定會返工。

所以我會先把頁面拆成 AppShell、Sidebar、TopStatusBar、SignalTable、ProjectSettings、ActivityLog、LogDetailDrawer 這一類結構，再回到代碼。這樣做的好處很現實：一旦數據接進來，組件邊界是清楚的，後面改佈局、改狀態、改抽屜，不會每次都牽一大片。

這不是理論上的潔癖。真實落地時，頁面一旦接上數據，組件邊界清楚不清楚，差別馬上就會冒出來。很多時候，頁面不是被“做壞”的，是被一開始沒拆清楚拖壞的。

我看生成圖時，不先問像不像，而先問還能不能往下修。信息優先級對不對，操作路徑順不順，異常狀態有沒有位置，組件能不能落地，視覺有沒有過度設計。後台產品最怕的不是不夠花，而是看着順眼，卻接不住真實業務。

截圖對比最有用的地方也在這裏：每一輪只改一類問題，先明確保留什麼，再明確只改什麼。佈局不對，就只調網格和間距；狀態色不清，就只收緊狀態標籤；抽屜太平，就只改層級和底部操作區，不要一口氣把頁面重寫。

下圖藍色序號是加了標註功能的位置（codex自帶瀏覽器打開後右上角的標註功能）

先把頁面目標、主路徑和異常狀態寫清，不要只說“做個頁面”。

再把結構翻譯成 gpt-image-2 能理解的視覺 prompt，給邊界，不給空話。

生成視覺稿後，先拆組件，再判斷保留項和修改項。

迭代時只改一類問題，比如佈局、狀態色、抽屜或日誌，不要一口氣重寫。

這套 AI UI 工作流不是在替你做判斷，而是在把判斷放到更早的位置。真正省下來的，不是幾行 CSS，而是來回改口的時間。