# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：leon7hao (@leon7hao) · 平台：X (Twitter) · 日期：2026-05-27

> 原始來源：https://x.com/leon7hao/status/2059191435753410630

## 中文摘要

# 如何使用 Codex 和 Claude Code 重構前端 UI

> 聲明：我不是設計師，也不是專業的前端工程師，重構後的設計也存在各種 UI/UX 問題，一切都是基於我個人的評價能力來做的，不存在專業建議，只是想分享如何透過 vibe coding 的方式來進行較大規模的 UI 與架構重構。全文手打無 AI 輔助，歡迎大家在評論區討論，提供更多建議。原文連結

由於底層技術棧與人力因素，Lody 完全使用 Web 技術來統一構建網頁端、桌面端與行動裝置端。最開始只做了網頁端，後續慢慢添加了桌面端與行動裝置端，同時又幾乎是在 vibe coding 的狀態下開發，導致 Lody 程式碼中行動裝置端的 UI 到處都是 `isMobile()` 的判斷，整體佈局也只是單純將桌面端變窄並添加一個 sidebar。

只能說是「適配」了行動裝置端，但並沒有專門為其進行設計，不可避免地存在互動彆扭、字體過小和按鈕過小等問題。隨著目前遠端控制與多端同步的能力趨於穩定，行動裝置端的優化優先級就變高了。

因此，這次重構我希望同時完成兩個較大的任務：一是將多端通用部分組件化，重新構建新的入口供行動裝置端單獨佈局，與舊的佈局解耦；二是完全重新設計行動裝置端的 UI 與互動。

## 動工之前先了解模型的特點

每個模型在當前階段都有不同的擅長領域，我們是 Codex 和 Claude Code 雙持，就這兩者來說：

| | 擅長 | 不擅長 |
| --- | --- | --- |
| GPT | 架構梳理；生成圖像；找出 bug 的真實原因；複雜的後端或業務邏輯 | 撰寫前端；撰寫簡潔的文件 |
| Opus | 撰寫前端；理解互動；中小型任務；撰寫文件總結 | 複雜且需要不斷深入的任務；不能遺漏細節的任務 |

這些差異在使用幾次後就能明顯感受到，這不是 80 分與 90 分的差別，而是「能用」與「不能用」的差別。所以在執行大型任務之前，先了解這些模型，每一次模型更新都需要重新試探這種邊界，這能讓你事半功倍地完成任務。這也是為什麼我在之前的文章中提到，異構的 multi-agent 能夠提升生產力的原因。

## 把絕大部分的時間花在文件 (spec) 上

針對我的需求，我先讓 Codex 整理了當前程式庫中所有與行動裝置端存在耦合的地方，並將整理出來的內容放在一份文件中。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859230519-iaHJOo6RmasAAgsKGjpg.jpg)

找出了大約 40 個檔案的耦合。接著根據 Codex 撰寫的重構文件調整了一些細節，例如檔案的分隔、命名、行動裝置端的路由方式與行動裝置端組件等。最後與 Codex 進行一次對齊，確保它理解了我的真實需求。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859229877-iaHJOpKkBakAIP1JCjpg.jpg)

現在這是一篇近一千行的計畫文件，由於我們的任務需求較大，我讓 Codex 進一步拆分這個大任務。

> 「在理解一致的前提下，幫我將這個大需求進一步拆分成不同階段的需求與實現方案文件，放到 docs 下的統一資料夾裡。」

拆分成了以下幾個階段：
0. 再次搜尋確認耦合位置，固化共享/分端的維護邊界
1. 拆出純行動裝置端使用且沒有耦合的組件
2. 較大規模重構，拆出 chat/session/settings/archive 等核心 feature 的行動裝置端佈局
3. 評估新的行動裝置端組件、手勢，以及詢問新的 UI 設計方案
4. 測試可存取性、設備矩陣與漸進式發布

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859229885-iaHJOpdGqbkAAkhTQjpg.jpg)

再根據每一階段的具體需求與方案文件進行幾輪 comment 討論，前一個階段實現完後再討論下一輪。在 Lody 中可以直接點開 diff 進行評論，非常好用。當 Codex 在處理這些重構時，我們就可以去設計新版的 UI 了。

## 不是設計師該怎麼設計 UI？

如果不是設計師，就先不用考慮美不美觀的問題，為你的功能服務、讓人看得過去、整體規規矩矩才是第一要務。自己不會設計，但總歸是用過很多軟體，很多被專業設計師設計過的軟體。不懂設計語言與設計系統、不知道該怎麼互動時，就去看別的軟體。但不能光看，要主動分析為什麼會這樣設計。前提是你參考的是優秀的軟體。

對於 Lody 這次重新設計，難度還好，因為功能都是既有的，且自己就是自己軟體的使用者。在對這樣的有限集進行考量時，可以簡單地帶入使用者視角：一進來希望看到什麼？哪些是最熱門的路徑？哪些功能希望是最快被觸達的？哪些可以增加層級做更明確且符合直覺的區分？這一步是最需要花時間多加考慮的。

大概考慮好之後，腦子裡就有了幾個藍圖與大致的結構。我就拿 iPad 把所有主要的介面和組件畫了出來。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859230579-iaHJOps7YagAAB6cLjpg.jpg)

有了草稿之後，現在只能表達想要的內容和佈局，但沒有樣式和風格。這時候就可以將草稿發給 Codex，並告訴它你大概想要的風格，讓它模擬真機的渲染圖。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859230397-iaHJOqm8Xb0AAdvT5jpg.jpg)

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859230734-iaHJOqqHwaUAACOZgjpg.jpg)

這期間可以不斷調整 prompt，不斷「抽卡」，直到獲得你想要的視覺效果。
現在我們有了大致想要的真實效果，Codex 那邊也重構得差不多了，把 diff review 一下，我們就可以開一個新的對話或者在 Lody 中開啟新的 Tab，有請 Opus 老師出場。Opus 真的蠻會寫前端的。

## 怎麼向 AI 描述想要的互動？

接下來我們就開始真的讓 AI 編寫前端程式碼了。我們有了「真實」的渲染圖和一些互動的想法，但該如何有效地讓 AI 理解你的想法呢？

如果你沒有做過設計或者前端，那你就需要去 shadcn ui 或者其他的組件庫官網，把所有的組件都看一遍。拿著你的渲染圖，對照那些不知道怎麼描述的組件，去組件的網站上挨個點一點，看效果是不是你想要的，然後記住這個組件的名稱。

和 AI 描述的時候就不用說：

> 「我想要一個問題和答案的列表，預設只展示問題，點擊之後可以在下面顯示答案，點擊別的問題時已經展開的需要自動收起。不同的問題之間有個分割線分開。問題和答案分別是 Question A，Answer A；......」

而是說：

> 「使用 Accordion 組件，Trigger 和 Content 分別是 Question A，Answer A；......」

非專業的朋友學習 vibe coding，可以在日常工作瀏覽網站時，看到這種專業名詞就記下來，不但節省 token，而且 AI 理解得更加清楚。

讓 Opus 復原渲染圖時，可以從上到下描述一遍當前圖上的所有組件：它是什麼、它的功能是什麼、你希望的互動效果是什麼。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859230986-iaHJOtlWNaYAAOwDcjpg.jpg)

第一遍 AI 應該只能復現個大概，很多地方會有偏差。先看一下大概的架構和主題風格是不是你想要的，然後有出入的地方就需要一點一點繼續磨，這全看個人對細節的把控了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779859229814-iaHJOtxWJaAAAFT8ujpg.jpg)

在磨 UI/UX 的時候，當前階段使用 web 技術棧的好處就體現出來了，這時候可以使用 Codex 的預覽模式、Cursor 的 design 模式或者是 Lody 的預覽模式。在 Lody 上甚至可以直接在手機上給對應的組件直接評論並發送給 Agent。Web 可以 HMR 熱更新，改完就能看到效果，節省很多時間。

## 善用 Storybook 便於走查

組件編碼完成不代表生命週期的結束，AI 隨時可能把已經設計好的樣式或者互動給搞壞。最後推薦一下 Storybook，它是用於獨立展示和測試構建 UI 組件的，不依賴真實的介面，非常適合在同一個畫面展示組件的所有可能狀態，例如：正常態、空態、載入態、錯誤態、禁用態等等。我們在 AGENTS.md 中就添加了一條規則：新增的組件就要創建枚舉所有狀態的 Storybook。之後就不需要特別地每次都端到端地測試組件樣式，都在 Storybook 中看就行，而且很多不會注意到的空狀態、異常狀態也都不會被忽略。

最近我對設計非常感興趣，如果你是設計師，且正在使用 vibe coding 來構建自己的軟體，方便的話私訊一起聊聊呀。

## 標籤

Codex, Claude Code, 教學資源, Web, Codex, Anthropic, Claude