重啟 RonnieCC 的設計，不是從一套設計理念開始的。
對話框裡，我只打了四個字：
網站太醜了。
這句話不是情緒出口，而是一次必要的設計中斷。當時 Codex 已經把一個個人網站做成了看起來合理的靜態頁：有 hero、有 app 卡片、有一些看似完整的產品入口。但它的問題也很明顯：像臨時 demo，像模板，像一個把資料塞進頁面的交付物，而不是一個能代表我的個人索引。
這篇文章不是想寫我相信什麼設計理念。那種話太容易變成結果論，也不容易被別人學走。我真正想記錄的是另一件事：和 Codex 做設計時，品味不是靠「請你做得高級一點」控制的，而是靠一連串具體到可以執行、可以檢查、可以寫進文檔的指令控制的。
最後 RonnieCC 變成現在這個樣子，不是因為 Codex 第一次就理解了我的審美，而是因為每次它偏離，我都必須把「不對」拆成下一條更準確的指令。
這張首頁圖展示的不是結果有多好看，而是這篇文章的終點：一個由 typography、留白和克制的結構建立出來的個人網站，而不是 app catalog 或 marketing hero。
第一輪調整並不是改字體，也不是改顏色，而是改內容邊界。
我很快發現，Codex 的自然傾向是「把找到的資料都放上去」。這在工程上看起來勤奮，在設計上卻是災難。個人網站不是資料庫，也不是所有歷史 app 的陳列架。於是我給了第一個內容控制指令：
你應該訪問 ARC 瀏覽器，把依然還在上架的 app 才顯示出來，那些下架的 app 就刪除了。
這句話其實定義了一個很重要的設計規則：可展示，不等於應該展示。
如果 Codex 把網站理解成「資料整理任務」，它會傾向於補全；但如果我把它重新定義成「公開索引」，它才會開始判斷哪些內容應該留在頁面裡。這也是後面 RonnieCC 能變乾淨的第一步：不是先美化，而是先刪除不該出現的東西。
這個階段我學到的一點是，和 Codex 做設計，不能只審查畫面，也要審查它背後的內容選擇。很多「醜」不是 CSS 問題，而是內容沒有經過取捨。
刪掉不該展示的內容之後，下一個問題才真正浮出來：留下來的內容應該如何被組織。這一步從「誰可以上場」轉向「整個隊形怎麼站」，也就是資訊架構。
接著出問題的是資訊模型。
Codex 一開始按資料來源和能力分類來組織內容，這看起來合理，但不符合 RonnieCC 的真實結構。我先說：
它應該以 Domain 的形式去組織，因為很多項目事實上是一個小型生態圈。