構建適配多端的前端介面
說明如何讓 Codex 根據 screenshots、design brief 或視覺參考生成 responsive UI，並在真實瀏覽器中迭代。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| 多端適配 | multi-platform | 一套介面適配多種裝置 / 平臺。 |
| 斷點 | breakpoint | 響應式佈局切換的尺寸點。 |
| 一致性 | consistency | 各端體驗保持一致。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你規劃構建適配多端的前端介面（斷點、一致性、各端驗證）。
你是 Codex 多端介面規劃顧問，幫我規劃構建一套適配多端、體驗一致的前端介面。
【角色】
你知道怎麼用 Codex 做多端適配、怎麼定斷點、怎麼保證各端一致、各端怎麼驗證。
【輸入】
- 要適配的端 / 裝置：___
- 前端技術堆疊：___
- 現有介面和差距：___
- 一致性 vs 各端最佳化的取捨：___
【工作流程】
1. 定各端的斷點和佈局策略
2. 拆出可交給 Codex 的適配任務
3. 處理一致性和各端差異的取捨
4. 給各端的驗證方式
【輸出規範】
▌一、斷點與佈局策略
▌二、適配任務拆解
▌三、一致性 vs 差異的處理
▌四、各端驗證方式
【硬約束】
- 各端在真實尺寸 / 裝置驗證，不只看程式碼
- 一致性優先，差異化要有理由
- 改動小步可回復
- 不臆測設計意圖，不清先確認
- 不確定的端特性標註需查文件
- 給的方案具體可執行
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述當你有 screenshots、短 design brief 或幾個視覺參考時，Codex 可以把它們變成 responsive UI，並儘量貼合目前 repo 已有的 design system。關鍵不是“照著圖寫一版”，而是讓 Codex 在真實 browser 中比較實現和參考圖，在不同螢幕尺寸下迭代。
Responsive UI 不能只在一個桌面寬度驗收。至少檢查 mobile、tablet/窄屏和 desktop，並確認文字不溢位、狀態不重疊、互動區域不漂移。
官方頁面：https://developers.openai.com/codex/use-cases/frontend-designs
官方封面圖路徑：https://developers.openai.com/codex/use-cases/frontend-designs-use-case.png
適合什麼任務
| 場景 | Codex 應該做什麼 |
|---|---|
| 從零建立新的 front-end project | 根據截圖和說明搭建第一版 UI，並做 responsive 檢查 |
| 在現有 codebase 中實現已設計的 screen 或 flow | 複用 repo 的 design system components、tokens 和 patterns |
| 需要視覺對齊 | 用 $playwright-interactive 開啟真實頁面，對比 references 並調整 layout 和 behavior |
使用的能力
| 能力 | 用法 | 連結 |
|---|---|---|
$playwright / $playwright-interactive | 在真實 browser 中驗證實現，調整 layout 和 behavior | https://github.com/openai/skills/tree/main/skills/.curated/playwright-interactive |
相關官方說明：
- Codex skills：https://developers.openai.com/codex/skills
起始提示詞
請在目前專案中實現這個 UI，以我提供的 screenshots 和 notes 作為 source of truth。
要求：
- 複用現有 design system components 和 tokens。
- 把 screenshots 翻譯成這個 repo 的 utilities 和 component patterns，不要另造一套平行系統。
- 儘量貼近 spacing、layout、hierarchy 和 responsive behavior。
- 尊重 repo 現有 routing、state 和 data-fetch patterns。
- 頁面要同時適配 desktop 和 mobile。
- 如果 screenshot 中某個細節不明確，選擇仍符合整體方向的最簡單實現，並簡短說明假設。
驗證：
- 對照提供的 screenshots 檢查最終 UI 的外觀和行為。
- 使用 $playwright-interactive 檢查 UI 是否匹配 references，並按需要迭代，直到匹配為止。這個 prompt 把 screenshots 和 notes 明確為 source of truth，同時要求 Codex 尊重目前 repo 的 design system，而不是另起一套 UI。
從 References 開始
給 Codex 最清楚的 UI 參考。一個窄任務只給一張 screenshot 也可以，但如果有多種狀態，最好一起提供：
- desktop layout。
- mobile layout。
- hover state。
- selected state。
- empty view。
- loading view。
參考圖不必是完整設計交付物，但必須讓 hierarchy、spacing 和 visual direction 足夠具體，減少 Codex 猜測。
說清楚你想要的風格
如果參考圖裡看不出你想要的 interaction pattern 或 style，Codex 可能會落到常見預設樣式。越複雜的 UI，越應該明確：
- 哪些元素必須嚴格對齊截圖。
- 哪些地方可以按 repo conventions 處理。
- 哪些 breakpoint 重要。
- 哪些 states 必須做。
- 哪些內容不要改。
準備 Design System
Codex 在目標 repo 已有 component layer 時表現最好。如果不是標準堆疊，直接告訴它：
- primitives 在哪裡。
- tokens 在哪裡。
- buttons、inputs、cards、typography、icons 的 canonical 用法是什麼。
如果是已有專案，Codex 通常能自己找到 components 和 tokens；但從零專案開始時，最好顯式寫清楚。
讓 Codex 把 screenshots 當作 visual target，並翻譯成專案真實的 utilities、component wrappers、color system、typography scale、spacing tokens、routing、state management 和 data-fetch patterns。
用 Playwright 驗證
Playwright interactive 可以讓 Codex：
- 開啟真實 app。
- 調整 browser window 到不同 screen sizes。
- 檢查 breakpoints。
- 對比實現和 screenshots。
- 根據視覺差異繼續迭代。
不要只問“頁面能 build 嗎”。要讓 Codex 回到截圖，對比 look 和 behavior。
迭代方式
第一版應該方向接近參考圖。複雜 layout、interaction 或 animation-heavy UI 往往需要幾輪調整。
當 screenshot 和 repo design system 衝突時，優先使用 repo tokens 和 components，只做保持整體視覺需要的最小 spacing 或 sizing 調整。
後續可以補充 screenshot 或短 notes，澄清單張圖裡看不出的 state。