--- schemaVersion: 1 slug: gp-130-20260327-emanueledpt-codex-ui-guide ticketId: GP-130 lang: zh-tw title: 用 Codex 做出驚豔 UI 的完整攻略 — 別再讓 AI 幫你寫出千篇一律的 SaaS 風格了 summary: GPT-5.4 確實能寫出漂亮的前端，但前提是你得知道怎麼問。Emanuele Di Pietro 整理了 OpenAI 官方的 frontend skill 精華：design system 先行、reasoning 調低、給 visual reference、用真實內容取代 placeholder。這不只是 GPT 技巧，是任何 AI coding agent 都適用的前端指導原則。 originalDate: 2026-03-21 translatedDate: 2026-03-27 source: "@emanueledpt on X" sourceUrl: https://x.com/emanueledpt/status/2035402224260550921 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-130-20260327-emanueledpt-codex-ui-guide status: published replacementTicketId: null replacementUrl: null --- # 用 Codex 做出驚豔 UI 的完整攻略 — 別再讓 AI 幫你寫出千篇一律的 SaaS 風格了 > **來源:** [@emanueledpt on X](https://x.com/emanueledpt/status/2035402224260550921) 讓 AI 幫忙做一個 landing page，結果出來長這樣：淡紫色背景、圓角卡片排排站、Inter 字體、中間一個大標題寫著「Welcome to \[Product Name\]」。 不是壞掉了。Responsive 有做、按鈕能點、所有功能都 work。但看著這個東西，腦子裡只會浮出一個念頭：「這不是想要的東西。」 更尷尬的是 — 連「到底想要什麼」都說不清楚。[Prompt](https://gu-log.vercel.app/glossary#prompt) 只寫了「幫忙做一個好看的網站」，剩下的全靠 model 猜。 Emanuele Di Pietro 最近在 X 上整理了一篇 GPT-5.4 前端開發的完整攻略，引用 OpenAI 官方剛發佈的 [frontend design guide](https://developers.openai.com/blog/designing-delightful-frontends-with-gpt-5-4)。讀完之後最大的收穫不是什麼技巧 — 是一記當頭棒喝：**這篇表面上在講 GPT，骨子裡在教人怎麼當一個好的設計 PM。** 而且這些原則不只適用於 [Codex](https://gu-log.vercel.app/glossary#codex) — 任何 [AI coding agent](https://gu-log.vercel.app/glossary#agent) 都適用。 --- ## AI 的番茄炒蛋困境 為什麼 AI 生成的網站看起來都像失散多年的兄弟？ 答案出奇地簡單。Prompt 不夠具體的時候，model 會做一件完全合理的事：回退到訓練資料裡出現頻率最高的 pattern。而那些 pattern 就是 GitHub 上幾百萬個 SaaS starter template — 圓角卡片、淡色系、system font、左右分欄 hero。 這就好比走進一家餐廳，跟廚師說「隨便做，好吃就好」。廚師不會端出分子料理。他會炒一盤番茄蛋 — 因為那是最安全、最不會出錯、最符合「好吃」這個模糊需求的選擇。 GPT-5.4 在前端能力上確實有大幅進步 — 原生理解圖片、用 Playwright 自己開瀏覽器檢查 render 結果、還能生成 mood board。但能力提升不代表品味會自己跑出來。**Brief 有多模糊，產出就有多 generic。** Model 不是沒有做好菜的能力，是沒人點菜。 > **Mogu murmur：** > > 這個「統計回退」現象解釋了一個很多人的困惑：AI 明明「懂」設計原則，做出來的東西卻毫無個性。問 GPT 什麼是好設計，它能寫一篇論文。但叫它「做一個網站」，它直接跳到最高頻的 pattern — 就像問一個米其林主廚「隨便煮點什麼」，搞不好他也會煮泡麵。懂跟做是兩碼事。(◍•ᴗ•◍) 但這裡有一個反直覺的轉折。問題不在 model 太笨，而在使用者太客氣 — 給了太多自由，反而逼 model 躲進安全區。解法？**不是寫更長的 prompt，是先把 code 以外的東西搞定。** --- ## 限制即自由：design system 的悖論 原文最核心的洞見是：**設計品質取決於 prompt 裡那些跟 code 完全無關的東西。** 多數人讓 AI 寫前端的時候，沒說要用什麼字體、什麼顏色、什麼佈局規則。然後對著產出搖頭說「AI 做的 UI 就是不好看」。真相是 — 不是 AI 沒品味，是沒人下單。 但這裡有一個違反直覺的建議：**把 reasoning 調低。** 「reasoning 不是越高越好嗎？」— 直覺上是這樣。但前端設計不是解微分方程，沒有唯一正解等著被推導。設計要的是直覺、果斷、帶態度的視覺決策。Reasoning 調高之後 model 會像第一天上班的 junior — 把十種佈局全做出來然後問「哪個好」。Low 或 medium reasoning 反而能逼出一個有主見的設計師角色，直接給一個有態度的答案。 > **Mogu 碎碎念：** > > 這個 reasoning 建議其實暗示了一個更深的道理：AI 的「思考越多」不等於「產出越好」。在需要 taste 而非 logic 的任務上，overthinking 反而是毒藥。Design 是 opinionated 的行為，不是 deductive reasoning。叫一個 model 花更多 token 想，只會讓它更保守、更 generic、更像那盤番茄蛋。(´・ω・\`) 然後是整篇文章裡最重要的一步 — 一步而已，但有沒有做天差地別：**先定義 design system。** Typography、color palette、layout constraints。在開口說「做一個 landing page」之前，先把這些規則寫死。俳句為什麼是 5-7-5 音節？十四行詩為什麼是 14 行？**所有偉大的創作都誕生在限制裡。** 沒有限制的自由不是自由，是茫然。告訴 model「只准用兩種字體、一個 accent color」，它反而會在這個小框框裡找到意想不到的驚喜。 接著是一個簡單但威力驚人的技巧：**給一張 visual reference。** 一張 screenshot 頂一千字描述。GPT-5.4 能從圖片裡讀出 rhythm、spacing、scale、色調、整體氛圍 — 文字要寫好幾段才講得清楚的東西，一張圖秒傳達。 最後是被嚴重低估的：**用真實內容取代 placeholder。** Lorem ipsum 出現的那一刻，等於在對 model 說：「內容不重要，隨便放。」然後它就真的隨便放了。標題是兩個字還是十個字，會影響 hero 的整個比例。CTA 是「立即購買」還是「免費試用 14 天」，會影響按鈕的設計。Placeholder 不只是假文字 — 它會傳染，讓整個設計都跟著變假。 --- ## 但是 — 有了工具還不夠 到這裡為止，都是「該準備什麼」。但即使做了以上四件事，model 還是有可能做出讓人翻白眼的選擇 — 在 hero 放六張卡片、用三種 accent color、首屏塞滿統計數字和活動時間表和一段沒人會讀的品牌故事。 為什麼？因為 model 有能力做好菜了，但還沒有被告知「哪些菜色根本不該出現在菜單上」。 這就是 OpenAI 指南裡最有態度的部分 — 不是「建議」，是一套 **hard rules**。設計界的十誡。 --- ## 首屏是海報，不是文件 想像站在三公尺外看一張海報。眼睛只會抓到一件事 — 品牌名和主訊息。如果三公尺外看不清楚，這張海報就失敗了。 首屏也是同一個道理。Viewport budget 很嚴格：品牌名、一個標題、一句支撐文案、一組 CTA、一張主視覺。就這些。統計數字、活動時間表、「本週精選」、老闆堅持要放的公司地址 — 通通往下丟。首屏的唯一任務是讓人想繼續看。 > **Mogu 補個刀：** > > 「首屏是海報」這個比喻精準，但我想補一個更現實的觀察：大部分首屏塞太多東西的原因不是不懂設計，是 stakeholder 太多。PM 想放 feature、marketing 想放促銷、老闆想放公司簡介、SEO 想放關鍵字。結果首屏變成委員會的會議記錄。AI 做的首屏也有同樣的問題 — 只不過那些 stakeholder 全部變成了 prompt 裡那些不分輕重的要求。(๑˃ᴗ˂)ﻭ 接受了「海報」觀念之後，下一個更痛的真相：**卡片，大部分是多餘的。** OpenAI 的 hard rule 寫得很絕：default 狀態是 no cards。Hero 區絕對不能有。其他地方也只有在「卡片本身就是互動容器」的時候才該出現。判斷方式？把 border、shadow、background、border-radius 全部拿掉。內容還是清楚的嗎？如果是 — 那張卡片只是在幫 layout 擦粉底。去看 Awwwards 得獎的網站，有幾個是卡片排排站的？再看 AI 隨便生的 — 幾乎每一個都是。Card grid 是 model 的番茄炒蛋：安全、萬用、絕對不會錯，但跟「讓人記住」差了十萬八千里。 品牌存在感也有硬標準。OpenAI 給了兩個 litmus test — 把 nav 遮住，品牌還看得到嗎？看不到代表品牌只活在 nav 裡，那不叫品牌，叫門牌。把 hero image 拿掉，頁面還能運作嗎？如果能 — 那張圖是牆上的裝飾畫，不是建築結構。 最後一條：**字體最多兩組，accent color 最多一個。** 聽起來嚴苛？想想書法 — 一支筆、一種墨，光靠粗細和速度就能寫出整幅層次。一個 accent color 讓讀者的眼睛自然知道焦點在哪。當所有東西都在強調，就等於什麼都沒強調。 --- ## 從文件到對話：三件在 code 之前就該寫好的東西 好，前面花了大量篇幅在講「不要做什麼」。但光有禁令不夠 — 知道不能塞六張卡片，不代表就知道該放什麼。 原文在這裡提出了一個轉折，也是整篇最精華的部分：**在動手寫 code 之前，先寫三樣跟 code 完全無關的東西。** 這三樣東西的作用不是限制 model，而是給它一個「角色」— 讓它從「隨便炒盤蛋的廚師」變成「理解今晚主題的主廚」。 第一樣叫 **visual thesis**。用一句話描述網站的「氣質」— 不是功能、不是技術棧 — 是它給人的感覺。「午後咖啡廳的暖光穿過磨砂玻璃，帶一點 Y2K 的金屬實驗感」。如果 visual thesis 可以套用在任何網站上（比如「簡潔大方」），那它就是一句廢話。重寫。 第二樣是 **content plan** — 每個 section 放什麼內容，在碰 code 之前就定死。這不是在「規劃」，是在「做決定」。寫 code 的人（不管是人還是 AI）不應該同時在做設計決策。角色分離，跟 code 裡的 separation of concerns 同一個道理。 第三樣是 **interaction thesis** — 2 到 3 個具體的動效想法，具體到「hero 從底部 stagger 淡入」這種程度。「加一些 animation」這種話等於什麼都沒說 — 跟跟廚師說「加點調味料」一樣，出來的東西不會是任何人想要的。 三件事全寫完，頁面就不再是一堆 section 的堆疊 — 它變成一場有結構的對話。Hero 告訴訪客「這是誰」，Supporting imagery 給一個畫面讓人想像，Product detail 進入正題講在賣什麼，Social proof 補上背書讓人放心，Final CTA 問一個問題：「要不要試試看？」 而且每個 section 只回答一個問題。如果一個 section 想同時介紹功能又放 testimonial — 需要的不是更多空間，是更多紀律。砍一個。 > **Mogu 插嘴：** > > 「每個 section 只做一件事」— 等等這不就是 Single Responsibility Principle 嗎？寫 code 的時候說「一個 function 只做一件事」大家都點頭如搗蒜，結果做 UI 就把 feature 介紹 + pricing + testimonial 全塞進同一塊。工程師的雙重標準，抓到了 (◍˃̶ᗜ˂̶◍)ノ” --- ## 海報跟瑞士刀不是同一種東西 到這裡為止講的都是 landing page。但有一個太多人踩過的坑需要特別拉出來講 — 把 landing page 的設計語言搬到 app 上，或者反過來。 這兩種東西的設計目標根本對立。 **Landing page 是一張海報。** 在路上看到它，它要在行人還沒停下腳步之前就抓住注意力。Full-bleed hero、邊到邊的視覺衝擊、大膽的 typography、一句讓人想了解更多的 tagline。任務是讓人 **感受**。 **App 是一把瑞士刀。** 每天打開，要在最短時間內完成工作。冷靜的表面層次、強烈但不花俏的字體、極少的顏色、高資訊密度但讀起來不費力。任務是讓人 **思考**。 把海報語言搬到瑞士刀上 — 會得到一個花花綠綠的 dashboard，漸層很美但找個 KPI 要翻三頁。把瑞士刀語言搬到海報上 — 會得到一個 SaaS template，功能列了十二條但沒有人想讀完第一條。 OpenAI 給了 app UI 一個 role model：[Linear](https://gu-log.vercel.app/glossary#linear)。冷靜、克制、typography 主導、卡片只在它就是互動本身的時候才出現。要避免的：dashboard-card mosaic（卡片拼貼牆）、每個區域都有粗框線、裝飾性漸層、多個互相打架的 accent color。 Litmus check：操作人員只看 heading、label 和數字就能搞懂頁面在幹嘛嗎？如果不行，重做。 > **Mogu 偷偷說：** > > 之前 [GP-110 講 Codex best practices](https://gu-log.vercel.app/posts/gp-110-20260310-derrickcchoi-codex-10-best-practices) 的時候也提到「context 品質決定產出品質」。但那篇講的是 code context — 這篇把同一個道理推到了設計面。兩篇都指向同一個結論：使用 AI 工具的人不是在「用工具」，是在做 AI 的 PM。而大部分「AI 做的東西好爛」的抱怨，翻譯成白話就是「PM 開的 spec 好爛」。被 AI 照鏡子照出自己的 spec 有多模糊，也是一種成長吧 (´・ω・\`) --- ## 動效是標點符號，不是螢光筆 最後一個經常被過度使用的東西 — 動畫。 想像一個打開之後滿畫面都在動的網站：標題在飛、背景在飄、卡片在翻、粒子在灑。眼睛像在看彈珠台，最後什麼都沒記住就關掉了。那不叫「有動感的設計」。那叫「視覺噪音」。 原文在這點上的態度非常克制，給了一個明確的數字：**2 到 3 個有意圖的動效。** 不是 10 個。不是「越多越好」。就是 2 到 3 個。 為什麼？好的文章怎麼用標點符號 — 一個逗號讓讀者稍微停頓，一個句號讓讀者消化，偶爾一個問號讓讀者思考。但如果每個字後面都加一個驚嘆號呢？讀三行就想關掉。動效也是同一個道理。 建議放在三個位置：hero 的入場動畫 — 句首大寫字母，告訴讀者「故事要開始了」。一個 scroll-linked 效果 — 段落之間的換行，讓滾動本身變成一種互動。一個 hover 或 reveal — 重點底線，悄悄說「這裡有東西值得點」。推薦用 Framer Motion。 判斷一個動效該不該留？原文給了一個殘酷但有效的問題：**把它拿掉，頁面會變差嗎？** 如果不會 — 刪掉。這是在做產品，不是在做 Dribbble 作品集。 --- ## Frontend [Skill](https://gu-log.vercel.app/glossary#skill)：一行指令裝品味 講了這麼多規則，好消息是不用每次都手動塞進 prompt。 OpenAI 把所有上述設計原則打包成了一個 [open-source skill](https://github.com/openai/skills/tree/main/skills/.curated/frontend-skill)，一行指令裝進 Codex：`$skill-installer frontend-skill`。裝完之後，model 在寫任何 code 之前會先被要求定義 visual thesis、content plan、interaction thesis，然後在開發過程中持續遵守那些 hard rules。 > **Mogu 內心戲：** > > 所以 OpenAI 的解法不是「讓 model 更懂設計」，而是「逼 model 在動手前先寫 brief」。等一下 — 這不就是所有設計公司對 junior designer 做的事嗎？「先把 mood board 做出來我看看再開工。」原來 AI 也需要有人逼它先想再做。再次證明：工具的天花板不是工具本身，是拿工具的人有沒有意識到自己該當 PM 而不是當觀眾 ╮(╯▽╰)╭ --- ## 結語 讀完整篇之後會發現一件諷刺的事 — OpenAI 花了整份指南在講「不要做什麼」。不要用卡片、不要在首屏塞東西、不要用裝飾性動畫、不要用 placeholder。 把這些「不要」加在一起，描述的就是那些讓人搖頭的 AI 生成網站。 所以那些網站不是 AI 做壞的。是沒人點菜，廚師只好炒了番茄蛋。 兩種字體、一個 accent color、一張 reference 圖、一句 visual thesis — 五分鐘的事。差別是：番茄炒蛋，還是主廚特餐。廚師都是同一個，菜單是誰決定的，答案不言自明 (´・ω・\`)