用 Codex 做設計：從「網站太醜」到可驗收的品味控制

重啟 RonnieCC 的設計，不是從一套設計理念開始的。

對話框裡，我只打了四個字：

網站太醜了。

這句話不是情緒出口，而是一次必要的設計中斷。當時 Codex 已經把一個個人網站做成了看起來合理的靜態頁：有 hero、有 app 卡片、有一些看似完整的產品入口。但它的問題也很明顯：像臨時 demo，像模板，像一個把資料塞進頁面的交付物，而不是一個能代表我的個人索引。

這篇文章不是想寫我相信什麼設計理念。那種話太容易變成結果論，也不容易被別人學走。我真正想記錄的是另一件事：和 Codex 做設計時，品味不是靠「請你做得高級一點」控制的，而是靠一連串具體到可以執行、可以檢查、可以寫進文檔的指令控制的。

最後 RonnieCC 變成現在這個樣子，不是因為 Codex 第一次就理解了我的審美，而是因為每次它偏離，我都必須把「不對」拆成下一條更準確的指令。

這張首頁圖展示的不是結果有多好看，而是這篇文章的終點：一個由 typography、留白和克制的結構建立出來的個人網站，而不是 app catalog 或 marketing hero。

先砍掉不該展示的東西

第一輪調整並不是改字體，也不是改顏色，而是改內容邊界。

我很快發現，Codex 的自然傾向是「把找到的資料都放上去」。這在工程上看起來勤奮，在設計上卻是災難。個人網站不是資料庫，也不是所有歷史 app 的陳列架。於是我給了第一個內容控制指令：

你應該訪問 ARC 瀏覽器，把依然還在上架的 app 才顯示出來，那些下架的 app 就刪除了。

這句話其實定義了一個很重要的設計規則：可展示，不等於應該展示。

如果 Codex 把網站理解成「資料整理任務」，它會傾向於補全；但如果我把它重新定義成「公開索引」，它才會開始判斷哪些內容應該留在頁面裡。這也是後面 RonnieCC 能變乾淨的第一步：不是先美化，而是先刪除不該出現的東西。

這個階段我學到的一點是，和 Codex 做設計，不能只審查畫面，也要審查它背後的內容選擇。很多「醜」不是 CSS 問題，而是內容沒有經過取捨。

刪掉不該展示的內容之後，下一個問題才真正浮出來：留下來的內容應該如何被組織。這一步從「誰可以上場」轉向「整個隊形怎麼站」，也就是資訊架構。

從 Domain 改成 Project ecosystem

接著出問題的是資訊模型。

Codex 一開始按資料來源和能力分類來組織內容，這看起來合理，但不符合 RonnieCC 的真實結構。我先說：

它應該以 Domain 的形式去組織，因為很多項目事實上是一個小型生態圈。

但很快我又修正了自己：

Domain 設計不好，雖然叫 Domain，但是它應該是 Projects 的形式。例如 Syncnext 就是一堆生態圈的，有 API / Plugin / main-app。

這個修正比任何視覺調整都重要。因為 Syncnext 不是一個 app 卡片，它是一個 project ecosystem。它有 main app，有 API，有 plugin，有外部工具，有支援系統。如果把它壓成一張 app card，畫面再精緻也錯。

所以 RonnieCC 的設計不是從「我要什麼版式」開始，而是從「什麼是這個網站的基本單位」開始。後來網站的導航也因此被收斂成三個入口：

index、Projects、Resume。

Index 展示現在的 project 和探索；Projects 承載完整分類；Resume 對應 Google Drive 的履歷文件。這一刻，Codex 不再能自由發明網站結構，它被限制在一個清楚的信息架構裡。

這張 Projects 圖的作用不是展示「項目頁很好看」，而是證明 project ecosystem 這個模型如何落到畫面：編號、幾何標記、項目名稱、summary、tags 都在服務同一件事，讓讀者按系統理解項目，而不是按 app icon 掃列表。

參考不是拿來照抄，而是拆成責任

真正的視覺轉折，是從 Kami 開始的。

我先告訴 Codex：

在視覺上，我喜歡 https://github.com/tw93/kami 這個項目提供的方法論，我感覺它值得被轉化成前端辦法。

第一次說 Kami，只是把方向從普通 portfolio 拉向一種更克制的設計方法。但這還不夠，因為 Codex 很容易只吸收一點表面語氣，然後繼續用自己的模板邏輯完成頁面。所以我又推進了一句：

我認為可以把 kami 提供的方法論執行得極致一些。

這句話的目的不是讓畫面更裝飾，而是讓 Codex 不要只借一點顏色或氛圍。既然要用 Kami，就要讓它成為設計行為的約束，而不是一個「風格參考」。

但只給一個參考仍然不夠。Codex 很容易把「參考」理解成「復刻外觀」。所以我又提供了另一個舊材料：5mlstudio。這是一個我以前的對外宣傳品牌。它可以作為品質參考，但不是要 Codex 把 RonnieCC 做成 5mlstudio 的復刻。

這裡最有效的一句提示詞，是後來這句：

使用 kami 提供的色彩 token。5mlstudio 提供的排版佈局。再重新做一次 index 看看是否一個正確的設計前進方向。

這句話是整個設計過程裡最值得學走的指令之一。它沒有說「參考 Kami」或「參考 5mlstudio」，而是把兩個參考拆成不同責任：Kami 只負責色彩 token，5mlstudio 只負責排版佈局。

這樣做之後，Codex 的搜索空間立刻變小。它不需要猜「我要哪種風格」，也不能把兩個參考混成拼貼。它只需要遵守兩條邊界：顏色從 Kami 來，空間從 5mlstudio 的排版品質來。

這就是用 Codex 做設計時最關鍵的操作：不要給它一個完整參考，給它拆分後的責任。

這張 Selected focus 圖不是功能介紹，而是三個被壓縮後的設計判斷：systems, not demos；AI with operating discipline；interface as judgement。畫面本身也在證明同一件事：幾何圖形只是結構標記，真正的品質來自文字、留白和比例。

失敗的 index 和幼稚的字體

在設計過程中，有一個版本徹底失敗。

我當時的反饋很重：

我覺得現在的 index 是一個完全失敗和錯誤的方法，我不清楚你是用什麼東西在支撐這些設計模式。你現在輸出的樣式，看起來就是一個 17 歲的小朋友，剛學會做網站，然後喜歡用這種幼稚的字體。

現在回看，這句話之所以有用，不在於情緒，而在於它內含兩個精確判斷。

第一，它否定的是「方法」，不是單個樣式。也就是說，問題不是某個字號太大、某個 padding 不對，而是 Codex 支撐設計的模式錯了。

第二，它指出了錯誤語氣：幼稚。這比「不好看」更有用。不好看太寬，幼稚則能讓 Codex 重新理解字體、裝飾、版式和整體氣質都在錯誤方向上。

後來字體被切到 Montserrat，我甚至一開始指定了 Thin 100。這個選擇不是為了追求「細」，而是為了把網站從 app showcase 的普通 UI 語氣，推向 typography-led 的個人索引。

接著我把 typography 的要求說得更具體：

網站應該重視強烈的 Typography 能力，透過妥善的 Typography 去表達內容。

以及：

高質量的 Typography，大留白，重視空氣感，關心行距，字距，才是 Typography 排版的核心。

這種指令比「做得高級」有效太多。因為它把品味拆成了可檢查的物理屬性：留白、空氣感、行距、字距。Codex 不需要猜什麼叫高級，它只需要把畫面調到這些屬性成立。

色彩不能背叛 typography

設計方向看起來穩定後，第一個問題是舊規則的殘留。

我問 Codex：

為何還有 var(--brand) 這種 5ml studio 留下的淡藍色呢？不是說好了用 kami 提供的色彩 token 嗎？

這是一個很典型的 AI 協作問題：它表面上接受了規則，但實作時仍然把舊 token、舊習慣或舊文件裡的殘留帶回來。

所以設計規則不能只說一次。你必須在畫面裡抓出違規點，告訴它這裡違反了哪條已經建立的約束。

比忘記規則更麻煩的，是在新情境裡誤用規則。dark mode 就是這樣的測試：不是把 light mode 的 token 反過來就完成了，也不是換一個更亮的 accent 就會更清楚。

我看見高亮色之後，指出：

亮藍色會引入明度不如核心字體的感覺，這會和 Typography 概念發生嚴重的衝突。

這句話背後的判斷是：色彩不是獨立裝飾，它必須服從文字層級。如果 highlight 的明度低於核心文字，它就不是 highlight，而是在破壞 typography 的秩序。

我又補了一句：

你應該透過瀏覽器的屏幕查看去理解問題。你的核心問題是，你標記的高亮色是存在明度不如其他字體。

這裡的重點是「屏幕查看」。很多時候 Codex 會用 CSS 值推理設計，但設計最後是視覺結果，不是 token 表格。dark mode 的對比度問題，必須在瀏覽器裡看見，不能只在代碼裡相信。

這張 dark mode 圖要證明的是：dark mode 不是把背景變黑，也不是加一個亮藍色 accent，而是讓所有顏色都服從 typography 層級。高亮可以存在，但不能比正文更弱，也不能搶走主句的權重。

規則成立後，才擴展到其他頁

當 index 的基礎設計終於可信後，我沒有讓 Codex 重新自由設計其他頁，而是下了另一句關鍵指令：

以相同的設計規則，去重建其他頁面。

這句話看起來普通，但它控制了後續所有頁面的品質。它的意思是：不要每個頁面重新發明風格；先在 index 驗證規則，再把規則擴展到 Projects、Detail、Resume 和 Blog。

這句指令也需要配一個驗收清單，否則很容易變成口號：

檢查其他頁面是否真的沿用 index 的設計規則：
1. 色彩 token 是否一致，沒有冒出新的品牌色或舊 token？
2. 字體層級、行距、留白是否沿用同一套 typography 節奏？
3. 是否出現 index 沒有使用過的大卡片牆、app grid 或 marketing hero 結構？

這樣 Codex 才不是「做另一個頁面」，而是在同一套已經驗證過的設計語法裡擴展內容。

接下來的調整看起來分散，其實都是同一套規則落到不同層級：符號、互動、語氣和閱讀節奏。

Project 頁需要不同的 SVG 幾何圖形作為配合，而不是統一模板圖形。這不是要插圖更豐富，而是避免 Codex 用一套模板符號假裝所有 project 都有同樣結構。

這裡其實也有一條可以直接拿走的設計指令：

為每個 project 設計不同的抽象幾何 SVG 標記。它們只能作為結構符號，不要做成 app icon、功能圖示或插畫；每個符號最好只用 2-3 個幾何動作，並且要反映這個 project 的性質，不能套用同一個模板。

這句話的價值在於，它同時限制了三件事：用途、複雜度和差異來源。用途是結構符號，不是裝飾插圖；複雜度被壓在 2-3 個幾何動作；差異必須來自 project 本身，而不是 AI 自己發明一組看起來很忙的圖案。這種 prompt 能立刻把 AI 從「畫幾個好看的 SVG」拉回「用符號幫資訊架構分層」。

互動識別也要服務 typography。我要求：

可交互按鈕和連結的話，使用下劃線標識，否則現在的 typography 缺乏可交互識別。

但規則必須有作用域，所以很快又補上一句：

site-header 下的 a 連結不應該追加下劃線，因為它們不是 typography 空間。

下劃線在正文和 typographic content 裡能提高可交互識別，但在 header nav 裡會破壞導航本身的結構。好的 prompt 不只定義規則，也定義規則的作用域。

文案也一樣。我看到 project 文案裡出現一種「證明 XXX」的僵硬句式，於是說：

重建所有 project 的文案，他們現在看起來的感覺我說不清楚，但是證明 XXX 的口吻太奇怪了。我想要的口吻是具備工程師和設計師的感覺。

這句話不是文案偏好，而是聲音控制。RonnieCC 不是 investor pitch，也不是作品集模板。它需要一種工程師和設計師都能成立的語氣：有判斷，但不表演；有技術密度，但不炫技。

這種文案調整也可以用 before/after 驗收：

Before：證明 Syncnext 是一個完整的生態系統。
After：Syncnext 包含 API、plugin 與 main app，三者構成一個可擴展的開發者工具鏈。

前者像在替產品辯護，後者直接說出系統構成。這就是我想要 Codex 學會的差別：少一點宣稱，多一點結構事實。

Blog list 的調整也延續同一套規則。Year 作為左上角分組標題，blog-items 左對齊，單列佈局，tags 降低對比度，再降低 blog-title 字號。這些指令都在服務同一個目標：讓閱讀節奏清楚，讓 metadata 不搶正文。

這張圖作為「規則擴展」的收束：Read the work by structure, not by release order. 這句話本身就是整個網站後半段設計的總結：不是按時間堆發布物，而是按結構建立閱讀路徑。

最後，把判斷寫進文檔

設計穩定後，我還要求：

更新舊的設計文檔，避免被文檔誤導。

這是和 Codex 長期協作時很容易被忽略的一步。

如果設計判斷只停留在對話裡，下一次 Codex 讀 repo 時，仍然可能被舊文檔、舊 token、舊頁面結構帶偏。於是 RonnieCC 後來有了公開 repo 裡的 docs/visual-direction.md，把幾件事明確寫下來：Kami 提供色彩 token，5mlstudio 提供排版方法，Typography 是主要表達；禁止背景網格，禁止大卡片牆，禁止 App Store 式 app grid，禁止把 Kami 當外觀模板照搬，也禁止把 5mlstudio 當 RonnieCC 復刻目標。

這份文檔的作用不是給人看的品牌手冊，而是給下一輪 Codex 的約束。它讓「品味」從聊天裡的感覺，變成 repo 裡的 contract。

可以學走的，不是審美，而是控制方式

回頭看這段流程，最有用的不是某個 CSS token，也不是 Montserrat 或 dark mode。真正可以學走的是一套控制方式。

當 Codex 做錯時，不要只說「不好看」。要指出錯誤模式：這像臨時 demo、像 app grid、像幼稚字體、像模板符號。

當你提供參考時，不要讓它照抄。要拆成責任：這個參考只管色彩，那個參考只管排版，另一個元素只吸收局部。

當你談 typography 時，不要說「高級」。要說留白、空氣感、行距、字距、明度、層級。

當規則有效時，不要讓它停留在一頁。要明確說：以相同設計規則重建其他頁面。

當規則穩定時，不要只留在聊天裡。要更新文檔，避免下一輪被舊方向誤導。

這就是我從 RonnieCC 這次設計合作裡得到的經驗：Codex 不會自動理解品味，但它可以執行邊界。好的設計協作，不是把審美交給 AI，而是把審美拆成它無法誤解太遠的指令。